From nobody Tue Mar 1 13:20:17 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980E41B2F7E; Tue, 1 Mar 2016 13:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmxH6BRy1rXZ; Tue, 1 Mar 2016 13:20:14 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E0A1B41D3; Tue, 1 Mar 2016 13:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2504; q=dns/txt; s=iport; t=1456867212; x=1458076812; h=from:to:subject:date:message-id:mime-version; bh=i5VNnjTjHGAXoo9NXbFdt7hsmIVNRC2Uugn39gsnOFI=; b=mienrSclc7nGhP4jSe0krwzRUIT+W9Y/DdcEAWoS1y5tNKGAyIe/xqtH mTP+ONx7JEPxo6mMKeox/rhJ/31DV237IAOWhAHyJfeZ6NfJsObjJixXW zOVIgGcB21cF0Czy3A/OYVhsT4Q8ufUbH/99oyCtbf2bwnpGvDrKqkqRq 8=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAwAyBtZW/5BdJa1cgzpSbQEFui0Og?= =?us-ascii?q?WYhgjyDNoFQOBQBAQEBAQEBZCeESIELARxkJwQBIIgRDr4fAQEBAQEBBAEBAQE?= =?us-ascii?q?BAQERCId+gk6EVYMLgQ8FknWEGQGBGoFugWRsiAmBYEuDeYhSjksBHgFDg2Rrh?= =?us-ascii?q?0IBfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,524,1449532800"; d="asc'?scan'208";a="76642620" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Mar 2016 21:20:11 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u21LKBoP023356 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Mar 2016 21:20:11 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 1 Mar 2016 15:20:10 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Tue, 1 Mar 2016 15:20:10 -0600 From: "Matt Miller (mamille2)" To: "draft-ietf-avtext-splicing-notification.all@ietf.org" , The IESG , "gen-art@ietf.org" , "secdir@ietf.org" Thread-Topic: Review of draft-ietf-avtext-splicing-notificaiton-04 Thread-Index: AQHRdAAjr6g+Q/FgyEGL9pH6QLQVnw== Date: Tue, 1 Mar 2016 21:20:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.6b2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.101.72.38] Content-Type: multipart/signed; boundary="Apple-Mail=_6C0E9EC5-725C-4B87-9ED5-389D50623BCE"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Subject: [secdir] Review of draft-ietf-avtext-splicing-notificaiton-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 21:20:15 -0000 --Apple-Mail=_6C0E9EC5-725C-4B87-9ED5-389D50623BCE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am the coincidentally-assigned Gen-ART and SecDir reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. The Security Directorate reviews all IETF documents being processed by the IESG for the security area directors. Please treat these comments just like any other last call comments that arrived on time. For more information on Gen-Art, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq >. Document: draft-ietf-avtext-splicing-notification-04 Reviewer: Matthew Miller Review Date: 2016-02-26 IETF LC End Date: 2016-02-26 IESG Telechat date: N/A Summary: Ready with a minor issue. Major issues: Minor issues: * I didn't see any discussion of the case where the RTP extension and = the RTCP message don't agree on the interval. Well-behaved software = shouldn't do this, but it seems like something that could happen. I'm = not sure what should be done in this case, but it seems to me like = something to at least acknowledge it. Nits/editorial comments: * idnits is reporting a bad reference to "3711" Section 7 "Security = Considerations", and that RFC 3711 is an unused normative reference. I = think this is because the pointer to it in Section 7 doesn't start with = "RFC". * In Section 1. "Introduction", it seems to me "However" would be a = better word than "Nevertheless" to use here. -- - m&m Matt Miller Cisco Systems, Inc. --Apple-Mail=_6C0E9EC5-725C-4B87-9ED5-389D50623BCE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJW1geOAAoJEDWi+S0W7cO1Aq8H/0LvgBiX4m9g4+kCRympTx4t ge/w8k9m6Ftuq563+cEwNhGl1zwqEWN6iwEkDQNMwGcgKHYpGtaSr+RGucujZfTU dUWdQPzLh4ke3IHmISaL4hTJc5UO5ml+9e4+xDsBumL9ku1402fiL2X9TWt+Qev2 DuG1q+78CjgLOx7bl4EVULU7vvTxAiAQP5Z71DqbzfLp8cEaCAfZB0FxntG1oWnI Sz3RQBdqolISNc7Qy1qxY+WGd8C31rsxMqgswSt6sbVeczkRutPVZJi3BGZ3Z0Zt c/hMFJ8f157ZnVW+qYBi8kthf+uFedwUCdlfasy4znaLlgqvV8z+nMw+ZMnzZpI= =7co+ -----END PGP SIGNATURE----- --Apple-Mail=_6C0E9EC5-725C-4B87-9ED5-389D50623BCE-- From nobody Tue Mar 1 18:23:54 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490251B44E7; Tue, 1 Mar 2016 18:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFtEa3LVi2wX; Tue, 1 Mar 2016 18:23:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D661B44E2; Tue, 1 Mar 2016 18:23:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFE99388; Wed, 02 Mar 2016 02:23:47 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Mar 2016 02:23:46 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.35]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Wed, 2 Mar 2016 10:23:41 +0800 From: "Huangyihong (Rachel)" To: "Matt Miller (mamille2)" , "draft-ietf-avtext-splicing-notification.all@ietf.org" , The IESG , "gen-art@ietf.org" , "secdir@ietf.org" Thread-Topic: Review of draft-ietf-avtext-splicing-notificaiton-04 Thread-Index: AQHRdAAjr6g+Q/FgyEGL9pH6QLQVn59FYJKg Date: Wed, 2 Mar 2016 02:23:40 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E8C0B1@nkgeml513-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.56D64EB4.0083, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.35, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e5d5a7c46660ff78856ea663d1375354 Archived-At: Subject: Re: [secdir] Review of draft-ietf-avtext-splicing-notificaiton-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 02:23:53 -0000 Hi Matt, Please see my replies inline. BR, Rachel > -----Original Message----- > From: Matt Miller (mamille2) [mailto:mamille2@cisco.com] > Sent: Wednesday, March 02, 2016 5:20 AM > To: draft-ietf-avtext-splicing-notification.all@ietf.org; The IESG; > gen-art@ietf.org; secdir@ietf.org > Subject: Review of draft-ietf-avtext-splicing-notificaiton-04 >=20 > I am the coincidentally-assigned Gen-ART and SecDir reviewer for this dra= ft. > The General Area Review Team (Gen-ART) reviews all IETF documents being > processed by the IESG for the IETF Chair. The Security Directorate revie= ws all > IETF documents being processed by the IESG for the security area director= s. > Please treat these comments just like any other last call comments that a= rrived > on time. >=20 > For more information on Gen-Art, please see the FAQ at >=20 > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq >. >=20 > Document: draft-ietf-avtext-splicing-notification-04 > Reviewer: Matthew Miller > Review Date: 2016-02-26 > IETF LC End Date: 2016-02-26 > IESG Telechat date: N/A >=20 > Summary: >=20 > Ready with a minor issue. >=20 > Major issues: >=20 > Minor issues: >=20 > * I didn't see any discussion of the case where the RTP extension and the= RTCP > message don't agree on the interval. Well-behaved software shouldn't do = this, > but it seems like something that could happen. I'm not sure what should = be > done in this case, but it seems to me like something to at least acknowle= dge it. [Rachel]: Good question. Since RTCP message and RTP extension packets are a= ll from the same main RTP sender, it's the sender's duty to keep them conta= in the same interval information. So I don't see any chance that inconsiste= nt intervals appear. But, I do think it's worth to mention it in the draft.= How about adding a sentence in first paragraph, Section 3.2, like this "The main RTP sender MUST make sure the splicing information contained in t= he RTCP splicing notification message consistent with the information inclu= ded in the RTP header extensions. " So what do you think? >=20 > Nits/editorial comments: >=20 > * idnits is reporting a bad reference to "3711" Section 7 "Security > Considerations", and that RFC 3711 is an unused normative reference. I t= hink > this is because the pointer to it in Section 7 doesn't start with "RFC". [Rachel]: Right. Will fix it. >=20 > * In Section 1. "Introduction", it seems to me "However" would be a bette= r > word than "Nevertheless" to use here. [Rachel]: All right. >=20 >=20 > -- > - m&m >=20 > Matt Miller > Cisco Systems, Inc. From nobody Wed Mar 2 09:41:48 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CDA1B2F51; Wed, 2 Mar 2016 09:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFn-QOWqaHI8; Wed, 2 Mar 2016 09:41:43 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id E27A91B2F43; Wed, 2 Mar 2016 09:41:42 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BBEDE3F4013; Wed, 2 Mar 2016 17:41:41 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id A5BDB3F4012; Wed, 2 Mar 2016 17:41:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1456940501; bh=TTwSwOGJ+B6mCxDDLt86u/lCMsNPa1OO2Smbgwp4mJ0=; l=904; h=From:To:Date:From; b=s4nxG7ch4bto8V1Pq+kV72BYJJ2dlbBSoXE4MROqsiAltaAWli9JdiAWJYMqHT1Ai toAFaiP3TJek2O14bitt8CylO7aKciQ/YzcSHEtk6lTA60kNZ/mXPv+tBdVnLVNTwq igHKU9iNvYWx/tzuGJo4y7QaHOtiugK2cV8Sdq7Y= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id A2D751FC88; Wed, 2 Mar 2016 17:41:41 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 2 Mar 2016 12:41:41 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Wed, 2 Mar 2016 12:41:41 -0500 From: "Salz, Rich" To: "'iesg@ietf.org'" , "'secdir@ietf.org'" , "draft-vinay-tictoc-ptp-mib.all@tools.ietf.org" Thread-Topic: secdir review of draft-binay-tictoc-ptp-mib Thread-Index: AdF0qjnK4/zyJuQBQOuVwbdY1gkHkg== Date: Wed, 2 Mar 2016 17:41:40 +0000 Message-ID: <9b6fb08db3b1430da5f218033a4a5265@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [secdir] secdir review of draft-binay-tictoc-ptp-mib X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 17:41:44 -0000 I have reviewed this document as part of the security directorate's ongoin= g effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the securit= y area directors. Document editors and WG chairs should treat these comme= nts just like any other last call comments. Summary: ready with nits. This is a read-only MIB. I didn't realize that until the end. PLEASE put = that in the abstract. Perhaps replace "objects for managing networks" to "= objects for monitoring networks" Also the abstract talks about SNMPv2 and v1. Why are those mentioned? And= why called out in the abstract as important? Perhaps add "For backward co= mpatibility," at the start of that last sentence. The security considerations sections seem fine. -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Wed Mar 2 15:45:30 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE291B3532; Wed, 2 Mar 2016 15:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cQ_yJjLYHqm; Wed, 2 Mar 2016 15:45:27 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4547F1B352D; Wed, 2 Mar 2016 15:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4085; q=dns/txt; s=iport; t=1456962327; x=1458171927; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=np4FjdAVtOocHIivJe/ptim0Bwxm6hh3AtVTDB7AEqM=; b=amMQujR5ch+0XrVoVO1tBiXS4wX1PE+pRP1Qh63vfc16ZSO+WQ/xhd0c 2BrXZaQz94/KTQFm98MT57Xx352bq8f6Xzd0Wy41WWVPIxwDnQSdNKmPA 38QYGGi6B/O9yYqyJwd3FjsyIJZ0KuhpXnt4zmK5xRPU7gEzJIA/7kM4T w=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AgB4etdW/5xdJa1egzpSbQa6IA6BZ?= =?us-ascii?q?yGCPIMyAoE/OBQBAQEBAQEBZCeEQQEBAQMBeQUHBAIBCBEDAQEBAScHMhQJCAI?= =?us-ascii?q?EDgUOiAsIDrwLAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiHfgiCRoRVgwuBDwWXE?= =?us-ascii?q?gGDCIFlbIgJgWBLg3mIUo5LAR4BQ4IDGYFIagGHYQF9AQEB?= X-IronPort-AV: E=Sophos;i="5.22,531,1449532800"; d="asc'?scan'208";a="77096633" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2016 23:45:26 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u22NjQOJ020213 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Mar 2016 23:45:26 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Mar 2016 17:45:25 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Wed, 2 Mar 2016 17:45:25 -0600 From: "Matt Miller (mamille2)" To: "Huangyihong (Rachel)" Thread-Topic: Review of draft-ietf-avtext-splicing-notificaiton-04 Thread-Index: AQHRdAAjUcpCdJ8p/ky1dczIPS+kNp9F0aYAgAFmJYA= Date: Wed, 2 Mar 2016 23:45:25 +0000 Message-ID: <00495258-9ED3-4F20-BB02-52BC63CCD525@cisco.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E8C0B1@nkgeml513-mbs.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86E8C0B1@nkgeml513-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.6b2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.101.72.38] Content-Type: multipart/signed; boundary="Apple-Mail=_2B24DA63-7FF7-4027-B363-AF90C94B2047"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: "gen-art@ietf.org" , "draft-ietf-avtext-splicing-notification.all@ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-avtext-splicing-notificaiton-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 23:45:29 -0000 --Apple-Mail=_2B24DA63-7FF7-4027-B363-AF90C94B2047 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for responding, Rachel. I think your proposed text is good. I'm not sure what more can be said = or done, but this at least acknowledges it. -- - m&m Matt Miller Cisco Systems, Inc. > On Mar 1, 2016, at 19:23, Huangyihong (Rachel) = wrote: >=20 > Hi Matt, >=20 > Please see my replies inline. >=20 > BR, > Rachel >=20 >=20 >> -----Original Message----- >> From: Matt Miller (mamille2) [mailto:mamille2@cisco.com] >> Sent: Wednesday, March 02, 2016 5:20 AM >> To: draft-ietf-avtext-splicing-notification.all@ietf.org; The IESG; >> gen-art@ietf.org; secdir@ietf.org >> Subject: Review of draft-ietf-avtext-splicing-notificaiton-04 >>=20 >> I am the coincidentally-assigned Gen-ART and SecDir reviewer for this = draft. >> The General Area Review Team (Gen-ART) reviews all IETF documents = being >> processed by the IESG for the IETF Chair. The Security Directorate = reviews all >> IETF documents being processed by the IESG for the security area = directors. >> Please treat these comments just like any other last call comments = that arrived >> on time. >>=20 >> For more information on Gen-Art, please see the FAQ at >>=20 >> < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq >. >>=20 >> Document: draft-ietf-avtext-splicing-notification-04 >> Reviewer: Matthew Miller >> Review Date: 2016-02-26 >> IETF LC End Date: 2016-02-26 >> IESG Telechat date: N/A >>=20 >> Summary: >>=20 >> Ready with a minor issue. >>=20 >> Major issues: >>=20 >> Minor issues: >>=20 >> * I didn't see any discussion of the case where the RTP extension and = the RTCP >> message don't agree on the interval. Well-behaved software shouldn't = do this, >> but it seems like something that could happen. I'm not sure what = should be >> done in this case, but it seems to me like something to at least = acknowledge it. >=20 > [Rachel]: Good question. Since RTCP message and RTP extension packets = are all from the same main RTP sender, it's the sender's duty to keep = them contain the same interval information. So I don't see any chance = that inconsistent intervals appear. But, I do think it's worth to = mention it in the draft. How about adding a sentence in first paragraph, = Section 3.2, like this > "The main RTP sender MUST make sure the splicing information contained = in the RTCP splicing notification message consistent with the = information included in the RTP header extensions. " > So what do you think? >=20 >>=20 >> Nits/editorial comments: >>=20 >> * idnits is reporting a bad reference to "3711" Section 7 "Security >> Considerations", and that RFC 3711 is an unused normative reference. = I think >> this is because the pointer to it in Section 7 doesn't start with = "RFC". >=20 > [Rachel]: Right. Will fix it. >>=20 >> * In Section 1. "Introduction", it seems to me "However" would be a = better >> word than "Nevertheless" to use here. >=20 > [Rachel]: All right. >=20 >>=20 >>=20 >> -- >> - m&m >>=20 >> Matt Miller >> Cisco Systems, Inc. --Apple-Mail=_2B24DA63-7FF7-4027-B363-AF90C94B2047 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJW13scAAoJEDWi+S0W7cO1Hp8H/0hIF5VwuWfQjLF997ySfX2Y bVK1/wxRpI6IVltCR4TP4gZC6gVXpDwHcyPnQ1/Tn0E8h5IgvJQ/KWRJa+4vz2Pl EGhnrAtIVmYlGZ2ObcUbclusV+31A0uPnDcqTR/5QOwRwUU9kgD41LeKwpgNecJN u5sAjqkLK/KR94AQi8+GDF9c+nleYhqeVikfD479vSJb1Ca5RnUUjykEfMosXDIo 5ikoz730JBtaxaQucuZMh4ioDDS2tENgjmhC8srdynRYurDwcxxaXtis4Rn2Fake HP3svwELet5E7eEdFRLIGIMJucD0+w+Mkb5iA/CQ7pG3jxCjO3MlOJ5axTCy2bg= =rUOh -----END PGP SIGNATURE----- --Apple-Mail=_2B24DA63-7FF7-4027-B363-AF90C94B2047-- From nobody Thu Mar 3 01:57:14 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F38F1B4036 for ; Thu, 3 Mar 2016 01:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLkQV8Ll1IGD for ; Thu, 3 Mar 2016 01:57:11 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18EC1B4033 for ; Thu, 3 Mar 2016 01:57:08 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u239v4OH006378 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 3 Mar 2016 11:57:04 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u239v4QJ024487; Thu, 3 Mar 2016 11:57:04 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22232.2672.232413.437723@fireball.acr.fi> Date: Thu, 3 Mar 2016 11:57:04 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 09:57:13 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview David Waltermire is next in the rotation. For telechat 2016-03-03 Reviewer LC end Draft Leif Johansson T 2016-02-10 draft-ietf-dprive-edns0-padding-02 Sandy Murphy T 2016-03-01 draft-ietf-ntp-checksum-trailer-05 For telechat 2016-03-17 Chris Inacio T 2016-02-02 draft-ietf-v6ops-ipv6-ehs-in-real-world-02 Benjamin Kaduk TR2016-02-09 draft-ietf-tsvwg-circuit-breaker-13 Hilarie Orman T 2016-03-09 draft-ietf-netmod-yang-json-08 Eric Osterweil T 2016-03-09 draft-ietf-netmod-yang-metadata-04 Radia Perlman T 2016-03-04 draft-ietf-p2psip-concepts-08 Vincent Roca T 2016-03-09 draft-ietf-rtcweb-audio-10 Joe Salowey T 2016-03-09 draft-ietf-rtcweb-audio-codecs-for-interop-05 Rifaat Shekh-Yusef T 2016-03-15 draft-ietf-aqm-docsis-pie-02 Takeshi Takahashi T 2016-03-16 draft-ietf-cdni-redirection-17 Tina TSOU T 2016-03-15 draft-ietf-dprive-dns-over-tls-07 Sean Turner T 2016-03-15 draft-ietf-netext-pmipv6-flowmob-17 Carl Wallace T 2016-03-30 draft-schoenw-opsawg-copspr-historic-03 Last calls and special requests: Donald Eastlake R2016-02-22 draft-ietf-dane-openpgpkey-07 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Jeffrey Hutzelman 2015-12-04 draft-ietf-core-block-18 Charlie Kaufman R2016-03-14 draft-ietf-i2rs-architecture-13 Alexey Melnikov 2016-03-07 draft-wallace-est-alt-challenge-04 Yoav Nir 2016-03-09 draft-bao-v6ops-rfc6145bis-05 Magnus Nystrom 2016-03-09 draft-ietf-avtcore-rtp-circuit-breakers-13 Eric Osterweil 2016-01-05 draft-campbell-art-rfc5727-update-02 Yaron Sheffer 2016-03-09 draft-ietf-v6ops-host-addr-availability-05 Robert Sparks 2016-03-14 draft-ietf-ccamp-otn-signal-type-subregistry-03 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-13 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-04 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-06 -- kivinen@iki.fi From nobody Thu Mar 3 08:47:38 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6D61A87EA; Thu, 3 Mar 2016 08:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJ6qq0RColpG; Thu, 3 Mar 2016 08:47:31 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2661A87E1; Thu, 3 Mar 2016 08:47:29 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 4470028B0041; Thu, 3 Mar 2016 11:47:28 -0500 (EST) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 3CDDA1F801E; Thu, 3 Mar 2016 11:47:28 -0500 (EST) From: Sandra Murphy X-Pgp-Agent: GPGMail 2.5.2 Content-Type: multipart/signed; boundary="Apple-Mail=_FDEEF1C7-7CB0-4270-9CCD-A792702A767C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 3 Mar 2016 11:47:27 -0500 Message-Id: <130DE753-A1AD-40AD-8C32-63F2AFE165D9@tislabs.com> To: secdir@ietf.org, draft-ietf-ntp-checksum-trailer@tools.ietf.org, The IETF Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [secdir] secdir review for draft-ietf-ntp-checksum-trailer-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 16:47:36 -0000 --Apple-Mail=_FDEEF1C7-7CB0-4270-9CCD-A792702A767C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document draft-ietf-ntp-checksum-trailer-04.txt defines a new extension header for NTP that will allow a hardware based timestamping engine to modify the timestamp in the NTP packet and then add a correction to the packet's UDP checksum to account for the modified timestamp. Putting the correction in an extension header allows for serial processing of the packet - no need to backtrack from the timestamp to the UDP checksum preceding in the packet and correct that field. I found the document adequate for the most part. (1) It seems there's an impossibility of protecting the NTP packet with this extension. This extension header MUST NOT be used with an NTP MAC, and so is usable only in those situations where NTP is used in an "unauthenticated mode". One might imagine that NTP running in an unauthenticated mode could be run in an ipsec tunnel for protection. However, the description of the timestamping engine makes it seem that the engine modifies the packet directly before transmission. I.e., the packet would be modified after the ipsec protections were applied. Certainly the "intermediate nodes" mentioned in 3.2.2 would be adding the extension header after the source applied the ipsec protection. If my suppositions are correct, then using this extension header means neither an authenticated NTP nor a protected tunnel could be used. All the intruder attacks mentioned in RFC5905 security considerations section would be possible. (2) RFC5905 and draft-ietf-ntp-extension-field-07.txt both define the general extension header format with the padding following the value. This draft defines this extension header as the value following the padding. That conflict should be addressed. (3) Section 1 describes intermediate entities (like the timestamping engine), and section 3.2.2 says: An intermediate node that receives and alters an NTP packet containing a Checksum Complement extension MAY use the Checksum Complement to maintain a correct UDP checksum value. However, section 4 says: The extension is intended to be used internally in an NTP client or server, and not intended to be used by intermediate switches and routers that reside between the client and the server. That seems to contradict the earlier statements, particularly section 3.2.2. Are the intermediate nodes of section 3.2.2 not "switches and routers"? This is probably just a wording issue, but it should be more clear. --Sandy --Apple-Mail=_FDEEF1C7-7CB0-4270-9CCD-A792702A767C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW2GqfAAoJEHplpQeet0IZHkkP/20DC96c9oBiNZromAYyuhc8 CM0wQj2EwAHVxdsMrkjslTyQbHecbDB2MKp0YX34z5OuOfj+ptYej+oXSXuvUs+e kuNO7y/ZGMQK44I6gQVdAY0YQW3TShvFYXDewtI7enjUJ5d51i2zw4RfN6IP115N z+rZm48AvF+R1U+bSDW6bMycNTiDmz7i/g+JZGaoX2UbgATQ+QTxT8/e2Kr54Csf 6PtFp1D8lmUvvvXzLZeapOqPL0sdi1tmaUxOcxASzmKHASwQUBSc3U5oR2AQhTTq 8UAGuk5xGnHJlIVupCUmdDvsnhF3Iz491LaKxSEXogSC1P/myvTwQo8861dGRp4/ 1SwukWU74dfR/8rBTlgGdrcM7tKGFcDfp7MXnGFEwNO9vPOrktUbRIYuf20jb+63 ITbb5kh1H/1QGQwkiLKcLxLRti1bHpAIwrpoikxnGFPGjm8J+sovW1urG9/xUJ5V VaEu03XoOfBLlJNsFppJP8zsBxXYiHFJwkHOZFXWFUo3X7+VNn8lS0Jpjl9Pg7gR t5Y4SruaYB/IAw7s0sN9nDAmM3e6ynregq+6fscekpA15M2EIKrZ5IfYAeAQhTt7 2+uWKejOLzhugdE+fYyOYuJNg8+tgWFKdiFE+TmMeH8Pm/phCt4ekYwSRDvKncVX 8VgaQwzQ1stmnY4vPY2i =osZF -----END PGP SIGNATURE----- --Apple-Mail=_FDEEF1C7-7CB0-4270-9CCD-A792702A767C-- From nobody Sat Mar 5 14:56:05 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CFD1B382B; Sat, 5 Mar 2016 14:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xm7pq9T3G--A; Sat, 5 Mar 2016 14:56:00 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B0C1B382A; Sat, 5 Mar 2016 14:56:00 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id l68so63470468wml.0; Sat, 05 Mar 2016 14:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=C3O8pyh8Ha6K1RjF3m/a0UURpf+N/QEaPmwoxuuHvck=; b=dZkVZTo3zlKrCSYyccDfyBPeg31sqCRo0hU6GNkz8WYcXc2LdDm1rp6MTJK4a5T/Vx 17FMlT32KDb0PDHj+MR7Sbuv5CH5TikBmAo0idNHJCpDgmg/mix3LJ83fvI+y1OTXOza BrmjF5pXoKdPwIzjZuqs0mNieUINdeCBybV1Uhl59sjUDqk5vpoxqeT68YNLcScvyNhZ 4DXVfoetJoHqg8lrWxZR1pHJEpzwa9RCin8O4QiABrO9uPunui2caD8Susg+sABce2lk gpdU9TxD1pMPtWXM7AqEj/s5jom4I6UovTpw0hMKJlGOnK7l/3iqqLB0PNqxCRFceLj3 G3hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=C3O8pyh8Ha6K1RjF3m/a0UURpf+N/QEaPmwoxuuHvck=; b=E1jxgNqRZI9Bz4z4DNYvAx38udhc6iET/kyWjbmDyBWWhjZE0YyLiPtrFhTvLGVuYv jok2N3qqnaS50fUACzBWX+jNvFu0vRMf1DUM4W2ANsbLhPdm/vle6bK6xirjKsRvwtAf klZ6PJ7dLQL0gJposio8enkW7ijpKaLU8q+ZfZKLuiBEIAMtScCHUaMD4UnR2zEXBnPe 2YFa0ZHmOapZWGVuhRZ7Qtl8Y0M1Nc7r8jvyhHwSxSzE6fxxqunnd7vGkteDbu5hQEjA uROP6DrZtxD1Ak6wu3Uf5U4/F8yK+SAi+jKCp7nD5mFmfvGD0cwkzy8nrMrUOW4ZgZyT DZXA== X-Gm-Message-State: AD7BkJJfNM6+4TWYN5Sk837JrKn8fFXAfLBHoqdeS9q86MICkOafOVsfNvXrRrADeec7Hw== X-Received: by 10.194.121.136 with SMTP id lk8mr17199323wjb.92.1457218558679; Sat, 05 Mar 2016 14:55:58 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id p191sm11710228wmb.0.2016.03.05.14.55.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 05 Mar 2016 14:55:57 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 6 Mar 2016 00:55:55 +0200 To: secdir , The IESG , draft-bao-v6ops-rfc6145bis.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [secdir] SecDir Review of draft-bao-v6ops-rfc6145bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 22:56:02 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. Summary: Ready with nits. The nits are not about security. they are mostly around readability. We = have statements in one section that are only explained several sections = later: Section 1.2 says this: Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., the UDP checksum field is zero) are not of significant use in the Internet, and in general will not be translated by the IP/ICMP translator. =20 It's not clear why this is true. What do UDP checksums have to do with = fragmentation? The mystery is solved in section 4.5 (You have to = calculate the UDP checksum for IPv6, and you can=E2=80=99t recalculate = it if it=E2=80=99s zero). It=E2=80=99s fine to explain later, but you = should have a forward reference in section 1.2. And speaking of the explanation in section 4.5: For a stateful translator, the handling of fragmented UDP IPv4 packets with a zero checksum is discussed in [RFC6146]), Section=20= 3.1. There is an extra closing bracket at the reference, and the section is = 3.4, not 3.1. First paragraph in section 1.3 mentions a lot of terms that are not = defined anywhere in the draft (masking addresses, hairpinning, = contiguous routing connectivity). These terms are not explained in RFC = 6144 either. Section 4 talks about "IPv4 datagram addressed to a destination towards = the IPv6 domain". This term is not clear, because IPv4 packets tend to = have destination addresses that are IPv4. I take this to mean that some = portion of the IPv4 space was allocated by DNS64 to "represent" IPv6 = addresses, but the text should say this. Later, section 4.6 actually = says this, but I think this needs to be mentioned before use. The security considerations draft is fine and addresses all the issues I = can think of. There is one nit, though: As with network address translation of IPv4 to IPv4, packets with tunnel mode Encapsulating Security Payload (ESP) can be translated since tunnel mode ESP does not depend on header fields prior to the ESP header. =20 ... the IPsec ESP endpoints will normally detect the presence of the translator and encapsulate ESP in UDP packets [RFC3948]. If ESP packets could be translated with no problems, we wouldn=E2=80=99t = need RFC 3948 (UDP encapsulation of IPsec ESP packets).=20 Yoav From nobody Mon Mar 7 08:05:52 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902761B437B; Mon, 7 Mar 2016 08:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgDDrUhsB902; Mon, 7 Mar 2016 08:05:48 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DECE61B4389; Mon, 7 Mar 2016 08:05:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,552,1449529200"; d="scan'208,217";a="167474923" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Mar 2016 17:05:38 +0100 From: roca Content-Type: multipart/alternative; boundary="Apple-Mail=_09B1A5AF-5991-4560-BD99-77540CA96649" Date: Mon, 7 Mar 2016 17:05:37 +0100 Message-Id: <81288E6E-8AE5-4B4D-9B16-C5D1FC3E827A@inria.fr> To: iesg@ietf.org, secdir@ietf.org, draft-ietf-rtcweb-audio@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [secdir] Secdir review of draft-ietf-rtcweb-audio-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 16:05:50 -0000 --Apple-Mail=_09B1A5AF-5991-4560-BD99-77540CA96649 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: ready This is a small document with many references to external documents and their related security sections. It seems appropriate to me. Typo: please remove the additional "security" in the following sentence: Likewise, consult the RTP base specification for security RTP-based = security considerations. Cheers, Vincent= --Apple-Mail=_09B1A5AF-5991-4560-BD99-77540CA96649 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hello,

I have reviewed this document as part of the security = directorate's
ongoing effort to review all IETF documents = being processed by the
IESG.  These comments were = written primarily for the benefit of the
security area = directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Summary: ready

This is a small = document with many references to external documents = and
their related security sections. It seems = appropriate to me.


Typo: please remove the additional "security" = in the following sentence:
Likewise, consult the RTP base =
specification for security RTP-based security =
considerations.

Cheers,

  = Vincent
= --Apple-Mail=_09B1A5AF-5991-4560-BD99-77540CA96649-- From nobody Mon Mar 7 09:58:33 2016 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8A411CD746; Mon, 7 Mar 2016 09:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a698wUaP2WLn; Mon, 7 Mar 2016 09:57:46 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 26E9E1CD738; Mon, 7 Mar 2016 09:57:29 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id e185so126084551vkb.1; Mon, 07 Mar 2016 09:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=CM8ZpXgSDlFrp84NBrtElcOQ2BnW5Nb2UJo4aMv8rmI=; b=lJNLsUVG1qeTS/cjbcdOJ3zkNA4IzL8rpXNvhcaNA+4HC9sz8SRYopbDBWqxrbf0sH qQc4F47OT8Ei32fqrmn5ycC/Z0sEdJgFMRU99AkA6rcc2l0fxTIsX+AhINHFD4Bn3iLt e34tORNBmxfTA12GKqJjpmn6sIoIVVX5QAEBOUqBAzrS9+lcpD++hedSouHNvhjEVRC2 p3G6aiHKkQE0hRfFcwYJxBMcPwPUQ/Dyem42NvajKWIBemrwpAI8NAqziIQ8NYsT5+su oW64dnTjOJsA4v4k55mvSas0rXg276318vcHsRVtarRfZUhMHO4Pq0VgcXllIkJskVs2 +3RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=CM8ZpXgSDlFrp84NBrtElcOQ2BnW5Nb2UJo4aMv8rmI=; b=mF2QY0Jvw34/T7RqIaxm4qTQUxgg/axM6NanzRgYrhPNqLy653zzNzE3Fd5waq2tBb kw+UDa+XOHTUtHVVWoUiB79T23O9qE/C6IT65XGX0IBpGpNNdlrwC/Ocnjq3V3S6Ofrg YccL3lkT06So97F0ZAjeZuWPcEYCfhBIzVLVW0rCN6lYQBk/naQLtrPVOUjce8Pm6LzL 0lZWWskYs4uxeEcCXOU8jATPYPIinKFJ48Pf2Dkaug+VMB3EK+5dnBuqruElQKufBs3x X9QyrRvlg8fqKDd/WmmFikIjFXFRblAzCSzfJs7/R+DUrArkava76kMHamPlwSIsIYX/ IIxw== X-Gm-Message-State: AD7BkJJakMdh/aj+z2o97Q6izyXk3+g5phMs7mBPXJgHE+2csvoJj1AdeDWc0D0i5/EVVBhE+ZYMmc+NDB2xxg== MIME-Version: 1.0 X-Received: by 10.31.6.17 with SMTP id 17mr21811450vkg.75.1457373448179; Mon, 07 Mar 2016 09:57:28 -0800 (PST) Received: by 10.159.38.38 with HTTP; Mon, 7 Mar 2016 09:57:28 -0800 (PST) Date: Mon, 7 Mar 2016 12:57:28 -0500 Message-ID: From: Rifaat Shekh-Yusef To: The IESG , secdir@ietf.org, draft-ietf-aqm-docsis-pie.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a1143f24aaf14fa052d793238 Archived-At: Subject: [secdir] SecDir review of draft-ietf-aqm-docsis-pie-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 17:57:49 -0000 X-List-Received-Date: Mon, 07 Mar 2016 17:57:49 -0000 --001a1143f24aaf14fa052d793238 Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: *Ready* This is an *Informational* draft that describes some high-level requirements, and describes a variant of a scheme defined in a separate Standards Track document. As such, the Security Considerations section, that states that the document does not introduce any new security issues, seems appropriate to me. Regards, Rifaat --001a1143f24aaf14fa052d793238 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security= directorate's ongoing effort to review all IETF documents being proces= sed by the IESG.=C2=A0 These comments were written primarily for the benefi= t of the security area directors.=C2=A0 Document editors and WG chairs shou= ld treat these comments just like any other last call comments.
<= br>
Summary: Ready

This is= an Informational draft that describes some high-level requirements,= and describes a variant of a scheme defined in a separate Standards Track = document.

As such, the Security Considerations sec= tion, that states that the document does not introduce any new security iss= ues, seems appropriate to me.

Regards,
= =C2=A0Rifaat

--001a1143f24aaf14fa052d793238-- From nobody Mon Mar 7 14:16:27 2016 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CEA751CDC8A; Mon, 7 Mar 2016 14:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_12LTRDOM=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYtItUGGm4rU; Mon, 7 Mar 2016 14:16:25 -0800 (PST) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id B30F71CDC89; Mon, 7 Mar 2016 14:16:25 -0800 (PST) Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ad3Rw-0007u7-OK; Mon, 07 Mar 2016 15:16:24 -0700 Received: from [72.250.219.84] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1ad3Rp-0005yS-Hw; Mon, 07 Mar 2016 15:16:24 -0700 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u27MG1TU002862; Mon, 7 Mar 2016 15:16:01 -0700 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id u27MG09g002861; Mon, 7 Mar 2016 15:16:00 -0700 Date: Mon, 7 Mar 2016 15:16:00 -0700 Message-Id: <201603072216.u27MG09g002861@rumpleteazer.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-AID: U2FsdGVkX1/ATdbxDuUcjwhjcQuzef4Y X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 6693 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.2 (0.0%), b_tie_ro: 2.2 (0.0%), parse: 0.66 (0.0%), extract_message_metadata: 16 (0.2%), get_uri_detail_list: 2.3 (0.0%), tests_pri_-1000: 3.2 (0.0%), tests_pri_-950: 1.37 (0.0%), tests_pri_-900: 1.07 (0.0%), tests_pri_-400: 27 (0.4%), check_bayes: 26 (0.4%), b_tokenize: 7 (0.1%), b_tok_get_all: 10 (0.2%), b_comp_prob: 2.6 (0.0%), b_tok_touch_all: 2.9 (0.0%), b_finish: 0.76 (0.0%), tests_pri_0: 670 (10.0%), check_dkim_signature: 0.69 (0.0%), check_dkim_adsp: 266 (4.0%), tests_pri_500: 5968 (89.2%), poll_dns_idle: 5962 (89.1%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Cc: draft-ietf-netmod-yang-json.all@tools.ietf.org Subject: [secdir] Security review of draft-ietf-netmod-yang-json-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 22:16:27 -0000 Security review of JSON Encoding of Data Modeled with YANG draft-ietf-netmod-yang-json-08 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. "This document defines encoding rules for representing configuration, state data, parameters of RPC operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. YANG is a data modeling language originally designed to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications." I have no specific recommendation for an action on this, just some observations. I'm not an expert on YANG, JSON, or XML, but I was taken aback to read in section 5.5: Anydata data node serves as a container for an arbitrary set of nodes that otherwise appear as normal YANG-modeled data. A data model for anydata content may or may not be known at run time. In the latter case, converting JSON-encoded instances to the XML encoding defined in [I-D.ietf-netmod-rfc6020bis] may be impossible. That seems ominous, and there are other warnings about the force fitting of JSON and XML: "JSON processing is rather different from XML, and JSON parsers may thus suffer from other types of vulnerabilities than their XML counterparts. To minimize these new security risks, software on the receiving side SHOULD reject all messages that do not comply to the rules of this document and reply with an appropriate error message to the sender." The security section refers back to the security considerations in https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-11 section 16 (should be 17) where we read: "Data modeled in YANG might contain sensitive information. RPCs or notifications defined in YANG might transfer sensitive information." "YANG parsers need to be robust with respect to malformed documents. Reading malformed documents from unknown or untrusted sources could result in an attacker gaining privileges of the user running the YANG parser. In an extreme situation, the entire machine could be compromised." There being no succinct description of correctness of YANG, JSON, or XML for NETCONF data, how would one determine that any of it, including mappings from one to another, was "robust"? If that simply means "doesn't cause a buffer overflow or crash", I suppose it's achievable (and should be explicit). But how could anyone be sure that sensitive data was not leaked without a full analysis of the specifications of all the component parts? Perhaps this is an unaddressable question, but one does hope that the extreme situation does not occur. From nobody Mon Mar 7 22:14:01 2016 Return-Path: X-Original-To: secdir@ietfc.amsl.com Delivered-To: secdir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7A0B01CDF9D for ; Mon, 7 Mar 2016 22:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO2588Qhf0nq for ; Mon, 7 Mar 2016 22:13:59 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 27EE41CD6D9 for ; Mon, 7 Mar 2016 22:13:59 -0800 (PST) Received: by mail-ob0-x229.google.com with SMTP id ts10so5239791obc.1 for ; Mon, 07 Mar 2016 22:13:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=OnErzRkCQ2eXsn3Get1Y+OO/+oGps6RadpShd5oJ/lA=; b=TJCw8E2dbhXaxrK5kcDW8Hg2AGPZQf8BymQXhUqAqiw8gmkatx9Jf4+z6j2n2pDiR+ o0I7gJ+q85/9pu/wowPNJKVGqEhd2qakcU7mjiPBqC/Y883rqfMXXKpcSavOmiLusL4F 6FLTcfsIKigWTp7L291JThxr95qp3ZqmV39YR3JelOxDSmEWiNuFq6nghzPfHe0ngrj/ T3HpPOcfG916n80ltLS+5SW0+SrVwo0IHxFzY8Xlgq2Lzxl4TTozgoqNUF4n1UAFVUTH TEkUb5cd47WoBUHZPTk55vvOQ3flYrEoWJCTxEVqxNWWMUsHFhDGb9LVV0Ju3d8UzRfz QJ0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=OnErzRkCQ2eXsn3Get1Y+OO/+oGps6RadpShd5oJ/lA=; b=CfcVkI3KjzRZvve7o+ggl/rXMJCbiYJZH54q+tamRLylDzg7OOM8nWXOa1LXeJ+Uft HqfOaj82m4XdTcCPTLuXNbZsFq251cZbJfLqy5DAUOOwyPODd695zuBtmPkQVGSdarFP 3UTwy2QkForKr7XDZZgi9dSzVFCePvaE5OcI+y/mWJIYl1UNnPoc0YTeTrEOzz+E8v4r MlxcwIhJ8y3nDQKVgGKMdIPm1QmPspwHnTcMNLJxwE31Da69h6B6YGbVq5c4uPBHeFSO /6ePkD0xyIZ9ji3wHmDLJCpxxZkykyoU7gmcpmYd7GJ+9sQ7VrtMe6GFGBcbpDQx4TY/ hllg== X-Gm-Message-State: AD7BkJLNqA6vzP1JVs+KEAfmZ85ausBUkMJ0RwQ8IkCmnpnQzndpYgfvDO9Kra98KVSIs8kwCIOp64xun7WfuA== MIME-Version: 1.0 X-Received: by 10.60.38.37 with SMTP id d5mr16478469oek.50.1457417638547; Mon, 07 Mar 2016 22:13:58 -0800 (PST) Received: by 10.202.63.215 with HTTP; Mon, 7 Mar 2016 22:13:58 -0800 (PST) Date: Mon, 7 Mar 2016 22:13:58 -0800 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: "secdir@ietf.org" , draft-ietf-avtcore-rtp-circuit-breakers@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Secdir review of draft-ietf-avtcore-rtp-circuit-breakers-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 06:14:00 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This memo describes a set of RTP "circuit-breakers." In this context, circuit-breakers are conditions under which an RTP sender "needs to stop transmitting media data in order to protect the network from excessive congestion." As such, the possibility for DOS and similar disruptions are possible in this context. However, the security considerations sections seems adequate and refers to the core RTP, RTCP documents for threat models and mitigations. -- Magnus From nobody Tue Mar 8 07:35:16 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF3912D793; Tue, 8 Mar 2016 07:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TioA4bekokGh; Tue, 8 Mar 2016 07:31:14 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AB96D12D791; Tue, 8 Mar 2016 07:31:13 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id E73A41CC035F; Tue, 8 Mar 2016 16:31:11 +0100 (CET) From: Ladislav Lhotka To: Hilarie Orman , iesg@ietf.org, secdir@ietf.org In-Reply-To: <201603072216.u27MG09g002861@rumpleteazer.rhmr.com> References: <201603072216.u27MG09g002861@rumpleteazer.rhmr.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Tue, 08 Mar 2016 16:31:09 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: X-Mailman-Approved-At: Tue, 08 Mar 2016 07:35:15 -0800 Cc: draft-ietf-netmod-yang-json.all@tools.ietf.org Subject: Re: [secdir] Security review of draft-ietf-netmod-yang-json-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 15:31:19 -0000 Hi Hilarie, thank you for the review, please se my responses inline. Hilarie Orman writes: > Security review of > JSON Encoding of Data Modeled with YANG draft-ietf-netmod-yang-json-08 > > Do not be alarmed. I have reviewed this document as part of the > security directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written primarily > for the benefit of the security area directors. Document editors and > WG chairs should treat these comments just like any other last call > comments. > > "This document defines encoding rules for representing configuration, > state data, parameters of RPC operations or actions, and notifications > defined using YANG as JavaScript Object Notation (JSON) text. YANG is > a data modeling language originally designed to model configuration > and state data manipulated by the Network Configuration Protocol > (NETCONF), NETCONF remote procedure calls, and NETCONF notifications." > > I have no specific recommendation for an action on this, just > some observations. > > I'm not an expert on YANG, JSON, or XML, but I was taken aback to read > in section 5.5: > > Anydata data node serves as a container for an arbitrary set of nodes > that otherwise appear as normal YANG-modeled data. A data model for > anydata content may or may not be known at run time. In the latter > case, converting JSON-encoded instances to the XML encoding defined > in [I-D.ietf-netmod-rfc6020bis] may be impossible. An "anydata" node represents data for which no schema is specified in the data model. The schema for such data may be known at run time, but the consensus in the NETMOD WG was to keep the possibility that this is not the case. And if the schema is not available, translation between XML and JSON encodings cannot be done because, for example, we use the data model info for translating namespace identifiers. As long as we want to keep the option of specifying schema-less data in the data model, we have to live with this. I don't think it is really ominous, also because normal configuration and state data should almost never be modelled with "anydata". > > That seems ominous, and there are other warnings about the force > fitting of JSON and XML: > > "JSON processing is rather different from XML, and JSON parsers may > thus suffer from other types of vulnerabilities than their XML > counterparts. To minimize these new security risks, software on the > receiving side SHOULD reject all messages that do not comply to the > rules of this document and reply with an appropriate error message to > the sender." Implementors might be tempted to apply the Postel Principle and be liberal on the receiving side. This paragraph warns against doing so, unless, of course, the implementor knows what he or she is doing. > > The security section refers back to the security considerations in > https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-11 > section 16 (should be 17) where we read: > > "Data modeled in YANG might contain sensitive information. RPCs or > notifications defined in YANG might transfer sensitive information." > > "YANG parsers need to be robust with respect to malformed documents. > Reading malformed documents from unknown or untrusted sources could > result in an attacker gaining privileges of the user running the YANG > parser. In an extreme situation, the entire machine could be > compromised." > > There being no succinct description of correctness of YANG, JSON, or > XML for NETCONF data, how would one determine that any of it, > including mappings from one to another, was "robust"? If that simply In fact, it is one of the most important virtues of data modelling that the correctness of configuration or state data can be reliably verified. In the context of draft-ietf-netmod-yang-json, correctness has two aspects: 1. All data is required to be I-JSON compliant [RFC 7493] which helps avoid common JSON-specific interoperability and security problems. 2. The data model precisely specifies the schema, data types of all values, and also semantic constraints. If an implementor pays attention to data model definitions (including textual descriptions), then I believe the risk of any data-induced issues is effectively minimised. > means "doesn't cause a buffer overflow or crash", I suppose it's > achievable (and should be explicit). But how could anyone be sure > that sensitive data was not leaked without a full analysis of the > specifications of all the component parts? Perhaps this is an > unaddressable question, but one does hope that the extreme situation > does not occur. > This question isn't specific to this document - sensitive data may be present in any encoding. It is also one of the duties of a good data model to identify such data, and sec. 6 in RFC 6087 puts forward specific requirements in this direction. Thanks, Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Mar 8 07:42:51 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED29512D734 for ; Tue, 8 Mar 2016 07:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hwA6V9nToTb for ; Tue, 8 Mar 2016 07:42:49 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAC5712D795 for ; Tue, 8 Mar 2016 07:42:48 -0800 (PST) Received: from [194.168.214.158] (port=52575 helo=[10.206.28.21]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1adJmY-0002RO-2R; Tue, 08 Mar 2016 15:42:47 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: Date: Tue, 8 Mar 2016 15:42:04 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <090131E6-D9A8-4FD9-BB09-DFC518450C26@csperkins.org> References: To: =?utf-8?Q?Magnus_Nystr=C3=B6m?= X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: draft-ietf-avtcore-rtp-circuit-breakers@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-avtcore-rtp-circuit-breakers-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 15:42:51 -0000 Thanks for the review. Colin > On 8 Mar 2016, at 06:13, Magnus Nystr=C3=B6m = wrote: >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > This memo describes a set of RTP "circuit-breakers." In this context, > circuit-breakers are conditions under which an RTP sender "needs to > stop transmitting media data in order to protect the network from > excessive congestion." As such, the possibility for DOS and similar > disruptions are possible in this context. However, the security > considerations sections seems adequate and refers to the core RTP, > RTCP documents for threat models and mitigations. >=20 > -- Magnus --=20 Colin Perkins https://csperkins.org/ From nobody Tue Mar 8 13:03:32 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70AE12D593; Tue, 8 Mar 2016 13:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSqSyygByDF5; Tue, 8 Mar 2016 13:03:26 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8464D12D552; Tue, 8 Mar 2016 13:03:23 -0800 (PST) Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u28L3MLq048436 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 8 Mar 2016 15:03:23 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf.org From: Robert Sparks Message-ID: <56DF3E1A.4010003@nostrum.com> Date: Tue, 8 Mar 2016 15:03:22 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010209000909050403040305" Archived-At: Subject: [secdir] Secdir review: draft-ietf-ccamp-otn-signal-type-subregistry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 21:03:28 -0000 This is a multi-part message in MIME format. --------------010209000909050403040305 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Almost ready for publication as PS with process nit This very short draft only changes the registration policy for an existing (sub)registry at IANA - adding "Specification Required" to the current "Standards Action" policy. It introduces no new security considerations. It has no security considerations section - the shepherd writeup asserts none is needed. As far as I recall, that's not true. A short section explicitly saying there are no new considerations is required. --------------010209000909050403040305 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 
I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.	

Summary: Almost ready for publication as PS with process nit

This very short draft only changes the registration policy for an existing (sub)registry at IANA - adding "Specification Required" to the current "Standards Action" policy.
It introduces no new security considerations.

It has no security considerations section - the shepherd writeup asserts none is needed.
As far as I recall, that's not true. A short section explicitly saying there are no new considerations is required.
--------------010209000909050403040305-- From nobody Tue Mar 8 15:29:48 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B96C12DC20; Tue, 8 Mar 2016 15:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9qgTZtt9mI9; Tue, 8 Mar 2016 15:29:41 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A2C12DC02; Tue, 8 Mar 2016 15:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4865; q=dns/txt; s=iport; t=1457479781; x=1458689381; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=mf00CLWNvetulWvOQfV7uxhoXnAUkBsIq4Wm8vW7u7w=; b=EdSI4dVXPjBEUmOKXdJ1uwoLaY9bFmeTLKjBS0BWARIMEte34JhTcCy5 c5ATfQUfa1jTyNwZkshfyu/a5Ecl0+bSeNbxhoMIHgRNulsIulUU5K/lV 8bDJBw80LI8nZrNLjHqB/JdozK6ohLp+HQN7/3WmBDi13jIaJXw7APn7j I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQAiX99W/5pdJa1cgm5MgT8GulMBD?= =?us-ascii?q?YFphg8CgUc4FAEBAQEBAQFkJ4RBAQEBBIEJAgEIBAoDAwECKAcyFAkIAgQBEog?= =?us-ascii?q?kvnsBAQEBAQEBAwEBAQEBAQEBGIYXhEKEWoQaBY1oiUIBjW2Oe45VAR4BAUKDZ?= =?us-ascii?q?GqJAX4BAQE?= X-IronPort-AV: E=Sophos; i="5.22,558,1449532800"; d="scan'208,217"; a="84426085" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2016 23:29:40 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u28NTeug001801 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Mar 2016 23:29:40 GMT Received: from xch-rtp-018.cisco.com (64.101.220.158) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 8 Mar 2016 18:29:39 -0500 Received: from xch-rtp-018.cisco.com ([64.101.220.158]) by XCH-RTP-018.cisco.com ([64.101.220.158]) with mapi id 15.00.1104.009; Tue, 8 Mar 2016 18:29:39 -0500 From: "Zafar Ali (zali)" To: Robert Sparks , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf.org" Thread-Topic: Secdir review: draft-ietf-ccamp-otn-signal-type-subregistry-03 Thread-Index: AQHReX34mRpGHW3TdEOtWeYBUUdOQZ9QMcQA Date: Tue, 8 Mar 2016 23:29:39 +0000 Message-ID: References: <56DF3E1A.4010003@nostrum.com> In-Reply-To: <56DF3E1A.4010003@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.208.195] Content-Type: multipart/alternative; boundary="_000_D304CA3516E796zaliciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir review: draft-ietf-ccamp-otn-signal-type-subregistry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 23:29:43 -0000 --_000_D304CA3516E796zaliciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Robert- We can add a security section stating "no new consideration is required". Thanks Regards ... Zafar From: Robert Sparks > Date: Tuesday, March 8, 2016 at 4:03 PM To: "secdir@ietf.org" >, "iesg@ietf.org" >, "draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf.org<= mailto:draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf.org>" > Subject: Secdir review: draft-ietf-ccamp-otn-signal-type-subregistry-03 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Almost ready for publication as PS with process nit This very short draft only changes the registration policy for an existing = (sub)registry at IANA - adding "Specification Required" to the current "Sta= ndards Action" policy. It introduces no new security considerations. It has no security considerations section - the shepherd writeup asserts no= ne is needed. As far as I recall, that's not true. A short section explicitly saying ther= e are no new considerations is required. --_000_D304CA3516E796zaliciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <8C45CEEF874A55419AF664F5236BBA66@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Robert- 

We can add a security section stating “no new consideration is r= equired". 

Thanks

Regards … Zafar

From: Robert Sparks <rjsparks@nostrum.com>
Date: Tuesday, March 8, 2016 at 4:0= 3 PM
To: "secdir@ietf.org" <= secdir@ietf.org>, "iesg@ietf.o= rg" <iesg@ietf.org>, &q= uot;draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf.org" <draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf.org> Subject: Secdir review: draft-ietf-= ccamp-otn-signal-type-subregistry-03

I have reviewed this document as part of the security d=
irectorate's=20
ongoing effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the=20
security area directors.  Document editors and WG chairs should treat=20
these comments just like any other last call comments.=09

Summary: Almost ready for publication as PS with process nit

This very short draft only changes the registration policy for an existing =
(sub)registry at IANA - adding "Specification Required" to the cu=
rrent "Standards Action" policy.
It introduces no new security considerations.

It has no security considerations section - the shepherd writeup asserts no=
ne is needed.
As far as I recall, that's not true. A short section explicitly saying ther=
e are no new considerations is required.
--_000_D304CA3516E796zaliciscocom_-- From nobody Wed Mar 9 20:47:41 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A4912D5A2; Wed, 9 Mar 2016 20:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMtbNEij7kRZ; Wed, 9 Mar 2016 20:47:35 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B331912D595; Wed, 9 Mar 2016 20:47:35 -0800 (PST) Received: by mail-ob0-x236.google.com with SMTP id fp4so69391374obb.2; Wed, 09 Mar 2016 20:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=iTkJk15fOoH+mDTTuni3yFiszgRYoUj6l//o48FXYoE=; b=mKFUqlf9KZTN2lmEQqg4xQy/k07hlPEAX9DYfH6h6ex6cl0G3NkNsBFoG6CDPtGTfM 6xysO867bDlWiAHSf6QyyJkbOu7hvpYY+iQvVOgwM5bsXCGk5qfwDV1BUAKFKuEOWmuV YOmJPpuL/Dkz1v5YPl+aBS+yo4BybGISST0XRIhe5upB59INlnATpjGjamNby4AXyamG DOzJH+i6k09Di0CkAA7i4+bDX17fz6MYSP1VZVJzqqs8CKVRBqCwzt6bR2xtK9ZOzyYX EzxCMKSxjL6/65m190tQZxMT6yoDV1HKrJAquZi8fPei2PWlIDq1GIfpuqj4KdKDYYNH xLVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=iTkJk15fOoH+mDTTuni3yFiszgRYoUj6l//o48FXYoE=; b=Lr/oa9BMfsolTDKSSRRhbwZ1uM/F/Tdd1nWxOZi7vEY3xQnwLlkSyVp9erl/sHYaIn Cq+22R61/Jcp+A1oiuw411SMT8QMoy9xPkS/0n4XJDxeD0JqJQunyljgXagjXNn/i1jh jhA+LTjszr8gmsQBtAyZVNLXNyrI/5/pK0nTxWAxhSjFzZFM4noQdwuMei3lO7e+X+v4 7Ee8xIoiognhEDPTPmB11mf8qaQu5EZT2TSu606LltgO8L25F4MgKNPS+RuLKcdwMK1q PeaajVf16ZnjJ8E8sszHMVV5BpRvg+p6VB4ahc9VM9UlxNphAYyzJvWV6G9PIGQbPGd7 F0ew== X-Gm-Message-State: AD7BkJI7ULY/vb2o5/deO8YsqYq8DieMFVBRoRbUsco4FUF20qbrGT44a/SoPiaJXQeLgOyN4pI+wOoJEURBuQ== MIME-Version: 1.0 X-Received: by 10.60.59.37 with SMTP id w5mr802482oeq.76.1457585255157; Wed, 09 Mar 2016 20:47:35 -0800 (PST) Received: by 10.182.159.1 with HTTP; Wed, 9 Mar 2016 20:47:35 -0800 (PST) Date: Wed, 9 Mar 2016 20:47:35 -0800 Message-ID: From: Radia Perlman To: The IESG , "secdir@ietf.org" , draft-ietf-p2psip-concept.all@tools.ietf.org Content-Type: multipart/alternative; boundary=089e0149d1865d1a4f052daa83b5 Archived-At: Subject: [secdir] Secdir review of draft-ietf-p2psip-concepts-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 04:47:37 -0000 --089e0149d1865d1a4f052daa83b5 Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is titled "Concepts and Terminology for Peer to Peer SIP", and as such would have no security considerations, as noted in the document. However, this document describes how to discover which host a client is at, instead of using a SIP proxy, by using a peer-to-peer network and DHT. I'd have liked a motivation for why this would be a preferable mechanism. It seems like it would be less secure, in that more things will need to be trusted. And furthermore, as this document says in section 5.4: "The P2PSIP WG does not impose a particular mechanism for how the peer-ID and the credentials are obtained, but the RELOAD protocol does specify the format for the configuration information." I'd think the hard problems would be things like who to get a credential from for joining the peer-to-peer group of proxies, and how that entity would decide whether you should be trusted to join the peer-to-peer group. And if there is such a trusted entity (a central administration), why wouldn't the whole discovery process be more centralized? Also, with a peer-to-peer DHT, it seems like there are more things that need to be trusted. Any of them acting maliciously can cause incorrect answers. Admittedly, I didn't read all the background documents. There's a minor typo in section 2.2, clearly a cut and paste error: "A special peer may be a member of the in the P2PSIP overlay" Radia --089e0149d1865d1a4f052daa83b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this docu= ment as part of the security directorate's ongoing effort to review all= IETF documents being processed by the IESG. These comments were written pr= imarily for the benefit of the security area directors. Document editors an= d WG chairs should treat these comments just like any other last call comme= nts.

This document is titled "Concepts and T= erminology for Peer to Peer SIP", and as such would have no security c= onsiderations, as noted in the document.

However, = this document describes how to discover which host a client is at, instead = of using a SIP proxy, by using a peer-to-peer network and DHT.
I'd have liked a motivation for why this would be a prefer= able mechanism.=C2=A0 It seems like it would be less secure, in that more t= hings will need to be trusted.=C2=A0 And furthermore, as this document says= in section 5.4:

"The P2PSIP WG does not= impose a particular mechanism for how the
=C2=A0peer-ID and the = credentials are obtained, but the RELOAD protocol
=C2=A0does spec= ify the format for the configuration information."

I'd think the hard problems would be things like who to get a cre= dential from for joining the peer-to-peer group of proxies, and how that en= tity would decide whether you should be trusted to join the peer-to-peer gr= oup.=C2=A0 And if there is such a trusted entity (a central administration)= , why wouldn't the whole discovery process be more centralized?

Also, with a peer-to-peer DHT, it seems like there are mo= re things that need to be trusted.=C2=A0 Any of them acting maliciously can= cause incorrect answers.

Admittedly, I didn't= read all the background documents.

There's a = minor typo in section 2.2, clearly a cut and paste error:

"A special peer may be a member of the in the P2PSIP over= lay"

Radia

--089e0149d1865d1a4f052daa83b5-- From nobody Thu Mar 10 00:44:02 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971FF12D5BA; Thu, 10 Mar 2016 00:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAqY62kOozeo; Thu, 10 Mar 2016 00:34:44 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40AEF12D5B9; Thu, 10 Mar 2016 00:34:36 -0800 (PST) X-AuditID: c1b4fb30-f79d26d000006389-79-56e1319a249b Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F9.82.25481.A9131E65; Thu, 10 Mar 2016 09:34:34 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.131]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Thu, 10 Mar 2016 09:34:33 +0100 From: Daniele Ceccarelli To: "Zafar Ali (zali)" , Robert Sparks , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf.org" , "CCamp-chairs@ietf.org" Thread-Topic: Secdir review: draft-ietf-ccamp-otn-signal-type-subregistry-03 Thread-Index: AQHReX33vqcogrnZg0ykW8cVvnIfnJ9QIQSAgAI5wuA= Date: Thu, 10 Mar 2016 08:34:33 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48162564BB@ESESSMB301.ericsson.se> References: <56DF3E1A.4010003@nostrum.com> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48162564BBESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7ru4sw4dhBqenK1ss3bGJyWLvtbms FjP+TGS2uDankc3iw8KHLBavd3xld2DzmPJ7I6vHkiU/mTxm7XzCEsAcxWWTkpqTWZZapG+X wJUx9eIspoJpORVXH91kb2BsT+xi5OSQEDCR2LzrAROELSZx4d56NhBbSOAwo8SHj0VdjFxA 9hJGifkXpzN3MXJwsAlYSTw55AMSFxE4yiRx+FAbWLOwgLfEz6nPwJpFBHwkDp4+wgpSLwJU f6KXEcRkEVCVuHJUF6SCV8BX4uGSBjaQsBBQ59a9biBhTgFdiR93e8CGMArISkzYvYgRxGYW EJe49WQ+1JUCEkv2nGeGsEUlXj7+xwphK0q0P22Aqs+X6Pu+hw1ilaDEyZlPWCYwisxCMmoW krJZSMog4noSN6ZOYYOwtSWWLXzNDGHrSsz4d4gFWXwBI/sqRtHi1OKk3HQjI73Uoszk4uL8 PL281JJNjMAYPLjlt8EOxpfPHQ8xCnAwKvHwflj1IEyINbGsuDL3EKMEB7OSCO9ug4dhQrwp iZVVqUX58UWlOanFhxilOViUxHlZP10OExJITyxJzU5NLUgtgskycXBKNTC6dV/amzT9Woby htz3ywpSfPT9Nh2Yzf1v5ld92fj9FedY1/+wS9javub4mtxXv+K9Sg8avK5KkbeS6XuSLXhR 4/+S7QsFni3l7rWPCN44V5XX2OOx5Nec0Np/7TN93dasqBDoebQoyk2of7PR7ubvD2pX/n2/ 7U77CoG/5u8aOiJvPdoW9f+iEktxRqKhFnNRcSIAqqhRI70CAAA= Archived-At: X-Mailman-Approved-At: Thu, 10 Mar 2016 00:44:00 -0800 Subject: Re: [secdir] Secdir review: draft-ietf-ccamp-otn-signal-type-subregistry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 08:34:50 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48162564BBESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Zafar, I would suggest a section similar to RFC7139 , as it's the reference for th= e OTN signal type sub-registry. What about something like: This document introduces no new security considerations to the existing GMP= LS signaling protocols. Refer to [RFC7139]for further details of the speci= fic security measures. Additionally, [RFC5920] provides an overview of security vulnerabilities and protection me= chanisms for the GMPLS control plane. Robert, does this address your concern? BR Daniele From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: mercoled=EC 9 marzo 2016 00:30 To: Robert Sparks; secdir@ietf.org; iesg@ietf.org; draft-ietf-ccamp-otn-sig= nal-type-subregistry.all@ietf.org Subject: Re: Secdir review: draft-ietf-ccamp-otn-signal-type-subregistry-03 Hi Robert- We can add a security section stating "no new consideration is required". Thanks Regards ... Zafar From: Robert Sparks > Date: Tuesday, March 8, 2016 at 4:03 PM To: "secdir@ietf.org" >, "iesg@ietf.org" >, "draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf.org<= mailto:draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf.org>" > Subject: Secdir review: draft-ietf-ccamp-otn-signal-type-subregistry-03 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Almost ready for publication as PS with process nit This very short draft only changes the registration policy for an existing = (sub)registry at IANA - adding "Specification Required" to the current "Sta= ndards Action" policy. It introduces no new security considerations. It has no security considerations section - the shepherd writeup asserts no= ne is needed. As far as I recall, that's not true. A short section explicitly saying ther= e are no new considerations is required. --_000_4A1562797D64E44993C5CBF38CF1BE48162564BBESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Zafar,

 <= /p>

I would suggest a section= similar to RFC7139 , as it’s the reference for the OTN signal type s= ub-registry.

What about something like= :

 <= /p>

This docume= nt introduces no new security considerations to the existing GMPLS signalin= g protocols.  Refer to [RFC7139]for further details of the specific security measures.  Additionally, [RFC5920] provides an overview of= security vulnerabilities and protection mechanisms for the GMPLS control plane.

 <= /p>

Robert, does this address= your concern?

 <= /p>

BR
Daniele

 <= /p>

 <= /p>

From: Zafar Al= i (zali) [mailto:zali@cisco.com]
Sent: mercoled=EC 9 marzo 2016 00:30
To: Robert Sparks; secdir@ietf.org; iesg@ietf.org; draft-ietf-ccamp-= otn-signal-type-subregistry.all@ietf.org
Subject: Re: Secdir review: draft-ietf-ccamp-otn-signal-type-subregi= stry-03

 

Hi Robert- =

 

We can add a security secti= on stating “no new consideration is required". <= /span>

 

Thanks

 

Regards … Zafar<= /o:p>

 

From: Robert Sparks <rjsparks@nostrum.com>
Date: Tuesday, March 8, 2016 at 4:03 PM
To: "secdir@ietf.org&quo= t; <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-ccamp-otn-signal= -type-subregistry.all@ietf.org" <draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf.org> Subject: Secdir review: draft-ietf-ccamp-otn-signal-type-subregistry= -03

  

I have reviewed this document as part of t=
he security directorate's 
ongoing effort to review all IETF document=
s being processed by the 
IESG.  These comments were written pr=
imarily for the benefit of the 
security area directors.  Document ed=
itors and WG chairs should treat 
these comments just like any other last ca=
ll comments.      
 
Summary: Almost ready for publication as P=
S with process nit
 
This very short draft only changes the reg=
istration policy for an existing (sub)registry at IANA - adding "Speci=
fication Required" to the current "Standards Action" policy.=

It introduces no new security consideratio=
ns.
 
It has no security considerations section =
- the shepherd writeup asserts none is needed.
As far as I recall, that's not true. A sho=
rt section explicitly saying there are no new considerations is required.
 
--_000_4A1562797D64E44993C5CBF38CF1BE48162564BBESESSMB301erics_-- From nobody Thu Mar 10 07:09:07 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B4712D9AE; Thu, 10 Mar 2016 07:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blr49g_88suF; Thu, 10 Mar 2016 07:08:59 -0800 (PST) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B7C12DAD7; Thu, 10 Mar 2016 07:00:11 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2AEvI4O007120; Thu, 10 Mar 2016 07:00:07 -0800 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 21fwpnkyxy-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 10 Mar 2016 07:00:07 -0800 Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 10 Mar 2016 17:00:02 +0200 Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1104.000; Thu, 10 Mar 2016 17:00:02 +0200 From: Tal Mizrahi To: Sandra Murphy , "secdir@ietf.org" , "Brian Haberman (brian@innovationslab.net)" , Suresh Krishnan , "Karen ODonoghue (odonoghue@isoc.org)" Thread-Topic: secdir review for draft-ietf-ntp-checksum-trailer-04.txt Thread-Index: AQHRdWxw/Xyzgagi2U+JRpDt6KSY/p9SzUpQ Date: Thu, 10 Mar 2016 15:00:02 +0000 Message-ID: <3a5d4b90f8264a68ad2d6b9abcea60a8@IL-EXCH01.marvell.com> References: <130DE753-A1AD-40AD-8C32-63F2AFE165D9@tislabs.com> In-Reply-To: <130DE753-A1AD-40AD-8C32-63F2AFE165D9@tislabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-10_08:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603100244 Archived-At: Cc: The IETF , "draft-ietf-ntp-checksum-trailer@tools.ietf.org" Subject: Re: [secdir] secdir review for draft-ietf-ntp-checksum-trailer-04.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 15:09:06 -0000 Hi Sandra, Thanks for the comments. In the current draft (07) I believe that all your comments have been addres= sed. https://tools.ietf.org/html/draft-ietf-ntp-checksum-trailer-07 Detailed responses below. >(1) > >It seems there's an impossibility of protecting the NTP packet with this >extension. This extension header MUST NOT be used with an NTP MAC, and >so is usable only in those situations where NTP is used in an "unauthentic= ated >mode". One might imagine that NTP running in an unauthenticated mode >could be run in an ipsec tunnel for protection. >However, the description of the timestamping engine makes it seem that the >engine modifies the packet directly before transmission. I.e., the packet >would be modified after the ipsec protections were applied. >Certainly the "intermediate nodes" mentioned in 3.2.2 would be adding the >extension header after the source applied the ipsec protection. >If my suppositions are correct, then using this extension header means nei= ther >an authenticated NTP nor a protected tunnel could be used. >All the intruder attacks mentioned in RFC5905 security considerations sect= ion >would be possible. Agreed.=20 This issue is discussed in the security considerations section. Based on yo= ur comment the text has been slightly revised to clarify this point further= . Here is the updated text: The concept described in this document is intended to be used only in unauthenticated mode. As discussed in Section 3.4. , if a cryptographic security mechanism is used, then the Checksum Complement does not simplify the implementation compared to using the conventional Checksum, and therefore the Checksum Complement is not used. >(2) > >RFC5905 and draft-ietf-ntp-extension-field-07.txt both define the general >extension header format with the padding following the value. >This draft defines this extension header as the value following the paddin= g. >That conflict should be addressed. Agreed.=20 Based on this comment the field name has been changed from "Padding" to "MB= Z". >(3) > >Section 1 describes intermediate entities (like the timestamping engine), = and >section 3.2.2 says: > > An intermediate node that receives and alters an NTP packet > containing a Checksum Complement extension MAY use the Checksum > Complement to maintain a correct UDP checksum value. > >However, section 4 says: > > The > extension is intended to be used internally in an NTP client or > server, and not intended to be used by intermediate switches and > routers that reside between the client and the server. > >That seems to contradict the earlier statements, particularly section 3.2.= 2. >Are the intermediate nodes of section 3.2.2 not "switches and routers"? T= his >is probably just a wording issue, but it should be more clear. The point is well taken. The use of the word "intermediate" was a bit confusing in a few locations i= n the document. The text has been rephrased in these cases in order to clar= ify the meaning. Specifically, the sentence from Section 4 that you mentioned above was reph= rased to the following: The extension is intended to be used internally in an NTP client or server. This extension is not intended to be used by switches and routers that reside between the client and the server. Best regards, Tal. >-----Original Message----- >From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Sandra Murphy >Sent: Thursday, March 03, 2016 6:47 PM >To: secdir@ietf.org; draft-ietf-ntp-checksum-trailer@tools.ietf.org; The I= ETF >Subject: secdir review for draft-ietf-ntp-checksum-trailer-04.txt > >I have reviewed this document as part of the security directorate's ongoin= g >effort to review all IETF documents being processed by the IESG. These >comments were written primarily for the benefit of the security area >directors. Document editors and WG chairs should treat these comments jus= t >like any other last call comments. > >The document draft-ietf-ntp-checksum-trailer-04.txt defines a new extensio= n >header for NTP that will allow a hardware based timestamping engine to >modify the timestamp in the NTP packet and then add a correction to the >packet's UDP checksum to account for the modified timestamp. Putting the >correction in an extension header allows for serial processing of the pack= et - >no need to backtrack from the timestamp to the UDP checksum preceding in >the packet and correct that field. > >I found the document adequate for the most part. > >(1) > >It seems there's an impossibility of protecting the NTP packet with this >extension. This extension header MUST NOT be used with an NTP MAC, and >so is usable only in those situations where NTP is used in an "unauthentic= ated >mode". One might imagine that NTP running in an unauthenticated mode >could be run in an ipsec tunnel for protection. >However, the description of the timestamping engine makes it seem that the >engine modifies the packet directly before transmission. I.e., the packet >would be modified after the ipsec protections were applied. >Certainly the "intermediate nodes" mentioned in 3.2.2 would be adding the >extension header after the source applied the ipsec protection. >If my suppositions are correct, then using this extension header means nei= ther >an authenticated NTP nor a protected tunnel could be used. >All the intruder attacks mentioned in RFC5905 security considerations sect= ion >would be possible. > >(2) > >RFC5905 and draft-ietf-ntp-extension-field-07.txt both define the general >extension header format with the padding following the value. >This draft defines this extension header as the value following the paddin= g. >That conflict should be addressed. > >(3) > >Section 1 describes intermediate entities (like the timestamping engine), = and >section 3.2.2 says: > > An intermediate node that receives and alters an NTP packet > containing a Checksum Complement extension MAY use the Checksum > Complement to maintain a correct UDP checksum value. > >However, section 4 says: > > The > extension is intended to be used internally in an NTP client or > server, and not intended to be used by intermediate switches and > routers that reside between the client and the server. > >That seems to contradict the earlier statements, particularly section 3.2.= 2. >Are the intermediate nodes of section 3.2.2 not "switches and routers"? T= his >is probably just a wording issue, but it should be more clear. > >--Sandy From nobody Thu Mar 10 07:42:14 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E516512D82E; Thu, 10 Mar 2016 07:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0Ah7NKVMHc1; Thu, 10 Mar 2016 07:40:46 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4909F12D8F3; Thu, 10 Mar 2016 07:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14916; q=dns/txt; s=iport; t=1457624446; x=1458834046; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tOvwDP0Ul6IIFPrJer+LdupMvBuuvD+cy9TK94gy9NA=; b=DGhqLxJ6Ysh8+C83hwAnhMYg/9OkBE2cn3d3dWhLseN3V4FCaGmU7ml5 j/6v2LZhXzhx9mxLklDnjMYy5UbaJI3NSgpCV64Tor0f8/LPP6pp2u/1Q X7lSb3lBmACr/+SGvIhg7Zke0urOIKuIA71wEQisEp8hwA7Rqe5Ip3nbG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAgDnlOFW/40NJK1egnJMUm0GulgBD?= =?us-ascii?q?YFtHYVyAoFBOBQBAQEBAQEBZCeEQQEBAQQtTBACAQgRAwEBASgHMhQJCAIEAQ0?= =?us-ascii?q?FCIgcDr1BAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYYhEKEWhaEBAWNa4UShD8Bh?= =?us-ascii?q?WmIB4I2jFCOaQEPDwEBQoNkaohVAX0BAQE?= X-IronPort-AV: E=Sophos; i="5.24,316,1454976000"; d="scan'208,217"; a="79380410" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2016 15:40:45 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u2AFejkq032677 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Mar 2016 15:40:45 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 10 Mar 2016 09:40:43 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Thu, 10 Mar 2016 09:40:44 -0600 From: "Matt Hartley (mhartley)" To: Daniele Ceccarelli , "Zafar Ali (zali)" , Robert Sparks , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf.org" , "CCamp-chairs@ietf.org" Thread-Topic: Secdir review: draft-ietf-ccamp-otn-signal-type-subregistry-03 Thread-Index: AQHReX33vqcogrnZg0ykW8cVvnIfnJ9QIQSAgAI5wuCAAHiTcA== Date: Thu, 10 Mar 2016 15:40:44 +0000 Message-ID: References: <56DF3E1A.4010003@nostrum.com> <4A1562797D64E44993C5CBF38CF1BE48162564BB@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48162564BB@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.171] Content-Type: multipart/alternative; boundary="_000_a109acdab84e490789495115947e789cXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 10 Mar 2016 07:42:10 -0800 Cc: "Matt Hartley \(mhartley\)" Subject: Re: [secdir] Secdir review: draft-ietf-ccamp-otn-signal-type-subregistry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 15:40:55 -0000 --_000_a109acdab84e490789495115947e789cXCHRCD001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That looks good to me! Cheers Matt Hi Zafar, I would suggest a section similar to RFC7139 , as it's the reference for th= e OTN signal type sub-registry. What about something like: This document introduces no new security considerations to the existing GMP= LS signaling protocols. Refer to [RFC7139]for further details of the speci= fic security measures. Additionally, [RFC5920] provides an overview of security vulnerabilities and protection me= chanisms for the GMPLS control plane. Robert, does this address your concern? BR Daniele From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: mercoled=EC 9 marzo 2016 00:30 To: Robert Sparks; secdir@ietf.org; iesg@ietf.org; draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf= .org Subject: Re: Secdir review: draft-ietf-ccamp-otn-signal-type-subregistry-03 Hi Robert- We can add a security section stating "no new consideration is required". Thanks Regards ... Zafar From: Robert Sparks > Date: Tuesday, March 8, 2016 at 4:03 PM To: "secdir@ietf.org" >, "iesg@ietf.org" >, "draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf.org<= mailto:draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf.org>" > Subject: Secdir review: draft-ietf-ccamp-otn-signal-type-subregistry-03 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Almost ready for publication as PS with process nit This very short draft only changes the registration policy for an existing = (sub)registry at IANA - adding "Specification Required" to the current "Sta= ndards Action" policy. It introduces no new security considerations. It has no security considerations section - the shepherd writeup asserts no= ne is needed. As far as I recall, that's not true. A short section explicitly saying ther= e are no new considerations is required. --_000_a109acdab84e490789495115947e789cXCHRCD001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

That looks good to me!

 

Cheers

 

Matt

 

 

Hi Zafar,

 

I would suggest a section similar to = RFC7139 , as it’s the reference for the OTN signal type sub-registry.=

What about something like:=

 

This docume= nt introduces no new security considerations to the existing GMPLS signalin= g protocols.  Refer to [RFC7139]for further details of the specific security measures.  Additionally, [RFC5920] provides an overview of= security vulnerabilities and protection mechanisms for the GMPLS control plane.

 

Robert, does this address your concer= n?

 

BR
Daniele

 

 

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: mercoled=EC 9 marzo 2016 00:30
To: Robert Sparks; secdir@ietf.or= g; iesg@ietf.org; draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf.org
Subject: Re: Secdir review: draft-ietf-ccamp-otn-signal-type-subregi= stry-03

 

Hi Robert- 

 

We can add a security section stating &= #8220;no new consideration is required". 

 

Thanks

 

Regards … Zafar=

 

From: Robert Sparks <rjsparks@nostrum.com>
Date: Tuesday, March 8, 2016 at 4:03 PM
To: "secdir@ietf.org&quo= t; <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-ccamp-otn-signal= -type-subregistry.all@ietf.org" <draft-ietf-ccamp-otn-signal-type-subregistry.all@ietf.org> Subject: Secdir review: draft-ietf-ccamp-otn-signal-type-subregistry= -03

 

I have reviewed this document as part of t=
he security directorate's 
ongoing effort to review all IETF document=
s being processed by the 
IESG.  These comments were written pr=
imarily for the benefit of the 
security area directors.  Document ed=
itors and WG chairs should treat 
these comments just like any other last ca=
ll comments.      
 
Summary: Almost ready for publication as P=
S with process nit
 
This very short draft only changes the reg=
istration policy for an existing (sub)registry at IANA - adding "Speci=
fication Required" to the current "Standards Action" policy.=

It introduces no new security consideratio=
ns.
 
It has no security considerations section =
- the shepherd writeup asserts none is needed.
As far as I recall, that's not true. A sho=
rt section explicitly saying there are no new considerations is required.
 
--_000_a109acdab84e490789495115947e789cXCHRCD001ciscocom_-- From nobody Thu Mar 10 09:57:38 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637C212DAB9; Thu, 10 Mar 2016 09:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1eJLRFFKsy5; Thu, 10 Mar 2016 09:57:35 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BF312DAE6; Thu, 10 Mar 2016 09:57:34 -0800 (PST) Received: by mail-ob0-x231.google.com with SMTP id m7so88437666obh.3; Thu, 10 Mar 2016 09:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=u/dqbUmPeYK343M/McJzCS2nIAKR7T2Bo5UEGzxNi1M=; b=KQCpfxpAe6O0NfWjhCdFEt7uMPChlcOCxrDauL1a2tUhVd+RHrYcwTJk13qb1CHa5T NdLzZXnM3gFUsQQ5rzUbqyuHcgorjadMZIQFsCeDvIWciPGPHSzT8zBHRv8myzPnDDO9 qCxwmDxSgUYjo6P90DR53nPTyg+NIxQoJXKQy5WiCI4JfzT2v8aQatnLABOzbFdH8bYR ef3eEySl9WLzBMPlIGulqnRXVQ+e9q2XbgcUZmqcNGOrYD9pn8TN5mEiGoarKRNN6HN9 IZCJtxQbKpJOd0uo9aJRCmC9Fap+XPeK/liKAimnX4sIPoRHMdRcHcHwtK1bLjZrkc8z Db3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=u/dqbUmPeYK343M/McJzCS2nIAKR7T2Bo5UEGzxNi1M=; b=eSlfY+gTsMIDi/w63Vj0p3j0OpN38KrQpDnKzufyX4RJDz7/0tJtJqFaAO6aDHcPmI 8y3hvuCZqLLJSt6aTh5qYUIOCyDbuV/8XmccEqvFCT8k4n5nKCy/lSAN1yeLIDi1fMSz rN2GMwMsdFf3hO4YxqDFRK0seXuoQj5zclba6uzYDatiSZx95zSqBRqq+pB7hDlA1FY3 Dduj6DAzYbE1dhbwPrPZai5+Anu2MynWlGC4RBbMGPIKHzQOQcLU5MfhcMuF2WX4T1l5 G/UpFy6Eiw0QT28AHmYJDWIu2VoaudnByI2+5SfMofFUN/rkaivZ5vDYVUyUdJFubQuF JChA== X-Gm-Message-State: AD7BkJJbh6t0M8AX4/UdfO7hnbJGi+SaLGPLMd9x3+SGfnwFYwJR0zop3+PTdKv+YrWcbwXbGVdnXtZgVIJMmA== MIME-Version: 1.0 X-Received: by 10.60.156.103 with SMTP id wd7mr2855921oeb.47.1457632654242; Thu, 10 Mar 2016 09:57:34 -0800 (PST) Received: by 10.182.159.1 with HTTP; Thu, 10 Mar 2016 09:57:34 -0800 (PST) Date: Thu, 10 Mar 2016 09:57:34 -0800 Message-ID: From: Radia Perlman To: "secdir@ietf.org" , The IESG , draft-ietf-p2psip-concepts.all@tools.ietf.org Content-Type: multipart/alternative; boundary=047d7bd6b3fc91c9cb052db58c3f Archived-At: Subject: [secdir] Secdir review of draft-ietf-p2psip-concepts-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 17:57:37 -0000 --047d7bd6b3fc91c9cb052db58c3f Content-Type: text/plain; charset=UTF-8 (Sorry...I'm resending because I mistyped and sent to draft-ietf-p2psip-concept.all@tools.ietf.org the first time) I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is titled "Concepts and Terminology for Peer to Peer SIP", and as such would have no security considerations, as noted in the document. However, this document describes how to discover which host a client is at, instead of using a SIP proxy, by using a peer-to-peer network and DHT. I'd have liked a motivation for why this would be a preferable mechanism. It seems like it would be less secure, in that more things will need to be trusted. And furthermore, as this document says in section 5.4: "The P2PSIP WG does not impose a particular mechanism for how the peer-ID and the credentials are obtained, but the RELOAD protocol does specify the format for the configuration information." I'd think the hard problems would be things like who to get a credential from for joining the peer-to-peer group of proxies, and how that entity would decide whether you should be trusted to join the peer-to-peer group. And if there is such a trusted entity (a central administration), why wouldn't the whole discovery process be more centralized? Also, with a peer-to-peer DHT, it seems like there are more things that need to be trusted. Any of them acting maliciously can cause incorrect answers. Admittedly, I didn't read all the background documents. There's a minor typo in section 2.2, clearly a cut and paste error: "A special peer may be a member of the in the P2PSIP overlay" Radia --047d7bd6b3fc91c9cb052db58c3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(Sorry...I'm resending beca= use I mistyped and sent to=C2=A0draft-ietf-p2psip-con= cept.all@tools.ietf.org the first time)

= I have reviewed this document as part of t= he security directorate's ongoing effort to review all IETF documents b= eing processed by the IESG. These comments were written primarily for the b= enefit of the security area directors. Document editors and WG chairs shoul= d treat these comments just like any other last call comments.
<= br>
This document is titled "Concepts and Terminology for Pe= er to Peer SIP", and as such would have no security considerations, as= noted in the document.

However, this document des= cribes how to discover which host a client is at, instead of using a SIP pr= oxy, by using a peer-to-peer network and DHT.

I= 9;d have liked a motivation for why this would be a preferable mechanism.= =C2=A0 It seems like it would be less secure, in that more things will need= to be trusted.=C2=A0 And furthermore, as this document says in section 5.4= :

"The P2PSIP WG does not impose a parti= cular mechanism for how the
=C2=A0peer-ID and the credentials are= obtained, but the RELOAD protocol
=C2=A0does specify the format = for the configuration information."

I'd t= hink the hard problems would be things like who to get a credential from fo= r joining the peer-to-peer group of proxies, and how that entity would deci= de whether you should be trusted to join the peer-to-peer group.=C2=A0 And = if there is such a trusted entity (a central administration), why wouldn= 9;t the whole discovery process be more centralized?

Also, with a peer-to-peer DHT, it seems like there are more things that = need to be trusted.=C2=A0 Any of them acting maliciously can cause incorrec= t answers.

Admittedly, I didn't read all the b= ackground documents.

There's a minor typo in s= ection 2.2, clearly a cut and paste error:

&q= uot;A special peer may be a member of the in the P2PSIP overlay"
=

Radia


--047d7bd6b3fc91c9cb052db58c3f-- From nobody Thu Mar 10 11:08:06 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FE512DBEC for ; Thu, 10 Mar 2016 11:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2-tRAEPqkTa for ; Thu, 10 Mar 2016 11:07:53 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5FE112DBA1 for ; Thu, 10 Mar 2016 11:07:52 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u2AJ7la7007992 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 10 Mar 2016 21:07:47 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u2AJ7lLH000019; Thu, 10 Mar 2016 21:07:47 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22241.50691.78059.489398@fireball.acr.fi> Date: Thu, 10 Mar 2016 21:07:47 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 19:07:56 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Frank Xialiang is next in the rotation. For telechat 2016-03-17 Reviewer LC end Draft Chris Inacio T 2016-02-02 draft-ietf-v6ops-ipv6-ehs-in-real-world-02 Benjamin Kaduk TR2016-02-09 draft-ietf-tsvwg-circuit-breaker-13 Alexey Melnikov T 2016-03-07 draft-wallace-est-alt-challenge-04 Eric Osterweil T 2016-03-09 draft-ietf-netmod-yang-metadata-04 Joe Salowey T 2016-03-09 draft-ietf-rtcweb-audio-codecs-for-interop-05 Takeshi Takahashi T 2016-03-16 draft-ietf-cdni-redirection-17 Tina TSOU T 2016-03-15 draft-ietf-dprive-dns-over-tls-07 Sean Turner T 2016-03-15 draft-ietf-netext-pmipv6-flowmob-17 Carl Wallace T 2016-03-30 draft-schoenw-opsawg-copspr-historic-03 David Waltermire T 2016-03-17 draft-ietf-aqm-fq-codel-05 Last calls and special requests: Donald Eastlake R2016-02-22 draft-ietf-dane-openpgpkey-07 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Jeffrey Hutzelman 2015-12-04 draft-ietf-core-block-18 Charlie Kaufman R2016-03-14 draft-ietf-i2rs-architecture-13 Eric Osterweil 2016-01-05 draft-campbell-art-rfc5727-update-02 Yaron Sheffer 2016-03-09 draft-ietf-v6ops-host-addr-availability-05 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-13 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-04 Sam Weiler 2016-03-18 draft-ietf-avtext-sdes-hdr-ext-05 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-06 Brian Weis 2016-03-22 draft-ietf-cdni-footprint-capabilities-semantics-12 Klaas Wierenga 2016-03-21 draft-ietf-imapapnd-rfc2088bis-04 Paul Wouters 2016-03-23 draft-ietf-radext-bigger-packets-05 -- kivinen@iki.fi From nobody Thu Mar 10 11:28:30 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF78E12DBFD for ; Thu, 10 Mar 2016 11:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=softarmor.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4QnqrbMLsX3 for ; Thu, 10 Mar 2016 11:28:26 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D3712DC22 for ; Thu, 10 Mar 2016 11:28:25 -0800 (PST) Received: by mail-ob0-x230.google.com with SMTP id m7so90951128obh.3 for ; Thu, 10 Mar 2016 11:28:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=+BWrBzYfWHtjxVswNPQqqEyGRtBL7KPNNWInttbMj+8=; b=COFzAT3vOj2/Nhkgk/e0I6SkPcKaF5oaoPs7mRQFllIxlvJaHgBs2UmVslLTW2Rt35 ruWbJUgv6Y5cr/PA2vVANVDnjzc+gEigEAuk2ZydCYQhpNgeom0wwAmED56zUMiUDikh fGcxKnaDi6HTFGZ1/Xo9SSdr4bsoROGwEbnp8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=+BWrBzYfWHtjxVswNPQqqEyGRtBL7KPNNWInttbMj+8=; b=CIB0cVW/eSBxy6YJ/rcCWeifykbg6PeR4Brx1U/QipcWUzXCC/e0C1KKsWJCgGlPhA SXhMQ1UrHFvBrnUQ8AdG2ABsOQLVy1BAETIILwi4phJb36fHpPjJT1hqlDBeui7MZkOT d1iZM5dI3pmKp3mPOsTRG2FdRBtURmk/SQj89Y9MPj/uvuIIFMgMOyhaPiSNq1QA54oT 3j2hvvs8U1wArAuSqv4PmiZeSrLBLP/FDaJVgYWpV3nFtK9IoCMWfO7kM7c3N+e/ODMs YfOQ670ZOnLCYeDnYzYubWvnLALciy5wQEqA4cKqdgt6yFf8y+OI6Col/Ao7Pe6lT04x 4UDA== X-Gm-Message-State: AD7BkJILKe3xXmAtfO3I2ERpCsmKrwgKqrVptKIpN9H66tg7770Q0rjy4YhAUb+fjnhsHQ== X-Received: by 10.182.225.231 with SMTP id rn7mr3423993obc.2.1457638104910; Thu, 10 Mar 2016 11:28:24 -0800 (PST) Received: from [192.168.2.124] ([104.50.220.72]) by smtp.gmail.com with ESMTPSA id ku6sm2416231obb.25.2016.03.10.11.28.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Mar 2016 11:28:23 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_102E1962-4957-4339-AFF8-1ED0920B0BDE" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dean Willis In-Reply-To: Date: Thu, 10 Mar 2016 13:28:22 -0600 Message-Id: References: To: Radia Perlman X-Mailer: Apple Mail (2.3112) Archived-At: Cc: The IESG , draft-ietf-p2psip-concepts.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-p2psip-concepts-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 19:28:29 -0000 --Apple-Mail=_102E1962-4957-4339-AFF8-1ED0920B0BDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Radia. Good catch on =E2=80=9Cthe the typo.=E2=80=9D RFC 6940 has most of the security considerations for RELOAD (the = protocol that came out of this work), using the terminology from this = document. In short, it boils down to the single-cert problem; the = typical RELOAD overlay has a simple PKI understructure, using a singular = authority (the enrollment server) that has a public key used to sign the = credentials for each enrollee. RFC 5765 is, in its entirety, security considerations for P2P. You actually ask a very good question here about motivation, one that we = spent a lot of time TALKING about, but apparently didn=E2=80=99t spend = much time WRITING about. There were =E2=80=9Cscenarios=E2=80=9D drafts = that covered motivations, but they didn=E2=80=99t get conserved into a = publication-ready state. An example is = https://tools.ietf.org/html/draft-jiang-p2psip-peer-protocol-requirement-0= 1 = The short answer to your concern is that the =E2=80=9Cenrollment=E2=80=9D = process happens on the order of N times, where N is the number of nodes = participating in the overlay (multiplied some relatively low expiry = rate). But registration and resolution (aka, rendezvous) operations are = vastly more frequent, happening (at the least) every time the IP address = of a node changes (or in SIP, every 30 seconds, just in case), and = every time one node needs to contact another (which scales with the = link-density of the network, typically an exponential).=20 Practically speaking, an enrollment server can run on a typical LAMP = stack with one box (or perhaps a redundant pair) supporting millions of = users. But the rendezvous problem is more like trying to run the = Internet on dynamic DNS servers =E2=80=94 it gets gnarly quickly. Further, if enrollment breaks, no new nodes can be added, but existing = nodes continue to work. But if rendezvous breaks, the whole system = grinds to a halt.=20 Rendezvous, therefore, benefits from a high level of distribution =E2=80=94= both from a load scaling and a resilience perspective.=20 Yet another issue is that the traditional SIP proxy/registrar represents = a very rich target for interception of communications metadata. If every = movement of a user and every communications between any two users is = mediated by a single box, that box becomes a very high priority target. = The attack surface is narrow, but the payoff is huge. The P2P routing = model, on the other hand, stores relatively little information at any = given node, producing a broader attack surface, but requiring vastly = more nodes to be compromised before overall opsec is diminished. This is = particularly significant in the scenario of a nation-state actor, who = must penetrate not just the local proxy-registrar but potentially = millions of foreign nodes in order to tap the metadata. So, here=E2=80=99s the question: Where should such motivations be = documented? Do they belong in the terminology document? I can see making = this into a terminology-and-rationale document. Do they belong in the = protocol specifications? =E2=80=94 Dean > On Mar 10, 2016, at 11:57, Radia Perlman = wrote: >=20 > (Sorry...I'm resending because I mistyped and sent to = draft-ietf-p2psip-concept.all@tools.ietf.org = the first time) >=20 > I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. >=20 > This document is titled "Concepts and Terminology for Peer to Peer = SIP", and as such would have no security considerations, as noted in the = document. >=20 > However, this document describes how to discover which host a client = is at, instead of using a SIP proxy, by using a peer-to-peer network and = DHT. >=20 > I'd have liked a motivation for why this would be a preferable = mechanism. It seems like it would be less secure, in that more things = will need to be trusted. And furthermore, as this document says in = section 5.4: >=20 > "The P2PSIP WG does not impose a particular mechanism for how the > peer-ID and the credentials are obtained, but the RELOAD protocol > does specify the format for the configuration information." >=20 > I'd think the hard problems would be things like who to get a = credential from for joining the peer-to-peer group of proxies, and how = that entity would decide whether you should be trusted to join the = peer-to-peer group. And if there is such a trusted entity (a central = administration), why wouldn't the whole discovery process be more = centralized? >=20 > Also, with a peer-to-peer DHT, it seems like there are more things = that need to be trusted. Any of them acting maliciously can cause = incorrect answers. >=20 > Admittedly, I didn't read all the background documents. >=20 > There's a minor typo in section 2.2, clearly a cut and paste error: >=20 > "A special peer may be a member of the in the P2PSIP overlay" >=20 > Radia >=20 >=20 --Apple-Mail=_102E1962-4957-4339-AFF8-1ED0920B0BDE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thanks, Radia. Good catch on =E2=80=9Cthe the = typo.=E2=80=9D

RFC 6940 has most of the security considerations for RELOAD = (the protocol that came out of this work), using the terminology from = this document. In short, it boils down to the single-cert problem; the = typical RELOAD overlay has a simple PKI understructure, using a singular = authority (the enrollment server) that has a public key used to sign the = credentials for each enrollee.

RFC 5765 is, in its entirety, security = considerations for P2P.

You actually ask a very good question here about motivation, = one that we spent a lot of time TALKING about, but apparently didn=E2=80=99= t spend much time WRITING about. There were =E2=80=9Cscenarios=E2=80=9D = drafts that covered motivations, but they didn=E2=80=99t get conserved = into a publication-ready state. An example is https://tools.ietf.org/html/draft-jiang-p2psip-peer-protocol-re= quirement-01

The short answer to your concern is that the =E2=80=9Cenrollmen= t=E2=80=9D process happens on the order of N times, where N is the = number of nodes participating in the overlay (multiplied some relatively = low expiry rate). But registration and resolution (aka, rendezvous) = operations are vastly more frequent, happening (at the least) every time = the IP address of a node changes (or in SIP, every 30 seconds, just in = case),  and every time one node needs to contact another (which = scales with the link-density of the network, typically an = exponential). 

Practically speaking, an enrollment server can run on a = typical LAMP stack with one box (or perhaps a redundant pair) supporting = millions of users. But the rendezvous problem is more like trying to run = the Internet on dynamic DNS servers =E2=80=94 it gets gnarly = quickly.

Further, if enrollment breaks, no new nodes can be added, but = existing nodes continue to work. But if rendezvous breaks, the whole = system grinds to a halt. 

Rendezvous, therefore, benefits from a = high level of distribution =E2=80=94 both from a load scaling and a = resilience perspective. 

Yet another issue is that the = traditional SIP proxy/registrar represents a very rich target for = interception of communications metadata. If every movement of a user =  and every communications between any two users  is mediated = by a single box, that box becomes a very high priority target. The = attack surface is narrow, but the payoff is huge. The P2P routing model, = on the other hand, stores relatively little information at any given = node, producing a broader attack surface, but requiring vastly more = nodes to be compromised before overall opsec is diminished. This is = particularly significant in the scenario of a nation-state actor, who = must penetrate not just the local proxy-registrar but potentially = millions of foreign nodes in order to tap the metadata.

So, here=E2=80=99s the = question: Where should such motivations be documented? Do they belong in = the terminology document? I can see making this into a = terminology-and-rationale document. Do they belong in the protocol = specifications?

=E2=80=94
Dean



On = Mar 10, 2016, at 11:57, Radia Perlman <radiaperlman@gmail.com> wrote:

(Sorry...I'm resending because I = mistyped and sent to draft-ietf-p2psip-concept.all@tools.ietf.org the first = time)

I have reviewed = this document as part of the security directorate's ongoing effort to = review all IETF documents being processed by the IESG. These comments = were written primarily for the benefit of the security area directors. = Document editors and WG chairs should treat these comments just like any = other last call comments.

This document is titled "Concepts and Terminology for Peer to = Peer SIP", and as such would have no security considerations, as noted = in the document.

However, this document describes how to discover which host a = client is at, instead of using a SIP proxy, by using a peer-to-peer = network and DHT.

I'd have liked a motivation for why this would be a = preferable mechanism.  It seems like it would be less secure, in = that more things will need to be trusted.  And furthermore, as this = document says in section 5.4:

"The P2PSIP WG does not = impose a particular mechanism for how the
 peer-ID and the credentials are obtained, but the = RELOAD protocol
 does specify the format for = the configuration information."

I'd think the hard problems would be = things like who to get a credential from for joining the peer-to-peer = group of proxies, and how that entity would decide whether you should be = trusted to join the peer-to-peer group.  And if there is such a = trusted entity (a central administration), why wouldn't the whole = discovery process be more centralized?

Also, with a peer-to-peer DHT, it seems = like there are more things that need to be trusted.  Any of them = acting maliciously can cause incorrect answers.

Admittedly, I didn't read all the = background documents.

There's a minor typo in section 2.2, clearly a cut and paste = error:

"A special peer may be a member of the in the P2PSIP = overlay"

Radia



= --Apple-Mail=_102E1962-4957-4339-AFF8-1ED0920B0BDE-- From nobody Thu Mar 10 16:56:07 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2872612DF4D; Thu, 10 Mar 2016 16:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj2lFCdJyVzN; Thu, 10 Mar 2016 16:56:01 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C08912DF47; Thu, 10 Mar 2016 16:56:01 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id 124so81797842pfg.0; Thu, 10 Mar 2016 16:56:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=gumtKCDqNgGInsae8hCxEzHbjv3KX0I5WUy19jhvhFw=; b=sDn2mlIDXMaGk4WFoKCAHpt5XGhsYhvU4g5hGb3uk5TYiS/ojIk8uqr+28t+gGGHHY 2NV48EL9cb/IaDpJnaS2NdA57TYhImcT1HtkbzYkSCngiwrNcSjxERV16azro4BxLgob e2aBNFnKsQSOPQ44HPGIcHuV7jTJXrYjtUhzWunAyBJmnGr8DKJao+OLr6dCvueyS3S/ o/6kHXeRBAu71Egdt4efqyrd8F9NSAq6XlSDN2Ddk9l3FQvDigk4Ao+txCvz0RuX5Ly8 d1HpG1saYZxONmHTHxhyde0DIBnKdWvQispXe6cbwBv/fqwg8dSxsYxQ7mx+Hd1aN2Pb YPRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=gumtKCDqNgGInsae8hCxEzHbjv3KX0I5WUy19jhvhFw=; b=c1opfqFKlhArafZ2JhGu4MjqDgstUYpVaGxSIxVi6i6dD8ytKZKhZ+XOkSqCYp0t8/ mi2alFCwS7avqry52vUOjiJ7HkLagJfDA70GzwhgLUFfhIzqHxDsDa7exy7NuYMWCd6V 31Lt2/bXBDtz/DYpUjwHLJu/bBqVuj9UhRJ+DasJ5eNAp87qrobFoW/vCCREmPSGaqNT OHHoL8FT5SB+jWDzUxHi0o+pOtzc1MJPpUqdt6VwJFbY2SQgcMRl7YOjaob/6lVWhr7L lFpU5uaroU22foUaT/FSsisvA63CJwGyxRaNnNvk7j1v88whXZMorHPj8WqKIA5v+b28 h8kA== X-Gm-Message-State: AD7BkJKZHCUWca5YR3qPu/lfflOQei4f5Tws0tsuHMcP+yvAGwLkrYOmMzgFMuRltPkr2A== X-Received: by 10.98.71.149 with SMTP id p21mr9335151pfi.133.1457657760631; Thu, 10 Mar 2016 16:56:00 -0800 (PST) Received: from ?IPv6:2001:420:290:1330:d51a:b8bc:3a23:fcd? ([2001:420:290:1330:d51a:b8bc:3a23:fcd]) by smtp.gmail.com with ESMTPSA id o185sm8175266pfo.36.2016.03.10.16.55.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Mar 2016 16:55:59 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_28763446-A8CE-48F8-BE37-2C9EA6CEF8F2" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Mahesh Jethanandani In-Reply-To: <2BC76448-BCD9-4B69-AF8E-A1D81D40A33B@gmail.com> Date: Thu, 10 Mar 2016 16:55:59 -0800 Message-Id: References: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> <2BC76448-BCD9-4B69-AF8E-A1D81D40A33B@gmail.com> To: Tom Yu X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-netconf-yang-library.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 00:56:03 -0000 --Apple-Mail=_28763446-A8CE-48F8-BE37-2C9EA6CEF8F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tom, Any update from your side? > On Feb 26, 2016, at 3:12 PM, Mahesh Jethanandani = wrote: >=20 > Tom, >=20 > Thanks for getting back to us.=20 >=20 > At the outset let me just say that this draft is defining a new = mechanism for advertisement of capabilities within YANG modules. As = such, the security considerations for this document are not very = different from the security considerations one might have using the = NETCONF protocol today. Some of the information is already being = exchanged today through other mechanisms.=20 >=20 > To your specific comments... >=20 >> On Feb 25, 2016, at 5:01 PM, Tom Yu > wrote: >>=20 >> Hi Mahesh, >>=20 >> Sorry about the delay. >>=20 >> I was looking at the specific comments in the Security Considerations = of >> this document about the sensitivity of the contents of = /modules/module. >> How do the risks of an attacker being able to inspect /modules/module >> compare with other information that could be available to an = attacker, >> such as fingerprinting through non-NETCONF means? >=20 > The attacker may have better success getting the information through = some other means, and even then the information would be no more = damaging than what they would be able to see if they had the right = SSH/NACM credentials. >=20 >>=20 >> If an attacker has limited NETCONF access on a server, what would the >> contents of /modules/module reveal to the attacker that might not >> otherwise be discovered by other kinds of probing within the NETCONF >> protocol? >=20 > With limited access most of the information about the modules/module = will not be visible. >=20 >>=20 >> These other risks might be trivial in comparison to the one mentioned = in >> the document, but lacking specific knowledge of the broader context = of >> NETCONF and how it is deployed, I'm not sure how they compare. For >> example, is it expected that anonymous or minimally trusted users = could >> be authorized to use NETCONF to access some public information about = a >> server? >=20 > No. There is no anonymous or minimal trusted user account (by = default). Accounts have to be setup for users to access the box over = NETCONF and then they are typically assigned to a authorized group with = specific permissions. >=20 > Thanks. >=20 >>=20 >> If these other risks are similar in magnitude to the possible = exposures >> allowed by /modules/module, you should consider mentioning them, and >> give the implementor or operator some guidance about how to weigh = these >> risks. If the exposures allowed by /modules/module vastly outweigh >> those from other avenues of obtaining similar capability or >> configuration information, in most environments and forseeable >> deployments, maybe the current text is sufficient. >>=20 >> -Tom >>=20 >> Mahesh Jethanandani > writes: >>=20 >>> Tom, >>>=20 >>> It is not entirely clear from this e-mail, what action you want the = authors to take.=20 >>>=20 >>> YANG module information or more like its encodings are sent over a = secure session (SSH/TLS) and are no more specific to this draft than = they are to any NETCONF/RESTCONF session. As such it is not clear what = you want the authors to do. Could you clarify or provide text for the = Security Consideration section? >>>=20 >>> Thanks. >>>=20 >>>> On Feb 1, 2016, at 6:03 PM, Tom Yu > wrote: >>>>=20 >>>> I have reviewed this document as part of the security directorate's=20= >>>> ongoing effort to review all IETF documents being processed by the=20= >>>> IESG. These comments were written primarily for the benefit of the=20= >>>> security area directors. Document editors and WG chairs should = treat=20 >>>> these comments just like any other last call comments. >>>>=20 >>>> The Security Considerations of this document seem reasonable. It = might >>>> be useful to add a comparison of the risks posed by sensitive >>>> information exposed by this YANG module with information exposed by >>>> other aspects of NETCONF, or available through methods such as >>>> fingerprinting. Admittedly, a meaningful comparison might be = highly >>>> context-specific, so a general comparison might have limited = utility. >>>=20 >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >=20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_28763446-A8CE-48F8-BE37-2C9EA6CEF8F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Tom,

Any = update from your side?

On = Feb 26, 2016, at 3:12 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Tom,

Thanks for getting back = to us. 

At = the outset let me just say that this draft is defining a new mechanism for advertisement of capabilities within YANG = modules. As such, the security considerations for this document are not = very different from the security considerations one might have using the = NETCONF protocol today. Some of the information is already being = exchanged today through other mechanisms. 

To your specific comments...

On Feb = 25, 2016, at 5:01 PM, Tom Yu <tlyu@mit.edu> wrote:

Hi Mahesh,

Sorry about the delay.

I was looking at the specific comments in the Security = Considerations of
this document about the sensitivity of = the contents of /modules/module.
How do the risks of an = attacker being able to inspect /modules/module
compare = with other information that could be available to an attacker,
such as fingerprinting through non-NETCONF means?

The = attacker may have better success getting the information through some = other means, and even then the information would be no more damaging = than what they would be able to see if they had the right SSH/NACM = credentials.


If an attacker has limited = NETCONF access on a server, what would the
contents of = /modules/module reveal to the attacker that might not
otherwise be discovered by other kinds of probing within the = NETCONF
protocol?

With limited access most of the = information about the modules/module will not be visible.


These other risks might be trivial in = comparison to the one mentioned in
the document, but = lacking specific knowledge of the broader context of
NETCONF= and how it is deployed, I'm not sure how they compare.  For
example, is it expected that anonymous or minimally trusted = users could
be authorized to use NETCONF to access some = public information about a
server?

No. = There is no anonymous or minimal trusted user account (by default). = Accounts have to be setup for users to access the box over NETCONF and = then they are typically assigned to a authorized group with specific = permissions.

Thanks.


If these other = risks are similar in magnitude to the possible exposures
allowed by /modules/module, you should consider mentioning = them, and
give the implementor or operator some guidance = about how to weigh these
risks.  If the exposures = allowed by /modules/module vastly outweigh
those from = other avenues of obtaining similar capability or
configuration information, in most environments and = forseeable
deployments, maybe the current text is = sufficient.

-Tom

Mahesh Jethanandani <mjethanandani@gmail.com> writes:

Tom,

It is not entirely clear from this e-mail, what action you = want the authors to take.

YANG module = information or more like its encodings are sent over a secure session = (SSH/TLS) and are no more specific to this draft than they are to any = NETCONF/RESTCONF session. As such it is not clear what you want =  the authors to do. Could you clarify or provide text for the = Security Consideration section?

Thanks.

On Feb 1, = 2016, at 6:03 PM, Tom Yu <tlyu@mit.edu> wrote:

I = have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed = by the
IESG.  These comments were written primarily = for the benefit of the
security area directors. =  Document editors and WG chairs should treat
these = comments just like any other last call comments.

The Security Considerations of this document seem reasonable. =  It might
be useful to add a comparison of the risks = posed by sensitive
information exposed by this YANG module = with information exposed by
other aspects of NETCONF, or = available through methods such as
fingerprinting. =  Admittedly, a meaningful comparison might be highly
context-specific, so a general comparison might have limited = utility.

Mahesh = Jethanandani
mjethanandani@gmail.com

Mahesh Jethanandani
mjethanandani@gmail.com




Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_28763446-A8CE-48F8-BE37-2C9EA6CEF8F2-- From nobody Sun Mar 13 18:05:00 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398B612D893; Sun, 13 Mar 2016 18:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTB08dA8V2nh; Sun, 13 Mar 2016 18:04:55 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 547A712D6D8; Sun, 13 Mar 2016 18:04:54 -0700 (PDT) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id u2E14qj2085230; Mon, 14 Mar 2016 10:04:52 +0900 (JST) Received: from TakeVaioVJP13 (ssh1.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id u2E14ohJ085204; Mon, 14 Mar 2016 10:04:50 +0900 (JST) From: "Takeshi Takahashi" To: , , , Date: Mon, 14 Mar 2016 10:05:13 +0900 Message-ID: <012401d17d8d$9176fc90$b464f5b0$@nict.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdF9jXvJZLira36nRV2pgaEw0ZgSTg== Content-Language: ja X-Virus-Scanned: clamav-milter 0.98.7 at zenith1 X-Virus-Status: Clean Archived-At: Subject: [secdir] Secdir review of draft-ietf-cdni-redirection-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 01:04:57 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. [overall feeling on this draft] ready. [summary of this document] This document talks about a necessary interface for CDN. It defines the CDNI Request Routing Recirection interface, which is the interface for the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. Specifically speaking, this document defines general message sequences of the redirection as well as the protocol message syntax. It also elaborates on how to handle the caches of the messages and how to handle errors. [questions] Here are some clarification questions. I would appreciate if you could provide some answers to them. 1. Example jsons in P.25: Do we need "description" in the json? Since we already have "error-code" in the json, I am not sure whether we need to embed the "description" in the json. The description is written in the IANA table and is unique to each error-code. For this reason, I feel that we can omit the "description" from the json, can't we? 2. error code of 503 in page 26 (3rd paragraph of the page). I have got one question by reading two sentences: "If a dCDN receives an RI request where the number of CDN Provider IDs in cdn-path is greater than max-hops, the dCDN SHOULD send an RI response with an error code of 503."(3rd paragraph of page 26) and "transit CDNs MUST NOT propagate to any downstream CDNs if the number of CDN Provider IDs in cdn-path is equal to or greater than max-hops"(last sentence of page 25) If "transit CDNs MUST NOT propagate to any downstream CDNs if the number of CDN Provider IDs in cdn-path is equal to or greater than max-hops" is true, no dCDN receives an RI request where the number of CDN Provider IDs in cdn-path is greater than max-hops, is it correct? Even if the answer is yes, I think it is wise to have the error code 503 (because some CDNs may be malfunctioning), but what types of actions should the receivers of the error message take? [typo] In Table 1 in P.24: "erred" -> "errored"? Cheers, Take From nobody Sun Mar 13 18:20:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EDA12D8D5; Sun, 13 Mar 2016 18:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ez2r_i2DdcUt; Sun, 13 Mar 2016 18:20:10 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC2012D634; Sun, 13 Mar 2016 18:20:09 -0700 (PDT) Received: by mail-ob0-x22a.google.com with SMTP id ts10so161922861obc.1; Sun, 13 Mar 2016 18:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=RpXVcbxAxUFBnFVFrOL9J3tVTym7XkyOLZzyAi0XgSw=; b=nIan8OyVEF9y39vZplFo9TUJ45GfUxW7/GuErojuh+ACsXOJUjPK9vDpLCeyTHnw4d O+YYAOBoh7zZDrVxf5pSsxKpkJxTnAyCQgTEBdplhPdSg9WcSrWPnCeIExr+z4DXAvT9 LcYp02Sa05MJGPZ3Ysq7MKnz8h5Lg8JfN/S7u+bNqCGfqtjFhh1ph+JEZDV6fFPlV6aJ ayImi8hRAwJbzYbiex0B+Wb/ca9GP+3IwQVg2lekB78ZhtIYbR4SnLMkiesHxF91EkR1 oL437IiTKwPpaQMbyXB6RrtmOn4wK9hiAIk8DuwIy+ImaA4hF2ukcv1rQBJky0SO5i6g FoNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RpXVcbxAxUFBnFVFrOL9J3tVTym7XkyOLZzyAi0XgSw=; b=W0ZYgGlhhJvUpZJBelx9K6i6JaUWIY76HPNHqSQ728wdML0LfpfdNkrwqBxe0Rl1KG ERzB+zstUA4NRvo1q7S6XhUzwr+S2LqUTYkTpGZhgd5+aGOV4iVBduAKO7l8Dz4M6FMo +gYtGyOC/yzDDhsjV8GoT8E0tbVeSdLhNTwx/WngN27ZijUMcPnlbDNFI+xpfc8bBXtW UysfPsiK+RSxnOfFDwrBUD89O5DvqTXRLLeVc/rxo9+H4KfyjEMnoYwL0k3iGdXdCA/0 /sZEWfuCxdkfWqxnBFGfhTeF9AExHsIMN2p1tVhR4UNZqzmWgaBad0C9yBGzTCDo2BGC Bu8Q== X-Gm-Message-State: AD7BkJL27xAUFNxMJys8fKGGYD0OliYz+TDT7YkjhGgjNuB4TvC9aSjQxi42HFxg/sn1WDlAmJlKNu6vT2rfKw== MIME-Version: 1.0 X-Received: by 10.60.128.229 with SMTP id nr5mr13014221oeb.56.1457918409298; Sun, 13 Mar 2016 18:20:09 -0700 (PDT) Received: by 10.182.159.1 with HTTP; Sun, 13 Mar 2016 18:20:09 -0700 (PDT) In-Reply-To: References: Date: Sun, 13 Mar 2016 18:20:09 -0700 Message-ID: From: Radia Perlman To: Dean Willis Content-Type: multipart/alternative; boundary=047d7b2e3f74e5dcf2052df81457 Archived-At: Cc: The IESG , draft-ietf-p2psip-concepts.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-p2psip-concepts-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 01:20:17 -0000 --047d7b2e3f74e5dcf2052df81457 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Re Dean's question to me: >>So, here=E2=80=99s the question: Where should such motivations be documen= ted? Do they belong in the terminology document? I can see making this into a terminology-and->>rationale document. Do they belong in the protocol specifications? I wish a protocol could be all in one document. I assume in some cases that's impractical because it would be too long. But at any rate, I'd prefer either the rationale should be in a few paragraphs, repeated in each document for which it's relevant (in this case, all the documents pertaining to the peer-to-peer variant), or the rationale be in one of the documents, and all the others have a sentence saying "the rationale for why in some cases the peer-to-peer variant is desirable is in XXX". Back to wishing a protocol could all be in one document...if it can't be, I'd love a single roadmap document that points to all the pieces needed for understanding the protocol (and rationale, and proofs it works, and terminology, and anything else relevant), with an explanation about what is in each one (rather than just saying "here are 17 other documents you should read). I'm not quite sure why documents wind up in so many pieces. I suppose in some cases something is added after the fact (like "how to run this over X"), and it's easier to come out with a tiny new simple document just for that, rather than editing it into the main document. But as a reader catching up on a new technology, I'd find it easier to just read one, well-organized, complete document. Radia On Thu, Mar 10, 2016 at 11:28 AM, Dean Willis wrote: > Thanks, Radia. Good catch on =E2=80=9Cthe the typo.=E2=80=9D > > RFC 6940 has most of the security considerations for RELOAD (the protocol > that came out of this work), using the terminology from this document. In > short, it boils down to the single-cert problem; the typical RELOAD overl= ay > has a simple PKI understructure, using a singular authority (the enrollme= nt > server) that has a public key used to sign the credentials for each > enrollee. > > RFC 5765 is, in its entirety, security considerations for P2P. > > You actually ask a very good question here about motivation, one that we > spent a lot of time TALKING about, but apparently didn=E2=80=99t spend mu= ch time > WRITING about. There were =E2=80=9Cscenarios=E2=80=9D drafts that covered= motivations, but > they didn=E2=80=99t get conserved into a publication-ready state. An exam= ple is > https://tools.ietf.org/html/draft-jiang-p2psip-peer-protocol-requirement-= 01 > > The short answer to your concern is that the =E2=80=9Cenrollment=E2=80=9D= process happens > on the order of N times, where N is the number of nodes participating in > the overlay (multiplied some relatively low expiry rate). But registratio= n > and resolution (aka, rendezvous) operations are vastly more frequent, > happening (at the least) every time the IP address of a node changes (or = in > SIP, every 30 seconds, just in case), and every time one node needs to > contact another (which scales with the link-density of the network, > typically an exponential). > > Practically speaking, an enrollment server can run on a typical LAMP stac= k > with one box (or perhaps a redundant pair) supporting millions of users. > But the rendezvous problem is more like trying to run the Internet on > dynamic DNS servers =E2=80=94 it gets gnarly quickly. > > Further, if enrollment breaks, no new nodes can be added, but existing > nodes continue to work. But if rendezvous breaks, the whole system grinds > to a halt. > > Rendezvous, therefore, benefits from a high level of distribution =E2=80= =94 both > from a load scaling and a resilience perspective. > > Yet another issue is that the traditional SIP proxy/registrar represents = a > very rich target for interception of communications metadata. If every > movement of a user and every communications between any two users is > mediated by a single box, that box becomes a very high priority target. T= he > attack surface is narrow, but the payoff is huge. The P2P routing model, = on > the other hand, stores relatively little information at any given node, > producing a broader attack surface, but requiring vastly more nodes to be > compromised before overall opsec is diminished. This is particularly > significant in the scenario of a nation-state actor, who must penetrate n= ot > just the local proxy-registrar but potentially millions of foreign nodes = in > order to tap the metadata. > > So, here=E2=80=99s the question: Where should such motivations be documen= ted? Do > they belong in the terminology document? I can see making this into a > terminology-and-rationale document. Do they belong in the protocol > specifications? > > =E2=80=94 > Dean > > > > On Mar 10, 2016, at 11:57, Radia Perlman wrote: > > (Sorry...I'm resending because I mistyped and sent to > draft-ietf-p2psip-concept.all@tools.ietf.org the first time) > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security are= a > directors. Document editors and WG chairs should treat these comments jus= t > like any other last call comments. > > This document is titled "Concepts and Terminology for Peer to Peer SIP", > and as such would have no security considerations, as noted in the docume= nt. > > However, this document describes how to discover which host a client is > at, instead of using a SIP proxy, by using a peer-to-peer network and DHT= . > > I'd have liked a motivation for why this would be a preferable mechanism. > It seems like it would be less secure, in that more things will need to b= e > trusted. And furthermore, as this document says in section 5.4: > > "The P2PSIP WG does not impose a particular mechanism for how the > peer-ID and the credentials are obtained, but the RELOAD protocol > does specify the format for the configuration information." > > I'd think the hard problems would be things like who to get a credential > from for joining the peer-to-peer group of proxies, and how that entity > would decide whether you should be trusted to join the peer-to-peer group= . > And if there is such a trusted entity (a central administration), why > wouldn't the whole discovery process be more centralized? > > Also, with a peer-to-peer DHT, it seems like there are more things that > need to be trusted. Any of them acting maliciously can cause incorrect > answers. > > Admittedly, I didn't read all the background documents. > > There's a minor typo in section 2.2, clearly a cut and paste error: > > "A special peer may be a member of the in the P2PSIP overlay" > > Radia > > > > --047d7b2e3f74e5dcf2052df81457 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Re Dean's question to me:

>>S= o, here=E2=80=99s the question: Where should such motivations be documented= ? Do they belong in the terminology document? I can see making this into a = terminology-and->>rationale document. Do they belong in the protocol = specifications?

I wish a protocol could be all in = one document.=C2=A0 I assume in some cases that's impractical because i= t would be too long.=C2=A0 But at any rate, I'd prefer either the ratio= nale should be in a few paragraphs, repeated in each document for which it&= #39;s relevant (in this case, all the documents pertaining to the peer-to-p= eer variant), or the rationale be in one of the documents, and all the othe= rs have a sentence saying "the rationale for why in some cases the pee= r-to-peer variant is desirable is in XXX".

Ba= ck to wishing a protocol could all be in one document...if it can't be,= I'd love a single roadmap document that points to all the pieces neede= d for understanding the protocol (and rationale, and proofs it works, and t= erminology, and anything else relevant), with an explanation about what is = in each one (rather than just saying "here are 17 other documents you = should read).

I'm not quite sure why documents= wind up in so many pieces.=C2=A0 I suppose in some cases something is adde= d after the fact (like "how to run this over X"), and it's ea= sier to come out with a tiny new simple document just for that, rather than= editing it into the main document.=C2=A0 But as a reader catching up on a = new technology, I'd find it easier to just read one, well-organized, co= mplete document.

Radia


On Thu, Mar 10,= 2016 at 11:28 AM, Dean Willis <dean.willis@softarmor.com><= /span> wrote:
= Thanks, Radia. Good catch on =E2=80=9Cthe the typo.=E2=80=9D

=
RFC 6940 has most of the security considerations for RELOAD (the= protocol that came out of this work), using the terminology from this docu= ment. In short, it boils down to the single-cert problem; the typical RELOA= D overlay has a simple PKI understructure, using a singular authority (the = enrollment server) that has a public key used to sign the credentials for e= ach enrollee.

RFC 5765 is, in its entirety, securi= ty considerations for P2P.

You actually ask a very= good question here about motivation, one that we spent a lot of time TALKI= NG about, but apparently didn=E2=80=99t spend much time WRITING about. Ther= e were =E2=80=9Cscenarios=E2=80=9D drafts that covered motivations, but the= y didn=E2=80=99t get conserved into a publication-ready state. An example i= s=C2=A0https://tools.ietf.org/html/draft-jia= ng-p2psip-peer-protocol-requirement-01

The sho= rt answer to your concern is that the =E2=80=9Cenrollment=E2=80=9D process = happens on the order of N times, where N is the number of nodes participati= ng in the overlay (multiplied some relatively low expiry rate). But registr= ation and resolution (aka, rendezvous) operations are vastly more frequent,= happening (at the least) every time the IP address of a node changes (or i= n SIP, every 30 seconds, just in case), =C2=A0and every time one node needs= to contact another (which scales with the link-density of the network, typ= ically an exponential).=C2=A0

Practically speaking= , an enrollment server can run on a typical LAMP stack with one box (or per= haps a redundant pair) supporting millions of users. But the rendezvous pro= blem is more like trying to run the Internet on dynamic DNS servers =E2=80= =94 it gets gnarly quickly.

Further, if enrollment= breaks, no new nodes can be added, but existing nodes continue to work. Bu= t if rendezvous breaks, the whole system grinds to a halt.=C2=A0
=
Rendezvous, therefore, benefits from a high level of distrib= ution =E2=80=94 both from a load scaling and a resilience perspective.=C2= =A0

Yet another issue is that the traditional SIP = proxy/registrar represents a very rich target for interception of communica= tions metadata. If every movement of a user =C2=A0and every communications = between any two users =C2=A0is mediated by a single box, that box becomes a= very high priority target. The attack surface is narrow, but the payoff is= huge. The P2P routing model, on the other hand, stores relatively little i= nformation at any given node, producing a broader attack surface, but requi= ring vastly more nodes to be compromised before overall opsec is diminished= . This is particularly significant in the scenario of a nation-state actor,= who must penetrate not just the local proxy-registrar but potentially mill= ions of foreign nodes in order to tap the metadata.

So, here=E2=80=99s the question: Where should such motivations be documen= ted? Do they belong in the terminology document? I can see making this into= a terminology-and-rationale document. Do they belong in the protocol speci= fications?

=E2=80=94
Dean
<= br>


On Mar 10, = 2016, at 11:57, Radia Perlman <radiaperlman@gmail.com> wrote:

(Sorry...I'm resending because = I mistyped and sent to=C2=A0draft-i= etf-p2psip-concept.all@tools.ietf.org the first time)

I have reviewed this documen= t as part of the security directorate's ongoing effort to review all IE= TF documents being processed by the IESG. These comments were written prima= rily for the benefit of the security area directors. Document editors and W= G chairs should treat these comments just like any other last call comments= .

This document is titled "Concepts and Term= inology for Peer to Peer SIP", and as such would have no security cons= iderations, as noted in the document.

However, thi= s document describes how to discover which host a client is at, instead of = using a SIP proxy, by using a peer-to-peer network and DHT.

<= /div>
I'd have liked a motivation for why this would be a preferabl= e mechanism.=C2=A0 It seems like it would be less secure, in that more thin= gs will need to be trusted.=C2=A0 And furthermore, as this document says in= section 5.4:

"The P2PSIP WG does not im= pose a particular mechanism for how the
=C2=A0peer-ID and the cre= dentials are obtained, but the RELOAD protocol
=C2=A0does specify= the format for the configuration information."

I'd think the hard problems would be things like who to get a creden= tial from for joining the peer-to-peer group of proxies, and how that entit= y would decide whether you should be trusted to join the peer-to-peer group= .=C2=A0 And if there is such a trusted entity (a central administration), w= hy wouldn't the whole discovery process be more centralized?
=
Also, with a peer-to-peer DHT, it seems like there are more = things that need to be trusted.=C2=A0 Any of them acting maliciously can ca= use incorrect answers.

Admittedly, I didn't re= ad all the background documents.

There's a min= or typo in section 2.2, clearly a cut and paste error:

=
"A special peer may be a member of the in the P2PSIP overlay= "

Radia




--047d7b2e3f74e5dcf2052df81457-- From nobody Tue Mar 15 10:28:59 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D46A12D65C for ; Tue, 15 Mar 2016 10:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50C7NxDP1qaJ for ; Tue, 15 Mar 2016 10:28:56 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAC312DA35 for ; Tue, 15 Mar 2016 10:28:56 -0700 (PDT) Received: by mail-lb0-x22a.google.com with SMTP id k12so31729765lbb.1 for ; Tue, 15 Mar 2016 10:28:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=na1pJBJY4aW15aWAo7stMvzGsPbYnEu/ds0ri8Il1LI=; b=jHJXOZ/aGYCjsw74PBKjf7ihWHr9s0pU/bBBWbIqrekCgvYtOpSzvB+l/W70jcIdS1 aGD0ExrJC7sPqbyqnV3oA5OJbW0w8IR+t2G/YHOVPysjji87u06xCb9FF4xYn6M2qqMz njgKmOnwQ+bWKe4DxGqd2XEmSo7K7o6PMjz1O7HCownnHE6/QGGQj8gzYAjKUhEeflFS UWh/gAl/MgYuwaT4mNGKXh8JcUjyEQvbOKiRVcHQwNt4MpiU78NQEzzcfJldQ0ut1IMU aHBFltQes/dfald6wrlWrMy1Ikfd32UTfHCR6tuq25iesG5zWSRAwl9DkxhN86h75Uni RbuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=na1pJBJY4aW15aWAo7stMvzGsPbYnEu/ds0ri8Il1LI=; b=GYuezH+CRLs4MUXJituJNECjYxaQaJM9WDBBkjuwhSAuo1mlyCP5c5EvdkKF7hOuJq +iftq0qb/JLNA87lxusCbnkJQVc7+de6xw6WhRDUfE4yFnBjGY6Y3wc0Bb4fzawNi0p/ BL9soJKaCw2OFfHQ9tkD+XYD0tUpbA9QBgKho1BpK8oFDXI7ucTUzHsMprcHzTflg3GX P8zT6e52PXqivdKftTffYAeQlrni/gkNBUDbyAfD4m7AMxXQHY8HOc2ypeHVfCTuIo0b PIQgF7ko4DvK/1gXUAEJJKo/L8FaFP9UNkZqrrJpWvmDOXy2zLyOOScFgM4GbA3nUpGj iieA== X-Gm-Message-State: AD7BkJJJ4uFYfYv9ctOAL8FKEObBSk9fi28UBet0hUmlG86VEh8AAtpV2cqzG/58LtzO4+A6B+DiiXUUaPlAUQ== MIME-Version: 1.0 X-Received: by 10.112.156.6 with SMTP id wa6mr10187326lbb.66.1458062934593; Tue, 15 Mar 2016 10:28:54 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Tue, 15 Mar 2016 10:28:54 -0700 (PDT) In-Reply-To: References: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> Date: Tue, 15 Mar 2016 10:28:54 -0700 Message-ID: From: Andy Bierman To: Tom Yu Content-Type: multipart/alternative; boundary=089e01161bf446edf0052e19bbd5 Archived-At: Cc: Mahesh Jethanandani , draft-ietf-netconf-yang-library.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 17:28:58 -0000 --089e01161bf446edf0052e19bbd5 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 25, 2016 at 5:01 PM, Tom Yu wrote: > Hi Mahesh, > > Sorry about the delay. > > I was looking at the specific comments in the Security Considerations of > this document about the sensitivity of the contents of /modules/module. > How do the risks of an attacker being able to inspect /modules/module > compare with other information that could be available to an attacker, > such as fingerprinting through non-NETCONF means? > > If an attacker has limited NETCONF access on a server, what would the > contents of /modules/module reveal to the attacker that might not > otherwise be discovered by other kinds of probing within the NETCONF > protocol? > > The YANG library provides the same information that is currently in the NETCONF message. It is expected that NACM (RFC 6536) will be used to prevent access to sensitive operations, notifications, and data. However NACM is optional-to-implement with NETCONF and RESTCONF. The risk is the same as current NETCONF. If a specific module/revision implementation is known to be vulernable, then NETCONF and this library both let the client know it is running on the server. > These other risks might be trivial in comparison to the one mentioned in > the document, but lacking specific knowledge of the broader context of > NETCONF and how it is deployed, I'm not sure how they compare. For > example, is it expected that anonymous or minimally trusted users could > be authorized to use NETCONF to access some public information about a > server? > If NACM is implemented and deployed correctly, no. Otherwise -- yes, if all users have all access to all YANG modules, > > If these other risks are similar in magnitude to the possible exposures > allowed by /modules/module, you should consider mentioning them, and > give the implementor or operator some guidance about how to weigh these > risks. If the exposures allowed by /modules/module vastly outweigh > those from other avenues of obtaining similar capability or > configuration information, in most environments and forseeable > deployments, maybe the current text is sufficient. > > -Tom > Andy > > Mahesh Jethanandani writes: > > > Tom, > > > > It is not entirely clear from this e-mail, what action you want the > authors to take. > > > > YANG module information or more like its encodings are sent over a > secure session (SSH/TLS) and are no more specific to this draft than they > are to any NETCONF/RESTCONF session. As such it is not clear what you want > the authors to do. Could you clarify or provide text for the Security > Consideration section? > > > > Thanks. > > > >> On Feb 1, 2016, at 6:03 PM, Tom Yu wrote: > >> > >> I have reviewed this document as part of the security directorate's > >> ongoing effort to review all IETF documents being processed by the > >> IESG. These comments were written primarily for the benefit of the > >> security area directors. Document editors and WG chairs should treat > >> these comments just like any other last call comments. > >> > >> The Security Considerations of this document seem reasonable. It might > >> be useful to add a comparison of the risks posed by sensitive > >> information exposed by this YANG module with information exposed by > >> other aspects of NETCONF, or available through methods such as > >> fingerprinting. Admittedly, a meaningful comparison might be highly > >> context-specific, so a general comparison might have limited utility. > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > --089e01161bf446edf0052e19bbd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 25, 2016 at 5:01 PM, Tom Yu <tlyu@mit.edu> wrot= e:
Hi Mahesh,

Sorry about the delay.

I was looking at the specific comments in the Security Considerations of this document about the sensitivity of the contents of /modules/module.
How do the risks of an attacker being able to inspect /modules/module
compare with other information that could be available to an attacker,
such as fingerprinting through non-NETCONF means?

If an attacker has limited NETCONF access on a server, what would the
contents of /modules/module reveal to the attacker that might not
otherwise be discovered by other kinds of probing within the NETCONF
protocol?



The YANG library provid= es the same information that is currently
in the NETCONF <hell= o> message.

It is expected that NACM (RFC 6536)= will be used to prevent access
to sensitive operations, notifica= tions, and data.
However NACM is optional-to-implement with NETCO= NF and RESTCONF.

The risk is the same as current N= ETCONF.
If a specific module/revision implementation is known to<= /div>
be vulernable, then NETCONF and this library both let
t= he client know it is running on the server.



=C2=A0
These other risks might be trivial in comparison to the one mentioned in the document, but lacking specific knowledge of the broader context of
NETCONF and how it is deployed, I'm not sure how they compare.=C2=A0 Fo= r
example, is it expected that anonymous or minimally trusted users could
be authorized to use NETCONF to access some public information about a
server?


If NACM is imple= mented and deployed correctly, no.
Otherwise -- yes, if all users= have all access to all YANG modules,
=C2=A0

If these other risks are similar in magnitude to the possible exposures
allowed by /modules/module, you should consider mentioning them, and
give the implementor or operator some guidance about how to weigh these
risks.=C2=A0 If the exposures allowed by /modules/module vastly outweigh those from other avenues of obtaining similar capability or
configuration information, in most environments and forseeable
deployments, maybe the current text is sufficient.

-Tom


Andy
=C2= =A0

Mahesh Jethanandani <mjethana= ndani@gmail.com> writes:

> Tom,
>
> It is not entirely clear from this e-mail, what action you want the au= thors to take.
>
> YANG module information or more like its encodings are sent over a sec= ure session (SSH/TLS) and are no more specific to this draft than they are = to any NETCONF/RESTCONF session. As such it is not clear what you want=C2= =A0 the authors to do. Could you clarify or provide text for the Security C= onsideration section?
>
> Thanks.
>
>> On Feb 1, 2016, at 6:03 PM, Tom Yu <tlyu@mit.edu> wrote:
>>
>> I have reviewed this document as part of the security directorate&= #39;s
>> ongoing effort to review all IETF documents being processed by the=
>> IESG.=C2=A0 These comments were written primarily for the benefit = of the
>> security area directors.=C2=A0 Document editors and WG chairs shou= ld treat
>> these comments just like any other last call comments.
>>
>> The Security Considerations of this document seem reasonable.=C2= =A0 It might
>> be useful to add a comparison of the risks posed by sensitive
>> information exposed by this YANG module with information exposed b= y
>> other aspects of NETCONF, or available through methods such as
>> fingerprinting.=C2=A0 Admittedly, a meaningful comparison might be= highly
>> context-specific, so a general comparison might have limited utili= ty.
>
> Mahesh Jethanandani
> mjethanandani@gmail.com=

--089e01161bf446edf0052e19bbd5-- From nobody Tue Mar 15 15:40:16 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF95E12DACF; Tue, 15 Mar 2016 14:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1458076026; bh=0r8JPlVp+ZS5RJia+JwPrSY0disdIo8bI+NEG49UdmM=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=bYWL0UW1Nrrtoiz4VtnKq4yb58fWKT0MUlpBzC1oLNDGGT25bipnm/hLPDVzjNfm9 edPERc4P8igJE23p8X9mwuWbVtVRUtcQWqEJtch2pdQH2wqJRmCiifw7tGJmwgi2PX 8H4SVUblPw6id6vj4gXragBsNMjC6T4YeDaJElbE= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA54A12D869 for ; Tue, 15 Mar 2016 14:06:50 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: Message-ID: <20160315210650.5419.43936.idtracker@ietfa.amsl.com> Date: Tue, 15 Mar 2016 14:06:50 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 15 Mar 2016 15:40:14 -0700 Subject: [secdir] [new-work] WG Review: Constrained RESTful Environments (core) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 21:07:06 -0000 The Constrained RESTful Environments (core) WG in the Applications and Real-Time Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2016-03-25. Constrained RESTful Environments (core) ----------------------------------------------------------------------- Current status: Active WG Chairs: Carsten Bormann Andrew McGregor Assigned Area Director: Barry Leiba Applications and Real-Time Area Directors: Barry Leiba Ben Campbell Alissa Cooper Mailing list: Address: core@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/core Archive: https://mailarchive.ietf.org/arch/browse/core/ Charter: https://datatracker.ietf.org/doc/charter-ietf-core/ CoRE provides a framework for resource-oriented applications intended to run on constrained IP networks. A constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time. These networks and the nodes within them are characterized by severe limits on throughput, available power, and particularly on the complexity that can be supported with limited code size and limited RAM per node [RFC 7228]. More generally, we speak of constrained node networks whenever at least some of the nodes and networks involved exhibit these characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) are an example of this type of network. Constrained networks can occur as part of home and building automation, energy management, and the Internet of Things. The CoRE working group will define a framework for a limited class of applications: those that deal with the manipulation of simple resources on constrained networks. This includes applications to monitor simple sensors (e.g. temperature sensors, light switches, and power meters), to control actuators (e.g. light switches, heating controllers, and door locks), and to manage devices. The general architecture consists of nodes on the constrained network, called Devices, that are responsible for one or more Resources that may represent sensors, actuators, combinations of values, and/or other information. Devices send messages to change and query resources on other Devices. Devices can send notifications about changed resource values to Devices that have expressed their interest to receive notification about changes. A Device can also publish or be queried about its resources. (Typically a single physical host on the network would have just one Device but a host might represent multiple logical Devices. The specific terminology to be used here is to be decided by the working group.) As part of the framework for building these applications, the working group has defined a Constrained Application Protocol (CoAP) for the manipulation of Resources on a Device. CoAP is designed for use between Devices on the same constrained network, between Devices and general nodes on the Internet, and between Devices on different constrained networks both joined by an internet. (CoAP is also being used via other mechanisms, such as SMS on mobile communication networks.) CoAP targets the type of operating environments defined in the ROLL and 6Lo working groups which have additional constraints compared to normal IP networks, but the CoAP protocol also operates over traditional IP networks. There also may be proxies that interconnect between other Internet protocols and the Devices using the CoAP protocol. It is worth noting that proxy does not have to occur at the boundary between the constrained network and the more general network, but can be deployed at various locations in the less-constrained network. CoAP supports various forms of "caching". Beyond the benefits of caching already well known from REST, caching can be used to increase energy savings of low-power nodes by allowing them to be normally-off [RFC 7228]. For example, a temperature sensor might wake up every five minutes and send the current temperature to a proxy that has expressed interest in notifications; when the proxy receives a request over CoAP or HTTP for that temperature resource, it can respond with the last notified value (instead of trying to query the Device which may not be reachable at this time). The working group will continue to evolve this model to increase its practical applicability. The working group will perform maintenance on its first four standards-track specifications: - RFC 6690 - RFC 7252 - RFC 7641 - draft-ietf-core-block and will continue to evolve the experimental group communications support (RFC 7390). The working group will not develop a reliable multicast solution. CoAP today works over UDP and DTLS. The working group will define transport mappings for alternative transports as required, both IP (starting with TCP and a secure version over TLS) and non-IP (e.g., SMS, working with the security area on potentially addressing the security gap); this includes defining appropriate URI schemes. Continued compatibility with CoAP over SMS as defined in OMA LWM2M will be considered. CoRE will continue and complete its work on draft-ietf-core-resource-directory, as already partially adopted by OMA LWM2M. Interoperability with DNS-SD (and the work of the dnssd working group) will be a primary consideration. The working group will also work on a specification enabling broker-based publish-subscribe-style communication over CoAP. CoRE will work on related data formats, such as alternative representations of RFC 6690 link format and RFC 7390 group communication information. The working group will complete the SenML specification, again with consideration to its adoption in OMA LWM2M. RFC 7252 defines a basic HTTP mapping for CoAP, with further discussion in draft-ietf-core-http-mapping. This mapping will be evolved and supported by further documents. Besides continuing to examine operational and manageability aspects of the CoAP protocol itself, CoRE will also develop a way to make RESTCONF-style management functions available via CoAP that is appropriate for constrained node networks. This will require very close coordination with NETCONF and other operations and management working groups. YANG data models will be used for manageability. Note that the YANG modeling language is not a target for change in this process, though additional mechanisms that support YANG modules may be employed in specific cases where significant performance gains are both attainable and required. The working group will continue to consider the OMA LWM2M management functions as a well-accepted alternative form of management and provide support at the CoAP protocol level where required. The working group has selected DTLS as the basis for the communications security in CoAP. CoRE will work with the TLS working group on the efficiency of this solution. The preferred cipher suites will evolve in cooperation with the TLS working group and CFRG. The ACE working group is expected to provide solutions to authorization that may need complementary elements on the CoRE side. Object security as defined in JOSE and being adapted to the constrained node network requirements in COSE also may need additions on the CoRE side. The working group will coordinate on requirements from many organizations and SDO. The working group will closely coordinate with other IETF working groups, particularly of the constrained node networks cluster (6Lo, 6TiSCH, LWIG, ROLL, ACE, COSE), and appropriate groups in the IETF OPS and Security areas. Work on these subjects, as well as on interaction models and design patterns (including follow-up work around the CoRE Interfaces draft) may benefit from close cooperation with the proposed Thing-to-Thing Research Group. Milestones: TDB _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Mar 16 05:28:54 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC27B12D1E5; Wed, 16 Mar 2016 05:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqEKgA3sRa9t; Wed, 16 Mar 2016 05:28:52 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D875712D585; Wed, 16 Mar 2016 05:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2584; q=dns/txt; s=iport; t=1458131329; x=1459340929; h=from:to:subject:date:message-id:mime-version; bh=DVBj2UudGWwkovwdaWUGQ1FlxdfJwKFiG1GiC4GWd7U=; b=YPF8dK+euU420a0L4DHvW1TJSh+twV6ZGvaw+ljNNOgTYIYjkXVcT5By 2QY1x0zWu5VZMFppHzu8/iQn9vRTPkJZRno1n5zE0Z4pNloUXuXtQ43nd LWJL988kCr5CIISCndSkdgzss945F3BQRn+YovK42zzbJkFF1JCcW5BBM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWBQCWUOlW/4YNJK1eg0apCpJHgW+GK?= =?us-ascii?q?4EiOhIBAQEBAQEBZCeESCNoAQwBPQIEMCcEAYg5r1aPVAEBAQEBAQEBAgEBAQE?= =?us-ascii?q?BAQEBGIYegXOKDSuBDwWXUQGOAI8Fjn4BJwI5g2WLTQEBAQ?= X-IronPort-AV: E=Sophos; i="5.24,344,1454976000"; d="scan'208,217"; a="83384738" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Mar 2016 12:28:49 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u2GCSmMx004994 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Mar 2016 12:28:49 GMT Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 16 Mar 2016 07:28:48 -0500 Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1104.009; Wed, 16 Mar 2016 07:28:48 -0500 From: "Klaas Wierenga (kwiereng)" To: "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-imapapnd-rfc2088bis.all@tools.ietf.ofg" Thread-Topic: draft-ietf-imapapnd-rfc2088bis-04 Thread-Index: AQHRf39jfLr0Hb/Ac02S5byxZLtYrQ== Date: Wed, 16 Mar 2016 12:28:48 +0000 Message-ID: <403E5EE1-B5BD-4BFE-92E1-542526A07DCD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_403E5EE1B5BD4BFE92E1542526A07DCDciscocom_" MIME-Version: 1.0 Archived-At: Subject: [secdir] draft-ietf-imapapnd-rfc2088bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 12:28:53 -0000 --_000_403E5EE1B5BD4BFE92E1542526A07DCDciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2Vj dXJpdHkgZGlyZWN0b3JhdGUncw0Kb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRv Y3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQpJRVNHLiAgVGhlc2UgY29tbWVudHMgd2Vy ZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlDQpzZWN1cml0eSBhcmVh IGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQN CnRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0K DQpUaGUgZG9jdW1lbnQgZGVzY3JpYmVzIDIgSU1BUCBleHRlbnNpb25zLCBMSVRFUkFMKyBhbmQg TElURVJBTC0gdGhhdCBhbGxvdyBmb3Igbm9uIHN5bmNocm9uaXppbmcgbGl0ZXJhbHMuDQoNCkkg YmVsaWV2ZSB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbg0KDQpLbGFhcw0K DQpTZW50IGZyb20gbXkgaVBhZA0K --_000_403E5EE1B5BD4BFE92E1542526A07DCDciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PkhpLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIGNsYXNzPSJ3aWtp IiBzdHlsZT0iYm9yZGVyOiAxcHggc29saWQgcmdiKDIxNSwgMjE1LCAyMTUpOyBtYXJnaW4tcmln aHQ6IDEuNzVlbTsgbWFyZ2luLWxlZnQ6IDEuNzVlbTsgcGFkZGluZzogMC4yNWVtOyBvdmVyZmxv dzogYXV0bzsiPjxmb250IGZhY2U9IlVJQ1RGb250VGV4dFN0eWxlVGFsbEJvZHkiPjxzcGFuIHN0 eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1 LCAyNTUsIDApOyI+SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUg c2VjdXJpdHkgZGlyZWN0b3JhdGUncyANCm9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVU RiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSANCklFU0cuICBUaGVzZSBjb21tZW50 cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgDQpzZWN1cml0 eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQg dHJlYXQgDQp0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21t ZW50cy48L3NwYW4+PC9mb250PjwvcHJlPg0KPGRpdj5UaGUgZG9jdW1lbnQgZGVzY3JpYmVzIDIg SU1BUCBleHRlbnNpb25zLCBMSVRFUkFMJiM0MzsgYW5kIExJVEVSQUwtIHRoYXQgYWxsb3cgZm9y IG5vbiBzeW5jaHJvbml6aW5nIGxpdGVyYWxzLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCkkgYmVsaWV2ZSB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+S2xhYXM8L2Rpdj4NCjxkaXY+PGJyPg0KPGRpdj5T ZW50IGZyb20gbXkgaVBhZDwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_403E5EE1B5BD4BFE92E1542526A07DCDciscocom_-- From nobody Wed Mar 16 05:43:15 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2043C12D943; Wed, 16 Mar 2016 05:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQxlYxqeJQSG; Wed, 16 Mar 2016 05:43:09 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2852312D942; Wed, 16 Mar 2016 05:43:09 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id h129so59878139ywb.1; Wed, 16 Mar 2016 05:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=c+fl7g4BFGiQcHlZQZuNddTTVYyftcH1D92xksdPcKQ=; b=0n+MuHcSGsBUuyd/qVMzn13e6+NkA9tf94znRC1jDgG2x5HD7ezTUWcY3daWdFJ0Gg DZG3vXxOd8OC2lf+8ytj1yRXB2L3VRVCp6OBt39NcuTolF54vTJtCu86I0qWEWaED6rn m1kIlz4Z+zA3goow/IqC2EUKCFVwHIHmwYrzy3jqkI12yBCGFReHmnCmYStbb5AJi/+P quf20xWzQzsnpLOhOTpNHMvq5yP/DMbZ1HWoEvYWpsTqN7AtkEkBwOBVEdrUc+jPczSI Cm33PxQi14UdKWFsuepw5vYFz/O2woE1k/BqiKi3f4eH33YRQY+1Gk4IPeHxEfurY1NS eyCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=c+fl7g4BFGiQcHlZQZuNddTTVYyftcH1D92xksdPcKQ=; b=idhyxVq4Ui6nynxeTmVYWfKYU0w80eINruLfGm1LS4Q3P7zwpar6IKnC0PInN10eAu Pnv0pNdXKTJ+MBC6xnDrBFwHOBYKybPU8J/zB63V2DOncJzNJuU1OOQU41gcOWY9X16j tDAmhNGUBd8cjacYWLAr5ojFvqHZvufrZEvxcgY5xIRP/kaiQEKtD96TvURCRId2BAl/ aK3hN87P+D721ki1OSlZWNjAkISukOr3qQEtcSSJlVcc/qwGZWXZiJLIQZHC+1GTSast g1jdH0eZ/UcCLcMTqNiB3LACrV9fhydyxUfmROvMHYXYH5aj7iS3Q1xNgA2sm18IphIQ ANdA== X-Gm-Message-State: AD7BkJJISieCV+gCY9ryGjxKTbpJ9LVnCwlSVZKyz8XCGwUBwGLPRGACLSoCe/PpVpIIWXI0SAL5D05XmGX12g== MIME-Version: 1.0 X-Received: by 10.129.71.135 with SMTP id u129mr1864709ywa.162.1458132188312; Wed, 16 Mar 2016 05:43:08 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.78.193 with HTTP; Wed, 16 Mar 2016 05:43:08 -0700 (PDT) In-Reply-To: <403E5EE1-B5BD-4BFE-92E1-542526A07DCD@cisco.com> References: <403E5EE1-B5BD-4BFE-92E1-542526A07DCD@cisco.com> Date: Wed, 16 Mar 2016 08:43:08 -0400 X-Google-Sender-Auth: KTVZdPTuIOitEm4GCnpwimEZ8Kg Message-ID: From: Barry Leiba To: "Klaas Wierenga (kwiereng)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-imapapnd-rfc2088bis.all@tools.ietf.ofg" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-imapapnd-rfc2088bis-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 12:43:11 -0000 Thanks for the review, Klaas. Barry On Wed, Mar 16, 2016 at 8:28 AM, Klaas Wierenga (kwiereng) wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The document describes 2 IMAP extensions, LITERAL+ and LITERAL- that allow > for non synchronizing literals. > > I believe this document is ready for publication > > Klaas > > Sent from my iPad From nobody Wed Mar 16 18:04:27 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D6212D565 for ; Wed, 16 Mar 2016 18:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMeEIMqEVG-K for ; Wed, 16 Mar 2016 18:04:24 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098C112D518 for ; Wed, 16 Mar 2016 18:04:23 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u2H14Lrn011005 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Mar 2016 03:04:21 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u2H14Ldo016362; Thu, 17 Mar 2016 03:04:21 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22250.661.833924.358744@fireball.acr.fi> Date: Thu, 17 Mar 2016 03:04:21 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 01:04:25 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Alan DeKok is next in the rotation. For telechat 2016-03-17 Reviewer LC end Draft Chris Inacio T 2016-02-02 draft-ietf-v6ops-ipv6-ehs-in-real-world-02 Benjamin Kaduk TR2016-02-09 draft-ietf-tsvwg-circuit-breaker-13 Charlie Kaufman TR2016-03-14 draft-ietf-i2rs-architecture-13 Alexey Melnikov T 2016-03-07 draft-wallace-est-alt-challenge-04 Eric Osterweil T 2016-03-09 draft-ietf-netmod-yang-metadata-06 Tina TSOU T 2016-03-15 draft-ietf-dprive-dns-over-tls-08 Sean Turner T 2016-03-15 draft-ietf-netext-pmipv6-flowmob-17 David Waltermire T 2016-03-17 draft-ietf-aqm-fq-codel-05 For telechat 2016-04-21 Derek Atkins T 2016-04-19 draft-ietf-lager-specification-10 Joe Salowey T 2016-03-09 draft-ietf-rtcweb-audio-codecs-for-interop-05 Carl Wallace T 2016-03-30 draft-schoenw-opsawg-copspr-historic-03 Brian Weis T 2016-03-22 draft-ietf-cdni-footprint-capabilities-semantics-12 Frank Xialiang T 2016-04-08 draft-alakuijala-brotli-08 Last calls and special requests: Shaun Cooley 2016-03-29 draft-ietf-pce-iro-update-06 Donald Eastlake R2016-02-22 draft-ietf-dane-openpgpkey-07 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Jeffrey Hutzelman 2015-12-04 draft-ietf-core-block-18 Eric Osterweil 2016-01-05 draft-campbell-art-rfc5727-update-03 Yaron Sheffer 2016-03-09 draft-ietf-v6ops-host-addr-availability-05 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-13 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-04 Sam Weiler 2016-03-18 draft-ietf-avtext-sdes-hdr-ext-05 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-06 Paul Wouters 2016-03-23 draft-ietf-radext-bigger-packets-05 Tom Yu 2016-03-24 draft-ietf-dime-drmp-04 Dacheng Zhang 2016-03-28 draft-ietf-grow-route-leak-problem-definition-04 -- kivinen@iki.fi From nobody Thu Mar 17 03:32:00 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B1C12D5BF; Thu, 17 Mar 2016 03:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFwfFOSqP6uM; Thu, 17 Mar 2016 03:31:51 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id A975B12D74F; Thu, 17 Mar 2016 03:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1458210705; d=isode.com; s=selector; i=@isode.com; bh=U31s6ijCSQuXZxvQ6GfP5jL7BtiGq2QpjXRvjj18uQc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=HXTB8tCLFVuyA0A3n6RBOozwAN/QM0I/MhSJKxJGURwX0rmUUZiAt1/nj/RJRIRRJcr2Qk rrm5T5vRpAUqxnbW19jvBfC2kqBbJHYSkyttybbZbuJtfcLxOl3nCPo/UaDq08r+WndCek 9ZTqhaSL7k3gKpYqJjacM7HlwFEZKCM=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 17 Mar 2016 10:31:44 +0000 From: Alexey Melnikov To: "secdir@ietf.org" , draft-wallace-est-alt-challenge.all@ietf.org Message-ID: <56EA875D.9050805@isode.com> Date: Thu, 17 Mar 2016 10:30:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] Secdir review of draft-wallace-est-alt-challenge-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 10:31:55 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines the otpChallenge attribute for use when a one- time password (OTP) value within the CSR is a requirement. The revocationChallenge attribute is defined to allow disambiguated usage of the original challenge password attribute semantics for certificate revocation. The estIdentityLinking attribute is defined to reference existing EST challenge password semantics with no potential for confusion with legacy challenge password practices. These attributes provide disambiguation of the existing overloaded uses for the challengePassword attribute defined in PKCS (Public-Key Cryptography Standards) #9 [RFC2985]. The Security Consideration seems adequate. I found one issue in the ASN.1 module in Appendix A, but it was fixed in the most recent version. So the document is ready for publication. From nobody Thu Mar 17 07:31:17 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4D012D5A7; Thu, 17 Mar 2016 07:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3VxgrWJuOcx; Thu, 17 Mar 2016 07:31:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8138312D50F; Thu, 17 Mar 2016 07:31:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4C255BE59; Thu, 17 Mar 2016 14:31:12 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RMpP4TgI4Af; Thu, 17 Mar 2016 14:31:04 +0000 (GMT) Received: from [10.87.48.83] (unknown [86.42.16.188]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E6762BE57; Thu, 17 Mar 2016 14:31:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458225064; bh=wJPOlEqb6GeYv/EZPw+Lk1YIUXwhVTexst7uZ4oD2kI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=r5TUp6a/dH2XjVOODRUYlDmZDxZdq1k/Y1kIC/yL0bdvuJJzyvnhZuR4YS3iiM9in jY80uGGzG++ta3CXXXtqYPoji3hqGGmYJPOy/ogWBnXV7TIuryAG3oSsE5mFwacOah g4ov/x/y0mQkzzUNBbSP2sumtRXKTdEMQVj4Gkr8= To: Ladislav Lhotka , Hilarie Orman , iesg@ietf.org, secdir@ietf.org References: <201603072216.u27MG09g002861@rumpleteazer.rhmr.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56EABFA7.6050506@cs.tcd.ie> Date: Thu, 17 Mar 2016 14:31:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020409070901080509020200" Archived-At: Cc: draft-ietf-netmod-yang-json.all@tools.ietf.org Subject: Re: [secdir] Security review of draft-ietf-netmod-yang-json-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 14:31:16 -0000 This is a cryptographically signed message in MIME format. --------------ms020409070901080509020200 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi folks, This thread seemed to just trail off. Hilarie, did you want to follow up more or do we think the document is all set? Thanks, S. On 08/03/16 15:31, Ladislav Lhotka wrote: > Hi Hilarie, >=20 > thank you for the review, please se my responses inline. >=20 > Hilarie Orman writes: >=20 >> Security review of >> JSON Encoding of Data Modeled with YANG draft-ietf-netmod-yang-json-08= >> >> Do not be alarmed. I have reviewed this document as part of the >> security directorate's ongoing effort to review all IETF documents >> being processed by the IESG. These comments were written primarily >> for the benefit of the security area directors. Document editors and >> WG chairs should treat these comments just like any other last call >> comments. >> >> "This document defines encoding rules for representing configuration, >> state data, parameters of RPC operations or actions, and notifications= >> defined using YANG as JavaScript Object Notation (JSON) text. YANG is= >> a data modeling language originally designed to model configuration >> and state data manipulated by the Network Configuration Protocol >> (NETCONF), NETCONF remote procedure calls, and NETCONF notifications."= >> >> I have no specific recommendation for an action on this, just >> some observations. >> >> I'm not an expert on YANG, JSON, or XML, but I was taken aback to read= >> in section 5.5: >> >> Anydata data node serves as a container for an arbitrary set of n= odes >> that otherwise appear as normal YANG-modeled data. A data model = for >> anydata content may or may not be known at run time. In the latt= er >> case, converting JSON-encoded instances to the XML encoding defin= ed >> in [I-D.ietf-netmod-rfc6020bis] may be impossible. >=20 > An "anydata" node represents data for which no schema is specified in > the data model. The schema for such data may be known at run time, but > the consensus in the NETMOD WG was to keep the possibility that this is= > not the case. And if the schema is not available, translation between > XML and JSON encodings cannot be done because, for example, we use the > data model info for translating namespace identifiers. >=20 > As long as we want to keep the option of specifying schema-less data in= > the data model, we have to live with this. I don't think it is really > ominous, also because normal configuration and state data should almost= > never be modelled with "anydata". >=20 >> >> That seems ominous, and there are other warnings about the force >> fitting of JSON and XML: >> >> "JSON processing is rather different from XML, and JSON parsers may= >> thus suffer from other types of vulnerabilities than their XML >> counterparts. To minimize these new security risks, software on th= e >> receiving side SHOULD reject all messages that do not comply to the= >> rules of this document and reply with an appropriate error message = to >> the sender." >=20 > Implementors might be tempted to apply the Postel Principle and be > liberal on the receiving side. This paragraph warns against doing so, > unless, of course, the implementor knows what he or she is doing. >=20 >> >> The security section refers back to the security considerations in >> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-11 >> section 16 (should be 17) where we read: >> >> "Data modeled in YANG might contain sensitive information. RPCs or= >> notifications defined in YANG might transfer sensitive information.= " >> >> "YANG parsers need to be robust with respect to malformed documents= =2E >> Reading malformed documents from unknown or untrusted sources could= >> result in an attacker gaining privileges of the user running the YA= NG >> parser. In an extreme situation, the entire machine could be >> compromised." >> >> There being no succinct description of correctness of YANG, JSON, or >> XML for NETCONF data, how would one determine that any of it, >> including mappings from one to another, was "robust"? If that simply >=20 > In fact, it is one of the most important virtues of data modelling that= > the correctness of configuration or state data can be reliably > verified. In the context of draft-ietf-netmod-yang-json, correctness ha= s > two aspects: >=20 > 1. All data is required to be I-JSON compliant [RFC 7493] which helps > avoid common JSON-specific interoperability and security problems. >=20 > 2. The data model precisely specifies the schema, data types of all > values, and also semantic constraints. >=20 > If an implementor pays attention to data model definitions (including > textual descriptions), then I believe the risk of any data-induced > issues is effectively minimised. >=20 >> means "doesn't cause a buffer overflow or crash", I suppose it's >> achievable (and should be explicit). But how could anyone be sure >> that sensitive data was not leaked without a full analysis of the >> specifications of all the component parts? Perhaps this is an >> unaddressable question, but one does hope that the extreme situation >> does not occur. >> >=20 > This question isn't specific to this document - sensitive data may be > present in any encoding. It is also one of the duties of a good data > model to identify such data, and sec. 6 in RFC 6087 puts forward specif= ic > requirements in this direction. >=20 > Thanks, Lada >=20 --------------ms020409070901080509020200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMTcx NDMxMDNaMC8GCSqGSIb3DQEJBDEiBCB/7znP+BAFHzo5kesBF9AgM925eFfCGQk0Zt8vyy2R KjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCFGiIqYVQ1r62xaHBOEIJguNKPC6wH2HCO3YbezvRvzBaWcH4udmWC RZ6p1uGeHMlNH+qiZyWoPFVJezV2gR3UXFw/SnfM2NT5VP8AEJeKFqyzd6Hi0X6tfmm6Ui6R jph5xxjS2UAZjuRFBzmOGIKkSucLqjfilIzN1dqxrB+If82bgXIkNAek8MDkIMShlu2JbXB1 BK9o4UPhuna9ga3dc7MXaEnKTj3e+1adx59qvmbS/Qu/OrDHlIEthG9gPsxSMcDYqk455/x5 p9v1XkY/pcspRl5q/KSl6vqDjscZAYEbo0QbIaFAjzXIW4ZReSvMRRBeioEDxfJNbad+WsC+ AAAAAAAA --------------ms020409070901080509020200-- From nobody Thu Mar 17 10:17:04 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCAD12DC7A; Thu, 17 Mar 2016 10:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ta5kTSvQ2gv; Thu, 17 Mar 2016 10:17:00 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4CB12D9EC; Thu, 17 Mar 2016 10:13:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 77D44E2044; Thu, 17 Mar 2016 13:12:35 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 24201-10; Thu, 17 Mar 2016 13:12:31 -0400 (EDT) Received: from securerf.ihtfp.org (IHTFP-DHCP-159.IHTFP.ORG [192.168.248.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 594F0E2036; Thu, 17 Mar 2016 13:12:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1458234750; bh=CwoaeC8m7NEwhxG10o4XoocsQi2eeVZChh1QPVtZwJU=; h=From:To:Cc:Subject:Date; b=l7VFp1jpMLc9nLirAEkVmA3PPZye/JjQEhI+OxMIozBanvPJb4GGWw4Ill6Ly9/ZP mYfbHhQpbDLLUGiN6ICufPSS6HJkUWUjaHa4FafgK8h8epf55qdGyc+AIfNdwbxSFD LJZeSrklWYpmIx8Xj+xchPwy2bRKoK0yeXgoEejM= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u2HHCTtO005386; Thu, 17 Mar 2016 13:12:29 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Thu, 17 Mar 2016 13:12:29 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: asmus@unicode.org, lager-chairs@ietf.org, kim.davies@icann.org Subject: [secdir] sec-dir review of draft-ietf-lager-specification-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 17:17:01 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready to publish. Details: I did not validate the correctness of the XML Syntax or Schema. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Mar 17 10:30:49 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC84512DD58; Thu, 17 Mar 2016 10:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJFJmZ4V1O5q; Thu, 17 Mar 2016 10:30:41 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524F912DCB8; Thu, 17 Mar 2016 10:22:17 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id g3so108638629ywa.3; Thu, 17 Mar 2016 10:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=dXmPgbhICOvitVx1AdKz82EHo6lhUc/zlDOIbY9qCEs=; b=Sj3zb85Llt6Fgt5NQ8ggaqcEyLrbwHYG2kaisaCqAFzESPkvdu91kMcLFb5w4LX8gX SmxIWKj6qwHTJlXHg7XIHZF4Fh3x/sPeCOrGfLP0hJdTl3nz8SYPeBuF51D4uIh7QKRG uytL5h1BipPF8ddVgExJPdGDUfsmp+gYZNSTdwfIa+TPUv+T9kdmQ8RZZ3TpI4ZQpkty vor0MCVEiKVLpy9fCqIu+M0pAwWfzUIj4LCCQSqDQ0bc7y52xL6Q5f7JGU1heh2Piucp do0AqAa0w9UfmSY/z6QTP0JWVQoMd1Y2P8l9S93XdHh09vCRnwEDDRfFTxk4ymM50QOS m+sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=dXmPgbhICOvitVx1AdKz82EHo6lhUc/zlDOIbY9qCEs=; b=kmODi4VTIxApwAES2RSxqCZc9d+YWMQxP9jTmyIS6EvBw/kCXs/fuHLcVReVCNXL2O 2NAAtn0uB640KZOYDKjj+eRkujAa03mhe8Y4J82NwAkcY/7J5wornGkCtewYEmHEwsYy w0MP0z8hDiXIyAnkHC8/UPufbh3PLdglbGcK+ul0WsNrPy21ng+wJAZKpbQHs/UnSXoz rPZVTcAza8abg8oEE+q6jEYCGFXhYlqkVQTqtu9o5u0Fyl83bWMgvt7H+UlwXQj/p0+u ufYoTim+dUaBy/HdesfkZzdSRYMw0WlsoiVR/W7iI5tBT+vGjcL/aXkWuDpTHjg/P050 S1Lg== X-Gm-Message-State: AD7BkJL2x8sk/59chd4dkxH8DjWPHe/8wjtCEy5GNAhHLCx3Mhap9IEW8oenyErYjo7UJ1f6eQ7j5d+bxQv6nw== MIME-Version: 1.0 X-Received: by 10.129.0.65 with SMTP id 62mr4422949ywa.199.1458235336618; Thu, 17 Mar 2016 10:22:16 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.78.193 with HTTP; Thu, 17 Mar 2016 10:22:16 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Mar 2016 13:22:16 -0400 X-Google-Sender-Auth: BXgPmjnWYP6fNfY6M-JpD7nRGEM Message-ID: From: Barry Leiba To: Derek Atkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: lager-chairs@ietf.org, asmus@unicode.org, IESG , Kim Davies , "secdir@ietf.org" Subject: Re: [secdir] sec-dir review of draft-ietf-lager-specification-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 17:30:44 -0000 Thanks for the review, Derek. Barry On Thu, Mar 17, 2016 at 1:12 PM, Derek Atkins wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written with the intent of improving > security requirements and considerations in IETF drafts. Comments > not addressed in last call may be included in AD reviews during the > IESG review. Document editors and WG chairs should treat these > comments just like any other last call comments. > > Summary: > > Ready to publish. > > Details: > > I did not validate the correctness of the XML Syntax or Schema. > > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > From nobody Thu Mar 17 15:39:50 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903A612DD72; Thu, 17 Mar 2016 15:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjHtnIuBZrWa; Thu, 17 Mar 2016 15:39:36 -0700 (PDT) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E74F12DD61; Thu, 17 Mar 2016 15:39:36 -0700 (PDT) Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aggZr-0005Ud-0C; Thu, 17 Mar 2016 16:39:35 -0600 Received: from [72.250.219.84] (helo=rumpleteazer.rhmr.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1aggZm-0003Gp-Am; Thu, 17 Mar 2016 16:39:34 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u2HMdGkR018877; Thu, 17 Mar 2016 16:39:16 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id u2HMdFff018872; Thu, 17 Mar 2016 16:39:15 -0600 Date: Thu, 17 Mar 2016 16:39:15 -0600 Message-Id: <201603172239.u2HMdFff018872@rumpleteazer.rhmr.com> From: "Hilarie Orman" To: stephen.farrell@cs.tcd.ie In-reply-to: Yourmessage <56EABFA7.6050506@cs.tcd.ie> X-XM-AID: U2FsdGVkX19N05aqfimG6D4OzDnIW+Iz X-SA-Exim-Connect-IP: 72.250.219.84 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****;stephen.farrell@cs.tcd.ie X-Spam-Relay-Country: X-Spam-Timing: total 4205 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.7 (0.1%), b_tie_ro: 2.7 (0.1%), parse: 0.80 (0.0%), extract_message_metadata: 21 (0.5%), get_uri_detail_list: 4.4 (0.1%), tests_pri_-1000: 6 (0.1%), tests_pri_-950: 1.24 (0.0%), tests_pri_-900: 1.03 (0.0%), tests_pri_-400: 34 (0.8%), check_bayes: 33 (0.8%), b_tokenize: 10 (0.2%), b_tok_get_all: 12 (0.3%), b_comp_prob: 4.0 (0.1%), b_tok_touch_all: 4.1 (0.1%), b_finish: 0.58 (0.0%), tests_pri_0: 869 (20.7%), check_dkim_signature: 0.55 (0.0%), check_dkim_adsp: 174 (4.1%), tests_pri_500: 3266 (77.7%), poll_dns_idle: 3256 (77.4%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: Cc: lhotka@nic.cz, draft-ietf-netmod-yang-json.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-netmod-yang-json-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 22:39:42 -0000 It is difficult to feel that the generic dont-worry response ("knows what he or she is doing", "almost never", and "pay(s) attention to the data model", etc.) is sufficient to address security concerns. My review boils down to "surely you can do better", but I do not have the expertise to write specific text that would improve the situation. Hilarie > From: Stephen Farrell > Date: Thu, 17 Mar 2016 14:31:03 +0000 > Hi folks, > This thread seemed to just trail off. > Hilarie, did you want to follow up more or do we think > the document is all set? > Thanks, > S. > On 08/03/16 15:31, Ladislav Lhotka wrote: > > Hi Hilarie, > >=20 > > thank you for the review, please se my responses inline. > >=20 > > Hilarie Orman writes: > >=20 > >> Security review of > >> JSON Encoding of Data Modeled with YANG draft-ietf-netmod-yang-json-08= > >> > >> Do not be alarmed. I have reviewed this document as part of the > >> security directorate's ongoing effort to review all IETF documents > >> being processed by the IESG. These comments were written primarily > >> for the benefit of the security area directors. Document editors and > >> WG chairs should treat these comments just like any other last call > >> comments. > >> > >> "This document defines encoding rules for representing configuration, > >> state data, parameters of RPC operations or actions, and notifications= > >> defined using YANG as JavaScript Object Notation (JSON) text. YANG is= > >> a data modeling language originally designed to model configuration > >> and state data manipulated by the Network Configuration Protocol > >> (NETCONF), NETCONF remote procedure calls, and NETCONF notifications."= > >> > >> I have no specific recommendation for an action on this, just > >> some observations. > >> > >> I'm not an expert on YANG, JSON, or XML, but I was taken aback to read= > >> in section 5.5: > >> > >> Anydata data node serves as a container for an arbitrary set of n= > odes > >> that otherwise appear as normal YANG-modeled data. A data model = > for > >> anydata content may or may not be known at run time. In the latt= > er > >> case, converting JSON-encoded instances to the XML encoding defin= > ed > >> in [I-D.ietf-netmod-rfc6020bis] may be impossible. > >=20 > > An "anydata" node represents data for which no schema is specified in > > the data model. The schema for such data may be known at run time, but > > the consensus in the NETMOD WG was to keep the possibility that this is= > > not the case. And if the schema is not available, translation between > > XML and JSON encodings cannot be done because, for example, we use the > > data model info for translating namespace identifiers. > >=20 > > As long as we want to keep the option of specifying schema-less data in= > > the data model, we have to live with this. I don't think it is really > > ominous, also because normal configuration and state data should almost= > > never be modelled with "anydata". > >=20 > >> > >> That seems ominous, and there are other warnings about the force > >> fitting of JSON and XML: > >> > >> "JSON processing is rather different from XML, and JSON parsers may= > >> thus suffer from other types of vulnerabilities than their XML > >> counterparts. To minimize these new security risks, software on th= > e > >> receiving side SHOULD reject all messages that do not comply to the= > >> rules of this document and reply with an appropriate error message = > to > >> the sender." > >=20 > > Implementors might be tempted to apply the Postel Principle and be > > liberal on the receiving side. This paragraph warns against doing so, > > unless, of course, the implementor knows what he or she is doing. > >=20 > >> > >> The security section refers back to the security considerations in > >> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-11 > >> section 16 (should be 17) where we read: > >> > >> "Data modeled in YANG might contain sensitive information. RPCs or= > >> notifications defined in YANG might transfer sensitive information.= > " > >> > >> "YANG parsers need to be robust with respect to malformed documents= > =2E > >> Reading malformed documents from unknown or untrusted sources could= > >> result in an attacker gaining privileges of the user running the YA= > NG > >> parser. In an extreme situation, the entire machine could be > >> compromised." > >> > >> There being no succinct description of correctness of YANG, JSON, or > >> XML for NETCONF data, how would one determine that any of it, > >> including mappings from one to another, was "robust"? If that simply > >=20 > > In fact, it is one of the most important virtues of data modelling that= > > the correctness of configuration or state data can be reliably > > verified. In the context of draft-ietf-netmod-yang-json, correctness ha= > s > > two aspects: > >=20 > > 1. All data is required to be I-JSON compliant [RFC 7493] which helps > > avoid common JSON-specific interoperability and security problems. > >=20 > > 2. The data model precisely specifies the schema, data types of all > > values, and also semantic constraints. > >=20 > > If an implementor pays attention to data model definitions (including > > textual descriptions), then I believe the risk of any data-induced > > issues is effectively minimised. > >=20 > >> means "doesn't cause a buffer overflow or crash", I suppose it's > >> achievable (and should be explicit). But how could anyone be sure > >> that sensitive data was not leaked without a full analysis of the > >> specifications of all the component parts? Perhaps this is an > >> unaddressable question, but one does hope that the extreme situation > >> does not occur. > >> > >=20 > > This question isn't specific to this document - sensitive data may be > > present in any encoding. It is also one of the duties of a good data > > model to identify such data, and sec. 6 in RFC 6087 puts forward specif= > ic > > requirements in this direction. > >=20 > > Thanks, Lada From nobody Thu Mar 17 16:51:43 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5AA12D641; Thu, 17 Mar 2016 16:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPF_jlBRiFwU; Thu, 17 Mar 2016 16:51:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D1812D5CD; Thu, 17 Mar 2016 16:51:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 205EFBE58; Thu, 17 Mar 2016 23:51:32 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HFmMZGivdIq; Thu, 17 Mar 2016 23:51:25 +0000 (GMT) Received: from [10.87.48.75] (unknown [86.46.16.138]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3B524BE51; Thu, 17 Mar 2016 23:51:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458258684; bh=gXzC7KAVdq301oehrXqPvvAbuiFQCNPavkxlWWzI5Ps=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=gAByiHuMDbPQdKS0+q5p5nbSLxTiINA5yKjFraYJ95CVvyZfiBjcFjrzr52IQ+hwF f/s9UHvRhPFSA/+it0KjhIkMAZQ9NqkGgYlIO3c0ub6aP/NtlzQaUyUeZd5XUQ6387 ez2g9x9s+wxdeRmFUgxKQ3hiBHMNahlIq7Y07xtw= To: Hilarie Orman References: <201603172239.u2HMdFff018872@rumpleteazer.rhmr.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56EB42FB.9040006@cs.tcd.ie> Date: Thu, 17 Mar 2016 23:51:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <201603172239.u2HMdFff018872@rumpleteazer.rhmr.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010001080802020404070807" Archived-At: Cc: lhotka@nic.cz, draft-ietf-netmod-yang-json.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-netmod-yang-json-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 23:51:37 -0000 This is a cryptographically signed message in MIME format. --------------ms010001080802020404070807 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Hilarie, Ok, I'll take a peek again at the thread. For some reason it was also daunting to me so I tried to re-delegate again, I guess I find XML + anydata just off-putting as a concept;-) Anyway, I'll get back tomorrow. Cheers, S. On 17/03/16 22:39, Hilarie Orman wrote: > It is difficult to feel that the generic dont-worry response ("knows > what he or she is doing", "almost never", and "pay(s) attention to the > data model", etc.) is sufficient to address security concerns. My > review boils down to "surely you can do better", but I do not have the > expertise to write specific text that would improve the situation. >=20 > Hilarie >=20 >> From: Stephen Farrell >> Date: Thu, 17 Mar 2016 14:31:03 +0000 >=20 >> Hi folks, >=20 >> This thread seemed to just trail off. >=20 >> Hilarie, did you want to follow up more or do we think >> the document is all set? >=20 >> Thanks, >> S. >=20 >> On 08/03/16 15:31, Ladislav Lhotka wrote: >> > Hi Hilarie, >> >=3D20 >> > thank you for the review, please se my responses inline. >> >=3D20 >> > Hilarie Orman writes: >> >=3D20 >> >> Security review of >> >> JSON Encoding of Data Modeled with YANG draft-ietf-netmod-yang-jso= n-08=3D >=20 >> >> >> >> Do not be alarmed. I have reviewed this document as part of the >> >> security directorate's ongoing effort to review all IETF documents= >> >> being processed by the IESG. These comments were written primaril= y >> >> for the benefit of the security area directors. Document editors = and >> >> WG chairs should treat these comments just like any other last cal= l >> >> comments. >> >> >> >> "This document defines encoding rules for representing configurati= on, >> >> state data, parameters of RPC operations or actions, and notificat= ions=3D >=20 >> >> defined using YANG as JavaScript Object Notation (JSON) text. YAN= G is=3D >=20 >> >> a data modeling language originally designed to model configuratio= n >> >> and state data manipulated by the Network Configuration Protocol >> >> (NETCONF), NETCONF remote procedure calls, and NETCONF notificatio= ns."=3D >=20 >> >> >> >> I have no specific recommendation for an action on this, just >> >> some observations. >> >> >> >> I'm not an expert on YANG, JSON, or XML, but I was taken aback to = read=3D >=20 >> >> in section 5.5: >> >> >> >> Anydata data node serves as a container for an arbitrary set = of n=3D >> odes >> >> that otherwise appear as normal YANG-modeled data. A data mo= del =3D >> for >> >> anydata content may or may not be known at run time. In the = latt=3D >> er >> >> case, converting JSON-encoded instances to the XML encoding d= efin=3D >> ed >> >> in [I-D.ietf-netmod-rfc6020bis] may be impossible. >> >=3D20 >> > An "anydata" node represents data for which no schema is specified = in >> > the data model. The schema for such data may be known at run time, = but >> > the consensus in the NETMOD WG was to keep the possibility that thi= s is=3D >=20 >> > not the case. And if the schema is not available, translation betwe= en >> > XML and JSON encodings cannot be done because, for example, we use = the >> > data model info for translating namespace identifiers. >> >=3D20 >> > As long as we want to keep the option of specifying schema-less dat= a in=3D >=20 >> > the data model, we have to live with this. I don't think it is real= ly >> > ominous, also because normal configuration and state data should al= most=3D >=20 >> > never be modelled with "anydata". >> >=3D20 >> >> >> >> That seems ominous, and there are other warnings about the force >> >> fitting of JSON and XML: >> >> >> >> "JSON processing is rather different from XML, and JSON parsers= may=3D >=20 >> >> thus suffer from other types of vulnerabilities than their XML >> >> counterparts. To minimize these new security risks, software o= n th=3D >> e >> >> receiving side SHOULD reject all messages that do not comply to= the=3D >=20 >> >> rules of this document and reply with an appropriate error mess= age =3D >> to >> >> the sender." >> >=3D20 >> > Implementors might be tempted to apply the Postel Principle and be >> > liberal on the receiving side. This paragraph warns against doing s= o, >> > unless, of course, the implementor knows what he or she is doing. >> >=3D20 >> >> >> >> The security section refers back to the security considerations in= >> >> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-11 >> >> section 16 (should be 17) where we read: >> >> >> >> "Data modeled in YANG might contain sensitive information. RPC= s or=3D >=20 >> >> notifications defined in YANG might transfer sensitive informat= ion.=3D >> " >> >> >> >> "YANG parsers need to be robust with respect to malformed docum= ents=3D >> =3D2E >> >> Reading malformed documents from unknown or untrusted sources c= ould=3D >=20 >> >> result in an attacker gaining privileges of the user running th= e YA=3D >> NG >> >> parser. In an extreme situation, the entire machine could be >> >> compromised." >> >> >> >> There being no succinct description of correctness of YANG, JSON, = or >> >> XML for NETCONF data, how would one determine that any of it, >> >> including mappings from one to another, was "robust"? If that sim= ply >> >=3D20 >> > In fact, it is one of the most important virtues of data modelling = that=3D >=20 >> > the correctness of configuration or state data can be reliably >> > verified. In the context of draft-ietf-netmod-yang-json, correctnes= s ha=3D >> s >> > two aspects: >> >=3D20 >> > 1. All data is required to be I-JSON compliant [RFC 7493] which hel= ps >> > avoid common JSON-specific interoperability and security problem= s. >> >=3D20 >> > 2. The data model precisely specifies the schema, data types of all= >> > values, and also semantic constraints. >> >=3D20 >> > If an implementor pays attention to data model definitions (includi= ng >> > textual descriptions), then I believe the risk of any data-induced >> > issues is effectively minimised. >> >=3D20 >> >> means "doesn't cause a buffer overflow or crash", I suppose it's >> >> achievable (and should be explicit). But how could anyone be sure= >> >> that sensitive data was not leaked without a full analysis of the >> >> specifications of all the component parts? Perhaps this is an >> >> unaddressable question, but one does hope that the extreme situati= on >> >> does not occur. >> >> >> >=3D20 >> > This question isn't specific to this document - sensitive data may = be >> > present in any encoding. It is also one of the duties of a good dat= a >> > model to identify such data, and sec. 6 in RFC 6087 puts forward sp= ecif=3D >> ic >> > requirements in this direction. >> >=3D20 >> > Thanks, Lada --------------ms010001080802020404070807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMTcy MzUxMjNaMC8GCSqGSIb3DQEJBDEiBCC7+zBi0Dt1orAuicG1T/jTAx7kMcQDFa2UzMRai7Px zTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCMq9iHl1cjNpx/BAW9h+9d1Zz94pPKGHSVQEB5XWEdDpanY/B+nwb5 SdlXISclqmbUrYuprg+UGIKFSdRIrKPQXfMP3d41N3JALkuxkLa4TVBeOG473XX+3tqzrkFf s4+rLJM0AHx2pEg1751K/MMFFhFkzwJ000+ThJBAaCgANh7gBqoll6uVN4colKihL5Yz7C0q pwAHaRpMFjY3/6eu9MTSMmgkVer+RcJ9Ft3On/Aait50e74tDEgnFs46NUJdkmxginvJDtyK F+pOHou10IK90k4PWqDXX191uDGrwKhvigHQwYHLzILD8F4N/VnZ1ysOtzsGdYxqByFmQAqI AAAAAAAA --------------ms010001080802020404070807-- From nobody Fri Mar 18 09:11:49 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBAE12D56F; Fri, 18 Mar 2016 09:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEvkuAkqtl0L; Fri, 18 Mar 2016 09:08:51 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8F212D590; Fri, 18 Mar 2016 09:08:43 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 22C1643DE62A8; Fri, 18 Mar 2016 16:08:38 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2IG8epC016560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Mar 2016 16:08:41 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2IG8NZj026753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Mar 2016 17:08:40 +0100 Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.90]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 18 Mar 2016 17:08:30 +0100 From: "Murray, Rob (Nokia - GB)" To: Vincent Roca Thread-Topic: Secdir review of draft-ietf-cdni-control-triggers-11 Thread-Index: AQHRRwzfQRQykiwnh0mW9gDUEP6L557tC9uAgAENeoCAcaifgA== Date: Fri, 18 Mar 2016 16:08:29 +0000 Message-ID: <252883D7-E325-4B9A-A978-FEACE5B40143@alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: <4F3156016E03884B91DD157704C7EC8C@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 18 Mar 2016 09:11:38 -0700 Cc: "draft-ietf-cdni-control-triggers@tools.ietf.org" , "cdni@ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-cdni-control-triggers-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 16:08:53 -0000 SGkgVmluY2VudCBhbmQgYWxsLA0KDQpJJ3ZlIGp1c3QgcG9zdGVkIGEgIi0xMiIgb2YgdGhlIENE TkkgVHJpZ2dlcnMgZHJhZnQsIGhvcGVmdWxseSBhZGRyZXNzaW5nIHRoZXNlIGNvbW1lbnRzLiBS ZXNwb25zZXMgaW5saW5lIGJlbG93Lg0KDQpDaGVlcnMsDQpSb2IuDQoNCk9uIDA2LzAxLzIwMTYs IDA4OjI3LCAiVmluY2VudCBSb2NhIiA8dmluY2VudC5yb2NhQGlucmlhLmZyPiB3cm90ZToNCg0K PkhlbGxvIFJvYiwNCj4NCj4+IEhpIFZpbmNlbnQgLSBtYW55IHRoYW5rcyBmb3IgdGhlIHJldmll dywgcmVzcG9uc2VzIGlubGluZSBiZWxvd+KApg0KPg0KPllvdeKAmXJlIHdlbGNvbWUuDQo+DQo+ DQo+Pj4gVGhlcmUgYXJlIHNldmVyYWwgdG9waWNzIEnigJlkIGxpa2UgdG8gZGlzY3VzczoNCj4+ PiANCj4+PiAxLSBDb25jZXJuaW5nIHRoZSB1c2Ugb2YgVExTIHRvIGNhcnJ5IENJL1QgdHJhZmZp YywgSSBzZWUgaXQgaXMgbWFuZGF0b3J5DQo+Pj4gdG8gaW1wbGVtZW50LCBidXQgc3RpbGwgb3B0 aW9uYWwgdG8gdXNlICgxc3Qgc2VudGVuY2Ugb2YgU2VjdGlvbiA4LjEpLiBJcw0KPj4+IGl0IHN0 aWxsIHJlYXNvbmFibGUgaW4gY3VycmVudCBJbnRlcm5ldD8gQXQgYSBtaW5pbXVtIEkgd291bGQg ZXhwZWN0IGENCj4+PiDCqyBNVVNUIHN1cHBvcnQgwrsgLyDCqyBTSE9VTEQgdXNlIMK7Lg0KPj4g DQo+PiBTZWN0aW9uIDguMSBnb2VzIG9uIHRvIHNheSAuLi4NCj4+IA0KPj4gICBbIC4uLiBkZXNj cmlwdGlvbiBvZiBiZW5lZml0cyBvZiBIVFRQUyAuLi4gXQ0KPj4gDQo+PiAgIEluIGFuIGVudmly b25tZW50IHdoZXJlIGFueSBzdWNoIHByb3RlY3Rpb24gaXMgcmVxdWlyZWQsIG11dHVhbGx5DQo+ PiAgIGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGVkIHRyYW5zcG9ydCBNVVNUIGJlIHVzZWQgdG8gZW5z dXJlDQo+PiAgIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUgQ0kvVCBpbmZvcm1hdGlvbi4gVG8gdGhh dCBlbmQsIFRMUyBNVVNUIGJlDQo+PiAgIHVzZWQgYnkgQ0kvVCwgaW5jbHVkaW5nIGF1dGhlbnRp Y2F0aW9uIG9mIHRoZSByZW1vdGUgZW5kLg0KPj4gDQo+PiAuLi4gdGhlIEludGVybmV0IGlzIGNs ZWFybHkgYW4gZW52aXJvbm1lbnQgd2hlcmUgc3VjaCBwcm90ZWN0aW9uIGlzDQo+PiByZXF1aXJl ZCwgYW5kIGl0J2xsIG9mdGVuIGJlIHVzZWQgZm9yIHRoZXNlIGludGVyZmFjZXMgLSB3ZSBjb3Vs ZCBzdGF0ZQ0KPj4gdGhhdCBleHBsaWNpdGx5LCB3b3VsZCB0aGF0IGFkZHJlc3MgdGhlIGNvbmNl cm4/DQo+PiANCj4+IEJ1dCwgQ0kvVCBjb3VsZCBhbHNvIGJlIGRlcGxveWVkIHRvIHJ1biBvdmVy IGEgVlBOIG9yIHByaXZhdGUgbmV0d29yaw0KPj4gYmV0d2VlbiB0d28gaW50ZXJjb25uZWN0ZWQg Q0ROcywgaW4gc3VjaCBhbiBlbnZpcm9ubWVudCBIVFRQUyB0cmFuc3BvcnQNCj4+IHdvdWxkIG5v dCBoYXZlIHRoZSBzYW1lIGJlbmVmaXRzLg0KPg0KPlllcywgdGhhdOKAmXMgbXkgcG9pbnQuIFNh eSBleHBsaWNpdGx5IHRoYXQgSW50ZXJuZXQgaXMgYW4gZXhhbXBsZSBvZiBlbnZpcm9ubWVudCB3 aGVyZQ0KPnN1Y2ggYSBwcm90ZWN0aW9uIGlzIG1hbmRhdG9yeS4NCg0KSW4gIi0xMiIgSSd2ZSBh bGlnbmVkIHRoZSB0ZXh0IGFib3ZlIHdpdGggdGhlIHRleHQgdXNlZCBpbiB0aGUgY2RuaS1tZXRh ZGF0YSBkcmFmdDoNCg0KICBUTFMgTVVTVCBiZSB1c2VkIGJ5IHRoZSBzZXJ2ZXItc2lkZSAoZENE TikgYW5kIHRoZSBjbGllbnQtc2lkZSAodUNETikgb2YNCiAgdGhlIENJL1QgaW50ZXJmYWNlLCBp bmNsdWRpbmcgYXV0aGVudGljYXRpb24gb2YgdGhlIHJlbW90ZSBlbmQsIHVubGVzcw0KICBhbHRl cm5hdGUgbWV0aG9kcyBhcmUgdXNlZCBmb3IgZW5zdXJpbmcgdGhlIGNvbmZpZGVudGlhbGl0eSBv ZiB0aGUNCiAgaW5mb3JtYXRpb24gaW4gdGhlIENJL1QgaW50ZXJmYWNlIHJlcXVlc3RzIGFuZCBy ZXNwb25zZXMgKHN1Y2ggYXMgc2V0dGluZw0KICB1cCBhbiBJUHNlYyB0dW5uZWwgYmV0d2VlbiB0 aGUgdHdvIENETnMgb3IgdXNpbmcgYSBwaHlzaWNhbGx5IHNlY3VyZWQNCiAgaW50ZXJuYWwgbmV0 d29yayBiZXR3ZWVuIHR3byBDRE5zIHRoYXQgYXJlIG93bmVkIGJ5IHRoZSBzYW1lIGNvcnBvcmF0 ZQ0KICBlbnRpdHkpLg0KDQpJIHRoaW5rIHRoYXQgY292ZXJzIGl0IGJldHRlciAoPykuDQoNCg0K Pj4+IDItIFNlY3Rpb24gOC4xLCBwbGVhc2UgY2hlY2sgdGhlIHBhcmFncmFwaCDCqyBOb3RlIHRo YXQgaW4gYSDCqyBkaWFtb25kIMK7DQo+Pj4gY29uZmlndXJhdGlvbiBb4oCmXSDCuy4gVGhpcyBw YXJhZ3JhcGggaXMgcmF0aGVyIGNvbmZ1c2luZyB0byBtZS4gQ29uZnVzaW9uDQo+Pj4gY29tZXMg ZnJvbToNCj4+PiAtIHRoZSBsYWNrIG9mIGRlc2NyaXB0aW9uIG9mIHRoZSDCqyBkaWFtb25kIGNv bmZpZ3VyYXRpb24gwrsuIEkgdW5kZXJzdGFuZA0KPj4+IHRoZXJlIGlzIG9uZSBkQ0ROIG9uIHRv cCBhbmQgbXVsdGlwbGUgdUNETiBkaXJlY3RseSBjb25uZWN0ZWQgYmVsb3csIGFtIEkNCj4+PiBy aWdodD8NCj4+IA0KPj4gWWVzLCB0aGF0J3MgcmlnaHQuIFRoZSBkcmFmdCBzYXlzOg0KPj4gDQo+ PiAgIE5vdGUgdGhhdCBpbiBhICJkaWFtb25kIiBjb25maWd1cmF0aW9uLCB3aGVyZSBvbmUgdUNE TidzIGNvbnRlbnQgY2FuDQo+PiAgIGJlIGFjcXVpcmVkIHZpYSBtb3JlIHRoYW4gb25lIGRpcmVj dGx5LWNvbm5lY3RlZCB1Q0ROLA0KPj4gDQo+PiBXb3VsZCB0aGUgZm9sbG93aW5nIHJlYXJyYW5n ZW1lbnQgaGVscD8gLi4uDQo+PiANCj4+ICAgQSAiZGlhbW9uZCIgY29uZmlndXJhdGlvbiBpcyBv bmUgd2hlcmUgYSBkQ0ROIGNhbiBhY3F1aXJlIGEgdUNETidzDQo+PiAgIGNvbnRlbnQgdmlhIG1v cmUgdGhhbiBvbmUgZGlyZWN0bHktY29ubmVjdGVkIHVDRE4uIE5vdGUgdGhhdA0KPj4gICBpbiBh IGRpYW1vbmQgY29uZmlndXJhdGlvbiBb4oCmXQ0KPg0KPlllcywgSSBwcmVmZXIgdGhpcyB2ZXJz aW9uLiBIb3dldmVyLCBjYW4gdGhlIHNhbWUgwqsgdUNETuKAmXMgY29udGVudCDCuyBiZQ0KPmF2 YWlsYWJsZSBhdCBzZXZlcmFsIHVDRE5zIGluIHRoaXMgZGlhbW9uZCBjb25maWd1cmF0aW9uPyBT YWlkIGRpZmZlcmVudGx5LA0KPndoYXQgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Og0KPg0KPglB IMKrIGRpYW1vbmQgwrsgY29uZmlndXJhdGlvbiBpcyBvbmUgd2hlcmUgYSBkQ0ROIGNhbiBhY3F1 aXJlIGEgZ2l2ZW4NCj4JY29udGVudCB2aWEgbW9yZSB0aGFuIG9uZSBkaXJlY3RseS1jb25uZWN0 ZWQgdUNETi4gTm90ZSB0aGF0IFvigKZdDQoNClllcywgbW9yZSB0aGFuIG9uZSB1Q0ROIHdpbGwg aGF2ZSB0aGUgc2FtZSBjb250ZW50IC0gYnV0IHRoZSBpbXBvcnRhbnQgcG9pbnQgaXMgdGhhdCB1 bHRpbWF0ZWx5IHRoZXkgd2lsbCBhbGwgaGF2ZSBhY3F1aXJlZCBpdCBmcm9tIHRoZSBzYW1lIHVD RE4sIGFuZCB0aGF0IHVDRE4gb3ducyB0aGUgbWV0YWRhdGEuDQoNCkkndmUgdHJpZWQgdG8gcHJv dmlkZSBhIGJldHRlciBpbnRyby9leHBsYW5hdGlvbiBpbiBuZXcgc2VjdGlvbiAyLjIuMSAiTXVs dGlwbGUgaW50ZXJjb25uZWN0ZWQgQ0ROcyIuIEhvcGVmdWxseSB0aGF0IG1ha2VzIGl0IGEgYml0 IGNsZWFyZXI/DQoNCg0KPj4+IC0gdGhlIG5vdGlvbiBvZiDCqyBjb250ZW50IGFjcXVpcmVkIGZy b20gYSB1Q0ROIMK7LiBJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LA0KPj4+IGl0IG1lYW5zIMKr IGNvbnRlbnQgdGhhdCBoYXMgYmVlbiBhY3F1aXJlZCBhZnRlciBhIHVDRE4gcmVxdWVzdCB0byBk byBzbyDCuy4NCj4+PiBJIGluaXRpYWxseSB0aG91Z2h0IHRoZXJlIHdlcmUgc29tZSBtaXN0YWtl cyBpbiB0aGUgdXNlIG9mIHVDRE4gLyBkQ0RO4oCmDQo+PiANCj4+IEEgZENETiB3aWxsIGFsd2F5 cyBhY3F1aXJlIGNvbnRlbnQgZnJvbSBhIHVDRE4gYmVjYXVzZSBpdCdzIGJlZW4gcmVxdWVzdGVk DQo+PiB0byBkbyBzbyAod2l0aG91dCBhIHJlcXVlc3QgaXQgd29uJ3Qga25vdyB0aGUgVVJMIGlu IHRoZSB1Q0ROKS4NCj4+IA0KPj4gVGhlIHJlcXVlc3QgY2FuIGJlIGZyb20gYW4gZW5kLWNsaWVu dCBvciBhIGZ1cnRoZXItZG93bnN0cmVhbSBDRE4sIGluIHdoaWNoDQo+PiBjYXNlIHRoZSBjb250 ZW50IHdpbGwgYmUgYWNxdWlyZWQgb24tZGVtYW5kLCBvciBpdCBjYW4gYmUgYSBDSS9UDQo+PiBw cmUtcG9zaXRpb25pbmcgcmVxdWVzdCBmcm9tIGEgdUNETi4NCj4+IA0KPj4gRG9lcyB0aGF0IGhl bHA/IEnigJltIG5vdCBzdXJlIHdoYXQgY2hhbmdlIG9yIGNsYXJpZmljYXRpb24geW91J3JlIGFz a2luZyBmb3IuDQo+DQo+Rm9yZ2V0IG15IGNvbW1lbnQsIEkgbWlzdW5kZXJzdG9vZCB0aGUgbm90 aW9uIG9mIHVDRE7igKYgSSBzaG91bGQgaGF2ZSByZWFkDQo+UkZDIDY3MDcgYmVmb3JlIQ0KPg0K Pg0KPj4+IDMtIFdpdGggdGhpcyDCqyBkaWFtb25kIGNvbmZpZ3VyYXRpb24gwrssIHNpbmNlIHNl dmVyYWwgdUNETiBjYW4gYWN0IHVwb24gdGhlDQo+Pj4gc2FtZSBjb250ZW50LCB3aGF0IGhhcHBl bnMgaWYgdGhleSBiZWhhdmUgaW4gYSBub24gY29vcmRpbmF0ZWQgbWFubmVyIChpLmUuLA0KPj4+ IGluIHRoZSBnZW5lcmFsIGNhc2UpPyBGb3IgaW5zdGFuY2UgbGV04oCZcyBpbWFnaW5lIG9uZSBv ZiB0aGVtIGFza3MgdGhlIGRDRE4NCj4+PiB0byBkZWxldGUgdGhlIGNvbnRlbnQgb3IgY2FuY2Vs IHRoZSBpbml0aWFsIGNvbW1hbmQuIFdoYXQgaGFwcGVucyBpZiBhbm90aGVyDQo+Pj4gdUNETiB0 aGVuIGFza3MgdGhlIGRDRE4gdG8gaW52YWxpZGF0ZSB0aGlzIGNvbnRlbnQsIHByb3ZpZGluZyB0 aGUgVVJMIG9mIHRoZQ0KPj4+IFRyaWdnZXIgU3RhdHVzIFJlc291cmNlIHdoaWNoIChpZiBJIHVu ZGVyc3RhbmQgY29ycmVjdGx5KSBpcyBubyBsb25nZXIgdmFsaWQ/DQo+Pj4gVGhpcyDCqyBkaWFt b25kIGNvbmZpZ3VyYXRpb24gwrsgY2FuIGJlIGEgbGl0dGxlIGJpdCB0cmlja3kgYW5kIG5vIGNs ZWFyDQo+Pj4gZ3VpZGVsaW5lIGlzIHByb3ZpZGVkIGluIHRoZSBkb2N1bWVudC4NCj4+IA0KPj4g QSB0cmlnZ2VyIHN0YXR1cyByZXNvdXJjZSBiZWxvbmdzIHRvIG9uZSB1Q0ROIGFuZCBjYW5ub3Qg YmUgYWNjZXNzZWQgb3INCj4+IG1hbmlwdWxhdGVkIGJ5IGFueSBvdGhlciBDRE4sIHNlY3Rpb24g MyBwYXJhIDMgc2F5czoNCj4+IA0KPj4gICBUcmlnZ2VyIFN0YXR1cyBSZXNvdXJjZXMgYmVsb25n aW5nIHRvIGEgdUNETiBNVVNUIE5PVA0KPj4gICBiZSB2aXNpYmxlIHRvIGFueSBvdGhlciBDRE4u IFRoZSBkQ0ROIGNvdWxkLCBmb3IgZXhhbXBsZSwgYWNoaWV2ZQ0KPj4gICB0aGlzIGJ5IG9mZmVy aW5nIGRpZmZlcmVudCBjb2xsZWN0aW9uIFVSTHMgdG8gZWFjaCB1Q0ROLCBhbmQvb3IgYnkNCj4+ ICAgZmlsdGVyaW5nIHRoZSByZXNwb25zZSBiYXNlZCBvbiB0aGUgdUNETiB3aXRoIHdoaWNoIHRo ZSBIVFRQIGNsaWVudA0KPj4gICBpcyBhc3NvY2lhdGVkLg0KPg0KPkkgc2Vl4oCmIEhvd2V2ZXIs IGlmIG11bHRpcGxlIHVDRE5zIGNhbiBhY3Qgb24gdGhlIHNhbWUgY29udGVudCAod2hhdCBpcyBz YWlkKSwNCj5ldmVuIGlmIGVhY2ggdUNETiB1c2VzIGEgZGlmZmVyZW50IFVSTCwgd2lsbCBzaW11 bHRhbmVvdXMgQ0kvVCBjb21tYW5kcyBmb3INCj50aGUgc2FtZSBjb250ZW50IGJlIG1hbmFnZWQg Y29ycmVjdGx5PyBUaGlzIGlzIG5vdCBzYWlkIGluIHNlY3Rpb24gMw0KPnBhcmFncmFwaCAzIGVp dGhlciBhbmQgdGhpcyBpcyBhIGtleSBwb2ludC4NCg0KU29ycnksIEknZCBtaXNzZWQgeW91ciBw b2ludC4NCg0KSW50ZXJhY3Rpb25zIGNhbiBiZSBpbmVmZmljaWVudCwgYnV0IGFyZSBvdGhlcndp c2UgaGFybWxlc3MgYmVjYXVzZSB0aGUgc3Ryb25nZXN0IG9mICJpbnZhbGlkYXRlIiBvciAicHVy Z2UiIHdpbGwgd2luLCBhbmQgY29udGVudCBjYW4gYWx3YXlzIGJlIHJlLWFjcXVpcmVkIGlmIGl0 J3Mgc3RpbGwgYXZhaWxhYmxlIGZyb20gYW55IHVDRE4uDQoNCkkndmUgZ2l2ZW4gc29tZSBleGFt cGxlcyBpbiBuZXcgc2VjdGlvbiAyLjIuMSAiTXVsdGlwbGUgaW50ZXJjb25uZWN0ZWQgQ0ROcyIs IGFuZCBhZGRlZCBhIHBvaW50ZXIgdG8gdGhhdCBmcm9tIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uLg0KDQoNCj4+IENvbnRlbnQgYWx3YXlzIG9yaWdpbmF0ZXMgZnJvbSBvbmUg dUNETiwgYnV0IGluIGEgZGlhbW9uZCBjb25maWdyYXRpb24gdGhlcmUNCj4+IG1heSBiZSBtdWx0 aXBsZSByb3V0ZXMgKHZpYSBvdGhlciBDRE5zKSB0byBhIGdpdmVuIGRDRE4uDQo+PiANCj4+IFRo ZSBtb3N0IGNvbW1vbiBzY2VuYXJpbyBtYXkgd2VsbCBiZSB0aGF0IHRoZSB1Q0ROIHdpbGwgaW5p dGlhdGUgYWxsIG9mIHRoZQ0KPj4gQ0kvVCBjb21tYW5kcyByZWxhdGVkIHRvIGl0cyBjb250ZW50 LCBhbmQgdGhvc2UgY29tbWFuZHMgd2lsbCBzaW1wbHkgYmUNCj4+IGZvcndhcmRlZCBieSBpbnRl cm1lZGlhdGUgQ0ROcy4NCj4+IA0KPj4gQnV0LCB0aGVyZSdzIG5vdGhpbmcgdG8gc3RvcCBhbiBp bnRlcm1lZGlhdGUgQ0ROIGluaXRpYXRpbmcgb3IgbW9kaWZ5aW5nDQo+PiBDSS9UIGNvbW1hbmRz IC0gYW5kIHNvbWUgbW9kaWZpY2F0aW9ucyBvZiB0aGUgY29tbWFuZCB3aWxsIGJlIG5lY2Vzc2Fy eQ0KPj4gKGZvciBleGFtcGxlLCBtZXRhZGF0YSBVUkxzIHdpbGwgbmVlZCB0byBiZSBjaGFuZ2Vk KS4NCj4+IA0KPj4gQnkgYW5hbHlzaXMgb2YgbG9nIGZpbGVzIGl0IHdpbGwgcHJvYmFibHkgYmUg cG9zc2libGUgdG8gd29yayBvdXQgd2hpY2gNCj4+IHVDRE4gYW4gaW5kaXZpZHVhbCBjYWNoZSBp biB0aGUgZENETiBhY3F1aXJlZCBlYWNoIGNhY2hlZCByZXNvdXJjZSBmcm9tLg0KPj4gQnV0IHRo ZSBjYWNoZSBpcyBub3QgcmVxdWlyZWQgdG8ga2VlcCBhIGxpdmUgcmVjb3JkIG9mIHRoYXQsIGFu ZCBpdA0KPj4gcHJvYmFibHkgd29uJ3QuIEluIHRoYXQgY2FzZSwgd2hlbiBpdCByZWNlaXZlcyBh IENJL1QgY29tbWFuZCB0byBpbnZhbGlkYXRlDQo+PiBvciBwdXJnZSBjb250ZW50LCB0aGUgZENE TiBzaG91bGQgYXBwbHkgdGhhdCBjb21tYW5kIHRvIGFueSBjb250ZW50IGl0DQo+PiBtYXkgaGF2 ZSBhY3F1aXJlZCBmcm9tIHRoZSB1Q0ROIGl0IGdvdCB0aGUgQ0kvVCBjb21tYW5kIGZyb20uDQo+ PiANCj4+IFNvIHRoZXJlIGlzIHNjb3BlIGZvciBhIG1hbGljaW91cyBpbnRlcm1lZGlhdGUgQ0RO IHRvIGNhdXNlIGV4dHJhIHByb2Nlc3NpbmcNCj4+IGFuZCBhY3F1aXNpdGlvbiBieSBhIGRDRE4g KGFuZCB0aGF0J3MgbWVudGlvbmVkIGluIHNlY3Rpb24gOCkuIEJ1dCBhDQo+PiBtYWxpY2lvdXMg Q0ROIGlzIGxpa2VseSB0byBmaW5kIGl0c2VsZiByZW1vdmVkIGZyb20gdGhlIENETiBmZWRlcmF0 aW9uIGZhaXJseQ0KPj4gcXVpY2tseSAtIHRoZXJlIHdpbGwgbmVjZXNzYXJpbHkgYmUgYSBsZXZl bCBvZiB0cnVzdCBiZXR3ZWVuIGludGVyY29ubmVjdGVkDQo+PiBDRE5zLg0KPj4gDQo+PiBXb3Vs ZCBpdCBoZWxwIHRvIHNwZWxsIG91dCBzb21lIG9mIHRoYXQgaW4gdGhlIGRyYWZ0PyAoVGhlIHNh bWUgb3IgdmVyeQ0KPj4gc2ltaWxhciB0ZXh0IGhhcyBiZWVuIHVzZWQgaW4gc2V2ZXJhbCBvZiB0 aGUgQ0ROSSBkcmFmdHMuKQ0KPg0KPlllcywgdGhpcyBwYXJhZ3JhcGggaXMgd29ydGggYmVpbmcg ZGV0YWlsZWQgYSBsaXR0bGUgYml0Lg0KPg0KPkluIHlvdXIgZXhwbGFuYXRpb25zIHlvdSBtZW50 aW9uIGludGVybWVkaWF0ZSBDRE5zIHdoaWxlIG9yaWdpbmFsIHRleHQgb25seQ0KPm1lbnRpb25z IGRpcmVjdGx5IGNvbm5lY3RlZCB1Q0ROcy4gVGhlIG5vdGlvbiBvZiDCqyBpbnRlcm1lZGlhdGUg Q0ROIMK7IGlzDQo+b25seSBkaXNjdXNzZWQgaW4gc2VjdGlvbnMgMi4zIGFuZCA0LjguIFNpbmNl IG1hbGljaW91cyBpbnRlcm1lZGlhdGUgQ0ROcyBhcmUNCj5wYXJ0IG9mIGEgdmFsaWQgYXR0YWNr IG1vZGVsLCBpdCBpcyB3b3J0aCB0byBleHBsYWluIGl0IChvciBnaXZlIGEgcmVmZXJlbmNlIHRv IGFub3RoZXINCj5kb2N1bWVudCkuDQoNCldoZW4gYSBjb250ZW50IG93bmVyLCB0aGUgb3JpZ2lu LCBkZWxlZ2F0ZXMgZGVsaXZlcnkgdG8gYSBDRE4gaXQgaXMgdHJ1c3RpbmcgdGhhdCBDRE4gdG8g ZGVsaXZlciB0aGUgcmlnaHQgY29udGVudCBvbiBpdHMgYmVoYWxmLiBBIG1hbGljaW91cyBDRE4g Y291bGQgZGVsaXZlciBhbnl0aGluZyBpbnN0ZWFkLCBidXQgaXQgd291bGQgc29vbiBsb3NlIHRo ZSB0cnVzdCBvZiB0aGUgb3JpZ2luLg0KDQpDRE4taW50ZXJjb25uZWN0aW9uIHNpbXBseSBleHRl bmRzIHRoYXQgdHJ1c3QgdG8gdGhlIGZ1cnRoZXItZG93bnN0cmVhbSBDRE5zIGFjdGluZyBvbiBi ZWhhbGYgb2YgdGhlIG9yaWdpbmFsLg0KDQpTbyBlc3RhYmxpc2htZW50L2VuZm9yY2VtZW50IG9m IHRoZSB0cnVzdCByZWxhdGlvbnNoaXAgaXRzZWxmLCB0aGUgY29udHJhY3QgYmV0d2VlbiB0aGUg b3JpZ2luIGFuZCB0aGUgQ0ROLCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiBDRE5JIGFuZCBpbiB0 aGUgbGFuZCBvZiBjb21tZXJjaWFsIGFncmVlbWVudHMuDQoNCkkndmUgYWRkZWQgYSBub3RlIG9u IHRoYXQgaW4gdGhlIGludHJvIHRvIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9u Lg0KDQoNCj4+PiA0LSBDb25jZXJuaW5nIHByaXZhY3kgYXNwZWN0cywgSSB3b3VsZCBiZSBtdWNo IG1vcmUgY2F1dGlvdXMgdGhhbiB0aGUgYXV0aG9ycy4NCj4+PiBGb3IgaW5zdGFuY2UsIEkgd291 bGRuJ3QgY2xhaW0gInRoZXJlIGFyZSBubyBwcml2YWN5IGNvbmNlcm5zIGZvciBFbmQgVXNlcnMi DQo+Pj4gYmVjYXVzZSB0aGUgQ0kvVCBwcm90b2NvbCBkb2VzIG5vdCBjYXJyeSBpbmZvcm1hdGlv biBhYm91dCBpbmRpdmlkdWFsIEVuZA0KPj4+IFVzZXJzIChzZWN0aW9uIDguMykuIFRoZSBkQ0RO IGtub3dzIHRoYXQgdGhlcmUgYXJlIHVzZXJzIGludGVyZXN0ZWQgKG9yIGF0DQo+Pj4gdGhlIG9w cG9zaXRlIG5vIHVzZXIgaW50ZXJlc3RlZCkgYnkgYSBjZXJ0YWluIGNvbnRlbnQgaW4gdGhlIHJl Z2lvbiBzZXJ2ZWQNCj4+PiBieSBhIHVDRE4uIFRoZXJlZm9yZSwgdGhlIHByb3RvY29sIG9ubHkg cHJvdmlkZXMgay1hbm9ueW1pdHksIHdoZXJlIGsgaXMgdGhlDQo+Pj4gbnVtYmVyIG9mIEVuZCBV c2VycyBpbiB0aGUgcmVnaW9uLiBEZXBlbmRpbmcgb24gdGhlIGNvbnRlbnQgc2Vuc2l0aXZpdHkg YW5kDQo+Pj4gayB2YWx1ZSwgdGhpcyBrLWFub255bWl0eSBtYXkgc3RpbGwgcmFpc2UgcHJpdmFj eSBpc3N1ZXMsIGV2ZW4gaWYgdGhlDQo+Pj4gaW5kaXZpZHVhbCBFbmQgVXNlciBhY3Rpdml0eSBs b2dzIGFyZSBub3QgYXZhaWxhYmxlIHRvIHRoZSBkQ0ROIChJIGFzc3VtZQ0KPj4+IFRMUyBpcyB1 c2VkIHRvIHByZXZlbnQgZWF2ZXNkcm9wcGluZ+KApikuDQo+PiANCj4+IEkgZG9uJ3QgdGhpbmsg dGhhdCBhbmFseXNpcyBpcyBjb3JyZWN0Li4uDQo+PiANCj4+IElycmVzcGVjdGl2ZSBvZiBDSS9U LCB0aGUgZENETiB3aWxsIGFsd2F5cyBrbm93IHdobydzIGFjY2Vzc2luZyB0aGUgY29udGVudCwN Cj4+IGNsaWVudHMgYXJlIG1ha2luZyB0aGVpciByZXF1ZXN0cyBkaXJlY3RseSB0byBpdC4NCj4+ IA0KPj4gVGhlIENJL1QgaW50ZXJmYWNlIGlzIG9ubHkgYSBzbWFsbCBwYXJ0IG9mIENETiBJbnRl cmNvbm5lY3Rpb24uIFRoZXJlIGFyZQ0KPj4gb3RoZXIgaW50ZXJmYWNlcyBmb3IgZGlzdHJpYnV0 aW9uIG9mIG1ldGFkYXRhLCByZXF1ZXN0IHJvdXRpbmcsIGFuZCByZXRyaWV2YWwNCj4+IG9mIGRD RE4gbG9nIGZpbGVzIGJ5IHRoZSB1Q0ROLg0KPj4gDQo+PiBTaWduaWZpY2FudCB3b3JrIHdlbnQg aW4gdG8gdGhlIENETkkgbG9nZ2luZyBpbnRlcmZhY2UgdG8gbWFrZSBpdCBwb3NzaWJsZQ0KPj4g dG8gYW5vbnltaXNlL2FnZ3JlZ2F0ZSBlbmQtY2xpZW50IGluZm9ybWF0aW9uIGJlZm9yZSBzaGFy aW5nIGl0IHdpdGggYQ0KPj4gdUNETiAtIGJ1dCB0aGF0J3Mgbm90IHJlbGV2YW50IHRvIHRoZSBD SS9UIGludGVyZmFjZSwgd2hpY2ggZG9lcyBub3QgY2FycnkNCj4+IGFueSBlbmQtdXNlciBzcGVj aWZpYyBpbmZvcm1hdGlvbi4NCj4+IA0KPj4gVGhlIENJL1QgaW50ZXJmYWNlIGRvZXMgbm90IGV4 cG9zZSBhbnkgZENETiBpbmZvcm1hdGlvbiBhYm91dCBlbmQtY2xpZW50cyB0bw0KPj4gdGhlIHVD RE4uDQo+DQo+TXkgY29tbWVudCBpcyBhbHNvIGNhdXNlZCBieSBteSBtaXN1bmRlcnN0YW5kaW5n IG9mIHVDRE4gaW4gdGhlIGFyY2hpdGVjdHVyZS4NCj5TbyB5ZXMsIEkgYWdyZWUgd2l0aCB5b3Ug dGhhdCB0aGVyZeKAmXMgbm8gcHJpdmFjeSBpc3N1ZSBoZXJlLg0KPg0KPkluIGFueSBjYXNlLCB0 aGFua3MgZm9yIHlvdXIgZGV0YWlsZWQgYW5zd2VyLiBBbmQgc29ycnkgZm9yIG15IG1pc3VuZGVy c3RhbmRpbmcNCj5vZiB0aGUgYXJjaGl0ZWN0dXJlLg0KPg0KPkNoZWVycywNCj4NCj4gICBWaW5j ZW50DQo= From nobody Sun Mar 20 13:18:39 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFDD12D54A; Sun, 20 Mar 2016 13:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD3o_0ngIOyA; Sun, 20 Mar 2016 13:18:26 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3249612D546; Sun, 20 Mar 2016 13:18:26 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qSqz400Hnz36T; Sun, 20 Mar 2016 21:18:24 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 5E_uBZrj2_Fd; Sun, 20 Mar 2016 21:18:22 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 20 Mar 2016 21:18:22 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id CB7326019B73; Sun, 20 Mar 2016 16:18:21 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca CB7326019B73 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C690126087; Sun, 20 Mar 2016 16:18:21 -0400 (EDT) Date: Sun, 20 Mar 2016 16:18:21 -0400 (EDT) From: Paul Wouters To: secdir , iesg@ietf.org Message-ID: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Cc: draft-ietf-radext-bigger-packets-05.all@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-radext-bigger-packets X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 20:18:28 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The draft is Ready with nits This document introduces new attributes to Radius to signal handling radius packets larger than 4096 octets. This is possible when using TCP as a transport mechanism which is already defined in another RFC. The document sort of suggests using TLS to protect against any possible attacks on TCP. I think it could be more explicit about this. I'm a little confused about when a size refers to a RADIUS packet size, and when it refers to a TCP packet size. eg: An implementation of [RFC6613] will silently discard any packet larger than 4096 octets and will close the TCP connection. But TCP is a stream, so it could be using multiple packets smaller than 4096 that would transport a radius packet that is larger than 4096 bytes. (I assume in the beginning it couldn't since everything was limited by single UDP packets?) What does "maximum size of a response" refer to? TCP packet size or radius packet size? I think it would make the document clearer if the authors would go over all mentions of "packet" and "size" and specifically write it out as radius packet size or TCP packet size. I'm also confused by: Other attributes or configuration MAY be used as an indicator that large responses are likely to be acceptable. Are those attributes defined in another RFC? If not, this document should not hand-wave about non-standard attributes. The security considerations state: These attacks can be entirely mitigated by using TLS. If these attacks are acceptable, then this specification can be used over TCP. This text is confusing. I think it means to say "These attacks can be avoided by using TLS". Because this whole document is about TCP, so there is no case where "this specification" can be used "not over TCP". nits: cloing -> closing? by including the attribute the client indicates -> By including the attribute, the client indicates an next hop -> a next hop Paul From nobody Tue Mar 22 07:57:45 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A6D12D9F5; Tue, 22 Mar 2016 07:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae5e_P8u6_4R; Tue, 22 Mar 2016 07:57:41 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5611E12D975; Tue, 22 Mar 2016 07:57:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,377,1454972400"; d="asc'?scan'208,217";a="209498763" Received: from geve.inrialpes.fr ([194.199.28.1]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2016 15:57:38 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_060E29B6-ECD5-44E4-BC08-AB14B7CE2E8D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Vincent Roca In-Reply-To: <252883D7-E325-4B9A-A978-FEACE5B40143@alcatel-lucent.com> Date: Tue, 22 Mar 2016 15:57:37 +0100 Message-Id: <61B94AAC-920E-4909-9680-6FF212E8901D@inria.fr> References: <252883D7-E325-4B9A-A978-FEACE5B40143@alcatel-lucent.com> To: "Murray, Rob (Nokia - GB)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "draft-ietf-cdni-control-triggers@tools.ietf.org" , "cdni@ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-cdni-control-triggers-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 14:57:43 -0000 --Apple-Mail=_060E29B6-ECD5-44E4-BC08-AB14B7CE2E8D Content-Type: multipart/alternative; boundary="Apple-Mail=_828F5FE5-2B44-482B-A67B-DAA632B1F4EB" --Apple-Mail=_828F5FE5-2B44-482B-A67B-DAA632B1F4EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rob, > I've just posted a "-12" of the CDNI Triggers draft, hopefully = addressing these comments. Responses inline below. I see you've added section 2.2.1 to clarify many architectural aspects. = That's quite useful. >>>> There are several topics I=E2=80=99d like to discuss: >>>>=20 >>>> 1- Concerning the use of TLS to carry CI/T traffic, I see it is = mandatory >>>> to implement, but still optional to use (1st sentence of Section = 8.1). Is >>>> it still reasonable in current Internet? At a minimum I would = expect a >>>> =C2=AB MUST support =C2=BB / =C2=AB SHOULD use =C2=BB. >>>=20 >>> Section 8.1 goes on to say ... >>>=20 >>> [ ... description of benefits of HTTPS ... ] >>>=20 >>> In an environment where any such protection is required, mutually >>> authenticated encrypted transport MUST be used to ensure >>> confidentiality of the CI/T information. To that end, TLS MUST be >>> used by CI/T, including authentication of the remote end. >>>=20 >>> ... the Internet is clearly an environment where such protection is >>> required, and it'll often be used for these interfaces - we could = state >>> that explicitly, would that address the concern? >>>=20 >>> But, CI/T could also be deployed to run over a VPN or private = network >>> between two interconnected CDNs, in such an environment HTTPS = transport >>> would not have the same benefits. >>=20 >> Yes, that=E2=80=99s my point. Say explicitly that Internet is an = example of environment where >> such a protection is mandatory. >=20 > In "-12" I've aligned the text above with the text used in the = cdni-metadata draft: >=20 > TLS MUST be used by the server-side (dCDN) and the client-side (uCDN) = of > the CI/T interface, including authentication of the remote end, = unless > alternate methods are used for ensuring the confidentiality of the > information in the CI/T interface requests and responses (such as = setting > up an IPsec tunnel between the two CDNs or using a physically secured > internal network between two CDNs that are owned by the same = corporate > entity). >=20 > I think that covers it better (?). This is much better. Just a minor comment: "... for insuring the = security" instead of "... for ensuring the confidentiality", since confidentiality is only = one aspect of security. >>>> 2- Section 8.1, please check the paragraph =C2=AB Note that in a =C2=AB= diamond =C2=BB >>>> configuration [=E2=80=A6] =C2=BB. This paragraph is rather = confusing to me. Confusion >>>> comes from: >>>> - the lack of description of the =C2=AB diamond configuration =C2=BB.= I understand >>>> there is one dCDN on top and multiple uCDN directly connected = below, am I >>>> right? >>>=20 >>> Yes, that's right. The draft says: >>>=20 >>> Note that in a "diamond" configuration, where one uCDN's content = can >>> be acquired via more than one directly-connected uCDN, >>>=20 >>> Would the following rearrangement help? ... >>>=20 >>> A "diamond" configuration is one where a dCDN can acquire a uCDN's >>> content via more than one directly-connected uCDN. Note that >>> in a diamond configuration [=E2=80=A6] >>=20 >> Yes, I prefer this version. However, can the same =C2=AB uCDN=E2=80=99s= content =C2=BB be >> available at several uCDNs in this diamond configuration? Said = differently, >> what about the following text: >>=20 >> A =C2=AB diamond =C2=BB configuration is one where a dCDN can = acquire a given >> content via more than one directly-connected uCDN. Note that = [=E2=80=A6] >=20 > Yes, more than one uCDN will have the same content - but the important = point is that ultimately they will all have acquired it from the same = uCDN, and that uCDN owns the metadata. >=20 > I've tried to provide a better intro/explanation in new section 2.2.1 = "Multiple interconnected CDNs". Hopefully that makes it a bit clearer? Yes, as said above, section 2.2.1 is rather useful. Just a comment for this section 2.2.1, third paragraph, last sentence. = You mention both "intermediate CDN" and just after "intermediate uCDN". This is a = bit confusing. Another detail: in second paragraph you mention ""intermediate" CDN" = with extra " " around intermediate. Please harmonize. >>>> 3- With this =C2=AB diamond configuration =C2=BB, since several = uCDN can act upon the >>>> same content, what happens if they behave in a non coordinated = manner (i.e., >>>> in the general case)? For instance let=E2=80=99s imagine one of = them asks the dCDN >>>> to delete the content or cancel the initial command. What happens = if another >>>> uCDN then asks the dCDN to invalidate this content, providing the = URL of the >>>> Trigger Status Resource which (if I understand correctly) is no = longer valid? >>>> This =C2=AB diamond configuration =C2=BB can be a little bit tricky = and no clear >>>> guideline is provided in the document. >>>=20 >>> A trigger status resource belongs to one uCDN and cannot be accessed = or >>> manipulated by any other CDN, section 3 para 3 says: >>>=20 >>> Trigger Status Resources belonging to a uCDN MUST NOT >>> be visible to any other CDN. The dCDN could, for example, achieve >>> this by offering different collection URLs to each uCDN, and/or by >>> filtering the response based on the uCDN with which the HTTP client >>> is associated. >>=20 >> I see=E2=80=A6 However, if multiple uCDNs can act on the same content = (what is said), >> even if each uCDN uses a different URL, will simultaneous CI/T = commands for >> the same content be managed correctly? This is not said in section 3 >> paragraph 3 either and this is a key point. >=20 > Sorry, I'd missed your point. >=20 > Interactions can be inefficient, but are otherwise harmless because = the strongest of "invalidate" or "purge" will win, and content can = always be re-acquired if it's still available from any uCDN. >=20 > I've given some examples in new section 2.2.1 "Multiple interconnected = CDNs", and added a pointer to that from the Security Considerations = section. Once again, the examples of section 2.2.1 answer my comments. Thanks. >>> Content always originates from one uCDN, but in a diamond = configration there >>> may be multiple routes (via other CDNs) to a given dCDN. >>>=20 >>> The most common scenario may well be that the uCDN will initiate all = of the >>> CI/T commands related to its content, and those commands will simply = be >>> forwarded by intermediate CDNs. >>>=20 >>> But, there's nothing to stop an intermediate CDN initiating or = modifying >>> CI/T commands - and some modifications of the command will be = necessary >>> (for example, metadata URLs will need to be changed). >>>=20 >>> By analysis of log files it will probably be possible to work out = which >>> uCDN an individual cache in the dCDN acquired each cached resource = from. >>> But the cache is not required to keep a live record of that, and it >>> probably won't. In that case, when it receives a CI/T command to = invalidate >>> or purge content, the dCDN should apply that command to any content = it >>> may have acquired from the uCDN it got the CI/T command from. >>>=20 >>> So there is scope for a malicious intermediate CDN to cause extra = processing >>> and acquisition by a dCDN (and that's mentioned in section 8). But a >>> malicious CDN is likely to find itself removed from the CDN = federation fairly >>> quickly - there will necessarily be a level of trust between = interconnected >>> CDNs. >>>=20 >>> Would it help to spell out some of that in the draft? (The same or = very >>> similar text has been used in several of the CDNI drafts.) >>=20 >> Yes, this paragraph is worth being detailed a little bit. >>=20 >> In your explanations you mention intermediate CDNs while original = text only >> mentions directly connected uCDNs. The notion of =C2=AB intermediate = CDN =C2=BB is >> only discussed in sections 2.3 and 4.8. Since malicious intermediate = CDNs are >> part of a valid attack model, it is worth to explain it (or give a = reference to another >> document). >=20 > When a content owner, the origin, delegates delivery to a CDN it is = trusting that CDN to deliver the right content on its behalf. A = malicious CDN could deliver anything instead, but it would soon lose the = trust of the origin. >=20 > CDN-interconnection simply extends that trust to the = further-downstream CDNs acting on behalf of the original. >=20 > So establishment/enforcement of the trust relationship itself, the = contract between the origin and the CDN, is outside the scope of CDNI = and in the land of commercial agreements. Sure, I agree. > I've added a note on that in the intro to the Security Considerations = section. That's perfect. To conclude the document is okay from my point of view. Thanks for your detailed answers. Cheers, Vincent --Apple-Mail=_828F5FE5-2B44-482B-A67B-DAA632B1F4EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Rob,

I've just posted a "-12" of the CDNI Triggers = draft, hopefully addressing these comments. Responses inline below.

I see you've = added section 2.2.1 to clarify many architectural aspects. That's quite = useful.


There are = several topics I=E2=80=99d like to discuss:

1- Concerning the use of TLS to carry CI/T traffic, I see it = is mandatory
to implement, but still optional to use (1st = sentence of Section 8.1). Is
it still reasonable in = current Internet? At a minimum I would expect a
=C2=AB = MUST support =C2=BB / =C2=AB SHOULD use =C2=BB.

Section 8.1 goes on to say ...

 [ ... description of benefits of HTTPS = ... ]

 In an environment where any = such protection is required, mutually
 authenticated = encrypted transport MUST be used to ensure
 confidentiality of the CI/T information. To that end, = TLS MUST be
 used by CI/T, including authentication = of the remote end.

... the Internet is = clearly an environment where such protection is
required, = and it'll often be used for these interfaces - we could state
that explicitly, would that address the concern?

But, CI/T could also be deployed to run over a = VPN or private network
between two interconnected CDNs, in = such an environment HTTPS transport
would not have the = same benefits.

Yes, that=E2=80=99= s my point. Say explicitly that Internet is an example of environment = where
such a protection is mandatory.

In "-12" I've aligned the text = above with the text used in the cdni-metadata draft:

 TLS MUST be used by the server-side (dCDN) and the = client-side (uCDN) of
 the CI/T interface, including = authentication of the remote end, unless
 alternate = methods are used for ensuring the confidentiality of the
 information in the CI/T interface requests and = responses (such as setting
 up an IPsec tunnel = between the two CDNs or using a physically secured
 internal network between two CDNs that are owned by the = same corporate
 entity).

I= think that covers it better (?).

This is much better. Just a minor comment: "... = for insuring the security" instead of
"... for ensuring the = confidentiality", since confidentiality is only one aspect of = security.


2- Section = 8.1, please check the paragraph =C2=AB Note that in a =C2=AB diamond = =C2=BB
configuration [=E2=80=A6] =C2=BB. This paragraph is = rather confusing to me. Confusion
comes from:
- the lack of description of the =C2=AB diamond configuration = =C2=BB. I understand
there is one dCDN on top and multiple = uCDN directly connected below, am I
right?

Yes, that's right. The draft = says:

 Note that in a "diamond" = configuration, where one uCDN's content can
 be = acquired via more than one directly-connected uCDN,

Would the following rearrangement help? ...

 A "diamond" configuration is one where a dCDN can = acquire a uCDN's
 content via more than one = directly-connected uCDN. Note that
 in a diamond = configuration [=E2=80=A6]

Yes, = I prefer this version. However, can the same =C2=AB uCDN=E2=80=99s = content =C2=BB be
available at several uCDNs in this = diamond configuration? Said differently,
what about the = following text:

A =C2=AB = diamond =C2=BB configuration is one where a dCDN can acquire a given
= content via more than one directly-connected uCDN. Note that = [=E2=80=A6]

Yes, more than one = uCDN will have the same content - but the important point is that = ultimately they will all have acquired it from the same uCDN, and that = uCDN owns the metadata.

I've tried to = provide a better intro/explanation in new section 2.2.1 "Multiple = interconnected CDNs". Hopefully that makes it a bit clearer?

Yes, as said = above, section 2.2.1 is rather useful.
Just a comment for this = section 2.2.1, third paragraph, last sentence. You = mention
both "intermediate CDN" and just after "intermediate = uCDN". This is a bit confusing.

Another detail: in second paragraph you mention = ""intermediate" CDN" with extra " "
around intermediate. = Please harmonize.


3- With this =C2=AB diamond configuration =C2=BB,= since several uCDN can act upon the
same content, what = happens if they behave in a non coordinated manner (i.e.,
in= the general case)? For instance let=E2=80=99s imagine one of them asks = the dCDN
to delete the content or cancel the initial = command. What happens if another
uCDN then asks the dCDN = to invalidate this content, providing the URL of the
Trigger= Status Resource which (if I understand correctly) is no longer = valid?
This =C2=AB diamond configuration =C2=BB can be a = little bit tricky and no clear
guideline is provided in = the document.

A trigger status = resource belongs to one uCDN and cannot be accessed or
manipulated by any other CDN, section 3 para 3 says:

 Trigger Status Resources belonging to a = uCDN MUST NOT
 be visible to any other CDN. The dCDN = could, for example, achieve
 this by offering = different collection URLs to each uCDN, and/or by
 filtering the response based on the uCDN with which the = HTTP client
 is associated.

I see=E2=80=A6 However, if = multiple uCDNs can act on the same content (what is said),
even if each uCDN uses a different URL, will simultaneous = CI/T commands for
the same content be managed correctly? = This is not said in section 3
paragraph 3 either and this = is a key point.

Sorry, I'd = missed your point.

Interactions can be = inefficient, but are otherwise harmless because the strongest of = "invalidate" or "purge" will win, and content can always be re-acquired = if it's still available from any uCDN.

I've = given some examples in new section 2.2.1 "Multiple interconnected CDNs", = and added a pointer to that from the Security Considerations section.

Once again, the = examples of section 2.2.1 answer my comments. Thanks.


Content always originates from one uCDN, but in a diamond = configration there
may be multiple routes (via other CDNs) = to a given dCDN.

The most common scenario = may well be that the uCDN will initiate all of the
CI/T = commands related to its content, and those commands will simply be
forwarded by intermediate CDNs.

But, there's nothing to stop an intermediate CDN initiating = or modifying
CI/T commands - and some modifications of the = command will be necessary
(for example, metadata URLs will = need to be changed).

By analysis of log = files it will probably be possible to work out which
uCDN = an individual cache in the dCDN acquired each cached resource from.
But the cache is not required to keep a live record of that, = and it
probably won't. In that case, when it receives a = CI/T command to invalidate
or purge content, the dCDN = should apply that command to any content it
may have = acquired from the uCDN it got the CI/T command from.

So there is scope for a malicious intermediate CDN to cause = extra processing
and acquisition by a dCDN (and that's = mentioned in section 8). But a
malicious CDN is likely to = find itself removed from the CDN federation fairly
quickly = - there will necessarily be a level of trust between interconnected
CDNs.

Would it help to spell out = some of that in the draft? (The same or very
similar text = has been used in several of the CDNI drafts.)

Yes, this paragraph is worth = being detailed a little bit.

In your = explanations you mention intermediate CDNs while original text only
mentions directly connected uCDNs. The notion of =C2=AB = intermediate CDN =C2=BB is
only discussed in sections 2.3 = and 4.8. Since malicious intermediate CDNs are
part of a = valid attack model, it is worth to explain it (or give a reference to = another
document).

When a content owner, the origin, delegates delivery to a CDN = it is trusting that CDN to deliver the right content on its behalf. A = malicious CDN could deliver anything instead, but it would soon lose the = trust of the origin.

CDN-interconnection = simply extends that trust to the further-downstream CDNs acting on = behalf of the original.

So = establishment/enforcement of the trust relationship itself, the contract = between the origin and the CDN, is outside the scope of CDNI and in the = land of commercial agreements.

Sure, I agree.


I've added a note on = that in the intro to the Security Considerations section.

That's = perfect.

To conclude = the document is okay from my point of view.

Thanks for your detailed = answers.
Cheers,

  =  Vincent
= --Apple-Mail=_828F5FE5-2B44-482B-A67B-DAA632B1F4EB-- --Apple-Mail=_060E29B6-ECD5-44E4-BC08-AB14B7CE2E8D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW8V1iAAoJEHBYw8t72N4rFogQAK4csGPr4nCwEWqqDMW+yqyz IYG35peb2e+mBwlgP032oxsAwUJonHCvG4hG1IaYGFb9XW6EROGdW9Pl8w1HXC4a prUdC0psicvn4k/qzaM5WPbU2klHn8twVu+OmDq1Xv7F4hJ7BRRJTS8OWXAF6qbO oXIvA8+GR6dVii9dKRYllu2JX+VDdgxjQdarLx//2cI6Kk4ZmpMQHj//fcsxULMq 1Oa8k59AG8yi5TtuRKpaNWIX0TN5FOFNqaI/jhSz3+pbItKT/GNuU8f2U1YK3QRe +/h3g+0dJZxVLA4k0B3A9eyRHZI5eypR3dCL6y1i7nUC+UyNtEQkTdycdhzj9+IJ ofXhcr+wozo0tapI45ZJaROxE8kJZCYjwbpcYBJSBJggGweOI4ErtBLFx9zQYRvi bI8giPEKKZEZ061Df4gcQdO1S6IDdL5Hupv6+43L/7fDlQzB48pxfOSpdji9GMvM 94h/glE6Sf40UU7KD7Bhyunbh8oRwwLDz/0Rl6LK7qMyG62OfdL3NuXuv1wyIvNB 13Re1P+o3P6pSQdKDRLch08IJ9CIMur8tU+5ftsvSUburyPNo8mAdEKq+s5BuqG8 fXtqN7x1obAARcjAKwlmy+inribBLn8+J5vOa5y04txRRauk1MUwnuy84vBIKTg3 PU8SqIW8vON3iD5crMvA =bPMU -----END PGP SIGNATURE----- --Apple-Mail=_060E29B6-ECD5-44E4-BC08-AB14B7CE2E8D-- From nobody Tue Mar 22 13:14:09 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F44712D8A7; Tue, 22 Mar 2016 13:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUdnH8TRd2pi; Tue, 22 Mar 2016 13:14:06 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B24012D509; Tue, 22 Mar 2016 13:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2568; q=dns/txt; s=iport; t=1458677646; x=1459887246; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=l+PvBa8ieZVjGE43kLZ3i31oyqBkTkgXrNWA2uP8Sw4=; b=XxDDpJ6eS+M26nmcwM4XTBtxeLPIEMPc6Wn9pepvHxZbrp+62qvu0c69 30qph9Y01z86wux+hzNMeSUM9a8ZGJfh3/KL3ShZu7DhCBt8Bkc0Ar4fp XJ9sQnz/wkZtHtj685meIX67fLPUEPKdGf9M0bwaWSSNFzNCUNNSJxwZN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgAgDjpvFW/5JdJa1egzOBU7pDAQ2Bc?= =?us-ascii?q?IYNgVE4FAEBAQEBAQFkJ4REBHIHEgGBACcEAQ2ILMEZAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEZiBGKOIIrBZdXAYEqjFmPCY8GAR4BAUKDZYlyfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,378,1454976000"; d="scan'208";a="252315963" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2016 20:14:05 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u2MKE5TT017711 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Mar 2016 20:14:05 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 22 Mar 2016 16:14:04 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Tue, 22 Mar 2016 16:14:04 -0400 From: "Brian Weis (bew)" To: The IESG , "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-cdni-footprint-capabilities-semantics-12 Thread-Index: AQHRhHdhY2ZvuIxqdkmtH/tNM8qcVg== Date: Tue, 22 Mar 2016 20:14:04 +0000 Message-ID: <6A77AE94-D1D3-42FF-BA8B-41FE180E1489@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.50.82] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-cdni-footprint-capabilities-semantics.all@tools.ietf.org" Subject: [secdir] Secdir review of draft-ietf-cdni-footprint-capabilities-semantics-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 20:14:08 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. The document describes high level semantics around the method that sites in= a CDN Interconnection (CDNI) can perform a capability exchange, and define= s the semantics that would be exchanged. The described semantics do not for= m a protocol, or even a data format, but provide an overview of considerati= ons and guidance on the types of information that are to be exchanged. The Security Considerations section does make requirements on protocols tha= t would implement a capabilities exchange conforming to this document, whic= h is that they must provide =93integrity and authentication services=94 bet= ween the sites. It also notes that since a CDNI is setup as the result of b= usiness relationships, it=92s reasonable to expect and out of band method f= or exchanging authentication state for a protocol. This seems right to me. Confidentiality of protocols that implement these semantics is not consider= ed a high priority because "It is not believed that there are any serious p= rivacy risks in sharing footprint or capability information=94. The section= states an assumption that the shared information will be aggregated data a= nd policy-related information about media, rather than personally identifyi= ng information (PII). However, since this document is not specifying any pa= rticular protocol, and thus does not strictly control the contents of the p= rotocol, this seems like an uncertain assumption to me. It would be better = to make a more positive assertion recommending confidentiality, so that pr= otocol implementors conforming to this document are less likely to forget t= o add confidentiality when they do pass PII, or when they forget to think a= bout privacy threats to PII. If a traditional cryptographic system (such as= TLS) is deployed to obtain integrity, including confidentiality protection= comes for a very small (perhaps negligible) additional cost but provides s= ubstantial added privacy value, so there isn=92t much technical justificati= on to explicitly omit confidentiality. Because of this privacy risks discussion, I consider document is "Ready wit= h issues=94 (but it=92s just the one issue, all else looks fine to me). Brian= From nobody Tue Mar 22 14:30:33 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E8012DA37; Tue, 22 Mar 2016 14:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJsAp_TTZpP5; Tue, 22 Mar 2016 14:30:29 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0EC12DA33; Tue, 22 Mar 2016 14:30:28 -0700 (PDT) X-AuditID: 1209190e-49bff70000000d1c-b6-56f1b973edd9 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id A9.DC.03356.379B1F65; Tue, 22 Mar 2016 17:30:27 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u2MLUQfa026192; Tue, 22 Mar 2016 17:30:27 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2MLUOt0009657; Tue, 22 Mar 2016 17:30:25 -0400 From: Tom Yu To: Andy Bierman References: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> Date: Tue, 22 Mar 2016 17:30:24 -0400 In-Reply-To: (Andy Bierman's message of "Tue, 15 Mar 2016 10:28:54 -0700") Message-ID: Lines: 26 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixG6nolu882OYwa2POhYPjsxit3hwuIXN YsaficwWp9+sY7P4sPAhiwOrx85Zd9k9liz5yeTx5fJnNo+W/ossASxRXDYpqTmZZalF+nYJ XBmL5zxkK7jDWfF9107GBsb/7F2MnBwSAiYSR9/3sXUxcnEICbQxSZyY3MQGkhAS2Mgo0dxk CJF4wyixpn82C0iCTUBa4vjlXUwgtoiAqsSFuROZQYqYBZYxSnQ//MwKkhAWcJDYeX4dI8Sk 04wS+57pg9gsQA3XDv0EW8cpMJFR4vrVh2BFvAK6Eod6p4Nt4BHglHh5ciNUXFDi5MwnYHFm AS2JG/9eMk1g5J+FJDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXWO93MwSvdSU0k2M oHDllOTbwTipwfsQowAHoxIPb8OGD2FCrIllxZW5hxglOZiURHmTtn8ME+JLyk+pzEgszogv Ks1JLT7EKMHBrCTCu6oPKMebklhZlVqUD5OS5mBREudlZGBgEBJITyxJzU5NLUgtgsnKcHAo SfD27wBqFCxKTU+tSMvMKUFIM3FwggznARruD1LDW1yQmFucmQ6RP8WoKCXO+xrkIgGQREZp HlwvOJ0IMe57xSgO9Iow7wuQKh5gKoLrfgU0mAlosEvkO5DBJYkIKakGRoOJVpcmvP6jXTSh TvX23c3FG3vWb/8WNGcJQ1Pchxtbjy179V/wxc6sny/8Dr/R7P8ao84qpPHpflbL812Ss6X3 FRun7O04tkH2YCxXxRIR7s27JbYUHOrdsdMgpeyj+bHHG0ILq69N4Y446m2RPZfFpf4Tb69J Bf9JeYvnVivvTHuew3Xy9hclluKMREMt5qLiRACvDltmAgMAAA== Archived-At: Cc: Mahesh Jethanandani , draft-ietf-netconf-yang-library.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 21:30:31 -0000 Andy Bierman writes: > The YANG library provides the same information that is currently > in the NETCONF message. > > It is expected that NACM (RFC 6536) will be used to prevent access > to sensitive operations, notifications, and data. > However NACM is optional-to-implement with NETCONF and RESTCONF. > > The risk is the same as current NETCONF. > If a specific module/revision implementation is known to > be vulernable, then NETCONF and this library both let > the client know it is running on the server. If the risk is the same as current NETCONF, then why mention it in this document? It seems to me that the YANG library provides somewhat more detail than the NETCONF message, right? The YANG library provides deviation and conformance details, unlike what I see in the NETCONF message description in RFC6241, unless there's something I'm missing. It would be good to clarify whether the risks of exposing /modules-state/module include vulnerabilities in the NETCONF implementation itself, or with vulnerabilities in the associated underlying network device functionality for which NETCONF provides configuration access (perhaps both, to different degrees?). From nobody Tue Mar 22 14:57:11 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D6612DAB0 for ; Tue, 22 Mar 2016 14:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1S_RSpGIbUxk for ; Tue, 22 Mar 2016 14:57:07 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94CE512DAAA for ; Tue, 22 Mar 2016 14:57:06 -0700 (PDT) Received: by mail-lb0-x234.google.com with SMTP id bc4so174304105lbc.2 for ; Tue, 22 Mar 2016 14:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=kpGH78teRuUa3xpU9F8VlIHXaiCdiPjYbk3JViwVH7g=; b=q/RjZ73pCjgMVykbFZ2ekSv/DUCrTUMeQ/os6RcXFbQ+QYOLf3Kpy5SKkpVNAHGG4q CZ26ATuu48N/kmy6GHP6weOcT28CYrTV+PIt2hZcdn2u7Qfxbwp9/tPmB15Meh5C3ttH O4PrOCPkZxYt8r7RxF+Nk0s7Gjef33dp83mnt7KrOBj6r8DprreZi4OBZwQjDtAJ2PV5 GLgYa+DWoTcDXpaMqYBKtGIHatd8sTxXsP9wLBnK6koNF73uAuk50xdryfJIoj99w9SB HkDvwd/a97b/ygItU7rRefDzUeQg5QizKIovo3oKQnTzOYiXaIqgm3+UbBTXcxorXt0s XRfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kpGH78teRuUa3xpU9F8VlIHXaiCdiPjYbk3JViwVH7g=; b=lpHKgDHuMQDnCCj422mypZHnMBMQsNTxnxy9DYgg3adu5mx4s2jrOjyihan0fKbTM3 8eEzwnXfF/vm21VHmuLTfKE7P77oSmhAPlExA9lOfR4uIs9cHcGHaIWojiaytBU2srBv BzJ2dPUtmzcKZc7UDTC1xXrDueVpPzjwaw7mw71qoBV5aFbzrPmE+3PVj51H97PG0UWt 5sV0in8alIhuJhQTW5b1MFXxLBIIXO6UTdbv6b1CWG/fS8qWODnBmj0Gu6zcxlcgKbas 57USXasRZw0UwoHtWaTuaYGYPokST482NjbM0c4ZkzASFhgswK6XKXo0wLEDGKrGbhPh 7ccA== X-Gm-Message-State: AD7BkJJ4q6TMuW8XCI0dPw4zbDldFO5JbgL2W6z/NhQRDBES2JaFFoaj8fYe79pstrK2/U/4eXNZ9bpamV+J6g== MIME-Version: 1.0 X-Received: by 10.112.62.229 with SMTP id b5mr13246071lbs.30.1458683824723; Tue, 22 Mar 2016 14:57:04 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Tue, 22 Mar 2016 14:57:04 -0700 (PDT) In-Reply-To: References: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> Date: Tue, 22 Mar 2016 14:57:04 -0700 Message-ID: From: Andy Bierman To: Tom Yu Content-Type: multipart/alternative; boundary=001a11c3c384366ba5052eaa4bf3 Archived-At: Cc: Mahesh Jethanandani , draft-ietf-netconf-yang-library.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 21:57:09 -0000 --001a11c3c384366ba5052eaa4bf3 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 22, 2016 at 2:30 PM, Tom Yu wrote: > Andy Bierman writes: > > > The YANG library provides the same information that is currently > > in the NETCONF message. > > > > It is expected that NACM (RFC 6536) will be used to prevent access > > to sensitive operations, notifications, and data. > > However NACM is optional-to-implement with NETCONF and RESTCONF. > > > > The risk is the same as current NETCONF. > > If a specific module/revision implementation is known to > > be vulernable, then NETCONF and this library both let > > the client know it is running on the server. > > If the risk is the same as current NETCONF, then why mention it in this > document? It seems to me that the YANG library provides somewhat more > detail than the NETCONF message, right? The YANG library > provides deviation and conformance details, unlike what I see in the > NETCONF message description in RFC6241, unless there's something > I'm missing. > > The YANG library provides the revision date of the deviations module, which is not included in the NETCONF . It also lists the submodules and their revisions, which is not contained in the NETCONF . The NETCONF message is not specified well enough to make any other generalizations about the differences. > It would be good to clarify whether the risks of exposing > /modules-state/module include vulnerabilities in the NETCONF > implementation itself, or with vulnerabilities in the associated > underlying network device functionality for which NETCONF provides > configuration access (perhaps both, to different degrees?). > The library is intended for other protocols such as RESTCONF. Is there some specific text you want changed? This is the only non-boilerplate text in the section: Is there some part of this that is incorrect? o /modules-state/module: The module list used in a server implementation may help an attacker identify the server capabilities and server implementations with known bugs. Server vulnerabilities may be specific to particular modules, module revisions, module features, or even module deviations. This information is included in each module entry. For example, if a particular operation on a particular data node is known to cause a server to crash or significantly degrade device performance, then the module list information will help an attacker identify server implementations with such a defect, in order to launch a denial of service attack on the device. --001a11c3c384366ba5052eaa4bf3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 22, 2016 at 2:30 PM, Tom Yu <tlyu@mit.edu> wrot= e:
Andy Bierman <andy@yumaworks.com> writes:

> The YANG library provides the same information that is currently
> in the NETCONF <hello> message.
>
> It is expected that NACM (RFC 6536) will be used to prevent access
> to sensitive operations, notifications, and data.
> However NACM is optional-to-implement with NETCONF and RESTCONF.
>
> The risk is the same as current NETCONF.
> If a specific module/revision implementation is known to
> be vulernable, then NETCONF and this library both let
> the client know it is running on the server.

If the risk is the same as current NETCONF, then why mention it in this
document?=C2=A0 It seems to me that the YANG library provides somewhat more=
detail than the NETCONF <hello> message, right?=C2=A0 The YANG librar= y
provides deviation and conformance details, unlike what I see in the
NETCONF <hello> message description in RFC6241, unless there's so= mething
I'm missing.



The YANG library provid= es the revision date of the deviations module,
which is not inclu= ded in the NETCONF <hello>.

It =C2=A0also li= sts the submodules and their revisions, which is
not contained in= the NETCONF <hello>.

The NETCONF <hello&= gt; message is not specified well enough to
make any other genera= lizations about the differences.


=C2=A0
It would be good to clarify whether the risks of exposing
/modules-state/module include vulnerabilities in the NETCONF
implementation itself, or with vulnerabilities in the associated
underlying network device functionality for which NETCONF provides
configuration access (perhaps both, to different degrees?).


The library is intended for other protocols such as RESTC= ONF.

I= s there some specific text you want changed?
This is the only non-boilerplate text in the section:
Is there some part of this that is incorrect?



=
   o  /modules-state/module: The module list used in a server
      implementation may help an attacker identify the server
      capabilities and server implementations with known bugs.  Server
      vulnerabilities may be specific to particular modules, module
      revisions, module features, or even module deviations.  This
      information is included in each module entry.  For example, if a
      particular operation on a particular data node is known to cause a
      server to crash or significantly degrade device performance, then
      the module list information will help an attacker identify server
      implementations with such a defect, in order to launch a denial of
      service attack on the device.


--001a11c3c384366ba5052eaa4bf3-- From nobody Wed Mar 23 08:58:56 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399CC12D6CA; Wed, 23 Mar 2016 08:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nza7d1I3S4G9; Wed, 23 Mar 2016 08:58:48 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1EC512D6A2; Wed, 23 Mar 2016 08:58:47 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-7b-56f2bd14c09d Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 86.0C.22441.41DB2F65; Wed, 23 Mar 2016 16:58:13 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0248.002; Wed, 23 Mar 2016 11:58:46 -0400 From: Kevin Ma J To: "Brian Weis (bew)" , The IESG , "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-cdni-footprint-capabilities-semantics-12 Thread-Index: AQHRhHdhY2ZvuIxqdkmtH/tNM8qcVp9nLyug Date: Wed, 23 Mar 2016 15:58:46 +0000 Message-ID: References: <6A77AE94-D1D3-42FF-BA8B-41FE180E1489@cisco.com> In-Reply-To: <6A77AE94-D1D3-42FF-BA8B-41FE180E1489@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZXLrHW1d076cwgzt/uCz63jayWtw77mox 489EZosPCx+yOLB4TPm9kdVjyZKfTB5fLn9mC2CO4rJJSc3JLEst0rdL4MpYt3wuc8FuqYoz PQoNjBdFuxg5OSQETCT+/z7OBmGLSVy4tx7I5uIQEjjCKLFjej87hLOcUeLF0VtMIFVsAloS j7/+BbNFBNIlznw6CtbNLDCRUeLQVWkQW1ggWOLrxQcsEDUhEl9arrJ2MXIA2UYSW286gZgs AqoS97/YgFTwCvhKdK5YBjZFSMBG4uL/+8wgNqeArcTX2WfANjEC3fb91BomiE3iEreezGeC uFlAYsme88wQtqjEy8f/WCFsJYmPv+ezQ9TrSCzY/QnqSm2JZQtfM0PsFZQ4OfMJywRGsVlI xs5C0jILScssJC0LGFlWMXKUFhfk5KYbGW5iBEbPMQk2xx2Me3s9DzEKcDAq8fAWnPsYJsSa WFZcmXuIUYKDWUmEN37DpzAh3pTEyqrUovz4otKc1OJDjNIcLErivN8+Xg4TEkhPLEnNTk0t SC2CyTJxcEo1MHZPDN2254S82+Rl3OLWUaoNS1mYkxeH1df3yEeln9jgERNr8Om3kOXvB20r fxYv4Lxm+Z95984VLLoP7/zedzjPUe1L51rjanX1BiWLE/a2EwxFJgmu3sd/JEcpeeeWw4lx AaFnj/rtk3n78RL3i7/Fd5O6v100PZPs/UxtyjOWuA1PVFuiW5RYijMSDbWYi4oTASqHaZSa AgAA Archived-At: Cc: "draft-ietf-cdni-footprint-capabilities-semantics.all@tools.ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-cdni-footprint-capabilities-semantics-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 15:58:50 -0000 Hi Brian, Thank you for the review. It is a fair comment and a good suggestion. I= agree that the follow-on protocol spec will have to do the real security e= valuation, and it makes sense to not offer too many assumptions in the sema= ntics doc. I will update the security section in the next rev, to remove t= hat statement and add the suggested privacy measures, in line with the othe= r CDNI protocol drafts. thanx! -- Kevin J. Ma=20 > -----Original Message----- > From: Brian Weis (bew) [mailto:bew@cisco.com] > Sent: Tuesday, March 22, 2016 4:14 PM > To: The IESG; secdir@ietf.org > Cc: draft-ietf-cdni-footprint-capabilities-semantics.all@tools.ietf.org > Subject: Secdir review of draft-ietf-cdni-footprint-capabilities- > semantics-12 >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security are= a > directors. Document editors and WG chairs should treat these comments jus= t > like any other last call comments. >=20 > The document describes high level semantics around the method that sites > in a CDN Interconnection (CDNI) can perform a capability exchange, and > defines the semantics that would be exchanged. The described semantics do > not form a protocol, or even a data format, but provide an overview of > considerations and guidance on the types of information that are to be > exchanged. >=20 > The Security Considerations section does make requirements on protocols > that would implement a capabilities exchange conforming to this document, > which is that they must provide "integrity and authentication services" > between the sites. It also notes that since a CDNI is setup as the result > of business relationships, it's reasonable to expect and out of band > method for exchanging authentication state for a protocol. This seems > right to me. >=20 > Confidentiality of protocols that implement these semantics is not > considered a high priority because "It is not believed that there are any > serious privacy risks in sharing footprint or capability information". Th= e > section states an assumption that the shared information will be > aggregated data and policy-related information about media, rather than > personally identifying information (PII). However, since this document is > not specifying any particular protocol, and thus does not strictly contro= l > the contents of the protocol, this seems like an uncertain assumption to > me. It would be better to make a more positive assertion recommending > confidentiality, so that protocol implementors conforming to this > document are less likely to forget to add confidentiality when they do > pass PII, or when they forget to think about privacy threats to PII. If a > traditional cryptographic system (such as TLS) is deployed to obtain > integrity, including confidentiality protection comes for a very small > (perhaps negligible) additional cost but provides substantial added > privacy value, so there isn't much technical justification to explicitly > omit confidentiality. >=20 > Because of this privacy risks discussion, I consider document is "Ready > with issues" (but it's just the one issue, all else looks fine to me). >=20 > Brian From nobody Wed Mar 23 09:03:55 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC12A12D704; Wed, 23 Mar 2016 09:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOAwjyygg8lr; Wed, 23 Mar 2016 09:03:47 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC19112D710; Wed, 23 Mar 2016 09:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3720; q=dns/txt; s=iport; t=1458749017; x=1459958617; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=W9d1v+Xr3N3rz1MhZxf11bErKIQoFWWX3NTz2HMI92w=; b=jIAPQtdFzIvNRf79Ebo+VV0IZ1qIUmfyvMdwpoBlISTytX2GCKJ7YO54 vmVW+VInKvO2sffQWjScpzY/PySIfG4SRWvSQaxeY0X/DrgFySdHjcLgL RcoTQze38izbnu5IYUWRU0B3u3ZqCrUgyFGE5I9vCTsUn8f4njDFXWm2s U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAgCWvfJW/4sNJK1bA4MzgU0GumEBD?= =?us-ascii?q?YFwhg0CgT04FAEBAQEBAQFkJ4RBAQEBAwE6OAcFBwQCAQgRBAEBHwkHMhQJCAI?= =?us-ascii?q?EDgWIHwjBGwEBAQEBAQEBAQEBAQEBAQEBAQEBARWIEYFSf4QMEQEcIyaCZIIrB?= =?us-ascii?q?ZdaAY4DgWaNJIYOiHgBHgEBQoNlagGIWDR+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,382,1454976000"; d="scan'208";a="252845692" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Mar 2016 16:03:36 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u2NG3afA030708 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Mar 2016 16:03:36 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 23 Mar 2016 12:03:35 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Wed, 23 Mar 2016 12:03:35 -0400 From: "Brian Weis (bew)" To: Kevin Ma J Thread-Topic: Secdir review of draft-ietf-cdni-footprint-capabilities-semantics-12 Thread-Index: AQHRhHdhY2ZvuIxqdkmtH/tNM8qcVp9nLyuggABGDgA= Date: Wed, 23 Mar 2016 16:03:35 +0000 Message-ID: <31166A57-71FC-4B4B-9D6C-CE67179DF3A1@cisco.com> References: <6A77AE94-D1D3-42FF-BA8B-41FE180E1489@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.191.168] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-cdni-footprint-capabilities-semantics.all@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-cdni-footprint-capabilities-semantics-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 16:03:54 -0000 Hi Kevin, That sounds like a great plan, thanks. Brian On Mar 23, 2016, at 8:58 AM, Kevin Ma J wrote: > Hi Brian, >=20 > Thank you for the review. It is a fair comment and a good suggestion. = I agree that the follow-on protocol spec will have to do the real security = evaluation, and it makes sense to not offer too many assumptions in the sem= antics doc. I will update the security section in the next rev, to remove = that statement and add the suggested privacy measures, in line with the oth= er CDNI protocol drafts. >=20 > thanx! >=20 > -- Kevin J. Ma=20 >=20 >> -----Original Message----- >> From: Brian Weis (bew) [mailto:bew@cisco.com] >> Sent: Tuesday, March 22, 2016 4:14 PM >> To: The IESG; secdir@ietf.org >> Cc: draft-ietf-cdni-footprint-capabilities-semantics.all@tools.ietf.org >> Subject: Secdir review of draft-ietf-cdni-footprint-capabilities- >> semantics-12 >>=20 >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the IESG. >> These comments were written primarily for the benefit of the security ar= ea >> directors. Document editors and WG chairs should treat these comments ju= st >> like any other last call comments. >>=20 >> The document describes high level semantics around the method that sites >> in a CDN Interconnection (CDNI) can perform a capability exchange, and >> defines the semantics that would be exchanged. The described semantics d= o >> not form a protocol, or even a data format, but provide an overview of >> considerations and guidance on the types of information that are to be >> exchanged. >>=20 >> The Security Considerations section does make requirements on protocols >> that would implement a capabilities exchange conforming to this document= , >> which is that they must provide "integrity and authentication services" >> between the sites. It also notes that since a CDNI is setup as the resul= t >> of business relationships, it's reasonable to expect and out of band >> method for exchanging authentication state for a protocol. This seems >> right to me. >>=20 >> Confidentiality of protocols that implement these semantics is not >> considered a high priority because "It is not believed that there are an= y >> serious privacy risks in sharing footprint or capability information". T= he >> section states an assumption that the shared information will be >> aggregated data and policy-related information about media, rather than >> personally identifying information (PII). However, since this document i= s >> not specifying any particular protocol, and thus does not strictly contr= ol >> the contents of the protocol, this seems like an uncertain assumption to >> me. It would be better to make a more positive assertion recommending >> confidentiality, so that protocol implementors conforming to this >> document are less likely to forget to add confidentiality when they do >> pass PII, or when they forget to think about privacy threats to PII. If = a >> traditional cryptographic system (such as TLS) is deployed to obtain >> integrity, including confidentiality protection comes for a very small >> (perhaps negligible) additional cost but provides substantial added >> privacy value, so there isn't much technical justification to explicitly >> omit confidentiality. >>=20 >> Because of this privacy risks discussion, I consider document is "Ready >> with issues" (but it's just the one issue, all else looks fine to me). >>=20 >> Brian --=20 Brian Weis Security, CSG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From nobody Wed Mar 23 09:34:52 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8213912D779 for ; Wed, 23 Mar 2016 09:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7degcDbhOvkM for ; Wed, 23 Mar 2016 09:34:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C7612D51E for ; Wed, 23 Mar 2016 09:34:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 74113BE3F for ; Wed, 23 Mar 2016 16:34:35 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xju6uEny-6Lr for ; Wed, 23 Mar 2016 16:34:34 +0000 (GMT) Received: from [192.150.181.133] (unknown [192.150.181.133]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C9B5EBE47 for ; Wed, 23 Mar 2016 16:34:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458750874; bh=6guXGe+kyVHNpGCZcDTXCm2/vuSHXRfsvvE73WToybs=; h=To:From:Subject:Date:From; b=ModSYqbSFk0QPBlHv44PZbHlCe0G/is65lQ1FJOqq7dXbYzYB8lZeqAs80kfa7Qrp EaS4pReZRQPnHpUoXZXNBc9mdZWeccFMUQKRt+ULzHacC+qla2/+zhIJNI18GzAo03 l7m20ROHuuDk2nCLB2btIkbPTizzjkHjfx/SPzsE= To: "secdir@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F2C599.5010309@cs.tcd.ie> Date: Wed, 23 Mar 2016 16:34:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020004010702080607040509" Archived-At: Subject: [secdir] secdir lunch location X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 16:34:51 -0000 This is a cryptographically signed message in MIME format. --------------ms020004010702080607040509 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, We'll have the usual secdir lunch on Tuesday at IETF95. The room is "Atlantico A" from 1230 to 1400. See you then, Cheers, S. --------------ms020004010702080607040509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjMx NjM0MzNaMC8GCSqGSIb3DQEJBDEiBCAAsmiSW1Kc+fCLdoIfh5suayto5JlMICzk9O/gN101 pjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCh23NXTxiPuxkfq9+Xzii57ujs/L96jSvmpiFkH/R4O5ItDBEmjIQA aB4pGgMl3XzKiEI1349Zzf3CYQ7nnbrj5n15QYTh6kt6zO+so0UII+x5GDvYOUOALS54XSRd 857WtWZS4/kWB2uQ2JYHwVO/BtcW4T6V+Xl0F6CiEVhLCz56xsSPllv6ZdUCLoHxqkyrSjas LapAXLA80MA/H6W66c4CZtuSoKX9lCRlQ4AAUX7/uGFM+EWdU2uX9xxKaZnVpfmTu4ekfkNd zTvWeR7QkTPTT/D0TIxyWr6VbDIUXc3NCPwWR4OYaK45rAvsM7Cki+VUlcCvjvtI5wTr/XjI AAAAAAAA --------------ms020004010702080607040509-- From nobody Wed Mar 23 12:39:44 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4FC127058; Wed, 23 Mar 2016 12:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnCYulZHk98A; Wed, 23 Mar 2016 12:39:40 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 616A812D6B8; Wed, 23 Mar 2016 12:39:39 -0700 (PDT) X-AuditID: 1209190c-debff70000000e13-44-56f2f0f97a16 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 32.09.03603.9F0F2F65; Wed, 23 Mar 2016 15:39:37 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u2NJdan3013708; Wed, 23 Mar 2016 15:39:37 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u2NJdYqw030527; Wed, 23 Mar 2016 15:39:35 -0400 From: Tom Yu To: Andy Bierman References: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> Date: Wed, 23 Mar 2016 15:39:33 -0400 In-Reply-To: (Andy Bierman's message of "Tue, 22 Mar 2016 14:57:04 -0700") Message-ID: Lines: 62 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixCmqrfvzw6cwg08HjC0eHJnFbvHgcAub xYw/E5ktTr9Zx2bxYeFDFgdWj52z7rJ7LFnyk8njy+XPbB4t/RdZAliiuGxSUnMyy1KL9O0S uDIurNnFWrBfvOL8u+ssDYwPhboYOTkkBEwkTj7cyQxiCwm0MUncPKrcxcgFZG9klFg15xYj hPOGUWLJ9iVgVWwC0hLHL+9iArFFBFQlLsydyAxSxCywjFGi++FnVpCEsICDxM7z66C6tzFJ vFh6Bcjh4GAB6lhyKhgkzikwkVHi8Pn7YFN5BXQlXu/5xwhi8whwSkz+P4cVIi4ocXLmExYQ m1lAS+LGv5dMExj5ZyFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXUC83s0QvNaV0 EyM4XCV5djCeeeN1iFGAg1GJh1fyzMcwIdbEsuLK3EOMkhxMSqK8u55+ChPiS8pPqcxILM6I LyrNSS0+xCjBwawkwlv+DCjHm5JYWZValA+TkuZgURLnLdx/OkxIID2xJDU7NbUgtQgmK8PB oSTBmwyMSyHBotT01Iq0zJwShDQTByfIcB6g4YEgNbzFBYm5xZnpEPlTjIpS4rxRIAkBkERG aR5cLzidCDHue8UoDvSKMO+m90BVPMBUBNf9CmgwE9DghT5gg0sSEVJSDYxGLMtWlS7o979Y 9rGh9HWDX2iHt8rkcu2P318l7y2d7XPj1nIJ/y8Mpz69637T9CLrHHP9B7tt7s9fy92vi/Ts /VUdtqHe6IK5lCPbJGH7y1kpjh/ObJO88V7w/JNQg8nff82w+W3GMf/F9hO1gd49k2Uaniow a/FNKtf3Ydjzk/no++dXtWcosRRnJBpqMRcVJwIAeHOzTAIDAAA= Archived-At: Cc: Mahesh Jethanandani , draft-ietf-netconf-yang-library.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 19:39:42 -0000 Andy Bierman writes: > The YANG library provides the revision date of the deviations module, > which is not included in the NETCONF . > > It also lists the submodules and their revisions, which is > not contained in the NETCONF . > > The NETCONF message is not specified well enough to > make any other generalizations about the differences. I think it would be good to explicitly mention that the YANG library provides a superset of the module and version information that might be available by other means, e.g., OLD Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: NEW Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments and authorization configurations. Although some of this information may be available to all users via the NETCONF message (or similar messages in other management protocols), this YANG module potentially exposes additional details that could be of some assistance to an attacker. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: I think if NETCONF access is restricted to a small number of trusted users (even for read-only access), the incremental risk posed by revealing more details about the modules is small. I imagine that there are use cases for providing (restricted) read-only NETCONF access to a wider, mostly untrusted population, in which case the detailed module version information provided by the YANG library could constitute a non-trivial additional risk. I'm not sure of a good, concise way to express this. > The library is intended for other protocols such as RESTCONF. > > Is there some specific text you want changed? I think there could be ambiguity about whether "server" refers to the NETCONF (or other management protocol) server process on the device, or to the overall capabilities of the device. If the YANG library could provide details that could reveal to an attacker the existence of vulnerabilities in the underlying network device capabilities, it might be good to mention it, e.g., In addition to revealing the potential existence of vulnerabilities in the network management protocol server on a device, the detailed version information available in the module list could help an attacker to discover the existence of vulnerable code in the implementation of the underlying network capabilities (or other functionality) of the device on which the management server is running. From nobody Wed Mar 23 13:12:28 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C0212D887 for ; Wed, 23 Mar 2016 13:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqwc43_YMOj8 for ; Wed, 23 Mar 2016 13:12:25 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99BF12D18A for ; Wed, 23 Mar 2016 13:12:24 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u2NKCLoU002701 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 23 Mar 2016 22:12:21 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u2NKCJE8018951; Wed, 23 Mar 2016 22:12:19 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22258.63651.218806.875575@fireball.acr.fi> Date: Wed, 23 Mar 2016 22:12:19 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 20:12:27 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Russ Housley is next in the rotation. For telechat 2016-04-21 Reviewer LC end Draft Donald Eastlake TR2016-02-22 draft-ietf-dane-openpgpkey-08 Steve Hanna T 2016-04-11 draft-ietf-pim-hierarchicaljoinattr-06 Jeffrey Hutzelman T 2015-12-04 draft-ietf-core-block-18 Joe Salowey T 2016-03-09 draft-ietf-rtcweb-audio-codecs-for-interop-05 Carl Wallace T 2016-03-30 draft-schoenw-opsawg-copspr-historic-03 Frank Xialiang T 2016-04-08 draft-alakuijala-brotli-08 For telechat 2016-05-05 Shawn Emery T 2016-04-12 draft-ietf-bfd-seamless-base-08 Daniel Kahn Gillmor T 2016-04-12 draft-ietf-bfd-seamless-ip-03 Tobias Gondrom T 2016-04-12 draft-ietf-bfd-seamless-use-case-04 Chris Lonvick TR2016-04-12 draft-ietf-roll-applicability-ami-12 Last calls and special requests: Shaun Cooley 2016-03-29 draft-ietf-pce-iro-update-06 Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Donald Eastlake 2016-04-13 draft-ietf-bess-multicast-damping-04 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Olafur Gudmundsson 2016-04-05 draft-ietf-l2tpext-sbfd-discriminator-03 Phillip Hallam-Baker 2016-04-05 draft-ietf-pals-seamless-vccv-02 Dan Harkins 2016-04-05 draft-ietf-tls-chacha20-poly1305-04 Paul Hoffman 2016-04-11 draft-ietf-tsvwg-rtcweb-qos-13 Eric Osterweil 2016-01-05 draft-campbell-art-rfc5727-update-03 Yaron Sheffer 2016-03-09 draft-ietf-v6ops-host-addr-availability-05 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-13 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-04 Sam Weiler 2016-03-18 draft-ietf-avtext-sdes-hdr-ext-05 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-06 Tom Yu 2016-03-24 draft-ietf-dime-drmp-04 Dacheng Zhang 2016-03-28 draft-ietf-grow-route-leak-problem-definition-04 -- kivinen@iki.fi From nobody Wed Mar 23 13:31:06 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A9912D8C9 for ; Wed, 23 Mar 2016 13:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PS33RFIf8csb for ; Wed, 23 Mar 2016 13:30:59 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3837012D8C8 for ; Wed, 23 Mar 2016 13:30:57 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id o73so20106827lfe.0 for ; Wed, 23 Mar 2016 13:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=NvGqufQ9z8k7eU2j4+7jct2fGtOrwakDYaAyTV3jv0k=; b=T76T6ZbEKVstocpy2ErO5+wboT6N2l+Z4SLOHg1ANyYewPxas5ONrDGVwPwu3eYXvB ssCVMrsOqMYdyghzpz28Wiguh6QVpcZKx/Y9jRIdZQVTh4j6RQ2XxZvLBW/zU85NN9yD IkkfZwhnnZgpZVMHAPdft4+bv5L3wa+f/UawJI6zlYdBz3Xy6qFir/rI5BCc0RIUseaJ ySDnxgb3SRtIb5k5p7XTx4ALfzFzbj+VVulvyCTD2odvN9eSFEpOa/HzGfYsFgBSc5fi 0PZHyqNKQqVHFwfy7ztLF+3pEoc4ptEdGPADjYOqC0YBVcdCyT36d9itApWLUX2T3nxP 3RBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NvGqufQ9z8k7eU2j4+7jct2fGtOrwakDYaAyTV3jv0k=; b=CTIJUZ0y+t5su2uK1M63fLo/xhhzC1X9R55hvkNktHmnJ71M0qIdm013fVXGXfOcHU 5VH/lZ5k5qdIPjUmHMo3Kg2iLDVVGROfmtEv0y6JiHkYQpLemmj+lIDx9slAK1G0WVvr hecBhZBd6snOt6GRaqXbJCkuyGFlCqXUW+iI95odd9Ryem83SehN9mO7//hALZx1PLOE 9UnmUZrcLVKUiBww0TkB/LP7UC17zFCZazkqLRAqX1cj3Zwcxiiv8lMVCjX81xQx2UfP RaZsVrQtZ1gnrM87EJSb59KxC2l1e168bgQpCADsxuULUOO+S+5wlPVva5cpctEN9B19 KekA== X-Gm-Message-State: AD7BkJLuXaOTr6U7eS7amK1UpjpjdnrIagsUw52JEQo6BP+fWC8Y9RnY9ssQv8z/HZOHlFD80paXMygeWVcefw== MIME-Version: 1.0 X-Received: by 10.25.154.65 with SMTP id c62mr2153916lfe.54.1458765055431; Wed, 23 Mar 2016 13:30:55 -0700 (PDT) Received: by 10.112.135.97 with HTTP; Wed, 23 Mar 2016 13:30:55 -0700 (PDT) In-Reply-To: References: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> Date: Wed, 23 Mar 2016 13:30:55 -0700 Message-ID: From: Andy Bierman To: Tom Yu Content-Type: multipart/alternative; boundary=001a114012b4f0ac3f052ebd3474 Archived-At: Cc: Mahesh Jethanandani , draft-ietf-netconf-yang-library.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 20:31:00 -0000 --001a114012b4f0ac3f052ebd3474 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 23, 2016 at 12:39 PM, Tom Yu wrote: > Andy Bierman writes: > > > The YANG library provides the revision date of the deviations module, > > which is not included in the NETCONF . > > > > It also lists the submodules and their revisions, which is > > not contained in the NETCONF . > > > > The NETCONF message is not specified well enough to > > make any other generalizations about the differences. > > I think it would be good to explicitly mention that the YANG library > provides a superset of the module and version information that might be > available by other means, e.g., > > OLD > > Some of the readable data nodes in this YANG module may be considered > sensitive or vulnerable in some network environments. It is thus > important to control read access (e.g., via get, get-config, or > notification) to these data nodes. These are the subtrees and data > nodes and their sensitivity/vulnerability: > > NEW > > Some of the readable data nodes in this YANG module may be considered > sensitive or vulnerable in some network environments and > authorization configurations. Although some of this information may > be available to all users via the NETCONF message (or similar > messages in other management protocols), this YANG module potentially > exposes additional details that could be of some assistance to an > attacker. It is thus important to control read access (e.g., via > get, get-config, or notification) to these data nodes. These are the > subtrees and data nodes and their sensitivity/vulnerability: > > This is the security boilterplate text that is supposed to go into every YANG module https://tools.ietf.org/html/rfc6087#section-6.1 I prefer to leave the boilerplate alone and move your text into YANG library specific part. Andy > I think if NETCONF access is restricted to a small number of trusted > users (even for read-only access), the incremental risk posed by > revealing more details about the modules is small. I imagine that there > are use cases for providing (restricted) read-only NETCONF access to a > wider, mostly untrusted population, in which case the detailed module > version information provided by the YANG library could constitute a > non-trivial additional risk. I'm not sure of a good, concise way to > express this. > > > The library is intended for other protocols such as RESTCONF. > > > > Is there some specific text you want changed? > > I think there could be ambiguity about whether "server" refers to the > NETCONF (or other management protocol) server process on the device, or > to the overall capabilities of the device. If the YANG library could > provide details that could reveal to an attacker the existence of > vulnerabilities in the underlying network device capabilities, it might > be good to mention it, e.g., > > In addition to revealing the potential existence of vulnerabilities > in the network management protocol server on a device, the detailed > version information available in the module list could help an > attacker to discover the existence of vulnerable code in the > implementation of the underlying network capabilities (or other > functionality) of the device on which the management server is > running. > --001a114012b4f0ac3f052ebd3474 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 23, 2016 at 12:39 PM, Tom Yu <tlyu@mit.edu> wrot= e:
Andy Bierman <andy@yumaworks.com> writes:

> The YANG library provides the revision date of the deviations module,<= br> > which is not included in the NETCONF <hello>.
>
> It=C2=A0 also lists the submodules and their revisions, which is
> not contained in the NETCONF <hello>.
>
> The NETCONF <hello> message is not specified well enough to
> make any other generalizations about the differences.

I think it would be good to explicitly mention that the YANG library
provides a superset of the module and version information that might be
available by other means, e.g.,

OLD

=C2=A0 =C2=A0Some of the readable data nodes in this YANG module may be con= sidered
=C2=A0 =C2=A0sensitive or vulnerable in some network environments.=C2=A0 It= is thus
=C2=A0 =C2=A0important to control read access (e.g., via get, get-config, o= r
=C2=A0 =C2=A0notification) to these data nodes.=C2=A0 These are the subtree= s and data
=C2=A0 =C2=A0nodes and their sensitivity/vulnerability:

NEW

=C2=A0 =C2=A0Some of the readable data nodes in this YANG module may be con= sidered
=C2=A0 =C2=A0sensitive or vulnerable in some network environments and
=C2=A0 =C2=A0authorization configurations.=C2=A0 Although some of this info= rmation may
=C2=A0 =C2=A0be available to all users via the NETCONF <hello> messag= e (or similar
=C2=A0 =C2=A0messages in other management protocols), this YANG module pote= ntially
=C2=A0 =C2=A0exposes additional details that could be of some assistance to= an
=C2=A0 =C2=A0attacker.=C2=A0 It is thus important to control read access (e= .g., via
=C2=A0 =C2=A0get, get-config, or notification) to these data nodes.=C2=A0 T= hese are the
=C2=A0 =C2=A0subtrees and data nodes and their sensitivity/vulnerability:



This is = the security boilterplate text that is supposed to
go into every = YANG module




I prefer to leave the= boilerplate alone and move your text into
YANG library specific = part.


Andy

=C2=A0
I think if NETCONF access is restricted to a small number of trusted
users (even for read-only access), the incremental risk posed by
revealing more details about the modules is small.=C2=A0 I imagine that the= re
are use cases for providing (restricted) read-only NETCONF access to a
wider, mostly untrusted population, in which case the detailed module
version information provided by the YANG library could constitute a
non-trivial additional risk.=C2=A0 I'm not sure of a good, concise way = to
express this.

> The library is intended for other protocols such as RESTCONF.
>
> Is there some specific text you want changed?

I think there could be ambiguity about whether "server" refers to= the
NETCONF (or other management protocol) server process on the device, or
to the overall capabilities of the device.=C2=A0 If the YANG library could<= br> provide details that could reveal to an attacker the existence of
vulnerabilities in the underlying network device capabilities, it might
be good to mention it, e.g.,

=C2=A0 =C2=A0 In addition to revealing the potential existence of vulnerabi= lities
=C2=A0 =C2=A0 in the network management protocol server on a device, the de= tailed
=C2=A0 =C2=A0 version information available in the module list could help a= n
=C2=A0 =C2=A0 attacker to discover the existence of vulnerable code in the<= br> =C2=A0 =C2=A0 implementation of the underlying network capabilities (or oth= er
=C2=A0 =C2=A0 functionality) of the device on which the management server i= s
=C2=A0 =C2=A0 running.

--001a114012b4f0ac3f052ebd3474-- From nobody Thu Mar 24 03:56:36 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1392812D121 for ; Thu, 24 Mar 2016 03:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfKQSup6siib for ; Thu, 24 Mar 2016 03:56:33 -0700 (PDT) Received: from implementers.org (implementers.org [173.246.102.69]) by ietfa.amsl.com (Postfix) with ESMTP id 64FBA12D6D4 for ; Thu, 24 Mar 2016 03:56:33 -0700 (PDT) Received: from [IPv6:2602:ae:176f:bd00:d965:1af4:ab4a:d9c1] (unknown [IPv6:2602:ae:176f:bd00:d965:1af4:ab4a:d9c1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id BAC39201B6 for ; Thu, 24 Mar 2016 11:56:31 +0100 (CET) To: "secdir@ietf.org" From: Marc Petit-Huguenin Message-ID: <56F3C7D7.9040706@petit-huguenin.org> Date: Thu, 24 Mar 2016 04:56:23 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bBPLdvopcwT7CeFcc4nSs0Wpjv7CgvwkN" Archived-At: Subject: [secdir] Early review of draft-ietf-p2psip-share X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 10:56:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bBPLdvopcwT7CeFcc4nSs0Wpjv7CgvwkN Content-Type: multipart/mixed; boundary="J160DMcMD0GtXv1GbnMwNoLTcmKw5ngTA" From: Marc Petit-Huguenin To: "secdir@ietf.org" Message-ID: <56F3C7D7.9040706@petit-huguenin.org> Subject: Early review of draft-ietf-p2psip-share --J160DMcMD0GtXv1GbnMwNoLTcmKw5ngTA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear Security Directorate, Following the advice from Alissa Cooper, I (as shepherd) solicit an early= security expert review for "A Usage for Shared Resources in RELOAD (ShaR= e)". This I-D can be found at https://datatracker.ietf.org/doc/draft-iet= f-p2psip-share/ Thanks. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug --J160DMcMD0GtXv1GbnMwNoLTcmKw5ngTA-- --bBPLdvopcwT7CeFcc4nSs0Wpjv7CgvwkN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW88fXAAoJECnERZXWan7E+VoP/RHiKFBMJIKxs5JMswHLEwLg otstQL4UIRB37oPL4ZfE/PnsTL7KT1hyXf/V4tP1tz9fcU5OdqvFfnZk3hgGgmVo ceI7oq0D8/7OsX9L+/O0KI3p0HeXrodVMiYPu/PKLp0xsts/w9dqRaVbC9xWbaRy Y+ZepzqgTGJ7mjSR6NnzCT12C8C5ErpFxriIDy6rvX0O3ojuZqsMyYNze8wTihOh +iMS10r7Qv8sNpPR3qY9/aJqHtDVAybPUnVxAYA9tfRSaSc06w7iFt2fYirEo60W oZg1U4J3viwqkb/QBe8OEp6P5YeNljQqdCndIffcpnPD/oNulDQgqNJKlUwp9Cef 53pE79P5bG1BWZmpDDI0W7kmYMLIhiamMpJFzhDHwx2dhBnYPrki4/rHuaHB9CLm gURccQBl6oU4U6PY+iLbPEuXIwNo+M+EYdvtC+qqvPvtGwjIPuRWbzNjR1/zy7Lf SHMY4SriXEEIa8seJpV0cJ/nNNFKTBfMfesU02FwKL74GL/iWWu6eLblAvYHUQkE wWjTkpCwD15VFjGNn6c8rHjkdDA7SipqkAjEtXJLjqN8oYXV9OSrQiv7v5+wCDK2 6CRHvrh0eBcd/H9BlZkO/8dL8DWwVFxqQeXiOI3USrQQBf3aTnIEZQ8x9bOwka/V N2rr5kXvtzp5uThfVAkb =QGo7 -----END PGP SIGNATURE----- --bBPLdvopcwT7CeFcc4nSs0Wpjv7CgvwkN-- From nobody Thu Mar 24 08:10:26 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F5312DD10; Thu, 24 Mar 2016 08:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oyv8wPfvumJi; Thu, 24 Mar 2016 08:10:22 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5418112DD2B; Thu, 24 Mar 2016 07:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11720; q=dns/txt; s=iport; t=1458831331; x=1460040931; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=GhelxFEmUmjt0HKTUx6OcGnFBALNxYujc2wxFyg6Nbk=; b=le+YfbHe8DyMDX/ws1ekdBtgh0Zr8QZhF/aSHoiQYixzGgMoLuUgWkqu OTJ03KKg8qmaty4caLaNUFWEgOeagPWIghBxqfpe5ls8G4M6KmcpvLnmh tJ3xrZQ16V650w0CMYdqU05MnZjjZeyt+vTg0PgFSzVZblgY/rhgEY6hc w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DSBABJ//NW/xbLJq1eDoN5fbVlhmwhh?= =?us-ascii?q?WwCgXsBAQEBAQFlJ4RBAQEBAwEjVQEFCwsYCRYIAwICCQMCAQIBNBEGAQwGAgE?= =?us-ascii?q?BiBsIDrAGkGoBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYehESEJIMYglYFkwWEW?= =?us-ascii?q?YVxiBOBZodRI4Uxjwligyo8OzABiVMBAQE?= X-IronPort-AV: E=Sophos;i="5.24,385,1454976000"; d="scan'208,217";a="636512449" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Mar 2016 14:55:29 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u2OEtStl000530; Thu, 24 Mar 2016 14:55:28 GMT To: Andy Bierman , Tom Yu References: <6AAFCD6E-4F8D-409C-ACB1-53C03413AF7F@gmail.com> From: Benoit Claise Message-ID: <56F3FFE0.3040408@cisco.com> Date: Thu, 24 Mar 2016 15:55:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060603080609070803000102" Archived-At: Cc: Mahesh Jethanandani , draft-ietf-netconf-yang-library.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-netconf-yang-library-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 15:10:25 -0000 This is a multi-part message in MIME format. --------------060603080609070803000102 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/23/2016 9:30 PM, Andy Bierman wrote: > > > On Wed, Mar 23, 2016 at 12:39 PM, Tom Yu > wrote: > > Andy Bierman > writes: > > > The YANG library provides the revision date of the deviations > module, > > which is not included in the NETCONF . > > > > It also lists the submodules and their revisions, which is > > not contained in the NETCONF . > > > > The NETCONF message is not specified well enough to > > make any other generalizations about the differences. > > I think it would be good to explicitly mention that the YANG library > provides a superset of the module and version information that > might be > available by other means, e.g., > > OLD > > Some of the readable data nodes in this YANG module may be > considered > sensitive or vulnerable in some network environments. It is thus > important to control read access (e.g., via get, get-config, or > notification) to these data nodes. These are the subtrees and data > nodes and their sensitivity/vulnerability: > > NEW > > Some of the readable data nodes in this YANG module may be > considered > sensitive or vulnerable in some network environments and > authorization configurations. Although some of this > information may > be available to all users via the NETCONF message (or > similar > messages in other management protocols), this YANG module > potentially > exposes additional details that could be of some assistance to an > attacker. It is thus important to control read access (e.g., via > get, get-config, or notification) to these data nodes. These > are the > subtrees and data nodes and their sensitivity/vulnerability: > > > > > This is the security boilterplate text that is supposed to > go into every YANG module > > > https://tools.ietf.org/html/rfc6087#section-6.1 > > > I prefer to leave the boilerplate alone and move your text into > YANG library specific part. I would support this. Regards, Benoit > > > Andy > > I think if NETCONF access is restricted to a small number of trusted > users (even for read-only access), the incremental risk posed by > revealing more details about the modules is small. I imagine that > there > are use cases for providing (restricted) read-only NETCONF access to a > wider, mostly untrusted population, in which case the detailed module > version information provided by the YANG library could constitute a > non-trivial additional risk. I'm not sure of a good, concise way to > express this. > > > The library is intended for other protocols such as RESTCONF. > > > > Is there some specific text you want changed? > > I think there could be ambiguity about whether "server" refers to the > NETCONF (or other management protocol) server process on the > device, or > to the overall capabilities of the device. If the YANG library could > provide details that could reveal to an attacker the existence of > vulnerabilities in the underlying network device capabilities, it > might > be good to mention it, e.g., > > In addition to revealing the potential existence of > vulnerabilities > in the network management protocol server on a device, the > detailed > version information available in the module list could help an > attacker to discover the existence of vulnerable code in the > implementation of the underlying network capabilities (or other > functionality) of the device on which the management server is > running. > > --------------060603080609070803000102 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 3/23/2016 9:30 PM, Andy Bierman wrote:


On Wed, Mar 23, 2016 at 12:39 PM, Tom Yu <tlyu@mit.edu> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> The YANG library provides the revision date of the deviations module,
> which is not included in the NETCONF <hello>.
>
> It  also lists the submodules and their revisions, which is
> not contained in the NETCONF <hello>.
>
> The NETCONF <hello> message is not specified well enough to
> make any other generalizations about the differences.

I think it would be good to explicitly mention that the YANG library
provides a superset of the module and version information that might be
available by other means, e.g.,

OLD

   Some of the readable data nodes in this YANG module may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control read access (e.g., via get, get-config, or
   notification) to these data nodes.  These are the subtrees and data
   nodes and their sensitivity/vulnerability:

NEW

   Some of the readable data nodes in this YANG module may be considered
   sensitive or vulnerable in some network environments and
   authorization configurations.  Although some of this information may
   be available to all users via the NETCONF <hello> message (or similar
   messages in other management protocols), this YANG module potentially
   exposes additional details that could be of some assistance to an
   attacker.  It is thus important to control read access (e.g., via
   get, get-config, or notification) to these data nodes.  These are the
   subtrees and data nodes and their sensitivity/vulnerability:




This is the security boilterplate text that is supposed to
go into every YANG module




I prefer to leave the boilerplate alone and move your text into
YANG library specific part.
I would support this.

Regards, Benoit


Andy

 
I think if NETCONF access is restricted to a small number of trusted
users (even for read-only access), the incremental risk posed by
revealing more details about the modules is small.  I imagine that there
are use cases for providing (restricted) read-only NETCONF access to a
wider, mostly untrusted population, in which case the detailed module
version information provided by the YANG library could constitute a
non-trivial additional risk.  I'm not sure of a good, concise way to
express this.

> The library is intended for other protocols such as RESTCONF.
>
> Is there some specific text you want changed?

I think there could be ambiguity about whether "server" refers to the
NETCONF (or other management protocol) server process on the device, or
to the overall capabilities of the device.  If the YANG library could
provide details that could reveal to an attacker the existence of
vulnerabilities in the underlying network device capabilities, it might
be good to mention it, e.g.,

    In addition to revealing the potential existence of vulnerabilities
    in the network management protocol server on a device, the detailed
    version information available in the module list could help an
    attacker to discover the existence of vulnerable code in the
    implementation of the underlying network capabilities (or other
    functionality) of the device on which the management server is
    running.


--------------060603080609070803000102-- From nobody Thu Mar 24 19:33:49 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE81312D18D for ; Thu, 24 Mar 2016 19:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sjn8jzt1s4H for ; Thu, 24 Mar 2016 19:33:43 -0700 (PDT) Received: from smtp74.iad3a.emailsrvr.com (smtp74.iad3a.emailsrvr.com [173.203.187.74]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1BF12D1BC for ; Thu, 24 Mar 2016 19:33:43 -0700 (PDT) Received: from smtp26.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id CE8D780199; Thu, 24 Mar 2016 22:33:42 -0400 (EDT) X-Auth-ID: ogud@ogud.com Received: by smtp26.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 44F7180185; Thu, 24 Mar 2016 22:33:42 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-173-66-187-177.washdc.fios.verizon.net [173.66.187.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Thu, 24 Mar 2016 22:33:42 -0400 From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_F9C1869E-D1DD-4F09-85A7-60E21C827902" Date: Thu, 24 Mar 2016 22:33:40 -0400 Message-Id: <0EB1425E-C43A-46B2-B0ED-D175D01ED179@ogud.com> To: The IESG , draft-gp-l2tpext-sbfd-discriminator@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: secdir@ietf.org Subject: [secdir] sec-dir: Review of draft-gp-l2tpext-sbfd-discriminator-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 02:33:46 -0000 --Apple-Mail=_F9C1869E-D1DD-4F09-85A7-60E21C827902 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. READY short and sweet simple IANA allocation Olafur --Apple-Mail=_F9C1869E-D1DD-4F09-85A7-60E21C827902 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii 
I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.
READY 
short and sweet  simple IANA allocation 

Olafur

--Apple-Mail=_F9C1869E-D1DD-4F09-85A7-60E21C827902-- From nobody Fri Mar 25 06:38:30 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B1512D69E; Fri, 25 Mar 2016 06:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncSG2hfU7opd; Fri, 25 Mar 2016 06:38:27 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24CD512D1EC; Fri, 25 Mar 2016 06:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3930; q=dns/txt; s=iport; t=1458913107; x=1460122707; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=m0K4d7cGUO9EVX7r21PIx1igFE3oAwIW8y3aeOsKfd0=; b=KaFi0lFbbhbOeUZ1SE3D2VUUX5LzlMLaoBtzCyp6FB+KE2wXuQWxcXTN wFqW+ET2QvkmcSznYhezZmTht4XOyS6t62XZZN31eNK+NgKls67w0WKwP 6JY4qr/WRZOjnKuu+1wesn8H+Mnh3wIAowW9IqIGzyySCpKTMUdmyg/DS o=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CKAgAHPvVW/xbLJq1dgmKCHAa1aIRuD?= =?us-ascii?q?oFwhg0CgWgUAQEBAQEBAWQnhEEBAQEDASNWBQsCAQgEAQkKKgICMiUCBA4FDog?= =?us-ascii?q?RCLEnkFYBAQEBAQEBAQEBAQEBAQEBAQEBAQENCIYegXMIgkmHPCuCKwEEl2ABg?= =?us-ascii?q?x2BZokAjwuPCQEeAUODZWyIH34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,391,1454976000"; d="asc'?scan'208,217";a="676290424" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2016 13:38:25 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u2PDcObq014394 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Mar 2016 13:38:25 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 25 Mar 2016 09:38:23 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Fri, 25 Mar 2016 09:38:23 -0400 From: "Carlos Pignataro (cpignata)" To: Olafur Gudmundsson Thread-Topic: sec-dir: Review of draft-gp-l2tpext-sbfd-discriminator-00 Thread-Index: AQHRhkQ1OOW/mFXYFEyvzqzkR66TNZ9qbbuA Date: Fri, 25 Mar 2016 13:38:23 +0000 Message-ID: <87BF33FB-76DE-4688-A17F-17E7B558011C@cisco.com> References: <0EB1425E-C43A-46B2-B0ED-D175D01ED179@ogud.com> In-Reply-To: <0EB1425E-C43A-46B2-B0ED-D175D01ED179@ogud.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.239.115] Content-Type: multipart/signed; boundary="Apple-Mail=_BEA95C56-E927-4EE5-868C-EDEC1DD48F8E"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "draft-gp-l2tpext-sbfd-discriminator@tools.ietf.org" , The IESG , "secdir@ietf.org" Subject: Re: [secdir] sec-dir: Review of draft-gp-l2tpext-sbfd-discriminator-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 13:38:29 -0000 --Apple-Mail=_BEA95C56-E927-4EE5-868C-EDEC1DD48F8E Content-Type: multipart/alternative; boundary="Apple-Mail=_D6FF6E69-E43F-4A89-B050-8EF798E598F9" --Apple-Mail=_D6FF6E69-E43F-4A89-B050-8EF798E598F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you for the review, Olafur! =E2=80=94 Carlos. > On Mar 24, 2016, at 10:33 PM, Olafur Gudmundsson = wrote: >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > READY > short and sweet simple IANA allocation >=20 > Olafur >=20 --Apple-Mail=_D6FF6E69-E43F-4A89-B050-8EF798E598F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank you for the review, Olafur!

=E2=80=94 Carlos.

On Mar 24, 2016, at 10:33 PM, Olafur Gudmundsson <ogud@ogud.com> = wrote:

I have reviewed this document as part of the security =
directorate's=20
ongoing effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the=20
security area directors.  Document editors and WG chairs should treat=20
these comments just like any other last call comments.
READY 
short and sweet  simple = IANA allocation 

Olafur


= --Apple-Mail=_D6FF6E69-E43F-4A89-B050-8EF798E598F9-- --Apple-Mail=_BEA95C56-E927-4EE5-868C-EDEC1DD48F8E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJW9T9QAAoJEIXgpQGOZny9Fh4P/3sGXfK+uflMWhr2fCSgoVI+ vVZRn/uSn1baDaTaM7WzPeUyCVw0cJTDU7F2/9jgPcfMd5kHAxWf0vUVhZWfTco8 F/NSGt4XNYtoPr0Vzgn1eNhZYXdaF57T6JFsKWfzmAJjpDuIAvtpYwvK045cs9ws nJL3vViGrSkosSS+noLU4KpN13ew9aNNYV1aZVJEShih6k/akhRDYSlDnRNKE0pK XOkROzFZJxZIC2iz6TzeWT5wzVBUjXbZ0609vigrueORY+FszuC9b/tr7M7UMZWd zUKaeUJ5+/cFG76O4AhJ44G9VDTbxt41IvUhqI3HSRRXoABidsdDtiph2UhElT5G MPA2spcjeWK1/zwdOW9Rstppu/s5fKdIis3UP6THz5LGKJj15KT0GUldJToDzfyT Z/xyhQoP0w8JcPP1AumV7UOMIxcsyfMpAyUzl/LnEGdSwUFukEwouMp7Bh3lRd+U 1iEVEu1VrzgM9t/Tz1T9H8nA4LgjFaMArUROYQKfUbgXdWz5CHTYiwoJyD9C7neX twDofh9lixAzFdhxLBG8n9qpKgb2/+CJZYKqCXF+zhU1+3qqxp2LKx7gb5krwrqE VN8JWAiaK8K/33OqrQrcwJ4s+FhEvTMOzi4LZrgMKEr9HrMyCDio8io/PTlQdZ/R RmGMuNTBaT05+qO8AJkI =dXIf -----END PGP SIGNATURE----- --Apple-Mail=_BEA95C56-E927-4EE5-868C-EDEC1DD48F8E-- From nobody Sat Mar 26 17:32:08 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797C812D0A9; Sat, 26 Mar 2016 17:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzcWWdKDRWuG; Sat, 26 Mar 2016 17:32:04 -0700 (PDT) Received: from COL004-OMC2S15.hotmail.com (col004-omc2s15.hotmail.com [65.55.34.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C02612D0A5; Sat, 26 Mar 2016 17:32:04 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com ([65.55.34.72]) by COL004-OMC2S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 26 Mar 2016 17:32:03 -0700 Received: from CY1PR17MB0425.namprd17.prod.outlook.com (10.163.253.19) by CY1PR17MB0425.namprd17.prod.outlook.com (10.163.253.19) with Microsoft SMTP Server (TLS) id 15.1.447.15; Sun, 27 Mar 2016 00:32:02 +0000 Received: from CY1PR17MB0425.namprd17.prod.outlook.com ([10.163.253.19]) by CY1PR17MB0425.namprd17.prod.outlook.com ([10.163.253.19]) with mapi id 15.01.0447.021; Sun, 27 Mar 2016 00:32:02 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , 'The IESG' , "draft-ietf-i2rs-architecture@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-i2rs-architecture-13 Thread-Index: AQHRh7+uB3jJS22tbU2+iGH5SUfCgQ== Date: Sun, 27 Mar 2016 00:32:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=outlook.com; x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [5NJuhbITBuLdYbLEkE1AkzWoYAGDkYLY] x-ms-office365-filtering-correlation-id: 29c1f06b-1ead-47dd-3cba-08d355d73758 x-microsoft-exchange-diagnostics: 1; CY1PR17MB0425; 23:xiho81pcX5FHfaCiJB+azyH9wufT8W7idsvwQlm0FTqk6YUQ6IDB6p1xb2eEyZaP4+Islfw9KMduZhbRJeDFnWYmucXIJVROkj2fXypf1ZqAJIf/NcLQTggZcgN8faxXmDVZ7oGwnCBTSKFPZmNF0nYl9keBm+FsQ90Dcmks8kpxUwIvg32XktVukEWQU6y57u95BqO0CsSoLoICo/DtKw==; 5:8eMmzLFBPBNKWMDR0gVu4wNs2pUmom+Vuq++2JByeI8BOYjsa+bJAVl6gKIi3BPNonnstI5I4G2XXZCpFhQBlkqaCRt2SSKtI9MASFiGXjMxVnvZ7DEZXjZArtO3a6qKAPMSAapvsG45oplUQD3sKQ==; 24:tuI/pMNzOS0hOwre2dgIxmL6OiA0WjUela9WXgXsWyFEPUZC8x9LXTy/QiU5w2TEPiXwTh5YmYyrQPWxqoecpGsVUjlK6bAHOUahfcySFg0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR17MB0425; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:CY1PR17MB0425; BCL:0; PCL:0; RULEID:; SRVR:CY1PR17MB0425; x-forefront-prvs: 089473E5FE x-forefront-antispam-report: SFV:NSPM; SFS:(7070004)(98900003); DIR:OUT; SFP:1901; SCL:1; SRVR:CY1PR17MB0425; H:CY1PR17MB0425.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR17MB04259499F0D4B9DCC34BAC24DF850CY1PR17MB0425namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2016 00:32:02.2043 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR17MB0425 X-OriginalArrivalTime: 27 Mar 2016 00:32:03.0980 (UTC) FILETIME=[15CECCC0:01D187C0] Archived-At: Subject: [secdir] Secdir review of draft-ietf-i2rs-architecture-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 00:32:06 -0000 --_000_CY1PR17MB04259499F0D4B9DCC34BAC24DF850CY1PR17MB0425namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. I reviewed the -07 version of this document in December 2014. As was true t= hen, this document says very little about security other than the kinds of = security mechanisms that are needed. In particular, it does not say what se= curity mechanisms will be used. The document appears to be part of a large = suite of documents covering various aspects of this I2RS thing. I would hop= e the security relevant information appears somewhere else. I can't resist commenting on some of the things I found confusing. It is li= kely a lot of my confusion is addressed in related documents. Assuming that= 's true, it would be helpful if some - perhaps common - introduction to the= document suite specified an order in which the documents should be read of= avoid forward references. The document calls itself An Architecture to the Interface to the Routing S= ystem. It doesn't say whether this interface is an API or a protocol. Proba= bly both are involved. Section 4 paragraph 1 says "I2RS has been designed t= o re-utilize existing protocols that carry network management information. = Two of the existing protocols which the which may be reused (sic) are NETCO= NF and RESTCONF." This makes it sound like I2RS is an API. But section 7.2 = paragraph 1 says "All such communication channels will use the same higher-= layer I2RS protocol (which combines secure transport and I2RS contextural i= nformation). This makes it sound like a protocol. Section 4.1 paragraph 2 talks about application identity, but it wasn't cle= ar (at least to me) whether it was referring to the application as code and= protocol (e.g., Wireshark) or as the owner of the instance of the applicat= ion to determine permissions. Section 6.4.2 says "Directly writing to these protocol-specific RIBs or dat= abases is out of scope for I2RS" but says "joining/removing interfaces from= multicast trees" was a supported operation. Doesn't that involve directly = updating a protocol-specific database? Section 7.6 says any given piece of information... (should only be)... mani= pulated by a single I2RS Client. But section 4.3 says there should be multi= ple clients running with the same client identity. This leaves ambiguous ho= w the clients are supposed to coordinate and whether (for example) both wil= l get copies of notifications the client identity has signed up for. Nits (typos/language): Section 4 para 1: "which the which may" -> "which may" Section 4 para 1: "existing protocol in order" -> "existing protocols in or= der" Section 4 para 5: "I2RSS" -> "I2RS" Section 6.3 para 1: First ref to "yang data model" should have reference. Section 7.4 para 1: "value ranges for portion of scope policy" -> ??? Section 7.5 para 3: "mechanism instantiated" -> "mechanisms instantiated" --_000_CY1PR17MB04259499F0D4B9DCC34BAC24DF850CY1PR17MB0425namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the security directorate's ongo= ing effort to review all IETF documents being processed by the IESG.  = These comments were written primarily for the benefit of the security area = directors.  Document editors and WG chairs should treat these comments just like any other last call comments.


I reviewed the -07 version of this document in December 2014. As was tru= e then, this document says very little about security other than the kinds = of security mechanisms that are needed. In particular, it does not say what= security mechanisms will be used. The document appears to be part of a large suite of documents covering var= ious aspects of this I2RS thing. I would hope the security relevant informa= tion appears somewhere else.

I can't resist commenting on some of the things I found confusing. It is= likely a lot of my confusion is addressed in related documents. Assuming t= hat's true, it would be helpful if some - perhaps common - introduction to = the document suite specified an order in which the documents should be read of avoid forward references.


The document calls itself An Architecture to the Interface to the Routin= g System. It doesn't say whether this interface is an API or a protocol. Pr= obably both are involved. Section 4 paragraph 1 says "I2RS has been de= signed to re-utilize existing protocols that carry network management information. Two of the existing protocols w= hich the which may be reused (sic) are NETCONF and RESTCONF." This mak= es it sound like I2RS is an API. But section 7.2 paragraph 1 says "All= such communication channels will use the same higher-layer I2RS protocol (which combines secure transport and I2RS = contextural information). This makes it sound like a protocol.


Section 4.1 paragraph 2 talks about application identity, but it wasn't = clear (at least to me) whether it was referring to the application as code = and protocol (e.g., Wireshark) or as the owner of the instance of the appli= cation to determine permissions.


Section 6.4.2 says "Directly writing to these protocol-specific RIB= s or databases is out of scope for I2RS" but says "joining/removi= ng interfaces from multicast trees" was a supported operation. Doesn't= that involve directly updating a protocol-specific database?


Section 7.6 says any given piece of information... (should only be)... m= anipulated by a single I2RS Client. But section 4.3 says there should be mu= ltiple clients running with the same client identity. This leaves ambiguous= how the clients are supposed to coordinate and whether (for example) both will get copies of notifications= the client identity has signed up for.


Nits (typos/language):

Section 4 para 1: "which the which may" -> "which may&= quot;
Section 4 para 1: "existing protocol in order" -> "existi= ng protocols in order"
Section 4 para 5: "I2RSS" -> "I2RS"
Section 6.3 para 1: First ref to "yang data model" should have re= ference.
Section 7.4 para 1: "value ranges for portion of scope policy" -&= gt; ???
Section 7.5 para 3: "mechanism instantiated" -> "mechanis= ms instantiated"



--_000_CY1PR17MB04259499F0D4B9DCC34BAC24DF850CY1PR17MB0425namp_-- From nobody Sun Mar 27 13:59:37 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093C712D1C0 for ; Sun, 27 Mar 2016 13:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGF89_TSfFx4 for ; Sun, 27 Mar 2016 13:59:33 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D98C12D141 for ; Sun, 27 Mar 2016 13:59:33 -0700 (PDT) Received: from [10.32.60.32] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u2RKxWIW062753 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 27 Mar 2016 13:59:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [10.32.60.32] From: "Paul Hoffman" To: secdir Date: Sun, 27 Mar 2016 13:59:31 -0700 Message-ID: <0361809E-945E-4E7F-95CE-126A98FD0ECC@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: [secdir] Secdir review of draft-ietf-tsvwg-rtcweb-qos X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 20:59:35 -0000 The extremely short Security Considerations section is actually fine: This specification does not add any additional security implications beyond those addressed in the following DSCP-related specifications. For security implications on use of DSCP, please refer to Section 7 of [RFC7657] and Section 6 of [RFC4594]. Please also see [I-D.ietf-rtcweb-security] as an additional reference. That is, suggesting adding a QOS value to a certain kind of packet doesn't add any security concerns beyond QOS that exists before now. --Paul Hoffman From nobody Thu Mar 31 02:50:48 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745DA12D55B for ; Thu, 31 Mar 2016 02:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4L00jVd3x7B for ; Thu, 31 Mar 2016 02:50:39 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26D9B12D9D5 for ; Thu, 31 Mar 2016 02:50:38 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u2V9oZYG029222 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 31 Mar 2016 12:50:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u2V9oZ5o007325; Thu, 31 Mar 2016 12:50:35 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22268.62187.225244.177127@fireball.acr.fi> Date: Thu, 31 Mar 2016 12:50:35 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 09:50:47 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Benjamin Kaduk is next in the rotation. For telechat 2016-04-21 Reviewer LC end Draft Shaun Cooley T 2016-03-29 draft-ietf-pce-iro-update-06 Donald Eastlake TR2016-02-22 draft-ietf-dane-openpgpkey-08 Steve Hanna T 2016-04-11 draft-ietf-pim-hierarchicaljoinattr-06 Jeffrey Hutzelman T 2015-12-04 draft-ietf-core-block-18 Leif Johansson T 2016-04-06 draft-ietf-p2psip-sip-17 Joe Salowey T 2016-03-09 draft-ietf-rtcweb-audio-codecs-for-interop-05 Carl Wallace T 2016-03-30 draft-schoenw-opsawg-copspr-historic-03 Frank Xialiang T 2016-04-08 draft-alakuijala-brotli-08 For telechat 2016-05-05 Shawn Emery T 2016-04-12 draft-ietf-bfd-seamless-base-08 Daniel Kahn Gillmor T 2016-04-12 draft-ietf-bfd-seamless-ip-03 Tobias Gondrom T 2016-04-12 draft-ietf-bfd-seamless-use-case-04 Christian Huitema T 2016-04-13 draft-ietf-bess-pta-flags-02 Chris Inacio T 2016-05-03 draft-ietf-ospf-sbfd-discriminator-03 Chris Lonvick TR2016-04-12 draft-ietf-roll-applicability-ami-12 Eric Osterweil T 2016-01-05 draft-campbell-art-rfc5727-update-03 Sam Weiler T 2016-03-18 draft-ietf-avtext-sdes-hdr-ext-05 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Donald Eastlake 2016-04-13 draft-ietf-bess-multicast-damping-04 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Phillip Hallam-Baker 2016-04-05 draft-ietf-pals-seamless-vccv-02 Dan Harkins 2016-04-05 draft-ietf-tls-chacha20-poly1305-04 Russ Housley E None draft-ietf-p2psip-share-08 Yaron Sheffer 2016-03-09 draft-ietf-v6ops-host-addr-availability-05 Hannes Tschofenig 2015-12-28 draft-ietf-hip-rfc5204-bis-07 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-13 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-04 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-06 Tom Yu 2016-03-24 draft-ietf-dime-drmp-04 Dacheng Zhang 2016-03-28 draft-ietf-grow-route-leak-problem-definition-04 -- kivinen@iki.fi