Re: [secdir] Secdir review of draft-ietf-ecrit-additional-

I have reviewed this document as part of the security dire= ctorate's ongoing effort to review all IETF documents being processed b= y the IESG.=C2=A0 These comments were written primarily for the benefit of = the security area directors and document authors.

I thin= k this document is ready with issues. =C2=A0 The document describes a passw= ord to key function, scrypt, based on memory hard functions to make it more= expensive and difficult to develop specialized hardware to obtain the pass= word from a recovered key.=C2=A0 I'd like to see this document publishe= d.=C2=A0 A few issues are listed below.=C2=A0

First, I = think Paul Kyzivat's GenArt review.=C2=A0http://mailarchive.= ietf.org/arch/msg/gen-art/fToZiioHo-6x5ZRQWNcTr-aUYVk,=C2=A0raised some= points that could help the readability of the document. =C2=A0

Second, the script algorithm has several parameters, but the docume= nt has very little discussion on how to choose those parameters or what the= y affect (this is also pointed out in Paul's message).=C2=A0 It would b= e good to have some discussion or guidance for parameter selection in the s= ecurity considerations. =C2=A0

Cheers,

<= br>

Joe

--089e011610300888c8051fa96bd9-- From nobody Sun Sep 13 17:08:07 2015 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 DC1A91B41E8; Sun, 13 Sep 2015 17:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 f1_9acn4_FaE; Sun, 13 Sep 2015 17:08:04 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (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 0A2D81B42A5; Sun, 13 Sep 2015 17:08:04 -0700 (PDT) Received: by obbbh8 with SMTP id bh8so96725049obb.0; Sun, 13 Sep 2015 17:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=nDaeZG1f4qEKH0W8VuBhL1nMA5zjDUiPgcI1KHMdFHQ=; b=gTXJJANsaktWFpkMcY6V+nkRdZcAShB3Yi4wjI4amS+gukAG79hNmMhXs+m7Zay3Gn TuBURr6W2prG8LWUT8vNDpDtaDgPYFy+CQHbKDuukjuaECKe9jUa+fsIp28CaYHpVw/K XCU6wtEM7hrDIQf2ddJ26ZN5k34VlDA5A3hPz7mN8siuVNgIDEKDlNNkFlkgKDPwnJU0 7bAIcSNKxaYR8JJFGjWdKoPY6cMnPw0VsCS32yQ3DYi2Wc+BoavvgMGqaz4xy7atSWnE rXPdP8Yeb77EMq+Bro8P4ArA5gdiChOCtilkZoJ1r3qhcBp+gPFX9L+wdqkWwLHPdYZ/ AoFg== MIME-Version: 1.0 X-Received: by 10.182.29.73 with SMTP id i9mr8612330obh.59.1442189283423; Sun, 13 Sep 2015 17:08:03 -0700 (PDT) Received: by 10.202.198.22 with HTTP; Sun, 13 Sep 2015 17:08:03 -0700 (PDT) Date: Sun, 13 Sep 2015 20:08:03 -0400 Message-ID: From: Matthew Lepinski To: "secdir@ietf.org" , "iesg@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2989eeffbcb051fa9db6a Archived-At: Cc: draft-ietf-dnsop-root-loopback.all@tools.ietf.org Subject: [secdir] SECDIR review of draft-ietf-dnsop-root-loopback-03 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, 14 Sep 2015 00:08:06 -0000 --001a11c2989eeffbcb051fa9db6a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate=E2=80=99s 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 draft is essentially ready for publication (with minor comments below)= . This is an Informational document that specifies how the operator of a recursive resolver could run a copy of the root zone on a loopback interface. The purpose of this mechanism are two-fold: (1) to speed response time in the case of a negative response from the root zone; (2) to hide queries to the root zone from malicious observers. The security story for this mechanism is essentially: A) Since this mechanism must be run on a loopback interface, there is no possibility that the mechanism will negatively impact other entities. (I.e., it would be bad if a recursive resolver started giving authoritative answers for the root zone to anyone other than itself.) B) DNSSEC is used to ensure that the answers provided by this mechanism are valid. The security considerations section for this document is somewhat terse and I believe the document could be improved by expanding that section. In particular, I believe that point (A) above should be stated explicitly in the security considerations section. (That is, it is stated elsewhere in the document that using a loopback mechanism is essential. However, I think that repeating that in the security considerations section would be helpful -- I think that point is an important part of the story for why this mechanism doesn't break things.) Additionally, in the security considerations section, the authors are somewhat brief in describing the need for DNSSEC. I think that is fine, but given the brevity, I think it would be helpful to have a citation to another document that describes why DNSSEC is needed. (Is RFC 4033 the best reference regarding what DNSSEC protects against? Or is there a better document now?) - Matt Lepinski --001a11c2989eeffbcb051fa9db6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have reviewed this docu= ment as part of the security directorate=E2=80=99s
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.=C2=A0 Document editors and WG = chairs should treat these comments
just like any other last call comments.

This draft is essentially ready for publication (wit= h minor comments below).

This is an Informati= onal document that specifies how the operator of a recursive resolver could= run a copy of the root zone on a loopback interface. The purpose of this m= echanism are two-fold: (1) to speed response time in the case of a negative= response from the root zone; (2) to hide queries to the root zone from mal= icious observers.=C2=A0

<= br>

The security story fo= r this mechanism is essentially:

A) Since this mechanism must be run on a loopback interface, there = is no=C2=A0possibility=C2=A0that the mechanism will negatively impact other= entities. (I.e., it would be bad if a recursive resolver started giving au= thoritative answers for the root zone to anyone other than itself.)<= /div>

B) DNSSEC is used to ensure that= the answers provided by this mechanism are valid.

The security considerations section for this document is somewhat ter= se and I believe the document could be improved by expanding that section. = In particular, I believe that point (A) above should be stated explicitly i= n the security considerations section. (That is, it is stated elsewhere in = the document that using a loopback mechanism is essential. However, I think= that repeating that in the security considerations section would be helpfu= l -- I think that point is an important part of the story for why this mech= anism doesn't break things.)

Additionally= , in the security considerations section, the authors are somewhat brief in= describing the need for DNSSEC. I think that is fine, but given the brevit= y, I think it would be helpful to have a citation to another document that = describes why DNSSEC is needed. (Is RFC 4033 the best reference regarding w= hat DNSSEC protects against? Or is there a better document now?)

- Matt Lepinski

--001a11c2989eeffbcb051fa9db6a-- From nobody Sun Sep 13 18:26:59 2015 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 5CA721B4EA7; Sun, 13 Sep 2015 18:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 wludJRDoj8Df; Sun, 13 Sep 2015 18:26:51 -0700 (PDT) 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 2EBCD1B4DEB; Sun, 13 Sep 2015 18:26:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXO38302; Mon, 14 Sep 2015 01:26:47 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Sep 2015 02:26:45 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.77]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Mon, 14 Sep 2015 09:26:39 +0800 From: "Xialiang (Frank)" To: Dirk Kutscher Thread-Topic: secdir review of draft-ietf-conex-mobile-05 Thread-Index: AdDsK7I1VyJu7Bl6QJ2ZXX3RKt6srwAQblSwAAEGHKAAAMkDEACF6owQ Date: Mon, 14 Sep 2015 01:26:38 +0000 Message-ID: References: <82AB329A76E2484D934BBCA77E9F52499A07A349@Hydra.office.hd> <82AB329A76E2484D934BBCA77E9F52499A07B50E@Hydra.office.hd> In-Reply-To: <82AB329A76E2484D934BBCA77E9F52499A07B50E@Hydra.office.hd> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12AE6C028SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-conex-mobile.all@ietf.org" , secdir Subject: Re: [secdir] secdir review of draft-ietf-conex-mobile-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: Mon, 14 Sep 2015 01:26:55 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12AE6C028SZXEMA502MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRGlyaywNCkkgc2VlLiBUaGFua3MgZm9yIHlvdXIgZGV0YWlsZWQgY2xhcmlmaWNhdGlvbi4N Cg0KQi5SLg0KRnJhbmsNCg0Kt6K8/sjLOiBEaXJrIEt1dHNjaGVyIFttYWlsdG86RGlyay5LdXRz Y2hlckBuZWNsYWIuZXVdDQq3osvNyrG85DogMjAxNcTqOdTCMTHI1SAxNzo0OQ0KytW8/sjLOiBY aWFsaWFuZyAoRnJhbmspDQqzrcvNOiBzZWNkaXI7IGllc2dAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt Y29uZXgtbW9iaWxlLmFsbEBpZXRmLm9yZw0K1vfM4jogUkU6IHNlY2RpciByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1jb25leC1tb2JpbGUtMDUNCg0KSGkgRnJhbmssDQoNCkluIGdlbmVyYWwsIHRoZSBD b25FeC1yZWxhdGVkIHJpc2tzIHJlZ2FyZGluZyBtYW5pcHVsYXRpbmcgY29uZ2VzdGlvbiBub3Rp ZmljYXRpb24vZXhwb3N1cmUgY2FuIGFwcGx5IHRvIG1vYmlsZSBuZXR3b3JrcywgdG9vLg0KDQpX aGF0IGNvdWxkIHBlcmhhcHMgYmUgc2FpZCBpcyB0aGF0IG1vYmlsZSBuZXR3b3JrcyAoVU1UUywg TFRFKSBlbXBsb3kgYSB2aXJ0dWFsLWNpcmN1aXQtbGlrZSBiZWFyZXIgbW9kZWwgZm9yIHRoZSBh Y2Nlc3MsIGkuZS4sIHVzZXJzIGluIGEgY2VsbCBjYW4gZ2VuZXJhbGx5IG5vdCBzZWUgb3RoZXIg dXNlcnOhryB0cmFmZmljIKhDIHNvIHRoYXQgd291bGQgcnVsZSBvdXQgc29tZSB0aHJlYXRzLiBB bHNvLCBhdXRoZW50aWNhdGlvbiBpcyBwYXJ0IG9mIHRoZSBiZWFyZXIgZXN0YWJsaXNobWVudCwg c28gdGhlIG5ldHdvcmsgZ2VuZXJhbGx5IGtub3dzIHRoZSB1c2VyIGFuZCBkZXZpY2UgaWRlbnRp dHkuDQoNCk5vdywgYXNzdW1pbmcgdGhhdCBtb2JpbGUgbmV0d29ya3MgY2FuIGJlIHN1YmplY3Qg dG8gcGFzc2l2ZSBtb25pdG9yaW5nLCBvbmUgY291bGQgY2xhaW0gdGhhdCB0aGlzIHdvdWxkIGVu YWJsZSBhdHRhY2tlcnMgdG8gY29sbGVjdCBpbmZvcm1hdGlvbiBhYm91dCBhIHVzZXKhr3MgY29u Z2VzdGlvbiBjb250cmlidXRpb24gKGFsc28gb3ZlciB0aW1lKSwgYnV0IHRoYXQgdGhyZWF0IHNl ZW1zIGxlc3MgY3JpdGljYWwgKGNvbXBhcmVkIHRvIGV4cG9zaW5nIHRoZSBwYXlsb2FkIGl0c2Vs ZikuDQoNCkJlc3QgcmVnYXJkcywNCkRpcmsNCg0KDQpGcm9tOiBYaWFsaWFuZyAoRnJhbmspIFtt YWlsdG86ZnJhbmsueGlhbGlhbmdAaHVhd2VpLmNvbV0NClNlbnQ6IEZyZWl0YWcsIDExLiBTZXB0 ZW1iZXIgMjAxNSAxMToyMA0KVG86IERpcmsgS3V0c2NoZXINCkNjOiBzZWNkaXI7IGllc2dAaWV0 Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWNvbmV4LW1vYmlsZS5hbGxA aWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY29uZXgtbW9iaWxlLmFsbEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29uZXgtbW9iaWxlLTA1DQoN CkhpIERpcmssDQpUaGFuayB5b3UgZm9yIHF1aWNrIHJlc3BvbnNlLg0KSSByZXZpZXdlZCB0aGUg ZHJhZnRzIHlvdSBtZW50aW9uZWQgYmVsb3cuIEkgYWdyZWUgdGhhdCB0aGV5IGFscmVhZHkgZGlz Y3Vzc2VkIHRoZSBnZW5lcmFsIHNlY3VyaXR5IGlzc3VlcyBJIGFtIGNvbmNlcm5lZCwgZXNwZWNp YWxseSBpbiB0aGUgZHJhZnQtY29uZXgtYWJzdHJhY3QtbWVjaC0xMyBhbmQgaXRzIHJlZmVyZW5j ZS4NCg0KU28sIGluIGdlbmVyYWwsIG15IGNvbmNlcm5zIGFyZSBhZGRyZXNzZWQuIEJ1dCBJIHN0 aWxsIGhhdmUgYSBsaXR0bGUgYml0IGRvdWJ0cyBhYm91dCBwb3NzaWJseSBuZXcgc2VjdXJpdHkg aXNzdWVzIGZvciB0aGUgdXNlIGNhc2VzIG9mIHVzaW5nIENvbkV4IHByb3RvY29sIG92ZXIgdGhl IG1vYmlsZSBjb21tdW5pY2F0aW9uIG5ldHdvcmtzLiBJIGFtIG5vdCBhbiBleHBlcnQgaW4gdGhp cyBhcmVhLCBjYW4geW91IGNsYXJpZnkgbWU/DQoNClRoYW5rcyENCg0KQi5SLg0KRnJhbmsNCg0K t6K8/sjLOiBEaXJrIEt1dHNjaGVyIFttYWlsdG86RGlyay5LdXRzY2hlckBuZWNsYWIuZXVdDQq3 osvNyrG85DogMjAxNcTqOdTCMTHI1SAxNjo1Mg0KytW8/sjLOiBYaWFsaWFuZyAoRnJhbmspOyBz ZWNkaXI7IGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWNv bmV4LW1vYmlsZS5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY29uZXgtbW9iaWxlLmFs bEBpZXRmLm9yZz4NCtb3zOI6IFJFOiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY29uZXgt bW9iaWxlLTA1DQoNCkhpIEZyYW5rLA0KDQp0aGFua3MgZm9yIHRoZSByZXZpZXcuDQoNClRoZSBz ZWN1cml0eSBpc3N1ZXMgeW91IG1lbnRpb25lZCB3b3VsZCBhcHBseSB0byBDb25FeCBpbiBnZW5l cmFsLiBUaGUgY29ycmVzcG9uZGluZyBkb2N1bWVudHMgYXJlIGRpc2N1c3NpbmcgcG90ZW50aWFs IHNlY3VyaXR5IGlzc3VlczoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtY29uZXgtYWJzdHJhY3QtbWVjaC0xMyNwYWdlLTI0IChhbHNvIHNlZSB0aGUgcmVmZXJlbmNl cykNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNvbmV4LWRlc3RvcHQt MDkjcGFnZS0xMA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY29uZXgt dGNwLW1vZGlmaWNhdGlvbnMtMDQjcGFnZS0xMQ0KDQpXZaGvZCB0aGVyZWZvcmUgcmF0aGVyIG5v dCBkdXBsaWNhdGUgdGhhdCBkaXNjdXNzaW9uIGluIGNvbmV4LW1vYmlsZS4NCg0KUmVnYXJkaW5n IHRoZSBzZWN1cml0eSByaXNrcyB5b3UgbWVudGlvbmVkLCBJoa9kIHNheSBpdCBpcyBxdWVzdGlv bmFibGUgd2hldGhlciBDb25FeCBpbnRyb2R1Y2VzIGFkZGl0aW9uYWwgaXNzdWVzIGZvciBjb25m aWRlbnRpYWxpdHkgKGNvbXBhcmVkIHRvIElQIGFsb25lKS4NCg0KVGhhbmtzLA0KRGlyaw0KDQoN Cg0KRnJvbTogWGlhbGlhbmcgKEZyYW5rKSBbbWFpbHRvOmZyYW5rLnhpYWxpYW5nQGh1YXdlaS5j b21dDQpTZW50OiBGcmVpdGFnLCAxMS4gU2VwdGVtYmVyIDIwMTUgMDI6NDkNClRvOiBzZWNkaXI7 IGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWNvbmV4LW1v YmlsZS5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtY29uZXgtbW9iaWxlLmFsbEBpZXRm Lm9yZz4NClN1YmplY3Q6IHNlY2RpciByZXZpZXcgb2YgZHJhZnQtaWV0Zi1jb25leC1tb2JpbGUt MDUNCg0KSGksDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBz ZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBk b2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2Vy ZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEg ZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0 aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50Lg0KDQpU aGlzIG1lbW8gZGVzY3JpYmVzIGEgbW9iaWxlIGNvbW11bmljYXRpb25zIHVzZSBjYXNlIGZvciBj b25nZXN0aW9uIGV4cG9zdXJlIChDb25FeCkgd2l0aCBhIHBhcnRpY3VsYXIgZm9jdXMgb24gdGhv c2UgbW9iaWxlIGNvbW11bmljYXRpb24gbmV0d29ya3MgdGhhdCBhcmUgYXJjaGl0ZWN0dXJhbGx5 IHNpbWlsYXIgdG8gdGhlIDNHUFAgRXZvbHZlZCBQYWNrZXQgU3lzdGVtIChFUFMpLg0KDQpJIGhh dmUgdGhlIGZvbGxvd2luZyBjb21tZW50czoNCg0KbCAgMS4gSXQgc2hvdWxkIGJlIGhlbHBmdWwg dG8gY29uc2lkZXIgdGhlIGNvbW11bmljYXRpb24gc2VjdXJpdHkgYmV0d2VlbiB0aGUgQ29uRXgg c2VuZGVycyBhbmQgcmVjZWl2ZXJzIHN1Y2ggYXMgdGhlIENvbmZpZGVudGlhbGl0eSwgZGF0YSBp bnRlZ3JpdHkgYW5kIHBlZXIgZW50aXR5IGF1dGhlbnRpY2F0aW9uIGluIHRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBwYXJ0LiBCZWNhdXNlIGluIGdlbmVyYWwsIHRoZSBjb3JyZXNwb25kaW5n IHJpc2tzIGFyZSBzdGlsbCBwb3NzaWJsZSB0byBleGlzdC4NCg0KbCAgMi4gVGhlIGF1dGhlbnRp Y2F0aW9uIG1lY2hhbmlzbSBhbW9uZyBhbGwgdGhlIGVsZW1lbnRzIG9mIENvbkV4IHNvbHV0aW9u IHNob3VsZCBhbHNvIGJlIGNvbnNpZGVyZWQgdG8gaGFuZGxlIHRoZSBjb25kaXRpb24gb2YgZmFr ZWQgbWVzc2FnZXMgb3IgaW52YWxpZCBwZWVyIGVsZW1lbnRzLg0KDQpSZWNvbW1lbmRhdGlvbjog IFJlYWR5IFdpdGggSXNzdWVzDQoNCkIuUi4NCkZyYW5rDQoNCg== --_000_C02846B1344F344EB4FAA6FA7AF481F12AE6C028SZXEMA502MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Dirk,

I see. Tha= nks for your detailed clarification.

= ;

B.R.<= /o:p>

Frank=

= ;

=B7=A2=BC=FE=C8=CB: Dirk Ku= tscher [mailto:Dirk.Kutscher@neclab.eu]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA9=D4=C211=C8=D5 17:49
=CA=D5=BC=FE=C8=CB: Xialiang (Frank)
=B3=AD=CB=CD: secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
=D6=F7=CC=E2: RE: secdir review of draft-ietf-conex-mobile-05<= /p>

Hi Frank,

In general= , the ConEx-related risks regarding manipulating congestion notification/ex= posure can apply to mobile networks, too.

= ;

What could= perhaps be said is that mobile networks (UMTS, LTE) employ a virtual-circu= it-like bearer model for the access, i.e., users in a cell can generally not see other users=A1=AF traffic =A8C so that would rule ou= t some threats. Also, authentication is part of the bearer establishment, s= o the network generally knows the user and device identity.

= ;

Now, assum= ing that mobile networks can be subject to passive monitoring, one could cl= aim that this would enable attackers to collect information about a user=A1=AFs congestion contribution (also over time), but that thr= eat seems less critical (compared to exposing the payload itself).

= ;

Best regar= ds,

Dirk<= /o:p>

= ;

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Freitag, 11. September 2015 11:20
To: Dirk Kutscher
Cc: secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
Subject: Re: secdir review of draft-ietf-conex-mobile-05<= /span>

Hi Dirk,

Thank you = for quick response.

I reviewed= the drafts you mentioned below. I agree that they already discussed the ge= neral security issues I am concerned, especially in the draft-conex-abstrac= t-mech-13 and its reference.

= ;

So, in gen= eral, my concerns are addressed. But I still have a little bit doubts about= possibly new security issues for the use cases of using ConEx protocol over the mobile communication networks. I am not an expert in thi= s area, can you clarify me?

= ;

Thanks!

= ;

B.R.<= /o:p>

Frank=

= ;

=B7=A2=BC=FE=C8=CB: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA9=D4=C211=C8=D5 16:52
=CA=D5= =BC=FE=C8=CB: Xialiang (Frank); secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
=D6=F7= =CC=E2: RE: secdir review of draft-ietf-conex-mobile-0= 5

Hi Frank,<= o:p>

= ;

thanks for= the review.

= ;

The securi= ty issues you mentioned would apply to ConEx in general. The corresponding = documents are discussing potential security issues:

= ;

htt= ps://tools.ietf.org/html/draft-ietf-conex-abstract-mech-13#page-24 (also see the references)

https://t= ools.ietf.org/html/draft-ietf-conex-destopt-09#page-10

https://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-04#page-11<= /a>

= ;

We=A1=AFd = therefore rather not duplicate that discussion in conex-mobile.<= /span>

= ;

Regarding = the security risks you mentioned, I=A1=AFd say it is questionable whether C= onEx introduces additional issues for confidentiality (compared to IP alone).

= ;

Thanks,

Dirk<= /o:p>

= ;

From: Xialiang (Frank) [mailto:frank.xialiang@huawei.com]
Sent: Freitag, 11. September 2015 02:49
To: secdir; iesg@ietf.org; draft-ietf-conex-mobile.all@ietf.org
Subject: secdir review of draft-ietf-conex-mobile-05

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 writ= ten primarily for the benefit of the security area directors. Do= cument editors and WG chairs should treat these comments just like any= other last call comment.

This memo describes a mobile communicatio= ns use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally simi= lar to the 3GPP Evolved Packet System (EPS).

I have the following comments:=

l 1. It should be = helpful to consider the communication security between the ConEx senders an= d receivers such as the Confidentiality, data integrity and peer entity authentication in the security considerations part. Becaus= e in general, the corresponding risks are still possible to exist.

l 2. The authentic= ation mechanism among all the elements of ConEx solution should also be con= sidered to handle the condition of faked messages or invalid peer elements.

Recommendation: Ready With Issues

B.R.

Frank

--_000_C02846B1344F344EB4FAA6FA7AF481F12AE6C028SZXEMA502MBSchi_-- From nobody Mon Sep 14 03:19:32 2015 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 88E061B53F8 for ; Mon, 14 Sep 2015 03:19:31 -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, J_CHICKENPOX_54=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 GKeFm-efWx_y for ; Mon, 14 Sep 2015 03:19:30 -0700 (PDT) Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) (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 09D2E1B545F for ; Mon, 14 Sep 2015 03:19:29 -0700 (PDT) Received: by qkcf65 with SMTP id f65so55866773qkc.3 for ; Mon, 14 Sep 2015 03:19:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=T6/Dwf11bOSBwh6QP54xCNkf+Tw32gSCtw+D8QPP0hM=; b=Dk8xfgu4xGfmUKRcbokyqCK5aVHDCWunYk6OdPJFzRJF1a2OrCqEasdZsQPQRITMkd nJZYqiXCMddMGoYX4xHzCtWC+vPB35xAql0mAWt7iLUaYHcu/hgWAXSPxzzz1lBx84MZ xPKNWPURecdKv6RMazE0g5kEiZkav+GBGWdSkAzvOcNm+SCX1k/uR4mEBUbskdzsHlMV cTSCZUcgVpjaSe0pvgTCQCcZDk2Kx/c4FLxf6q1868RV2zapQy3Ia2/p45TB+1ynsDAQ 2sOobqSMOB5cyk9U98hJG6P9uw6Ff2BmJxUZQBuxUUtoV8dU/O3Mfo8/qwSlgqX02IPK UTdw== X-Gm-Message-State: ALoCoQkhzcBvHXW1YWmKdZK1IoT6Rf6H1c6gSnvBqVewirkFuS8y9ev50gwqFcYTGxlpTKr5eHz/ X-Received: by 10.55.221.8 with SMTP id n8mr20533267qki.85.1442225968170; Mon, 14 Sep 2015 03:19:28 -0700 (PDT) Received: from [192.168.2.27] (pool-173-66-90-83.washdc.fios.verizon.net. [173.66.90.83]) by smtp.gmail.com with ESMTPSA id 88sm5614103qkr.5.2015.09.14.03.19.20 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 14 Sep 2015 03:19:27 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.5.4.150722 Date: Mon, 14 Sep 2015 06:19:14 -0400 From: Carl Wallace To: Mingui Zhang , "draft-ietf-trill-pseudonode-nickname.all@tools.ietf.org" Message-ID: Thread-Topic: draft-ietf-trill-pseudonode-nickname-06 References: <4552F0907735844E9204A62BBDD325E7871BB1E4@nkgeml512-mbx.china.huawei.com> In-Reply-To: <4552F0907735844E9204A62BBDD325E7871BB1E4@nkgeml512-mbx.china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-trill-pseudonode-nickname-06 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, 14 Sep 2015 10:19:31 -0000 On 9/13/15, 11:51 PM, "Mingui Zhang" wrote: >Hi Carl, > >Thanks for the comment. > >If the DF fails, the failure will be noted by other member RBridge >through LSDB sync. Then the DF election algorithm defined in Section 5.2 >will be locally used to determine who is the new DF. >In the transient condition when LSDB has not been sync-ed, there might be >packet lost but there is no racing Sorry, =E2=80=98race condition=E2=80=99 may not have been the best term to use here. >: suppose, RB1 is the old DF before the failure while RB2 is the new DF >after RB1 fails according to the election algorithm. If RB2 has been >sync-ed while RB3 is not, then RB2 will begin to do forwarding; If RB3 is >sync-ed while RB2 is not, then no member RBridge will do the forwarding. That there could be a lost packet (or traffic disruption as mentioned elsewhere) was what I was getting at. The language in the first paragraph of section 8 indicated unicast could have trouble but as I read it the second paragraph intimated that multicast could not. It wasn=E2=80=99t clear to m= e that was true and it sounds like it isn=E2=80=99t true for all cases (but is true after a new DF has been elected). Re-reading it now it is clear the point is that no =E2=80=98special actions=E2=80=99 ar= e required not that there can be no lost packet. It might be more clear if it stated acknowledged the hang time between failure and full establishment of the new RBv following the failure. >=20 > >Thanks, >Mingui > >> -----Original Message----- >> From: Carl Wallace [mailto:carl@redhoundsoftware.com] >> Sent: Sunday, September 13, 2015 4:00 AM >> To: draft-ietf-trill-pseudonode-nickname.all@tools.ietf.org >> Cc: iesg@ietf.org; secdir@ietf.org >> Subject: draft-ietf-trill-pseudonode-nickname-06 >>=20 >> I have reviewed this document as part of the security directorate=E2=80=99s >>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 describes use of pseudo-nicknames for RBridges in an >> Active-Active Edge RBridge group. I am not familiar with TRILL but >>found the >> document to be well written and easy to follow. I did have one >>question, which >> may just be due to my lack of familiarity with relevant normative >>specs. The >> second paragraph of section 8 states the following: >>=20 >> "However, for multi-destination TRILL Data packets, since they can >>reach >> all member RBridges of the new RBv and be egressed to CE1 by either RB2 >>or >> RB3 (i.e., the new DF for the traffic's Inner.VLAN or the VLAN the >>packet's >> Inner.Label maps to in the new RBv), special actions to protect against >> downlink failure for such multi-destination packets is not >> needed." >>=20 >> Why is there no race condition between the arrival of multi=E2=80=94destinatio= n >>traffic >> and the creation of a new RBv following the failure of RB1 that enables >>the >> traffic to be forwarded? Generally, mentioning failure of the DF for >>the virtual >> RBridge seemed like it might warrant mention in the security >>considerations >> section, since that is new relative to the specs noted in the current >>security >> considerations. >>=20 > From nobody Mon Sep 14 08:03:53 2015 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 E516F1B5A8F; Sun, 13 Sep 2015 20:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 NHAOVBrtpsKa; Sun, 13 Sep 2015 20:52:10 -0700 (PDT) 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 1763D1B5A85; Sun, 13 Sep 2015 20:52:08 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXO46959; Mon, 14 Sep 2015 03:52:07 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 14 Sep 2015 04:52:04 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.166]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Mon, 14 Sep 2015 11:51:59 +0800 From: Mingui Zhang To: Carl Wallace , "draft-ietf-trill-pseudonode-nickname.all@tools.ietf.org" Thread-Topic: draft-ietf-trill-pseudonode-nickname-06 Thread-Index: AQHQ7ZWmwM2br1fzd0eZlb8TxXO1+547X/TQ Date: Mon, 14 Sep 2015 03:51:58 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7871BB1E4@nkgeml512-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Mon, 14 Sep 2015 08:03:52 -0700 Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-trill-pseudonode-nickname-06 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, 14 Sep 2015 03:52:13 -0000 SGkgQ2FybCwNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudC4NCg0KSWYgdGhlIERGIGZhaWxzLCB0 aGUgZmFpbHVyZSB3aWxsIGJlIG5vdGVkIGJ5IG90aGVyIG1lbWJlciBSQnJpZGdlIHRocm91Z2gg TFNEQiBzeW5jLiBUaGVuIHRoZSBERiBlbGVjdGlvbiBhbGdvcml0aG0gZGVmaW5lZCBpbiBTZWN0 aW9uIDUuMiB3aWxsIGJlIGxvY2FsbHkgdXNlZCB0byBkZXRlcm1pbmUgd2hvIGlzIHRoZSBuZXcg REYuIA0KSW4gdGhlIHRyYW5zaWVudCBjb25kaXRpb24gd2hlbiBMU0RCIGhhcyBub3QgYmVlbiBz eW5jLWVkLCB0aGVyZSBtaWdodCBiZSBwYWNrZXQgbG9zdCBidXQgdGhlcmUgaXMgbm8gcmFjaW5n OiBzdXBwb3NlLCBSQjEgaXMgdGhlIG9sZCBERiBiZWZvcmUgdGhlIGZhaWx1cmUgd2hpbGUgUkIy IGlzIHRoZSBuZXcgREYgYWZ0ZXIgUkIxIGZhaWxzIGFjY29yZGluZyB0byB0aGUgZWxlY3Rpb24g YWxnb3JpdGhtLiBJZiBSQjIgaGFzIGJlZW4gc3luYy1lZCB3aGlsZSBSQjMgaXMgbm90LCB0aGVu IFJCMiB3aWxsIGJlZ2luIHRvIGRvIGZvcndhcmRpbmc7IElmIFJCMyBpcyBzeW5jLWVkIHdoaWxl IFJCMiBpcyBub3QsIHRoZW4gbm8gbWVtYmVyIFJCcmlkZ2Ugd2lsbCBkbyB0aGUgZm9yd2FyZGlu Zy4gDQoNClRoYW5rcywNCk1pbmd1aQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IENhcmwgV2FsbGFjZSBbbWFpbHRvOmNhcmxAcmVkaG91bmRzb2Z0d2FyZS5jb21dDQo+ IFNlbnQ6IFN1bmRheSwgU2VwdGVtYmVyIDEzLCAyMDE1IDQ6MDAgQU0NCj4gVG86IGRyYWZ0LWll dGYtdHJpbGwtcHNldWRvbm9kZS1uaWNrbmFtZS5hbGxAdG9vbHMuaWV0Zi5vcmcNCj4gQ2M6IGll c2dAaWV0Zi5vcmc7IHNlY2RpckBpZXRmLm9yZw0KPiBTdWJqZWN0OiBkcmFmdC1pZXRmLXRyaWxs LXBzZXVkb25vZGUtbmlja25hbWUtMDYNCj4gDQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3Vt ZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRl4oCZcyBvbmdvaW5nDQo+IGVm Zm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUg SUVTRy4NCj4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJl bmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWENCj4gZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9y cyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cw0KPiBqdXN0IGxpa2Ug YW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4gDQo+IFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIHVzZSBvZiBwc2V1ZG8tbmlja25hbWVzIGZvciBSQnJpZGdlcyBpbiBhbg0KPiBBY3RpdmUt QWN0aXZlIEVkZ2UgUkJyaWRnZSBncm91cC4gSSBhbSBub3QgZmFtaWxpYXIgd2l0aCBUUklMTCBi dXQgZm91bmQgdGhlDQo+IGRvY3VtZW50IHRvIGJlIHdlbGwgd3JpdHRlbiBhbmQgZWFzeSB0byBm b2xsb3cuIEkgZGlkIGhhdmUgb25lIHF1ZXN0aW9uLCB3aGljaA0KPiBtYXkganVzdCBiZSBkdWUg dG8gbXkgbGFjayBvZiBmYW1pbGlhcml0eSB3aXRoIHJlbGV2YW50IG5vcm1hdGl2ZSBzcGVjcy4g VGhlDQo+IHNlY29uZCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA4IHN0YXRlcyB0aGUgZm9sbG93aW5n Og0KPiANCj4gCSJIb3dldmVyLCBmb3IgbXVsdGktZGVzdGluYXRpb24gVFJJTEwgRGF0YSBwYWNr ZXRzLCBzaW5jZSB0aGV5IGNhbiByZWFjaA0KPiBhbGwgbWVtYmVyIFJCcmlkZ2VzIG9mIHRoZSBu ZXcgUkJ2IGFuZCBiZSBlZ3Jlc3NlZCB0byBDRTEgYnkgZWl0aGVyIFJCMiBvcg0KPiBSQjMgKGku ZS4sIHRoZSBuZXcgREYgZm9yIHRoZSB0cmFmZmljJ3MgSW5uZXIuVkxBTiBvciB0aGUgVkxBTiB0 aGUgcGFja2V0J3MNCj4gSW5uZXIuTGFiZWwgbWFwcyB0byBpbiB0aGUgbmV3IFJCdiksIHNwZWNp YWwgYWN0aW9ucyB0byBwcm90ZWN0IGFnYWluc3QNCj4gZG93bmxpbmsgZmFpbHVyZSBmb3Igc3Vj aCBtdWx0aS1kZXN0aW5hdGlvbiBwYWNrZXRzIGlzIG5vdA0KPiBuZWVkZWQuIg0KPiANCj4gV2h5 IGlzIHRoZXJlIG5vIHJhY2UgY29uZGl0aW9uIGJldHdlZW4gdGhlIGFycml2YWwgb2YgbXVsdGni gJRkZXN0aW5hdGlvbiB0cmFmZmljDQo+IGFuZCB0aGUgY3JlYXRpb24gb2YgYSBuZXcgUkJ2IGZv bGxvd2luZyB0aGUgZmFpbHVyZSBvZiBSQjEgdGhhdCBlbmFibGVzIHRoZQ0KPiB0cmFmZmljIHRv IGJlIGZvcndhcmRlZD8gR2VuZXJhbGx5LCBtZW50aW9uaW5nIGZhaWx1cmUgb2YgdGhlIERGIGZv ciB0aGUgdmlydHVhbA0KPiBSQnJpZGdlIHNlZW1lZCBsaWtlIGl0IG1pZ2h0IHdhcnJhbnQgbWVu dGlvbiBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCj4gc2VjdGlvbiwgc2luY2UgdGhh dCBpcyBuZXcgcmVsYXRpdmUgdG8gdGhlIHNwZWNzIG5vdGVkIGluIHRoZSBjdXJyZW50IHNlY3Vy aXR5DQo+IGNvbnNpZGVyYXRpb25zLg0KPiANCg0K From nobody Mon Sep 14 08:18:02 2015 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 8732C1B54BB; Mon, 14 Sep 2015 08:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553] 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 b3Fq8h_PSU-G; Mon, 14 Sep 2015 08:17:59 -0700 (PDT) Received: from hoffman.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 B59541B4358; Mon, 14 Sep 2015 08:17:59 -0700 (PDT) Received: from [10.32.60.144] (142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t8EFHv8w079126 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Sep 2015 08:17:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123] claimed to be [10.32.60.144] From: "Paul Hoffman" To: "Matthew Lepinski" Date: Mon, 14 Sep 2015 08:17:56 -0700 Message-ID: <138F09FC-109C-410E-ACA7-2DADF3D4460D@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: draft-ietf-dnsop-root-loopback.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-dnsop-root-loopback-03 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, 14 Sep 2015 15:18:00 -0000 Thanks! We have made these changes in the pre-draft of -04. If the ADs want us to publish this before the IESG review, we can; otherwise, we'll wait until after the IESG review to release them. --Paul Hoffman A system that does not follow the DNSSEC-related requirements given in can be fooled into giving bad responses in the same way as any recursive resolver that does not do DNSSEC validation on responses from a remote root server. Anyone deploying the method described in this document should be familiar with the operational benefits and costs of deploying DNSSEC . As stated in , this design explicitly only allows the new root zone server to be run on a loopback address, in order to prevent the server from serving authoritative answers to any system other than the recursive resolver. This has the security property of limiting damage to any other system that might try to rely on the copy of the root in case that copy becomes altered. From nobody Mon Sep 14 09:55:00 2015 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 DF9201B2A1C; Mon, 14 Sep 2015 09:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1442249010; bh=Wfi1ILYDpD9ZF2b8ydFiKTv7WkL1yonIdOhcE/MAEH4=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=JcXVUMWO4EXmaapkXJ4iqf6L7u6b5B82rZRonrIZpy7nXk99BpyFrISkUVBazu5v+ yjxNKE2warylcuIOn9vXjg+m5LHnoGeEcUmb3uxcb/7t22Kx9Eu/2WrujuZbxZe7u8 9hZHNoJ6PTqyYGCc8F/Rdwpr2dLU3vOYsMcFRGzo= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91ED1B2A1C; Mon, 14 Sep 2015 09:43:29 -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 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 F0MNdlDrn3L0; Mon, 14 Sep 2015 09:43:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E90931B2A6B; Mon, 14 Sep 2015 09:43:23 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150914164323.31029.94918.idtracker@ietfa.amsl.com> Date: Mon, 14 Sep 2015 09:43:23 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 14 Sep 2015 09:55:00 -0700 Subject: [secdir] [new-work] WG Review: Geographic JSON (geojson) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 16:43:31 -0000 A new IETF working group has been proposed in the Applications and Real-Time Area. 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 at ietf.org) by 2015-09-24. Geographic JSON (geojson) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Alissa Cooper Charter: GeoJSON is a format for encoding data about geographic features using JavaScript Object Notation (JSON) [RFC7159]. Geographic features need not be physical things; any thing with properties that are bounded in space may be considered a feature. GeoJSON provides a means of representing both the properties and spatial extent of features. The GeoJSON format specification was published at http://geojson.org in 2008. GeoJSON today plays an important and growing role in many spatial databases, web APIs, and open data platforms. Consequently the implementers increasingly demand formal standardization, improvements in the specification, guidance on extensibility, and the means to utilize larger GeoJSON datasets. This WG will work on a GeoJSON Format RFC that specifies the format more precisely, serves as a better guide for implementers, and improves extensibility of the format. The work will start from an Internet-Draft written by the original GeoJSON authors: draft-butler-geojson [1]. This WG will work on GeoJSON mappings of 'geo' URIs, reinforcing the use of RFC 5870. This WG will work on a format for a streamable sequence of GeoJSON texts based on RFC 7464 to address the difficulties in serializing very large sequences of features or feature sequences of indeterminate length. GeoJSON objects represent geographic features only and do not specify associations between geographic features and particular devices, users, or facilities. Any association with a particular device, user, or facility requires another protocol. When a GeoJSON object is used in a context where it identifies the location of a device, user, or facility, it becomes subject to the architectural, security, and privacy considerations in RFC 6280. The application of those considerations is specific to protocols that make use of GeoJSON objects and is out of scope for the GeoJSON WG. Although the WG is chartered to improve the extensibility of the format, extensions that would allow GeoJSON objects to specify associations between geographic features and particular devices, users, or facilities are not expected to be defined in the WG. Should that be needed, re-chartering will be required. Deliverables: * A GeoJSON format specification document including mappings of 'geo' URIs * A document describing a format for a streamable sequence of GeoJSON texts [1] https://tools.ietf.org/html/draft-butler-geojson Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Sep 14 10:44:58 2015 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 E36211B2EC5; Mon, 14 Sep 2015 10:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 jt2qx5q9UGvS; Mon, 14 Sep 2015 10:44:56 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 8CF981B3A90; Mon, 14 Sep 2015 10:44:56 -0700 (PDT) Received: from mb.local ([156.39.136.139]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t8EHiqKv058169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Sep 2015 17:44:53 GMT (envelope-from joelja@bogus.com) To: Paul Hoffman , Matthew Lepinski References: <138F09FC-109C-410E-ACA7-2DADF3D4460D@vpnc.org> From: joel jaeggli Message-ID: <55F7078E.2070802@bogus.com> Date: Mon, 14 Sep 2015 10:44:46 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: <138F09FC-109C-410E-ACA7-2DADF3D4460D@vpnc.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OtT1oKHMOlSUPLsiCNVxbwbe8B7HB02nT" Archived-At: Cc: draft-ietf-dnsop-root-loopback.all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-dnsop-root-loopback-03 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, 14 Sep 2015 17:44:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OtT1oKHMOlSUPLsiCNVxbwbe8B7HB02nT Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 9/14/15 8:17 AM, Paul Hoffman wrote: > Thanks! We have made these changes in the pre-draft of -04. If the ADs > want us to publish this before the IESG review, we can; otherwise, we'l= l > wait until after the IESG review to release them. It's fine by me if you do that. no reason not to be dicsussing the latest version so long as we have a few days between the update and the review call. thanks joel > --Paul Hoffman >=20 > A system that does not follow the DNSSEC-related requirements > given > in can be fooled into giving bad response= s > in the > same way as any recursive resolver that does not do DNSSEC > validation on > responses from a remote root server. Anyone deploying the method > described in this document should be familiar with the operationa= l > benefits > and costs of deploying DNSSEC . >=20 > As stated in , this design explicitly > only allows > the new root zone server to be run on a loopback address, in orde= r to > prevent the server from serving authoritative answers to any > system other > than the recursive resolver. This has the security property of > limiting > damage to any other system that might try to rely on the copy of > the root > in case that copy becomes altered. >=20 --OtT1oKHMOlSUPLsiCNVxbwbe8B7HB02nT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlX3B48ACgkQ8AA1q7Z/VrJr+ACfbX3ccdFwIHNxGSaudUDRZBgy Y0gAn2+wOrzKrT1+gdiZlu8w3+OhMZie =gvUC -----END PGP SIGNATURE----- --OtT1oKHMOlSUPLsiCNVxbwbe8B7HB02nT-- From nobody Mon Sep 14 10:46:25 2015 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 34F721B3D0A; Mon, 14 Sep 2015 10:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 JrfDdHAMcaSa; Mon, 14 Sep 2015 10:46:20 -0700 (PDT) Received: from hoffman.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 9B9C51B3BF8; Mon, 14 Sep 2015 10:46:20 -0700 (PDT) Received: from [10.32.60.144] (142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t8EHkDnt088134 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Sep 2015 10:46:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123] claimed to be [10.32.60.144] From: "Paul Hoffman" To: "joel jaeggli" Date: Mon, 14 Sep 2015 10:46:13 -0700 Message-ID: In-Reply-To: <55F7078E.2070802@bogus.com> References: <138F09FC-109C-410E-ACA7-2DADF3D4460D@vpnc.org> <55F7078E.2070802@bogus.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "iesg@ietf.org" , draft-ietf-dnsop-root-loopback.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-dnsop-root-loopback-03 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, 14 Sep 2015 17:46:21 -0000 On 14 Sep 2015, at 10:44, joel jaeggli wrote: > On 9/14/15 8:17 AM, Paul Hoffman wrote: >> Thanks! We have made these changes in the pre-draft of -04. If the ADs >> want us to publish this before the IESG review, we can; otherwise, we'll >> wait until after the IESG review to release them. > > > It's fine by me if you do that. no reason not to be dicsussing the > latest version so long as we have a few days between the update and the > review call. OK, we'll do a new rev soon then. --Paul Hoffman From nobody Mon Sep 14 15:23:03 2015 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 551E51A87A6 for ; Mon, 14 Sep 2015 15:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 WL408SlWygQr for ; Mon, 14 Sep 2015 15:22:58 -0700 (PDT) Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) (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 B0DED1B2E45 for ; Mon, 14 Sep 2015 15:22:56 -0700 (PDT) Received: by ykdg206 with SMTP id g206so167437701ykd.1 for ; Mon, 14 Sep 2015 15:22:56 -0700 (PDT) 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:content-type; bh=cv/PysJo2CME3tlo2w/aM9hJEsTsXnwnTSb/9ijeH8g=; b=EUyCrlxEmaSgoh75PNYw8/bJpDG5G1YSddhnjKaLZsLvkE04HYQ4UluHBcarGWnK/0 JinOjczEmtRJ6D2umz+gAYPjjmkzRN8g/JHLnpyUUFWJAzxHb06gBiYWWFiXhp1UTN+T QEwlJi0+ABH82GWs7E7rJZ34Ki0sDMRUVNObSQ4pRzMR91onPbOKRGNhVr6sHuV9INuz GuNgGNxebozJjq49aYPYoatr7BV+Z8C2J3CY1DTq2E1s41csUbCM7RIiftF+zCkUXkIe EZ6FARCPO8xoM2cUIhKDasIzHZk7RxVDAWfTjMOhzujQk5QOhc7eByimZZgvTqN80ZDt 65hw== X-Gm-Message-State: ALoCoQldx/CD1isGGcoSg5TsADAYYwlwUMCi/aWmSx9hwCgY2w9CiKPhjLlqd62gaE1bJA9SOcHD MIME-Version: 1.0 X-Received: by 10.129.124.8 with SMTP id x8mr17111642ywc.44.1442269375888; Mon, 14 Sep 2015 15:22:55 -0700 (PDT) Received: by 10.37.52.135 with HTTP; Mon, 14 Sep 2015 15:22:55 -0700 (PDT) In-Reply-To: References: <138F09FC-109C-410E-ACA7-2DADF3D4460D@vpnc.org> <55F7078E.2070802@bogus.com> Date: Mon, 14 Sep 2015 18:22:55 -0400 Message-ID: From: Warren Kumari To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11493a2cd23677051fbc81cf Archived-At: Cc: joel jaeggli , "draft-ietf-dnsop-root-loopback.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-dnsop-root-loopback-03 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, 14 Sep 2015 22:22:59 -0000 --001a11493a2cd23677051fbc81cf Content-Type: text/plain; charset=UTF-8 Thank you Paul for taking care of this... W On Monday, September 14, 2015, Paul Hoffman wrote: > On 14 Sep 2015, at 10:44, joel jaeggli wrote: > > > On 9/14/15 8:17 AM, Paul Hoffman wrote: > >> Thanks! We have made these changes in the pre-draft of -04. If the ADs > >> want us to publish this before the IESG review, we can; otherwise, we'll > >> wait until after the IESG review to release them. > > > > > > It's fine by me if you do that. no reason not to be dicsussing the > > latest version so long as we have a few days between the update and the > > review call. > > OK, we'll do a new rev soon then. > > --Paul Hoffman > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --001a11493a2cd23677051fbc81cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you Paul for taking care of this...

W=

On Monday, September 14, 2015, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

On 14 Sep 2015, at 10:44, joel jaeggli wrote:

> On 9/14/15 8:17 AM, Paul Hoffman wrote:
>> Thanks! We have made these changes in the pre-draft of -04. If the= ADs
>> want us to publish this before the IESG review, we can; otherwise,= we'll
>> wait until after the IESG review to release them.
>
>
> It's fine by me if you do that. no reason not to be dicsussing the=
> latest version so long as we have a few days between the update and th= e
> review call.

OK, we'll do a new rev soon then.

--Paul Hoffman

_______________________________________________
secdir mailing list
secdir@ietf.org
= https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

--
I don't think the execution is releva= nt when it was obviously a bad idea in the first place.
This is like put= ting rabid weasels in your pants, and later expressing regret at having cho= sen those particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0= ---maf
--001a11493a2cd23677051fbc81cf-- From nobody Mon Sep 14 18:15:39 2015 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 D0FE01ACE04; Mon, 14 Sep 2015 18:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 effumwVwip3G; Mon, 14 Sep 2015 18:15:31 -0700 (PDT) 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 22AEE1A86F6; Mon, 14 Sep 2015 18:15:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBG92308; Tue, 15 Sep 2015 01:15:27 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 15 Sep 2015 02:15:24 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.166]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Tue, 15 Sep 2015 09:15:20 +0800 From: Mingui Zhang To: Carl Wallace , "draft-ietf-trill-pseudonode-nickname.all@tools.ietf.org" Thread-Topic: draft-ietf-trill-pseudonode-nickname-06 Thread-Index: AQHQ7ZWmwM2br1fzd0eZlb8TxXO1+547X/TQ///sYACAAX0hQA== Date: Tue, 15 Sep 2015 01:15:19 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E7871CA6AF@nkgeml512-mbx.china.huawei.com> References: <4552F0907735844E9204A62BBDD325E7871BB1E4@nkgeml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-trill-pseudonode-nickname-06 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, 15 Sep 2015 01:15:35 -0000 SGkgQ2FybCwNCg0KSSBhZ3JlZSB0aGF0IGl0IGlzIG1vcmUgY2xlYXIgaWYgdGhlIHRyYW5zaWVu dCBjb25kaXRpb24gaXMgZXhwbGljaXRseSBzdGF0ZSBpbiB0aGUgdGV4dCBvZiBwYXJhZ3JhcGgg Mi4gVGhhdCB3aWxsIGJlIGRvbmUgYmVmb3JlIGl0IGlzIHB1Ymxpc2hlZC4NCg0KVGhhbmtzLA0K TWluZ3VpDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQ2FybCBXYWxs YWNlIFttYWlsdG86Y2FybEByZWRob3VuZHNvZnR3YXJlLmNvbV0NCj4gU2VudDogTW9uZGF5LCBT ZXB0ZW1iZXIgMTQsIDIwMTUgNjoxOSBQTQ0KPiBUbzogTWluZ3VpIFpoYW5nOyBkcmFmdC1pZXRm LXRyaWxsLXBzZXVkb25vZGUtbmlja25hbWUuYWxsQHRvb2xzLmlldGYub3JnDQo+IENjOiBpZXNn QGlldGYub3JnOyBzZWNkaXJAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IGRyYWZ0LWlldGYtdHJp bGwtcHNldWRvbm9kZS1uaWNrbmFtZS0wNg0KPiANCj4gDQo+IA0KPiBPbiA5LzEzLzE1LCAxMTo1 MSBQTSwgIk1pbmd1aSBaaGFuZyIgPHpoYW5nbWluZ3VpQGh1YXdlaS5jb20+IHdyb3RlOg0KPiAN Cj4gPkhpIENhcmwsDQo+ID4NCj4gPlRoYW5rcyBmb3IgdGhlIGNvbW1lbnQuDQo+ID4NCj4gPklm IHRoZSBERiBmYWlscywgdGhlIGZhaWx1cmUgd2lsbCBiZSBub3RlZCBieSBvdGhlciBtZW1iZXIg UkJyaWRnZQ0KPiA+dGhyb3VnaCBMU0RCIHN5bmMuIFRoZW4gdGhlIERGIGVsZWN0aW9uIGFsZ29y aXRobSBkZWZpbmVkIGluIFNlY3Rpb24NCj4gPjUuMiB3aWxsIGJlIGxvY2FsbHkgdXNlZCB0byBk ZXRlcm1pbmUgd2hvIGlzIHRoZSBuZXcgREYuDQo+ID5JbiB0aGUgdHJhbnNpZW50IGNvbmRpdGlv biB3aGVuIExTREIgaGFzIG5vdCBiZWVuIHN5bmMtZWQsIHRoZXJlIG1pZ2h0DQo+ID5iZSBwYWNr ZXQgbG9zdCBidXQgdGhlcmUgaXMgbm8gcmFjaW5nDQo+IA0KPiBTb3JyeSwg4oCYcmFjZSBjb25k aXRpb27igJkgbWF5IG5vdCBoYXZlIGJlZW4gdGhlIGJlc3QgdGVybSB0byB1c2UgaGVyZS4NCj4g DQo+ID46IHN1cHBvc2UsIFJCMSBpcyB0aGUgb2xkIERGIGJlZm9yZSB0aGUgZmFpbHVyZSB3aGls ZSBSQjIgaXMgdGhlIG5ldyBERg0KPiA+YWZ0ZXIgUkIxIGZhaWxzIGFjY29yZGluZyB0byB0aGUg ZWxlY3Rpb24gYWxnb3JpdGhtLiBJZiBSQjIgaGFzIGJlZW4NCj4gPnN5bmMtZWQgd2hpbGUgUkIz IGlzIG5vdCwgdGhlbiBSQjIgd2lsbCBiZWdpbiB0byBkbyBmb3J3YXJkaW5nOyBJZiBSQjMNCj4g PmlzIHN5bmMtZWQgd2hpbGUgUkIyIGlzIG5vdCwgdGhlbiBubyBtZW1iZXIgUkJyaWRnZSB3aWxs IGRvIHRoZSBmb3J3YXJkaW5nLg0KPiANCj4gVGhhdCB0aGVyZSBjb3VsZCBiZSBhIGxvc3QgcGFj a2V0IChvciB0cmFmZmljIGRpc3J1cHRpb24gYXMgbWVudGlvbmVkDQo+IGVsc2V3aGVyZSkgd2Fz IHdoYXQgSSB3YXMgZ2V0dGluZyBhdC4gVGhlIGxhbmd1YWdlIGluIHRoZSBmaXJzdCBwYXJhZ3Jh cGggb2YNCj4gc2VjdGlvbiA4IGluZGljYXRlZCB1bmljYXN0IGNvdWxkIGhhdmUgdHJvdWJsZSBi dXQgYXMgSSByZWFkIGl0IHRoZSBzZWNvbmQNCj4gcGFyYWdyYXBoIGludGltYXRlZCB0aGF0IG11 bHRpY2FzdCBjb3VsZCBub3QuIEl0IHdhc27igJl0IGNsZWFyIHRvIG1lIHRoYXQgd2FzDQo+IHRy dWUgYW5kIGl0IHNvdW5kcyBsaWtlIGl0IGlzbuKAmXQgdHJ1ZSBmb3IgYWxsIGNhc2VzIChidXQg aXMgdHJ1ZSBhZnRlciBhIG5ldyBERiBoYXMNCj4gYmVlbiBlbGVjdGVkKS4NCj4gDQo+IFJlLXJl YWRpbmcgaXQgbm93IGl0IGlzIGNsZWFyIHRoZSBwb2ludCBpcyB0aGF0IG5vIOKAmHNwZWNpYWwg YWN0aW9uc+KAmSBhcmUgcmVxdWlyZWQNCj4gbm90IHRoYXQgdGhlcmUgY2FuIGJlIG5vIGxvc3Qg cGFja2V0LiBJdCBtaWdodCBiZSBtb3JlIGNsZWFyIGlmIGl0IHN0YXRlZA0KPiBhY2tub3dsZWRn ZWQgdGhlIGhhbmcgdGltZSBiZXR3ZWVuIGZhaWx1cmUgYW5kIGZ1bGwgZXN0YWJsaXNobWVudCBv ZiB0aGUgbmV3DQo+IFJCdiBmb2xsb3dpbmcgdGhlIGZhaWx1cmUuDQo+IA0KPiANCj4gDQo+ID4N Cj4gPg0KPiA+VGhhbmtzLA0KPiA+TWluZ3VpDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPj4gRnJvbTogQ2FybCBXYWxsYWNlIFttYWlsdG86Y2FybEByZWRob3VuZHNv ZnR3YXJlLmNvbV0NCj4gPj4gU2VudDogU3VuZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTUgNDowMCBB TQ0KPiA+PiBUbzogZHJhZnQtaWV0Zi10cmlsbC1wc2V1ZG9ub2RlLW5pY2tuYW1lLmFsbEB0b29s cy5pZXRmLm9yZw0KPiA+PiBDYzogaWVzZ0BpZXRmLm9yZzsgc2VjZGlyQGlldGYub3JnDQo+ID4+ IFN1YmplY3Q6IGRyYWZ0LWlldGYtdHJpbGwtcHNldWRvbm9kZS1uaWNrbmFtZS0wNg0KPiA+Pg0K PiA+PiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0 eSBkaXJlY3RvcmF0ZeKAmXMNCj4gPj5vbmdvaW5nICBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRG IGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQo+ID4+SUVTRy4NCj4gPj4gVGhlc2Ug Y29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNl Y3VyaXR5DQo+ID4+YXJlYSAgZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hh aXJzIHNob3VsZCB0cmVhdCB0aGVzZQ0KPiA+PmNvbW1lbnRzICBqdXN0IGxpa2UgYW55IG90aGVy IGxhc3QgY2FsbCBjb21tZW50cy4NCj4gPj4NCj4gPj4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMg dXNlIG9mIHBzZXVkby1uaWNrbmFtZXMgZm9yIFJCcmlkZ2VzIGluIGFuDQo+ID4+QWN0aXZlLUFj dGl2ZSBFZGdlIFJCcmlkZ2UgZ3JvdXAuIEkgYW0gbm90IGZhbWlsaWFyIHdpdGggVFJJTEwgYnV0 DQo+ID4+Zm91bmQgdGhlICBkb2N1bWVudCB0byBiZSB3ZWxsIHdyaXR0ZW4gYW5kIGVhc3kgdG8g Zm9sbG93LiBJIGRpZCBoYXZlDQo+ID4+b25lIHF1ZXN0aW9uLCB3aGljaCAgbWF5IGp1c3QgYmUg ZHVlIHRvIG15IGxhY2sgb2YgZmFtaWxpYXJpdHkgd2l0aA0KPiA+PnJlbGV2YW50IG5vcm1hdGl2 ZSBzcGVjcy4gVGhlICBzZWNvbmQgcGFyYWdyYXBoIG9mIHNlY3Rpb24gOCBzdGF0ZXMNCj4gPj50 aGUgZm9sbG93aW5nOg0KPiA+Pg0KPiA+PiAJIkhvd2V2ZXIsIGZvciBtdWx0aS1kZXN0aW5hdGlv biBUUklMTCBEYXRhIHBhY2tldHMsIHNpbmNlIHRoZXkgY2FuDQo+ID4+cmVhY2ggIGFsbCBtZW1i ZXIgUkJyaWRnZXMgb2YgdGhlIG5ldyBSQnYgYW5kIGJlIGVncmVzc2VkIHRvIENFMSBieQ0KPiA+ PmVpdGhlciBSQjIgb3INCj4gPj4gUkIzIChpLmUuLCB0aGUgbmV3IERGIGZvciB0aGUgdHJhZmZp YydzIElubmVyLlZMQU4gb3IgdGhlIFZMQU4gdGhlDQo+ID4+cGFja2V0J3MgIElubmVyLkxhYmVs IG1hcHMgdG8gaW4gdGhlIG5ldyBSQnYpLCBzcGVjaWFsIGFjdGlvbnMgdG8NCj4gPj5wcm90ZWN0 IGFnYWluc3QgIGRvd25saW5rIGZhaWx1cmUgZm9yIHN1Y2ggbXVsdGktZGVzdGluYXRpb24gcGFj a2V0cw0KPiA+PmlzIG5vdCAgbmVlZGVkLiINCj4gPj4NCj4gPj4gV2h5IGlzIHRoZXJlIG5vIHJh Y2UgY29uZGl0aW9uIGJldHdlZW4gdGhlIGFycml2YWwgb2YNCj4gPj5tdWx0aeKAlGRlc3RpbmF0 aW9uIHRyYWZmaWMgIGFuZCB0aGUgY3JlYXRpb24gb2YgYSBuZXcgUkJ2IGZvbGxvd2luZyB0aGUN Cj4gPj5mYWlsdXJlIG9mIFJCMSB0aGF0IGVuYWJsZXMgdGhlICB0cmFmZmljIHRvIGJlIGZvcndh cmRlZD8gR2VuZXJhbGx5LA0KPiA+Pm1lbnRpb25pbmcgZmFpbHVyZSBvZiB0aGUgREYgZm9yIHRo ZSB2aXJ0dWFsICBSQnJpZGdlIHNlZW1lZCBsaWtlIGl0DQo+ID4+bWlnaHQgd2FycmFudCBtZW50 aW9uIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyAgc2VjdGlvbiwgc2luY2UNCj4gPj50 aGF0IGlzIG5ldyByZWxhdGl2ZSB0byB0aGUgc3BlY3Mgbm90ZWQgaW4gdGhlIGN1cnJlbnQgc2Vj dXJpdHkNCj4gPj5jb25zaWRlcmF0aW9ucy4NCj4gPj4NCj4gPg0KPiANCg0K From nobody Tue Sep 15 18:02:13 2015 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 F39561B2FFE for ; Tue, 15 Sep 2015 17:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.311 X-Spam-Level: X-Spam-Status: No, score=-5.311 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JiF-Q1N31hyX for ; Tue, 15 Sep 2015 17:58:43 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9545F1B2FFA for ; Tue, 15 Sep 2015 17:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442365123; x=1473901123; h=message-id:in-reply-to:references:date:to:from:subject: mime-version:content-transfer-encoding; bh=jTBOPuJxK3AeyUleWaGHpN5psbuCQDJGkRPinsNMmwk=; b=Qihao/3yedU19QJkCEefiVnI27GiIpBX1G0TPOuWa2NbSkwiGcVr0KNZ sdta1Sj3Fjo8jZKWPNXxmAC8TQ6187Cnrh3yxozstXwKeLMdA5lLNxK0C jOrDO5uO1RQdOIccp6C60oBXYm2Y8LGgRFr9kE2hpa8ylZW4tXdIovC67 k=; X-IronPort-AV: E=McAfee;i="5700,7163,7925"; a="138779972" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Sep 2015 17:58:43 -0700 X-IronPort-AV: E=Sophos;i="5.17,537,1437462000"; d="scan'208";a="1055554162" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Sep 2015 17:58:42 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 15 Sep 2015 17:58:41 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Tue, 15 Sep 2015 17:58:39 -0700 To: Magnus =?iso-8859-1?Q?Nystr=F6m?= , "secdir@ietf.org" , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: X-Mailman-Approved-At: Tue, 15 Sep 2015 18:02:12 -0700 Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 00:58:45 -0000 Hi Magnus, Thank you for your review and comments. Please see in-line. At 9:26 PM -0700 8/31/15, Magnus Nystr=F6m wrote: > I have reviewed this document as part of the=20 > security directorate's ongoing effort to review=20 > all IETF documents being processed by the IESG.=20 > These comments were written primarily for the=20 > benefit of the security area directors.=20 > Document editors and WG chairs should treat=20 > these comments just like any other last call=20 > comments. > > This memo provides fundamental data structure=20 > definitions and procedural rules for providing=20 > auxiliary information to public service=20 > answering points (PSAPs) when emergency calls=20 > are being made. > > > This reads as an important memo and has been at=20 > least five years in the making. I don't find=20 > the Security (and Privacy) Considerations=20 > section lacking per se, but do have these=20 > questions: > > - Why require HTTPS for the reference case but=20 > not the value case (I can understand why you=20 > don't require it for the value case, but=20 > couldn't it be a choice for the PSAP also in=20 > the reference case? This would also seem to=20 > simplify during an introductory phase when a=20 > wide-spread PKI solution is not yet in place.)? I'm very surprised that a security area person is=20 asking why we don't make TLS optional! It's a=20 valid question, of course, just surprising in=20 this context. Because of the limited scope of=20 the document, specifically emergency services,=20 and given that the dereferencing entities will be=20 PSAPs and other responders that have upgraded to=20 support next-generation, we felt that it was=20 reasonable to require the use of TLS and=20 client-side certificates for dereferencing. > - When HTTPS is required, I assume the PSAP=20 > needs a client certificate - i.e., that the=20 > mutual auth option of TLS is being used,=20 > perhaps this needs to be clarified? Yes, good point. I added clarifying text in response to Ben's comments. > - Was there any discussion around any MTI TLS cipher suites? No, this was never discussed as far as I can recall. > - I assume there's not only a privacy issue but=20 > also a potential spoofing issue - the PSAPs=20 > don't want to be overly susceptible to spoofed=20 > calls (although they rather err on the side of=20 > safety, of course. Thus, should integrity of=20 > infomation in the direct case be considered?=20 > I.e., by n/w or service providers in the path=20 > to the PSAP vouching for the information? You're absolutely correct that PSAPs are=20 concerned about spoofed (and other false) calls=20 but will generally err by taking a call and=20 asking the caller for information. In general,=20 PSAPs prefer information that comes from known=20 and trusted providers (the major carriers). Are=20 you suggesting a mechanism by which providers=20 verify the information provided by the device?=20 =46or location information, there are discussions=20 in other SDOs about sanity-checking=20 device-provided information (location or Wi-Fi=20 APs) against network-known information (macro=20 cell to which the device is associated). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- In a sense, when we started Virgin Atlantic, I was trying to create an airline for myself. If you try to build the perfect airline for yourself, it will be appreciated by others. --Richard Branson, 1996. From nobody Tue Sep 15 18:39:58 2015 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 C69501B2FC1 for ; Tue, 15 Sep 2015 18:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 XqXyaQkyvLfM for ; Tue, 15 Sep 2015 18:39:55 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::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 73B0C1B2F08 for ; Tue, 15 Sep 2015 18:39:54 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so51949556wic.1 for ; Tue, 15 Sep 2015 18:39:53 -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:content-type; bh=GJHVE5cVBOTcBIIQLxmXjZ3myzItkUuMsozvQgV8/xM=; b=KuQLnkoMR+1yFqJ3HJAGnOJwqsPJBIAW5EXLw1ulATzfvbIc1xqsBgfq48ycjVX2dY yAwzZhV1UGpenCaMZT9QWZJccOQUEDHbu4fazTEbAWWEUWptW0G/LiAS21UZaZtHZqmU kC6S7vvY4KU2dov1NRxSHRIgumxalWqF/ZniL1s6/iDy/RtM33RqhKea+EPCeU+AcUUT syWn89o1waf4yqAMN1LWfp0Q6neYBYLMU0ta6QYB5SVqLXq0pG6ZcfDuKlhv7Ar8XVp8 ZKwLBFHdwPLrN3p+syscs2BMvo8Ju1dT5UcNyxs/Idmey4MculUNZpSCPBaHWtzFO7l8 82SQ== MIME-Version: 1.0 X-Received: by 10.180.23.162 with SMTP id n2mr13031210wif.8.1442367593071; Tue, 15 Sep 2015 18:39:53 -0700 (PDT) Received: by 10.27.130.200 with HTTP; Tue, 15 Sep 2015 18:39:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Sep 2015 18:39:53 -0700 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: Randall Gellens Content-Type: multipart/alternative; boundary=e89a8f838a9705485f051fd36086 Archived-At: Cc: draft-ietf-ecrit-additional-data@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 01:39:56 -0000 --e89a8f838a9705485f051fd36086 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Randall, Yes, I guess it may be surprising ... but I was thinking more about getting this effort implemented in an expedited fashion rather than potentially delaying due to the potential issues (also pointed out in the draft) around getting the necessary trust anchors in place between PSAPs and service providers enabling the mutual authentication. It may be good to say something about MTI suites - I would suggest mandating support for a set of suites that offers PFS and avoids CBC, e.g., something like: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 I would also suggest mandating TLS 1.2 (or later) for a new application like this. On the last point, yes, if the service provider is in a possession to vouch for or sanity-check then that could help introduce reliability. Best, On Tue, Sep 15, 2015 at 5:58 PM, Randall Gellens wrote: > Hi Magnus, > > Thank you for your review and comments. Please see in-line. > > At 9:26 PM -0700 8/31/15, Magnus Nystr=C3=B6m 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 ar= ea >> directors. Document editors and WG chairs should treat these comments ju= st >> like any other last call comments. >> >> This memo provides fundamental data structure definitions and procedura= l >> rules for providing auxiliary information to public service answering >> points (PSAPs) when emergency calls are being made. >> >> >> This reads as an important memo and has been at least five years in the >> making. I don't find the Security (and Privacy) Considerations section >> lacking per se, but do have these questions: >> >> - Why require HTTPS for the reference case but not the value case (I ca= n >> understand why you don't require it for the value case, but couldn't it = be >> a choice for the PSAP also in the reference case? This would also seem t= o >> simplify during an introductory phase when a wide-spread PKI solution is >> not yet in place.)? >> > > I'm very surprised that a security area person is asking why we don't mak= e > TLS optional! It's a valid question, of course, just surprising in this > context. Because of the limited scope of the document, specifically > emergency services, and given that the dereferencing entities will be PSA= Ps > and other responders that have upgraded to support next-generation, we fe= lt > that it was reasonable to require the use of TLS and client-side > certificates for dereferencing. > > - When HTTPS is required, I assume the PSAP needs a client certificate - >> i.e., that the mutual auth option of TLS is being used, perhaps this nee= ds >> to be clarified? >> > > Yes, good point. I added clarifying text in response to Ben's comments. > > - Was there any discussion around any MTI TLS cipher suites? >> > > No, this was never discussed as far as I can recall. > > - I assume there's not only a privacy issue but also a potential spoofin= g >> issue - the PSAPs don't want to be overly susceptible to spoofed calls >> (although they rather err on the side of safety, of course. Thus, should >> integrity of infomation in the direct case be considered? I.e., by n/w o= r >> service providers in the path to the PSAP vouching for the information? >> > > You're absolutely correct that PSAPs are concerned about spoofed (and > other false) calls but will generally err by taking a call and asking the > caller for information. In general, PSAPs prefer information that comes > from known and trusted providers (the major carriers). Are you suggestin= g > a mechanism by which providers verify the information provided by the > device? For location information, there are discussions in other SDOs abo= ut > sanity-checking device-provided information (location or Wi-Fi APs) again= st > network-known information (macro cell to which the device is associated). > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > In a sense, when we started Virgin Atlantic, I was trying to create > an airline for myself. If you try to build the perfect airline for > yourself, it will be appreciated by others. --Richard Branson, 1996. > --=20 -- Magnus --e89a8f838a9705485f051fd36086 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Randall,

Yes, I guess it may be surprisi= ng ... but I was thinking more about getting this effort implemented in an = expedited fashion rather than potentially delaying due to the potential iss= ues (also pointed out in the draft) around getting the necessary trust anch= ors in place between PSAPs and service providers enabling the mutual authen= tication.

It may be good to say something about MT= I suites - I would suggest mandating support for a set of suites that offer= s PFS and avoids CBC, e.g., something like:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_S= HA384

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_S= HA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA= 384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA= 256

TLS_DHE_RSA_WITH_AES_256_GCM_SHA38= 4

TLS_DHE_RSA_WITH_AES_128_GCM_SHA25= 6

I would also suggest mandating TLS 1.2 (or later) for a new applicat= ion like this.

On the last point, yes, if the service provider is in a po= ssession to vouch for or sanity-check then that could help introduce reliab= ility.

Best,

On Tue, Sep 15, 2015 at 5:58 PM, Rand= all Gellens <randy@qti.qualcomm.com> wrote:
Hi Magnus,

Thank you for your review and comments.=C2=A0 Please see in-line.

At 9:26 PM -0700 8/31/15, Magnus Nystr=C3=B6m wrote:

=C2=A0I 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.

=C2=A0This memo provides fundamental data structure definitions and procedu= ral rules for providing auxiliary information to public service answering p= oints (PSAPs) when emergency calls are being made.

=C2=A0This reads as an important memo and has been at least five years in t= he making. I don't find the Security (and Privacy) Considerations secti= on lacking per se, but do have these questions:

=C2=A0- Why require HTTPS for the reference case but not the value case (I = can understand why you don't require it for the value case, but couldn&= #39;t it be a choice for the PSAP also in the reference case? This would al= so seem to simplify during an introductory phase when a wide-spread PKI sol= ution is not yet in place.)?

I'm very surprised that a security area person is asking why we don'= ;t make TLS optional!=C2=A0 It's a valid question, of course, just surp= rising in this context.=C2=A0 Because of the limited scope of the document,= specifically emergency services, and given that the dereferencing entities= will be PSAPs and other responders that have upgraded to support next-gene= ration, we felt that it was reasonable to require the use of TLS and client= -side certificates for dereferencing.

=C2=A0- When HTTPS is required, I assume the PSAP needs a client certificat= e - i.e., that the mutual auth option of TLS is being used, perhaps this ne= eds to be clarified?

Yes, good point.=C2=A0 I added clarifying text in response to Ben's com= ments.

=C2=A0- Was there any discussion around any MTI TLS cipher suites?

No, this was never discussed as far as I can recall.

=C2=A0- I assume there's not only a privacy issue but also a potential = spoofing issue - the PSAPs don't want to be overly susceptible to spoof= ed calls (although they rather err on the side of safety, of course. Thus, = should integrity of infomation in the direct case be considered? I.e., by n= /w or service providers in the path to the PSAP vouching for the informatio= n?

You're absolutely correct that PSAPs are concerned about spoofed (and o= ther false) calls but will generally err by taking a call and asking the ca= ller for information.=C2=A0 In general, PSAPs prefer information that comes= from known and trusted providers (the major carriers).=C2=A0 Are you sugge= sting a mechanism by which providers verify the information provided by the= device? For location information, there are discussions in other SDOs abou= t sanity-checking device-provided information (location or Wi-Fi APs) again= st network-known information (macro cell to which the device is associated)= .

--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
In a sense, when we started Virgin Atlantic, I was trying to create
an airline for myself. If you try to build the perfect airline for
yourself, it will be appreciated by others. --Richard Branson, 1996.

-- Magnus

--e89a8f838a9705485f051fd36086-- From nobody Tue Sep 15 19:07:03 2015 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 5E1A71ACD03 for ; Tue, 15 Sep 2015 19:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.711 X-Spam-Level: X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 7R5ml097IdtZ for ; Tue, 15 Sep 2015 19:07:00 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 904FB1AC3D9 for ; Tue, 15 Sep 2015 19:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442369220; x=1473905220; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=5nhDzqSWZrYVklLOGhRonodsDhIe08XMLJolefz7zZc=; b=A4ujBRHaOuhrt9FzyqyHO39meanMl4UyM92QUHum+CVxAF74M+h/9Ox6 QkC1l8hX+CHymZ7oQYIYexWXWSZaC8h+Bhhh5tj5Nu4Nv4vvCAl8tx7vR JmeHeIipfzAoZYMBvhlm5mhqxoLZM+xTb2WPOyNDFLwyHr2oaUWbh5MoS o=; X-IronPort-AV: E=McAfee;i="5700,7163,7925"; a="97928829" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 15 Sep 2015 19:07:00 -0700 X-IronPort-AV: E=Sophos;i="5.17,537,1437462000"; d="scan'208";a="33674514" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Sep 2015 19:06:59 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 15 Sep 2015 19:06:58 -0700 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Tue, 15 Sep 2015 19:06:49 -0700 To: Magnus =?iso-8859-1?Q?Nystr=F6m?= From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 02:07:02 -0000 Hi Magnus, I think we can mandate TLS 1.2 or later without=20 any problem, and I can add that to the text that=20 mandates HTTPS. I don't think I can add MTI=20 cypher suites at this stage, but I think it would=20 be OK to add text such as "it is RECOMMENDED to=20 use only suites that offer Perfect Forward=20 Secrecy (PFS) and avoid Cipher Block Chaining=20 (CBC)", with your list of suites as an example.=20 What do you think? If we go this way, I'd=20 probably need to also add an informational=20 reference or two; what do you suggest? At 6:39 PM -0700 9/15/15, Magnus Nystr=F6m wrote: > Hi Randall, > Yes, I guess it may be surprising ... but I was=20 > thinking more about getting this effort=20 > implemented in an expedited fashion rather than=20 > potentially delaying due to the potential=20 > issues (also pointed out in the draft) around=20 > getting the necessary trust anchors in place=20 > between PSAPs and service providers enabling=20 > the mutual authentication. > > It may be good to say something about MTI=20 > suites - I would suggest mandating support for=20 > a set of suites that offers PFS and avoids CBC,=20 > e.g., something like: > > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 > > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > > > I would also suggest mandating TLS 1.2 (or=20 > later) for a new application like this. > On the last point, yes, if the service provider=20 > is in a possession to vouch for or sanity-check=20 > then that could help introduce reliability. > > Best, > > > On Tue, Sep 15, 2015 at 5:58 PM, Randall=20 > Gellens=20 > <randy@qti.qualcomm.com>=20 > wrote: > > Hi Magnus, > > Thank you for your review and comments. Please see in-line. > > At 9:26 PM -0700 8/31/15, Magnus Nystr=F6m wrote: > > I have reviewed this document as part of the=20 > security directorate's ongoing effort to review=20 > all IETF documents being processed by the IESG.=20 > These comments were written primarily for the=20 > benefit of the security area directors.=20 > Document editors and WG chairs should treat=20 > these comments just like any other last call=20 > comments. > > This memo provides fundamental data structure=20 > definitions and procedural rules for providing=20 > auxiliary information to public service=20 > answering points (PSAPs) when emergency calls=20 > are being made. > > > This reads as an important memo and has been=20 > at least five years in the making. I don't find=20 > the Security (and Privacy) Considerations=20 > section lacking per se, but do have these=20 > questions: > > - Why require HTTPS for the reference case but=20 > not the value case (I can understand why you=20 > don't require it for the value case, but=20 > couldn't it be a choice for the PSAP also in=20 > the reference case? This would also seem to=20 > simplify during an introductory phase when a=20 > wide-spread PKI solution is not yet in place.)? > > > I'm very surprised that a security area person=20 > is asking why we don't make TLS optional! It's=20 > a valid question, of course, just surprising in=20 > this context. Because of the limited scope of=20 > the document, specifically emergency services,=20 > and given that the dereferencing entities will=20 > be PSAPs and other responders that have=20 > upgraded to support next-generation, we felt=20 > that it was reasonable to require the use of=20 > TLS and client-side certificates for=20 > dereferencing. > > - When HTTPS is required, I assume the PSAP=20 > needs a client certificate - i.e., that the=20 > mutual auth option of TLS is being used,=20 > perhaps this needs to be clarified? > > > Yes, good point. I added clarifying text in response to Ben's comments. > > - Was there any discussion around any MTI TLS cipher suites? > > > No, this was never discussed as far as I can recall. > > - I assume there's not only a privacy issue=20 > but also a potential spoofing issue - the PSAPs=20 > don't want to be overly susceptible to spoofed=20 > calls (although they rather err on the side of=20 > safety, of course. Thus, should integrity of=20 > infomation in the direct case be considered?=20 > I.e., by n/w or service providers in the path=20 > to the PSAP vouching for the information? > > > You're absolutely correct that PSAPs are=20 > concerned about spoofed (and other false) calls=20 > but will generally err by taking a call and=20 > asking the caller for information. In general,=20 > PSAPs prefer information that comes from known=20 > and trusted providers (the major carriers).=20 > Are you suggesting a mechanism by which=20 > providers verify the information provided by=20 > the device? For location information, there are=20 > discussions in other SDOs about sanity-checking=20 > device-provided information (location or Wi-Fi=20 > APs) against network-known information (macro=20 > cell to which the device is associated). > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > In a sense, when we started Virgin Atlantic, I was trying to create > an airline for myself. If you try to build the perfect airline for > yourself, it will be appreciated by others. --Richard Branson, 1996. > > > > > -- > > -- Magnus -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- All we're seeing is the negative side of nuclear war. --Barry Goldwater From nobody Tue Sep 15 20:09:09 2015 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 F1BEE1B322B for ; Tue, 15 Sep 2015 20:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 gfG6yQPfL6BB for ; Tue, 15 Sep 2015 20:09:05 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 4C65A1B321F for ; Tue, 15 Sep 2015 20:09:05 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so54133794wic.1 for ; Tue, 15 Sep 2015 20:09:04 -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:content-type; bh=FKgV9mpwu6R/dXuAv8kZ/tbzCxJYMB48d3AuxTSjx48=; b=Z5Sl/KZklllCqeBU4dSd45Neotngxra2vwketIxocsntdw/EZy0um5ehLFevzUFy2t +ISpYp4lDZM3ZvgpQRW+hPzWzQCAHhMkUNO1Hpns6mgwKGgoMIzo6QUEGVr+ErFp2mg7 o4tq5xH33Z2euoeT9HkxIP4ed4yz7PqbwHFa6US72z8hkJYZfxfBSZu1inbgwFXhgkg9 JFGblTfY37ms0rAQhw7lLL1KCDWTRQEtg4UiMEMXXA/6vyn9UdDZO/7TflZDKa1pRtTN seRu7vCGzxn+7XFxijJ+W9/4eIbBVUhpgXyknIioT6WCovqw/l/nkSoY//4297wmnzmT KiLg== MIME-Version: 1.0 X-Received: by 10.194.203.99 with SMTP id kp3mr11766074wjc.157.1442372943861; Tue, 15 Sep 2015 20:09:03 -0700 (PDT) Received: by 10.27.130.200 with HTTP; Tue, 15 Sep 2015 20:09:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Sep 2015 20:09:03 -0700 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: Randall Gellens Content-Type: multipart/alternative; boundary=047d7bd91af2f3de88051fd49e49 Archived-At: Cc: draft-ietf-ecrit-additional-data@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 03:09:08 -0000 --047d7bd91af2f3de88051fd49e49 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, at least mandating TLS 1.2 or higher and recommending as per above seems reasonable. The references for the GCM suites would be RFC 5288 and RFC 5289. Thanks! On Tue, Sep 15, 2015 at 7:06 PM, Randall Gellens wrote: > Hi Magnus, > > I think we can mandate TLS 1.2 or later without any problem, and I can ad= d > that to the text that mandates HTTPS. I don't think I can add MTI cypher > suites at this stage, but I think it would be OK to add text such as "it = is > RECOMMENDED to use only suites that offer Perfect Forward Secrecy (PFS) a= nd > avoid Cipher Block Chaining (CBC)", with your list of suites as an exampl= e. > What do you think? If we go this way, I'd probably need to also add an > informational reference or two; what do you suggest? > > At 6:39 PM -0700 9/15/15, Magnus Nystr=C3=B6m wrote: > > Hi Randall, >> Yes, I guess it may be surprising ... but I was thinking more about >> getting this effort implemented in an expedited fashion rather than >> potentially delaying due to the potential issues (also pointed out in th= e >> draft) around getting the necessary trust anchors in place between PSAPs >> and service providers enabling the mutual authentication. >> >> It may be good to say something about MTI suites - I would suggest >> mandating support for a set of suites that offers PFS and avoids CBC, e.= g., >> something like: >> >> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 >> >> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 >> >> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >> >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >> >> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 >> >> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 >> >> >> I would also suggest mandating TLS 1.2 (or later) for a new application >> like this. >> On the last point, yes, if the service provider is in a possession to >> vouch for or sanity-check then that could help introduce reliability. >> >> Best, >> >> >> On Tue, Sep 15, 2015 at 5:58 PM, Randall Gellens <> randy@qti.qualcomm.com>randy@qti.qualcomm.com> wrote: >> >> Hi Magnus, >> >> Thank you for your review and comments. Please see in-line. >> >> At 9:26 PM -0700 8/31/15, Magnus Nystr=C3=B6m 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 ar= ea >> directors. Document editors and WG chairs should treat these comments ju= st >> like any other last call comments. >> >> This memo provides fundamental data structure definitions and >> procedural rules for providing auxiliary information to public service >> answering points (PSAPs) when emergency calls are being made. >> >> >> This reads as an important memo and has been at least five years in th= e >> making. I don't find the Security (and Privacy) Considerations section >> lacking per se, but do have these questions: >> >> - Why require HTTPS for the reference case but not the value case (I >> can understand why you don't require it for the value case, but couldn't= it >> be a choice for the PSAP also in the reference case? This would also see= m >> to simplify during an introductory phase when a wide-spread PKI solution= is >> not yet in place.)? >> >> >> I'm very surprised that a security area person is asking why we don't >> make TLS optional! It's a valid question, of course, just surprising in >> this context. Because of the limited scope of the document, specificall= y >> emergency services, and given that the dereferencing entities will be PS= APs >> and other responders that have upgraded to support next-generation, we f= elt >> that it was reasonable to require the use of TLS and client-side >> certificates for dereferencing. >> >> - When HTTPS is required, I assume the PSAP needs a client certificate >> - i.e., that the mutual auth option of TLS is being used, perhaps this >> needs to be clarified? >> >> >> Yes, good point. I added clarifying text in response to Ben's comments= . >> >> - Was there any discussion around any MTI TLS cipher suites? >> >> >> No, this was never discussed as far as I can recall. >> >> - I assume there's not only a privacy issue but also a potential >> spoofing issue - the PSAPs don't want to be overly susceptible to spoofe= d >> calls (although they rather err on the side of safety, of course. Thus, >> should integrity of infomation in the direct case be considered? I.e., b= y >> n/w or service providers in the path to the PSAP vouching for the >> information? >> >> >> You're absolutely correct that PSAPs are concerned about spoofed (and >> other false) calls but will generally err by taking a call and asking th= e >> caller for information. In general, PSAPs prefer information that comes >> from known and trusted providers (the major carriers). Are you suggestin= g a >> mechanism by which providers verify the information provided by the devi= ce? >> For location information, there are discussions in other SDOs about >> sanity-checking device-provided information (location or Wi-Fi APs) agai= nst >> network-known information (macro cell to which the device is associated)= . >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> In a sense, when we started Virgin Atlantic, I was trying to create >> an airline for myself. If you try to build the perfect airline for >> yourself, it will be appreciated by others. --Richard Branson, 1996. >> >> >> >> >> -- >> >> -- Magnus >> > > > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > All we're seeing is the negative side of nuclear war. > --Barry Goldwater > --=20 -- Magnus --047d7bd91af2f3de88051fd49e49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes, at least mandating TLS 1.2 or higher and re= commending as per above seems reasonable.

The references for the G= CM suites would be RFC 5288 and RFC 5289.

Thanks!

On Tue, Sep 15, 2015= at 7:06 PM, Randall Gellens <randy@qti.qualcomm.com> w= rote:

Hi Magnus,

I think we can mandate TLS 1.2 or later without any problem, and I can add = that to the text that mandates HTTPS.=C2=A0 I don't think I can add MTI= cypher suites at this stage, but I think it would be OK to add text such a= s "it is RECOMMENDED to use only suites that offer Perfect Forward Sec= recy (PFS) and avoid Cipher Block Chaining (CBC)", with your list of s= uites as an example. What do you think?=C2=A0 If we go this way, I'd pr= obably need to also add an informational reference or two; what do you sugg= est?

At 6:39 PM -0700 9/15/15, Magnus Nystr=C3=B6m wrote:

=C2=A0Hi Randall,
=C2=A0Yes, I guess it may be surprising ... but I was thinking more about g= etting this effort implemented in an expedited fashion rather than potentia= lly delaying due to the potential issues (also pointed out in the draft) ar= ound getting the necessary trust anchors in place between PSAPs and service= providers enabling the mutual authentication.

=C2=A0It may be good to say something about MTI suites - I would suggest ma= ndating support for a set of suites that offers PFS and avoids CBC, e.g., s= omething like:

=C2=A0TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

=C2=A0TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

=C2=A0TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

=C2=A0TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

=C2=A0TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

=C2=A0TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

=C2=A0I would also suggest mandating TLS 1.2 (or later) for a new applicati= on like this.
=C2=A0On the last point, yes, if the service provider is in a possession to= vouch for or sanity-check then that could help introduce reliability.

=C2=A0Best,

=C2=A0On Tue, Sep 15, 2015 at 5:58 PM, Randall Gellens <<mailto:randy@qti.qualcomm.c= om>randy= @qti.qualcomm.com> wrote:

=C2=A0Hi Magnus,

=C2=A0Thank you for your review and comments.=C2=A0 Please see in-line.

=C2=A0At 9:26 PM -0700 8/31/15, Magnus Nystr=C3=B6m wrote:

=C2=A0 I have reviewed this document as part of the security directorate= 9;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.

=C2=A0 This memo provides fundamental data structure definitions and proced= ural rules for providing auxiliary information to public service answering = points (PSAPs) when emergency calls are being made.

=C2=A0 This reads as an important memo and has been at least five years in = the making. I don't find the Security (and Privacy) Considerations sect= ion lacking per se, but do have these questions:

=C2=A0 - Why require HTTPS for the reference case but not the value case (I= can understand why you don't require it for the value case, but couldn= 't it be a choice for the PSAP also in the reference case? This would a= lso seem to simplify during an introductory phase when a wide-spread PKI so= lution is not yet in place.)?

=C2=A0I'm very surprised that a security area person is asking why we d= on't make TLS optional!=C2=A0 It's a valid question, of course, jus= t surprising in this context.=C2=A0 Because of the limited scope of the doc= ument, specifically emergency services, and given that the dereferencing en= tities will be PSAPs and other responders that have upgraded to support nex= t-generation, we felt that it was reasonable to require the use of TLS and = client-side certificates for dereferencing.

=C2=A0 - When HTTPS is required, I assume the PSAP needs a client certifica= te - i.e., that the mutual auth option of TLS is being used, perhaps this n= eeds to be clarified?

=C2=A0Yes, good point.=C2=A0 I added clarifying text in response to Ben'= ;s comments.

=C2=A0 - Was there any discussion around any MTI TLS cipher suites?

=C2=A0No, this was never discussed as far as I can recall.

=C2=A0 - I assume there's not only a privacy issue but also a potential= spoofing issue - the PSAPs don't want to be overly susceptible to spoo= fed calls (although they rather err on the side of safety, of course. Thus,= should integrity of infomation in the direct case be considered? I.e., by = n/w or service providers in the path to the PSAP vouching for the informati= on?

=C2=A0You're absolutely correct that PSAPs are concerned about spoofed = (and other false) calls but will generally err by taking a call and asking = the caller for information.=C2=A0 In general, PSAPs prefer information that= comes from known and trusted providers (the major carriers). Are you sugge= sting a mechanism by which providers verify the information provided by the= device? For location information, there are discussions in other SDOs abou= t sanity-checking device-provided information (location or Wi-Fi APs) again= st network-known information (macro cell to which the device is associated)= .

=C2=A0--
=C2=A0Randall Gellens
=C2=A0Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I= speak for myself only
=C2=A0-------------- Randomly selected tag: ---------------
=C2=A0In a sense, when we started Virgin Atlantic, I was trying to create =C2=A0an airline for myself. If you try to build the perfect airline for =C2=A0yourself, it will be appreciated by others. --Richard Branson, 1996.<= br>

=C2=A0--

=C2=A0-- Magnus

--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
All we're seeing is the negative side of nuclear war.
=C2=A0 =C2=A0--Barry Goldwater

-- Magnus

--047d7bd91af2f3de88051fd49e49-- From nobody Tue Sep 15 21:21:21 2015 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 18C001B33AD for ; Tue, 15 Sep 2015 21:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.711 X-Spam-Level: X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 eYC3aFgShDGB for ; Tue, 15 Sep 2015 21:21:18 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 380761B33AA for ; Tue, 15 Sep 2015 21:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442377278; x=1473913278; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=vtbIpv0pP5RbIABRpiXY5HEGJtjnz0/jx6MHDaYbPPE=; b=uxh57WN7t6J5my0Qgxl/Gmi7zjlxZZz1dv5vUhzia2+w4cCfkkBbwpAm owoUtA6h7H78gwg28wr7l+nMBPJWauqPty9lLqUlTzAIBmJZPUr9fsyxw aFkKsnI7uIKICA5FKZeYB7VeehFhjttBN/69TyEn/mHNDa4x8FbHHpTFD Y=; X-IronPort-AV: E=McAfee;i="5700,7163,7925"; a="97936575" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Sep 2015 21:21:17 -0700 X-IronPort-AV: E=Sophos;i="5.17,537,1437462000"; d="scan'208";a="1002528923" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Sep 2015 21:21:17 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 15 Sep 2015 21:21:16 -0700 Message-ID: In-Reply-To: References:

X-Mailer: Eudora for Mac OS X Date: Tue, 15 Sep 2015 21:21:14 -0700 To: Magnus =?iso-8859-1?Q?Nystr=F6m?= From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 04:21:20 -0000 I've made these changes and included the two references. Thanks very much. At 8:09 PM -0700 9/15/15, Magnus Nystr=F6m wrote: > Yes, at least mandating TLS 1.2 or higher and recommending as per above > seems reasonable. > The references for the GCM suites would be RFC 5288 and RFC 5289. > > Thanks! > > On Tue, Sep 15, 2015 at 7:06 PM, Randall Gellens > wrote: > >> Hi Magnus, >> >> I think we can mandate TLS 1.2 or later without any problem, and I can a= dd >> that to the text that mandates HTTPS. I don't think I can add MTI cyphe= r >> suites at this stage, but I think it would be OK to add text such as "it= is >> RECOMMENDED to use only suites that offer Perfect Forward Secrecy (PFS) = and >> avoid Cipher Block Chaining (CBC)", with your list of suites as an examp= le. >> What do you think? If we go this way, I'd probably need to also add an >> informational reference or two; what do you suggest? >> >> At 6:39 PM -0700 9/15/15, Magnus Nystr=F6m wrote: >> >> Hi Randall, >>> Yes, I guess it may be surprising ... but I was thinking more about >>> getting this effort implemented in an expedited fashion rather than >>> potentially delaying due to the potential issues (also pointed out in t= he >>> draft) around getting the necessary trust anchors in place between PSAP= s >>> and service providers enabling the mutual authentication. >>> >>> It may be good to say something about MTI suites - I would suggest >>> mandating support for a set of suites that offers PFS and avoids CBC, e= =2Eg., >>> something like: >>> >>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 >>> >>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 >>> >>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 >>> >>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 >>> >>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 >>> >>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 >>> >>> >>> I would also suggest mandating TLS 1.2 (or later) for a new applicatio= n >>> like this. >>> On the last point, yes, if the service provider is in a possession to >>> vouch for or sanity-check then that could help introduce reliability. >>> >>> Best, >>> >>> >>> On Tue, Sep 15, 2015 at 5:58 PM, Randall Gellens <>> randy@qti.qualcomm.com>randy@qti.qualcomm.com> wrote: >>> >>> Hi Magnus, >>> >>> Thank you for your review and comments. Please see in-line. >>> >>> At 9:26 PM -0700 8/31/15, Magnus Nystr=F6m 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= =2E >>> These comments were written primarily for the benefit of the security a= rea >>> directors. Document editors and WG chairs should treat these comments j= ust >>> like any other last call comments. >>> >>> This memo provides fundamental data structure definitions and >>> procedural rules for providing auxiliary information to public service >>> answering points (PSAPs) when emergency calls are being made. >>> >>> >>> This reads as an important memo and has been at least five years in t= he >>> making. I don't find the Security (and Privacy) Considerations section >>> lacking per se, but do have these questions: >>> >>> - Why require HTTPS for the reference case but not the value case (I >>> can understand why you don't require it for the value case, but= couldn't it >>> be a choice for the PSAP also in the reference case? This would also se= em >>> to simplify during an introductory phase when a wide-spread PKI= solution is >>> not yet in place.)? >>> >>> >>> I'm very surprised that a security area person is asking why we don't >>> make TLS optional! It's a valid question, of course, just surprising i= n >>> this context. Because of the limited scope of the document, specifical= ly >>> emergency services, and given that the dereferencing entities will be P= SAPs >>> and other responders that have upgraded to support next-generation, we = felt >>> that it was reasonable to require the use of TLS and client-side > >> certificates for dereferencing. >>> >>> - When HTTPS is required, I assume the PSAP needs a client certificat= e >>> - i.e., that the mutual auth option of TLS is being used, perhaps this >>> needs to be clarified? >>> >>> >>> Yes, good point. I added clarifying text in response to Ben's comment= s -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- This fortune intentionally not included. From nobody Wed Sep 16 00:38:14 2015 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 218671B3845 for ; Wed, 16 Sep 2015 00:38:12 -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 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 YuwV87AbOUYj for ; Wed, 16 Sep 2015 00:38:09 -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 1859D1B36F3 for ; Wed, 16 Sep 2015 00:38:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1D938BE87; Wed, 16 Sep 2015 08:38:07 +0100 (IST) 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 xKoUC8D3Vd6p; Wed, 16 Sep 2015 08:38:05 +0100 (IST) Received: from [127.0.0.1] (unknown [86.46.27.30]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0AB57BE2F; Wed, 16 Sep 2015 08:38:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1442389085; bh=N0zrb2vwbaIxy9LSK8koJFRc5CNbdGbC4HAKPj/ogLE=; h=To:Cc:From:Subject:In-Reply-To:References:Date:From; b=SA9nCw9bUIp0MfitPLjQnaPqBwyppstAslOjOCo6vSEwNMiti8uOKTC5mE8YLZ8hM nZDOUjJkaq+zqj2TzY1XT1gYFd9yI1Oynebw7IHwWAKnFPr6Vadco7jCPLYfvo0wxR BqN+QxmknDRoDWZfCMlzwSvle/0KKXNZlZ7bD2e8= X-Priority: 3 To: magnusn@gmail.com From: stephen.farrell@cs.tcd.ie In-Reply-To: References:

Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Date: Wed, 16 Sep 2015 07:38:03 +0000 Message-ID: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> MIME-Version: 1.0 Archived-At: Cc: randy@qti.qualcomm.com, draft-ietf-ecrit-additional-data@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 07:38:12 -0000 DQoNCk9uIFdlZCBTZXAgMTYgMDQ6MDk6MDMgMjAxNSBHTVQrMDEwMCwgTWFnbnVzIE55c3Ryw7Zt IHdyb3RlOg0KPiBZZXMsIGF0IGxlYXN0IG1hbmRhdGluZyBUTFMgMS4yIG9yIGhpZ2hlciBhbmQg cmVjb21tZW5kaW5nIGFzIHBlciBhYm92ZQ0KPiBzZWVtcyByZWFzb25hYmxlLg0KPiBUaGUgcmVm ZXJlbmNlcyBmb3IgdGhlIEdDTSBzdWl0ZXMgd291bGQgYmUgUkZDIDUyODggYW5kIFJGQyA1Mjg5 Lg0KDQpCQ1AxOTUgaGFzIHJlY2VudCByZWNvbW1lbmRhdGlvbnMgZm9yIG1vc3QgVExTIG9wdGlv bnMuIEknZCBzYXkgaXQnZCBiZSBiZXN0IHRvIHVzZSB0aG9zZSBvciBpZiBub3QgZmlndXJlIG91 dCB3aHkgdGhleSdyZSBub3QgY29ycmVjdCBmb3IgdGhpcyBjb250ZXh0Lg0KDQpTLg0KIA0KDQo+ IA0KPiBUaGFua3MhDQo+IA0KPiBPbiBUdWUsIFNlcCAxNSwgMjAxNSBhdCA3OjA2IFBNLCBSYW5k YWxsIEdlbGxlbnMgPHJhbmR5QHF0aS5xdWFsY29tbS5jb20+DQo+IHdyb3RlOg0KPiANCj4gPiBI aSBNYWdudXMsDQo+ID4NCj4gPiBJIHRoaW5rIHdlIGNhbiBtYW5kYXRlIFRMUyAxLjIgb3IgbGF0 ZXIgd2l0aG91dCBhbnkgcHJvYmxlbSwgYW5kIEkgY2FuIGFkZA0KPiA+IHRoYXQgdG8gdGhlIHRl eHQgdGhhdCBtYW5kYXRlcyBIVFRQUy4gIEkgZG9uJ3QgdGhpbmsgSSBjYW4gYWRkIE1USSBjeXBo ZXINCj4gPiBzdWl0ZXMgYXQgdGhpcyBzdGFnZSwgYnV0IEkgdGhpbmsgaXQgd291bGQgYmUgT0sg dG8gYWRkIHRleHQgc3VjaCBhcyAiaXQgaXMNCj4gPiBSRUNPTU1FTkRFRCB0byB1c2Ugb25seSBz dWl0ZXMgdGhhdCBvZmZlciBQZXJmZWN0IEZvcndhcmQgU2VjcmVjeSAoUEZTKSBhbmQNCj4gPiBh dm9pZCBDaXBoZXIgQmxvY2sgQ2hhaW5pbmcgKENCQykiLCB3aXRoIHlvdXIgbGlzdCBvZiBzdWl0 ZXMgYXMgYW4gZXhhbXBsZS4NCj4gPiBXaGF0IGRvIHlvdSB0aGluaz8gIElmIHdlIGdvIHRoaXMg d2F5LCBJJ2QgcHJvYmFibHkgbmVlZCB0byBhbHNvIGFkZCBhbg0KPiA+IGluZm9ybWF0aW9uYWwg cmVmZXJlbmNlIG9yIHR3bzsgd2hhdCBkbyB5b3Ugc3VnZ2VzdD8NCj4gPg0KPiA+IEF0IDY6Mzkg UE0gLTA3MDAgOS8xNS8xNSwgTWFnbnVzIE55c3Ryw7ZtIHdyb3RlOg0KPiA+DQo+ID4gIEhpIFJh bmRhbGwsDQo+ID4+ICBZZXMsIEkgZ3Vlc3MgaXQgbWF5IGJlIHN1cnByaXNpbmcgLi4uIGJ1dCBJ IHdhcyB0aGlua2luZyBtb3JlIGFib3V0DQo+ID4+IGdldHRpbmcgdGhpcyBlZmZvcnQgaW1wbGVt ZW50ZWQgaW4gYW4gZXhwZWRpdGVkIGZhc2hpb24gcmF0aGVyIHRoYW4NCj4gPj4gcG90ZW50aWFs bHkgZGVsYXlpbmcgZHVlIHRvIHRoZSBwb3RlbnRpYWwgaXNzdWVzIChhbHNvIHBvaW50ZWQgb3V0 IGluIHRoZQ0KPiA+PiBkcmFmdCkgYXJvdW5kIGdldHRpbmcgdGhlIG5lY2Vzc2FyeSB0cnVzdCBh bmNob3JzIGluIHBsYWNlIGJldHdlZW4gUFNBUHMNCj4gPj4gYW5kIHNlcnZpY2UgcHJvdmlkZXJz IGVuYWJsaW5nIHRoZSBtdXR1YWwgYXV0aGVudGljYXRpb24uDQo+ID4+DQo+ID4+ICBJdCBtYXkg YmUgZ29vZCB0byBzYXkgc29tZXRoaW5nIGFib3V0IE1USSBzdWl0ZXMgLSBJIHdvdWxkIHN1Z2dl c3QNCj4gPj4gbWFuZGF0aW5nIHN1cHBvcnQgZm9yIGEgc2V0IG9mIHN1aXRlcyB0aGF0IG9mZmVy cyBQRlMgYW5kIGF2b2lkcyBDQkMsIGUuZy4sDQo+ID4+IHNvbWV0aGluZyBsaWtlOg0KPiA+Pg0K PiA+PiAgVExTX0VDREhFX0VDRFNBX1dJVEhfQUVTXzI1Nl9HQ01fU0hBMzg0DQo+ID4+DQo+ID4+ ICBUTFNfRUNESEVfRUNEU0FfV0lUSF9BRVNfMTI4X0dDTV9TSEEyNTYNCj4gPj4NCj4gPj4gIFRM U19FQ0RIRV9SU0FfV0lUSF9BRVNfMjU2X0dDTV9TSEEzODQNCj4gPj4NCj4gPj4gIFRMU19FQ0RI RV9SU0FfV0lUSF9BRVNfMTI4X0dDTV9TSEEyNTYNCj4gPj4NCj4gPj4gIFRMU19ESEVfUlNBX1dJ VEhfQUVTXzI1Nl9HQ01fU0hBMzg0DQo+ID4+DQo+ID4+ICBUTFNfREhFX1JTQV9XSVRIX0FFU18x MjhfR0NNX1NIQTI1Ng0KPiA+Pg0KPiA+Pg0KPiA+PiAgSSB3b3VsZCBhbHNvIHN1Z2dlc3QgbWFu ZGF0aW5nIFRMUyAxLjIgKG9yIGxhdGVyKSBmb3IgYSBuZXcgYXBwbGljYXRpb24NCj4gPj4gbGlr ZSB0aGlzLg0KPiA+PiAgT24gdGhlIGxhc3QgcG9pbnQsIHllcywgaWYgdGhlIHNlcnZpY2UgcHJv dmlkZXIgaXMgaW4gYSBwb3NzZXNzaW9uIHRvDQo+ID4+IHZvdWNoIGZvciBvciBzYW5pdHktY2hl Y2sgdGhlbiB0aGF0IGNvdWxkIGhlbHAgaW50cm9kdWNlIHJlbGlhYmlsaXR5Lg0KPiA+Pg0KPiA+ PiAgQmVzdCwNCj4gPj4NCj4gPj4NCj4gPj4gIE9uIFR1ZSwgU2VwIDE1LCAyMDE1IGF0IDU6NTgg UE0sIFJhbmRhbGwgR2VsbGVucyA8PG1haWx0bzoNCj4gPj4gcmFuZHlAcXRpLnF1YWxjb21tLmNv bT5yYW5keUBxdGkucXVhbGNvbW0uY29tPiB3cm90ZToNCj4gPj4NCj4gPj4gIEhpIE1hZ251cywN Cj4gPj4NCj4gPj4gIFRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLiAgUGxl YXNlIHNlZSBpbi1saW5lLg0KPiA+Pg0KPiA+PiAgQXQgOToyNiBQTSAtMDcwMCA4LzMxLzE1LCBN YWdudXMgTnlzdHLDtm0gd3JvdGU6DQo+ID4+DQo+ID4+ICAgSSBoYXZlIHJldmlld2VkIHRoaXMg ZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncw0KPiA+PiBvbmdv aW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBi eSB0aGUgSUVTRy4NCj4gPj4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBm b3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWENCj4gPj4gZGlyZWN0b3JzLiBEb2N1 bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1 c3QNCj4gPj4gbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiA+Pg0KPiA+PiAg IFRoaXMgbWVtbyBwcm92aWRlcyBmdW5kYW1lbnRhbCBkYXRhIHN0cnVjdHVyZSBkZWZpbml0aW9u cyBhbmQNCj4gPj4gcHJvY2VkdXJhbCBydWxlcyBmb3IgcHJvdmlkaW5nIGF1eGlsaWFyeSBpbmZv cm1hdGlvbiB0byBwdWJsaWMgc2VydmljZQ0KPiA+PiBhbnN3ZXJpbmcgcG9pbnRzIChQU0FQcykg d2hlbiBlbWVyZ2VuY3kgY2FsbHMgYXJlIGJlaW5nIG1hZGUuDQo+ID4+DQo+ID4+DQo+ID4+ICAg VGhpcyByZWFkcyBhcyBhbiBpbXBvcnRhbnQgbWVtbyBhbmQgaGFzIGJlZW4gYXQgbGVhc3QgZml2 ZSB5ZWFycyBpbiB0aGUNCj4gPj4gbWFraW5nLiBJIGRvbid0IGZpbmQgdGhlIFNlY3VyaXR5IChh bmQgUHJpdmFjeSkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbg0KPiA+PiBsYWNraW5nIHBlciBzZSwg YnV0IGRvIGhhdmUgdGhlc2UgcXVlc3Rpb25zOg0KPiA+Pg0KPiA+PiAgIC0gV2h5IHJlcXVpcmUg SFRUUFMgZm9yIHRoZSByZWZlcmVuY2UgY2FzZSBidXQgbm90IHRoZSB2YWx1ZSBjYXNlIChJDQo+ ID4+IGNhbiB1bmRlcnN0YW5kIHdoeSB5b3UgZG9uJ3QgcmVxdWlyZSBpdCBmb3IgdGhlIHZhbHVl IGNhc2UsIGJ1dCBjb3VsZG4ndCBpdA0KPiA+PiBiZSBhIGNob2ljZSBmb3IgdGhlIFBTQVAgYWxz byBpbiB0aGUgcmVmZXJlbmNlIGNhc2U/IFRoaXMgd291bGQgYWxzbyBzZWVtDQo+ID4+IHRvIHNp bXBsaWZ5IGR1cmluZyBhbiBpbnRyb2R1Y3RvcnkgcGhhc2Ugd2hlbiBhIHdpZGUtc3ByZWFkIFBL SSBzb2x1dGlvbiBpcw0KPiA+PiBub3QgeWV0IGluIHBsYWNlLik/DQo+ID4+DQo+ID4+DQo+ID4+ ICBJJ20gdmVyeSBzdXJwcmlzZWQgdGhhdCBhIHNlY3VyaXR5IGFyZWEgcGVyc29uIGlzIGFza2lu ZyB3aHkgd2UgZG9uJ3QNCj4gPj4gbWFrZSBUTFMgb3B0aW9uYWwhICBJdCdzIGEgdmFsaWQgcXVl c3Rpb24sIG9mIGNvdXJzZSwganVzdCBzdXJwcmlzaW5nIGluDQo+ID4+IHRoaXMgY29udGV4dC4g IEJlY2F1c2Ugb2YgdGhlIGxpbWl0ZWQgc2NvcGUgb2YgdGhlIGRvY3VtZW50LCBzcGVjaWZpY2Fs bHkNCj4gPj4gZW1lcmdlbmN5IHNlcnZpY2VzLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZGVyZWZlcmVu Y2luZyBlbnRpdGllcyB3aWxsIGJlIFBTQVBzDQo+ID4+IGFuZCBvdGhlciByZXNwb25kZXJzIHRo YXQgaGF2ZSB1cGdyYWRlZCB0byBzdXBwb3J0IG5leHQtZ2VuZXJhdGlvbiwgd2UgZmVsdA0KPiA+ PiB0aGF0IGl0IHdhcyByZWFzb25hYmxlIHRvIHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMgYW5kIGNs aWVudC1zaWRlDQo+ID4+IGNlcnRpZmljYXRlcyBmb3IgZGVyZWZlcmVuY2luZy4NCj4gPj4NCj4g Pj4gICAtIFdoZW4gSFRUUFMgaXMgcmVxdWlyZWQsIEkgYXNzdW1lIHRoZSBQU0FQIG5lZWRzIGEg Y2xpZW50IGNlcnRpZmljYXRlDQo+ID4+IC0gaS5lLiwgdGhhdCB0aGUgbXV0dWFsIGF1dGggb3B0 aW9uIG9mIFRMUyBpcyBiZWluZyB1c2VkLCBwZXJoYXBzIHRoaXMNCj4gPj4gbmVlZHMgdG8gYmUg Y2xhcmlmaWVkPw0KPiA+Pg0KPiA+Pg0KPiA+PiAgWWVzLCBnb29kIHBvaW50LiAgSSBhZGRlZCBj bGFyaWZ5aW5nIHRleHQgaW4gcmVzcG9uc2UgdG8gQmVuJ3MgY29tbWVudHMuDQo+ID4+DQo+ID4+ ICAgLSBXYXMgdGhlcmUgYW55IGRpc2N1c3Npb24gYXJvdW5kIGFueSBNVEkgVExTIGNpcGhlciBz dWl0ZXM/DQo+ID4+DQo+ID4+DQo+ID4+ICBObywgdGhpcyB3YXMgbmV2ZXIgZGlzY3Vzc2VkIGFz IGZhciBhcyBJIGNhbiByZWNhbGwuDQo+ID4+DQo+ID4+ICAgLSBJIGFzc3VtZSB0aGVyZSdzIG5v dCBvbmx5IGEgcHJpdmFjeSBpc3N1ZSBidXQgYWxzbyBhIHBvdGVudGlhbA0KPiA+PiBzcG9vZmlu ZyBpc3N1ZSAtIHRoZSBQU0FQcyBkb24ndCB3YW50IHRvIGJlIG92ZXJseSBzdXNjZXB0aWJsZSB0 byBzcG9vZmVkDQo+ID4+IGNhbGxzIChhbHRob3VnaCB0aGV5IHJhdGhlciBlcnIgb24gdGhlIHNp ZGUgb2Ygc2FmZXR5LCBvZiBjb3Vyc2UuIFRodXMsDQo+ID4+IHNob3VsZCBpbnRlZ3JpdHkgb2Yg aW5mb21hdGlvbiBpbiB0aGUgZGlyZWN0IGNhc2UgYmUgY29uc2lkZXJlZD8gSS5lLiwgYnkNCj4g Pj4gbi93IG9yIHNlcnZpY2UgcHJvdmlkZXJzIGluIHRoZSBwYXRoIHRvIHRoZSBQU0FQIHZvdWNo aW5nIGZvciB0aGUNCj4gPj4gaW5mb3JtYXRpb24/DQo+ID4+DQo+ID4+DQo+ID4+ICBZb3UncmUg YWJzb2x1dGVseSBjb3JyZWN0IHRoYXQgUFNBUHMgYXJlIGNvbmNlcm5lZCBhYm91dCBzcG9vZmVk IChhbmQNCj4gPj4gb3RoZXIgZmFsc2UpIGNhbGxzIGJ1dCB3aWxsIGdlbmVyYWxseSBlcnIgYnkg dGFraW5nIGEgY2FsbCBhbmQgYXNraW5nIHRoZQ0KPiA+PiBjYWxsZXIgZm9yIGluZm9ybWF0aW9u LiAgSW4gZ2VuZXJhbCwgUFNBUHMgcHJlZmVyIGluZm9ybWF0aW9uIHRoYXQgY29tZXMNCj4gPj4g ZnJvbSBrbm93biBhbmQgdHJ1c3RlZCBwcm92aWRlcnMgKHRoZSBtYWpvciBjYXJyaWVycykuIEFy ZSB5b3Ugc3VnZ2VzdGluZyBhDQo+ID4+IG1lY2hhbmlzbSBieSB3aGljaCBwcm92aWRlcnMgdmVy aWZ5IHRoZSBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSB0aGUgZGV2aWNlPw0KPiA+PiBGb3IgbG9j YXRpb24gaW5mb3JtYXRpb24sIHRoZXJlIGFyZSBkaXNjdXNzaW9ucyBpbiBvdGhlciBTRE9zIGFi b3V0DQo+ID4+IHNhbml0eS1jaGVja2luZyBkZXZpY2UtcHJvdmlkZWQgaW5mb3JtYXRpb24gKGxv Y2F0aW9uIG9yIFdpLUZpIEFQcykgYWdhaW5zdA0KPiA+PiBuZXR3b3JrLWtub3duIGluZm9ybWF0 aW9uIChtYWNybyBjZWxsIHRvIHdoaWNoIHRoZSBkZXZpY2UgaXMgYXNzb2NpYXRlZCkuDQo+ID4+ DQo+ID4+ICAtLQ0KPiA+PiAgUmFuZGFsbCBHZWxsZW5zDQo+ID4+ICBPcGluaW9ucyBhcmUgcGVy c29uYWw7ICAgIGZhY3RzIGFyZSBzdXNwZWN0OyAgICBJIHNwZWFrIGZvciBteXNlbGYgb25seQ0K PiA+PiAgLS0tLS0tLS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0tLS0t LS0NCj4gPj4gIEluIGEgc2Vuc2UsIHdoZW4gd2Ugc3RhcnRlZCBWaXJnaW4gQXRsYW50aWMsIEkg d2FzIHRyeWluZyB0byBjcmVhdGUNCj4gPj4gIGFuIGFpcmxpbmUgZm9yIG15c2VsZi4gSWYgeW91 IHRyeSB0byBidWlsZCB0aGUgcGVyZmVjdCBhaXJsaW5lIGZvcg0KPiA+PiAgeW91cnNlbGYsIGl0 IHdpbGwgYmUgYXBwcmVjaWF0ZWQgYnkgb3RoZXJzLiAtLVJpY2hhcmQgQnJhbnNvbiwgMTk5Ni4N Cj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gIC0tDQo+ID4+DQo+ID4+ICAtLSBNYWdudXMN Cj4gPj4NCj4gPg0KPiA+DQo+ID4NCj4gPiAtLQ0KPiA+IFJhbmRhbGwgR2VsbGVucw0KPiA+IE9w aW5pb25zIGFyZSBwZXJzb25hbDsgICAgZmFjdHMgYXJlIHN1c3BlY3Q7ICAgIEkgc3BlYWsgZm9y IG15c2VsZiBvbmx5DQo+ID4gLS0tLS0tLS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAt LS0tLS0tLS0tLS0tLS0NCj4gPiBBbGwgd2UncmUgc2VlaW5nIGlzIHRoZSBuZWdhdGl2ZSBzaWRl IG9mIG51Y2xlYXIgd2FyLg0KPiA+ICAgIC0tQmFycnkgR29sZHdhdGVyDQo+ID4NCj4gDQo+IA0K PiANCj4gLS0gDQo+IC0tIE1hZ251cw0KPg== From nobody Wed Sep 16 03:55:58 2015 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 8ABB31A6F9F for ; Wed, 16 Sep 2015 03:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wj3olpQA28-z for ; Wed, 16 Sep 2015 03:55:54 -0700 (PDT) Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [207.82.80.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B771A6F84 for ; Wed, 16 Sep 2015 03:55:48 -0700 (PDT) Received: from emea-cam-gw2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-10-3MAizUhoQ02o6SqVZiDbSA-2; Wed, 16 Sep 2015 11:55:46 +0100 Received: from EMEA-CAM-GW3.Emea.Arm.com (10.1.106.86) by emea-cam-gw2.Emea.Arm.com (10.1.105.150) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 16 Sep 2015 11:55:40 +0100 Received: from george.Emea.Arm.com ([fe80::6ccb:73b1:f5c3:796]) by EMEA-CAM-GW3.Emea.Arm.com ([::1]) with mapi; Wed, 16 Sep 2015 11:55:40 +0100 From: Hannes Tschofenig To: "stephen.farrell@cs.tcd.ie" , "magnusn@gmail.com" Date: Wed, 16 Sep 2015 11:55:41 +0100 Thread-Topic: [secdir] Secdir review of draft-ietf-ecrit-additional-data Thread-Index: AdDwUqnlHP38AwnPTnKalfOVbYlGWAAG4svA Message-ID: References:

<2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> In-Reply-To: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB MIME-Version: 1.0 X-MC-Unique: 3MAizUhoQ02o6SqVZiDbSA-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: "randy@qti.qualcomm.com" , "draft-ietf-ecrit-additional-data@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 10:55:57 -0000 SSB0aGluayBCQ1AxOTUgZG9lcyB0aGUgam9iIGZvciB1cy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IHNlY2RpciBbbWFpbHRvOnNlY2Rpci1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2Ygc3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZQ0KU2VudDogMTYgU2VwdGVtYmVy IDIwMTUgMDk6MzgNClRvOiBtYWdudXNuQGdtYWlsLmNvbQ0KQ2M6IHJhbmR5QHF0aS5xdWFsY29t bS5jb207IGRyYWZ0LWlldGYtZWNyaXQtYWRkaXRpb25hbC1kYXRhQHRvb2xzLmlldGYub3JnOyBz ZWNkaXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2VjZGlyXSBTZWNkaXIgcmV2aWV3IG9mIGRy YWZ0LWlldGYtZWNyaXQtYWRkaXRpb25hbC1kYXRhDQoNCg0KDQpPbiBXZWQgU2VwIDE2IDA0OjA5 OjAzIDIwMTUgR01UKzAxMDAsIE1hZ251cyBOeXN0csO2bSB3cm90ZToNCj4gWWVzLCBhdCBsZWFz dCBtYW5kYXRpbmcgVExTIDEuMiBvciBoaWdoZXIgYW5kIHJlY29tbWVuZGluZyBhcyBwZXINCj4g YWJvdmUgc2VlbXMgcmVhc29uYWJsZS4NCj4gVGhlIHJlZmVyZW5jZXMgZm9yIHRoZSBHQ00gc3Vp dGVzIHdvdWxkIGJlIFJGQyA1Mjg4IGFuZCBSRkMgNTI4OS4NCg0KQkNQMTk1IGhhcyByZWNlbnQg cmVjb21tZW5kYXRpb25zIGZvciBtb3N0IFRMUyBvcHRpb25zLiBJJ2Qgc2F5IGl0J2QgYmUgYmVz dCB0byB1c2UgdGhvc2Ugb3IgaWYgbm90IGZpZ3VyZSBvdXQgd2h5IHRoZXkncmUgbm90IGNvcnJl Y3QgZm9yIHRoaXMgY29udGV4dC4NCg0KUy4NCg0KDQo+DQo+IFRoYW5rcyENCj4NCj4gT24gVHVl LCBTZXAgMTUsIDIwMTUgYXQgNzowNiBQTSwgUmFuZGFsbCBHZWxsZW5zDQo+IDxyYW5keUBxdGku cXVhbGNvbW0uY29tPg0KPiB3cm90ZToNCj4NCj4gPiBIaSBNYWdudXMsDQo+ID4NCj4gPiBJIHRo aW5rIHdlIGNhbiBtYW5kYXRlIFRMUyAxLjIgb3IgbGF0ZXIgd2l0aG91dCBhbnkgcHJvYmxlbSwg YW5kIEkNCj4gPiBjYW4gYWRkIHRoYXQgdG8gdGhlIHRleHQgdGhhdCBtYW5kYXRlcyBIVFRQUy4g IEkgZG9uJ3QgdGhpbmsgSSBjYW4NCj4gPiBhZGQgTVRJIGN5cGhlciBzdWl0ZXMgYXQgdGhpcyBz dGFnZSwgYnV0IEkgdGhpbmsgaXQgd291bGQgYmUgT0sgdG8NCj4gPiBhZGQgdGV4dCBzdWNoIGFz ICJpdCBpcyBSRUNPTU1FTkRFRCB0byB1c2Ugb25seSBzdWl0ZXMgdGhhdCBvZmZlcg0KPiA+IFBl cmZlY3QgRm9yd2FyZCBTZWNyZWN5IChQRlMpIGFuZCBhdm9pZCBDaXBoZXIgQmxvY2sgQ2hhaW5p bmcgKENCQykiLCB3aXRoIHlvdXIgbGlzdCBvZiBzdWl0ZXMgYXMgYW4gZXhhbXBsZS4NCj4gPiBX aGF0IGRvIHlvdSB0aGluaz8gIElmIHdlIGdvIHRoaXMgd2F5LCBJJ2QgcHJvYmFibHkgbmVlZCB0 byBhbHNvIGFkZA0KPiA+IGFuIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlIG9yIHR3bzsgd2hhdCBk byB5b3Ugc3VnZ2VzdD8NCj4gPg0KPiA+IEF0IDY6MzkgUE0gLTA3MDAgOS8xNS8xNSwgTWFnbnVz IE55c3Ryw7ZtIHdyb3RlOg0KPiA+DQo+ID4gIEhpIFJhbmRhbGwsDQo+ID4+ICBZZXMsIEkgZ3Vl c3MgaXQgbWF5IGJlIHN1cnByaXNpbmcgLi4uIGJ1dCBJIHdhcyB0aGlua2luZyBtb3JlDQo+ID4+ IGFib3V0IGdldHRpbmcgdGhpcyBlZmZvcnQgaW1wbGVtZW50ZWQgaW4gYW4gZXhwZWRpdGVkIGZh c2hpb24NCj4gPj4gcmF0aGVyIHRoYW4gcG90ZW50aWFsbHkgZGVsYXlpbmcgZHVlIHRvIHRoZSBw b3RlbnRpYWwgaXNzdWVzIChhbHNvDQo+ID4+IHBvaW50ZWQgb3V0IGluIHRoZQ0KPiA+PiBkcmFm dCkgYXJvdW5kIGdldHRpbmcgdGhlIG5lY2Vzc2FyeSB0cnVzdCBhbmNob3JzIGluIHBsYWNlIGJl dHdlZW4NCj4gPj4gUFNBUHMgYW5kIHNlcnZpY2UgcHJvdmlkZXJzIGVuYWJsaW5nIHRoZSBtdXR1 YWwgYXV0aGVudGljYXRpb24uDQo+ID4+DQo+ID4+ICBJdCBtYXkgYmUgZ29vZCB0byBzYXkgc29t ZXRoaW5nIGFib3V0IE1USSBzdWl0ZXMgLSBJIHdvdWxkIHN1Z2dlc3QNCj4gPj4gbWFuZGF0aW5n IHN1cHBvcnQgZm9yIGEgc2V0IG9mIHN1aXRlcyB0aGF0IG9mZmVycyBQRlMgYW5kIGF2b2lkcw0K PiA+PiBDQkMsIGUuZy4sIHNvbWV0aGluZyBsaWtlOg0KPiA+Pg0KPiA+PiAgVExTX0VDREhFX0VD RFNBX1dJVEhfQUVTXzI1Nl9HQ01fU0hBMzg0DQo+ID4+DQo+ID4+ICBUTFNfRUNESEVfRUNEU0Ff V0lUSF9BRVNfMTI4X0dDTV9TSEEyNTYNCj4gPj4NCj4gPj4gIFRMU19FQ0RIRV9SU0FfV0lUSF9B RVNfMjU2X0dDTV9TSEEzODQNCj4gPj4NCj4gPj4gIFRMU19FQ0RIRV9SU0FfV0lUSF9BRVNfMTI4 X0dDTV9TSEEyNTYNCj4gPj4NCj4gPj4gIFRMU19ESEVfUlNBX1dJVEhfQUVTXzI1Nl9HQ01fU0hB Mzg0DQo+ID4+DQo+ID4+ICBUTFNfREhFX1JTQV9XSVRIX0FFU18xMjhfR0NNX1NIQTI1Ng0KPiA+ Pg0KPiA+Pg0KPiA+PiAgSSB3b3VsZCBhbHNvIHN1Z2dlc3QgbWFuZGF0aW5nIFRMUyAxLjIgKG9y IGxhdGVyKSBmb3IgYSBuZXcNCj4gPj4gYXBwbGljYXRpb24gbGlrZSB0aGlzLg0KPiA+PiAgT24g dGhlIGxhc3QgcG9pbnQsIHllcywgaWYgdGhlIHNlcnZpY2UgcHJvdmlkZXIgaXMgaW4gYSBwb3Nz ZXNzaW9uDQo+ID4+IHRvIHZvdWNoIGZvciBvciBzYW5pdHktY2hlY2sgdGhlbiB0aGF0IGNvdWxk IGhlbHAgaW50cm9kdWNlIHJlbGlhYmlsaXR5Lg0KPiA+Pg0KPiA+PiAgQmVzdCwNCj4gPj4NCj4g Pj4NCj4gPj4gIE9uIFR1ZSwgU2VwIDE1LCAyMDE1IGF0IDU6NTggUE0sIFJhbmRhbGwgR2VsbGVu cyA8PG1haWx0bzoNCj4gPj4gcmFuZHlAcXRpLnF1YWxjb21tLmNvbT5yYW5keUBxdGkucXVhbGNv bW0uY29tPiB3cm90ZToNCj4gPj4NCj4gPj4gIEhpIE1hZ251cywNCj4gPj4NCj4gPj4gIFRoYW5r IHlvdSBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzLiAgUGxlYXNlIHNlZSBpbi1saW5lLg0K PiA+Pg0KPiA+PiAgQXQgOToyNiBQTSAtMDcwMCA4LzMxLzE1LCBNYWdudXMgTnlzdHLDtm0gd3Jv dGU6DQo+ID4+DQo+ID4+ICAgSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBv ZiB0aGUgc2VjdXJpdHkNCj4gPj4gZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZp ZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4NCj4gPj4g VGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2Yg dGhlDQo+ID4+IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBX RyBjaGFpcnMgc2hvdWxkDQo+ID4+IHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkg b3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiA+Pg0KPiA+PiAgIFRoaXMgbWVtbyBwcm92aWRl cyBmdW5kYW1lbnRhbCBkYXRhIHN0cnVjdHVyZSBkZWZpbml0aW9ucyBhbmQNCj4gPj4gcHJvY2Vk dXJhbCBydWxlcyBmb3IgcHJvdmlkaW5nIGF1eGlsaWFyeSBpbmZvcm1hdGlvbiB0byBwdWJsaWMN Cj4gPj4gc2VydmljZSBhbnN3ZXJpbmcgcG9pbnRzIChQU0FQcykgd2hlbiBlbWVyZ2VuY3kgY2Fs bHMgYXJlIGJlaW5nIG1hZGUuDQo+ID4+DQo+ID4+DQo+ID4+ICAgVGhpcyByZWFkcyBhcyBhbiBp bXBvcnRhbnQgbWVtbyBhbmQgaGFzIGJlZW4gYXQgbGVhc3QgZml2ZSB5ZWFycw0KPiA+PiBpbiB0 aGUgbWFraW5nLiBJIGRvbid0IGZpbmQgdGhlIFNlY3VyaXR5IChhbmQgUHJpdmFjeSkNCj4gPj4g Q29uc2lkZXJhdGlvbnMgc2VjdGlvbiBsYWNraW5nIHBlciBzZSwgYnV0IGRvIGhhdmUgdGhlc2Ug cXVlc3Rpb25zOg0KPiA+Pg0KPiA+PiAgIC0gV2h5IHJlcXVpcmUgSFRUUFMgZm9yIHRoZSByZWZl cmVuY2UgY2FzZSBidXQgbm90IHRoZSB2YWx1ZSBjYXNlDQo+ID4+IChJIGNhbiB1bmRlcnN0YW5k IHdoeSB5b3UgZG9uJ3QgcmVxdWlyZSBpdCBmb3IgdGhlIHZhbHVlIGNhc2UsIGJ1dA0KPiA+PiBj b3VsZG4ndCBpdCBiZSBhIGNob2ljZSBmb3IgdGhlIFBTQVAgYWxzbyBpbiB0aGUgcmVmZXJlbmNl IGNhc2U/DQo+ID4+IFRoaXMgd291bGQgYWxzbyBzZWVtIHRvIHNpbXBsaWZ5IGR1cmluZyBhbiBp bnRyb2R1Y3RvcnkgcGhhc2Ugd2hlbg0KPiA+PiBhIHdpZGUtc3ByZWFkIFBLSSBzb2x1dGlvbiBp cyBub3QgeWV0IGluIHBsYWNlLik/DQo+ID4+DQo+ID4+DQo+ID4+ICBJJ20gdmVyeSBzdXJwcmlz ZWQgdGhhdCBhIHNlY3VyaXR5IGFyZWEgcGVyc29uIGlzIGFza2luZyB3aHkgd2UNCj4gPj4gZG9u J3QgbWFrZSBUTFMgb3B0aW9uYWwhICBJdCdzIGEgdmFsaWQgcXVlc3Rpb24sIG9mIGNvdXJzZSwg anVzdA0KPiA+PiBzdXJwcmlzaW5nIGluIHRoaXMgY29udGV4dC4gIEJlY2F1c2Ugb2YgdGhlIGxp bWl0ZWQgc2NvcGUgb2YgdGhlDQo+ID4+IGRvY3VtZW50LCBzcGVjaWZpY2FsbHkgZW1lcmdlbmN5 IHNlcnZpY2VzLCBhbmQgZ2l2ZW4gdGhhdCB0aGUNCj4gPj4gZGVyZWZlcmVuY2luZyBlbnRpdGll cyB3aWxsIGJlIFBTQVBzIGFuZCBvdGhlciByZXNwb25kZXJzIHRoYXQgaGF2ZQ0KPiA+PiB1cGdy YWRlZCB0byBzdXBwb3J0IG5leHQtZ2VuZXJhdGlvbiwgd2UgZmVsdCB0aGF0IGl0IHdhcyByZWFz b25hYmxlDQo+ID4+IHRvIHJlcXVpcmUgdGhlIHVzZSBvZiBUTFMgYW5kIGNsaWVudC1zaWRlIGNl cnRpZmljYXRlcyBmb3IgZGVyZWZlcmVuY2luZy4NCj4gPj4NCj4gPj4gICAtIFdoZW4gSFRUUFMg aXMgcmVxdWlyZWQsIEkgYXNzdW1lIHRoZSBQU0FQIG5lZWRzIGEgY2xpZW50DQo+ID4+IGNlcnRp ZmljYXRlDQo+ID4+IC0gaS5lLiwgdGhhdCB0aGUgbXV0dWFsIGF1dGggb3B0aW9uIG9mIFRMUyBp cyBiZWluZyB1c2VkLCBwZXJoYXBzDQo+ID4+IHRoaXMgbmVlZHMgdG8gYmUgY2xhcmlmaWVkPw0K PiA+Pg0KPiA+Pg0KPiA+PiAgWWVzLCBnb29kIHBvaW50LiAgSSBhZGRlZCBjbGFyaWZ5aW5nIHRl eHQgaW4gcmVzcG9uc2UgdG8gQmVuJ3MgY29tbWVudHMuDQo+ID4+DQo+ID4+ICAgLSBXYXMgdGhl cmUgYW55IGRpc2N1c3Npb24gYXJvdW5kIGFueSBNVEkgVExTIGNpcGhlciBzdWl0ZXM/DQo+ID4+ DQo+ID4+DQo+ID4+ICBObywgdGhpcyB3YXMgbmV2ZXIgZGlzY3Vzc2VkIGFzIGZhciBhcyBJIGNh biByZWNhbGwuDQo+ID4+DQo+ID4+ICAgLSBJIGFzc3VtZSB0aGVyZSdzIG5vdCBvbmx5IGEgcHJp dmFjeSBpc3N1ZSBidXQgYWxzbyBhIHBvdGVudGlhbA0KPiA+PiBzcG9vZmluZyBpc3N1ZSAtIHRo ZSBQU0FQcyBkb24ndCB3YW50IHRvIGJlIG92ZXJseSBzdXNjZXB0aWJsZSB0bw0KPiA+PiBzcG9v ZmVkIGNhbGxzIChhbHRob3VnaCB0aGV5IHJhdGhlciBlcnIgb24gdGhlIHNpZGUgb2Ygc2FmZXR5 LCBvZg0KPiA+PiBjb3Vyc2UuIFRodXMsIHNob3VsZCBpbnRlZ3JpdHkgb2YgaW5mb21hdGlvbiBp biB0aGUgZGlyZWN0IGNhc2UgYmUNCj4gPj4gY29uc2lkZXJlZD8gSS5lLiwgYnkgbi93IG9yIHNl cnZpY2UgcHJvdmlkZXJzIGluIHRoZSBwYXRoIHRvIHRoZQ0KPiA+PiBQU0FQIHZvdWNoaW5nIGZv ciB0aGUgaW5mb3JtYXRpb24/DQo+ID4+DQo+ID4+DQo+ID4+ICBZb3UncmUgYWJzb2x1dGVseSBj b3JyZWN0IHRoYXQgUFNBUHMgYXJlIGNvbmNlcm5lZCBhYm91dCBzcG9vZmVkDQo+ID4+IChhbmQg b3RoZXIgZmFsc2UpIGNhbGxzIGJ1dCB3aWxsIGdlbmVyYWxseSBlcnIgYnkgdGFraW5nIGEgY2Fs bCBhbmQNCj4gPj4gYXNraW5nIHRoZSBjYWxsZXIgZm9yIGluZm9ybWF0aW9uLiAgSW4gZ2VuZXJh bCwgUFNBUHMgcHJlZmVyDQo+ID4+IGluZm9ybWF0aW9uIHRoYXQgY29tZXMgZnJvbSBrbm93biBh bmQgdHJ1c3RlZCBwcm92aWRlcnMgKHRoZSBtYWpvcg0KPiA+PiBjYXJyaWVycykuIEFyZSB5b3Ug c3VnZ2VzdGluZyBhIG1lY2hhbmlzbSBieSB3aGljaCBwcm92aWRlcnMgdmVyaWZ5IHRoZSBpbmZv cm1hdGlvbiBwcm92aWRlZCBieSB0aGUgZGV2aWNlPw0KPiA+PiBGb3IgbG9jYXRpb24gaW5mb3Jt YXRpb24sIHRoZXJlIGFyZSBkaXNjdXNzaW9ucyBpbiBvdGhlciBTRE9zIGFib3V0DQo+ID4+IHNh bml0eS1jaGVja2luZyBkZXZpY2UtcHJvdmlkZWQgaW5mb3JtYXRpb24gKGxvY2F0aW9uIG9yIFdp LUZpIEFQcykNCj4gPj4gYWdhaW5zdCBuZXR3b3JrLWtub3duIGluZm9ybWF0aW9uIChtYWNybyBj ZWxsIHRvIHdoaWNoIHRoZSBkZXZpY2UgaXMgYXNzb2NpYXRlZCkuDQo+ID4+DQo+ID4+ICAtLQ0K PiA+PiAgUmFuZGFsbCBHZWxsZW5zDQo+ID4+ICBPcGluaW9ucyBhcmUgcGVyc29uYWw7ICAgIGZh Y3RzIGFyZSBzdXNwZWN0OyAgICBJIHNwZWFrIGZvciBteXNlbGYgb25seQ0KPiA+PiAgLS0tLS0t LS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0tLS0tLS0gIEluIGEgc2Vu c2UsDQo+ID4+IHdoZW4gd2Ugc3RhcnRlZCBWaXJnaW4gQXRsYW50aWMsIEkgd2FzIHRyeWluZyB0 byBjcmVhdGUgIGFuIGFpcmxpbmUNCj4gPj4gZm9yIG15c2VsZi4gSWYgeW91IHRyeSB0byBidWls ZCB0aGUgcGVyZmVjdCBhaXJsaW5lIGZvciAgeW91cnNlbGYsDQo+ID4+IGl0IHdpbGwgYmUgYXBw cmVjaWF0ZWQgYnkgb3RoZXJzLiAtLVJpY2hhcmQgQnJhbnNvbiwgMTk5Ni4NCj4gPj4NCj4gPj4N Cj4gPj4NCj4gPj4NCj4gPj4gIC0tDQo+ID4+DQo+ID4+ICAtLSBNYWdudXMNCj4gPj4NCj4gPg0K PiA+DQo+ID4NCj4gPiAtLQ0KPiA+IFJhbmRhbGwgR2VsbGVucw0KPiA+IE9waW5pb25zIGFyZSBw ZXJzb25hbDsgICAgZmFjdHMgYXJlIHN1c3BlY3Q7ICAgIEkgc3BlYWsgZm9yIG15c2VsZiBvbmx5 DQo+ID4gLS0tLS0tLS0tLS0tLS0gUmFuZG9tbHkgc2VsZWN0ZWQgdGFnOiAtLS0tLS0tLS0tLS0t LS0gQWxsIHdlJ3JlDQo+ID4gc2VlaW5nIGlzIHRoZSBuZWdhdGl2ZSBzaWRlIG9mIG51Y2xlYXIg d2FyLg0KPiA+ICAgIC0tQmFycnkgR29sZHdhdGVyDQo+ID4NCj4NCj4NCj4NCj4gLS0NCj4gLS0g TWFnbnVzDQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc2VjZGlyIG1haWxpbmcgbGlzdA0Kc2VjZGlyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NlY2Rpcg0Kd2lraTogaHR0cDovL3Rvb2xzLmlldGYub3Jn L2FyZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJSZXZpZXcNCg0KLS0gSU1QT1JUQU5UIE5PVElDRTog VGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlk ZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0 IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55 IG1lZGl1bS4gIFRoYW5rIHlvdS4NCg0KQVJNIExpbWl0ZWQsIFJlZ2lzdGVyZWQgb2ZmaWNlIDEx MCBGdWxib3VybiBSb2FkLCBDYW1icmlkZ2UgQ0IxIDlOSiwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5k ICYgV2FsZXMsIENvbXBhbnkgTm86ICAyNTU3NTkwDQpBUk0gSG9sZGluZ3MgcGxjLCBSZWdpc3Rl cmVkIG9mZmljZSAxMTAgRnVsYm91cm4gUm9hZCwgQ2FtYnJpZGdlIENCMSA5TkosIFJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAmIFdhbGVzLCBDb21wYW55IE5vOiAgMjU0ODc4Mg0K From nobody Wed Sep 16 09:14:31 2015 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 6E70E1A0275 for ; Wed, 16 Sep 2015 09:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 o5iegzKJqp0N for ; Wed, 16 Sep 2015 09:14:28 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F101A026E for ; Wed, 16 Sep 2015 09:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442420069; x=1473956069; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=3MlQFPYuNdznl48u/LFaTcwSATG1kJjFqHkJaYaNDhY=; b=O1KJwpFLcMq3zxNHrSUCRJ1qg8xgqYksJnrfUJmDzxMvKdIaXqSmZJgJ 2Lr+mxVhzPey2OEaStux8/dEDR44rQZvFUaFSNu9lzdjy0x9Esn+QBG/L oAIk7vfdYnauOJQIhs8NkOcXx4PrKTk0uAoai7trOAdNX+5pAC+SqoKUA s=; X-IronPort-AV: E=McAfee;i="5700,7163,7925"; a="97973667" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Sep 2015 09:14:09 -0700 X-IronPort-AV: E=Sophos;i="5.17,540,1437462000"; d="scan'208";a="1055867249" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Sep 2015 09:14:08 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 16 Sep 2015 09:14:07 -0700 Message-ID: In-Reply-To: <2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> References:

<2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> X-Mailer: Eudora for Mac OS X Date: Wed, 16 Sep 2015 09:14:05 -0700 To: , , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 16:14:29 -0000 At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote: > On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=F6m wrote: >> Yes, at least mandating TLS 1.2 or higher and recommending as per above >> seems reasonable. >> The references for the GCM suites would be RFC 5288 and RFC 5289. > > BCP195 has recent recommendations for most TLS=20 > options. I'd say it'd be best to use those or=20 > if not figure out why they're not correct for=20 > this context. Just to be clear: are you suggesting that we replace text suggested by Magnu= s: TLS MUST be version 1.2 or later. It is RECOMMENDED to use only cypher suites that offer Perfect Forward Secrecy (PFS) and avoid Cipher Block Chaining (CBC), for example, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. With this: TLS MUST be version 1.2 or later. It is RECOMMENDED follow [BCP195]. Note that BCP 195 does not address CBC (but does=20 discuss PFS). I just want to be clear before=20 making the change, so please confirm that this=20 works. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- If the odds are a million to one against something occurring, chances are 50-50 it will. From nobody Wed Sep 16 10:18:01 2015 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 B4C2D1A21AB for ; Wed, 16 Sep 2015 10:02:42 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 QUxoxY6TDQFU for ; Wed, 16 Sep 2015 10:02:39 -0700 (PDT) Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) by ietfa.amsl.com (Postfix) with ESMTP id C1D451A21A4 for ; Wed, 16 Sep 2015 10:02:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by chessie.everett.org (Postfix) with SMTP id BD18BB82B for ; Wed, 16 Sep 2015 17:02:38 +0000 (UTC) Received: from [10.2.64.185] (unknown [198.22.153.36]) by chessie.everett.org (Postfix) with ESMTPSA id 738CBB80E; Wed, 16 Sep 2015 17:02:36 +0000 (UTC) References: To: Sean Turner , draft-ietf-ntp-extension-field.all@tools.ietf.org, The IESG , secdir@ietf.org From: Danny Mayer Message-ID: <55F9A0AA.90300@pdmconsulting.net> Date: Wed, 16 Sep 2015 13:02:34 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Sep 16 17:02:38 2015 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 6780,55f9a0ae829931401138963 Archived-At: X-Mailman-Approved-At: Wed, 16 Sep 2015 10:18:00 -0700 Subject: Re: [secdir] secdir review of draft-ietf-ntp-extension-field X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mayer@pdmconsulting.net List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 17:02:42 -0000 Sorry for the delay in responding. I've been up to my ears in problems. See my feedback below. Danny On 8/27/2015 9:08 AM, Sean Turner wrote: > Fear not as this is just the secdir review! > > 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. > > draft summary: This draft updates NTPv4 Protocol and Algorithm > Specification (aka RFC 5905) s7.5, which is the section that > describes extension fields, and to paraphrase the: clarify the > relationship between extension fields and MACs and define the > behavior of a host that receives an unknown extension field. Note > that when comparing the �OLD� section to RFC 5905, you�ll should note > that the �OLD� text incorporates a verified errata > (http://www.rfc-editor.org/errata_search.php?eid=3627). The �NEW" > text requires things like when defining an extension the definition > must specify whether it must be MACed or not, the MTI MAC, the length > of the MAC, etc. > > secdir status summary: I need to clarify something in my mind, which > I hope fall into the �you missed that in this spec over here� or the > �these are *NOT* the droids you�re looking for� bucket, before I can > say "ready with nits": > > 0) 7.5.1.1 says an extension can support multiple MACs, that the > extension�s document defines the MTI algorithm & MAC length, and that > if more than one algorithm is allowed the extension includes an > indication of which one was actually used; all great. But, I�m > trying to figure out how that fits with RFC 5905: > > - In s7.3, I see "dgst (128)� in f8 > > - In s9.2, I see "There is no specific requirement for > authentication; however, if authentication is implemented, then the > MD5-keyed hash algorithm described in [RFC1321] must be supported� > > Doesn�t s7.3 limit the MAC to HMAC-MD5 and the length to 128? I mean > if you�re going to allow an extension to override s9.2 that seems > like something worth noting in say the abstract/intro. Now that you bring this up, I should tell you that the reference implementation implements MD5 and NOT HMAC_MD5 but it also implements DES (not 3DES) and SHA-1! None of this is documented of course and the packets are inspected for which algorithm to use based on the size of the MAC field! Since there is no way to know from the packet whether there is one or more extension fields or if there is a MAC present the code ends up guessing which in turn limits the size that you can give an extension field. This all leads to the strange wording in section 7.5.1.3 and 7.5.1.4 in the draft and is necessary to detect the presence of a MAC. We probably need to update the dgest field in RFC5905 to make it clear that it can have multiple lengths depending on the algorithm used. On the other hand I would prefer to get rid of the MAC and turn it into an extension field, assuming that the NTS/CMS scheme is not used. The advantages of that is obvious especially as no guessing would be required and we could specify the algorithm to use and you could have multiple MAC extension fields that would cover different parts of the packet. > > Thinking there�s got to be a reason for this I went off and looked at > the other NTP WG drafts � after finding the NTS & CMS-based specs, > are the changes proposed in this draft to to allow an NTP packet blob > that doesn�t use the MAC mechanism described in RFC 5905 but instead > use the NTS/CMS �scheme�, i.e., an NTP extension that is a CMS > object, with no MAC in the 5905 sense - the CMS object instead of the > NTP MAC field gives you the authentication? > > 1) s7.5.1.2 seems to be saying if extension A specifies alg X, and > extension B specifies alg X and Y, and extension C specifies alg Y > then extension A and B can appear together as can extension B and C, > but A and C can�t appear together? Sounds great, but what if A and > C do appear together what happens? I think that the draft makes it clear that you cannot have that case since it requires that the MAC use one algorithm. "multiple extension fields that require a MAC they MUST all require use of the same algorithm and MAC length" > > 2) Still on 7.5.12: "If there are multiple extension fields that > require a MAC they MUST all require use of the same algorithm and MAC > length.� > > So if I specify extension A with X as the MUST, and extension B with > X as the SHOULD and Y as the MUST, then I can�t include both > extension A and B? Extension A requires X, but extension B requires > Y. That's right. > > 3) s7.5.1.3: What�s the 24-octet limitation based on? > The MAC guessing game. See the insanity above. > Minor: > > 0) The new s7.5 says: > > The Field Type field is specific to the defined function and is not > elaborated here. If a �. > > 0.a) I think what you�re trying to say is that the Field Type field > is defined in an IANA registry and it�s length and value are defined > by the document referred to by the registry? > Yes. > 0.b) Neither RFC5905 nor this document specify how the padding is > done. Is padding determined by the document referred to by the field > type? I.e., can I do padding with all 1s and somebody else do it > with all zeros? > It shouldn't matter. If the extension field specification needs it to be specific it should state that in the specification. > Maybe: > > The Field Type field defines the extension�s semantics as well as the > extension�s syntax, i.e., length, value, and padding. This > document defines no extensions. > Yes. > If a � > > Nits: > > 0) process wise: RFC 5905 has a lot of other errata; some marked > verified some marked HFDU. Since this document updates RFC 5905, did > the WG consider including the other verified errata and resolving > whether the errata marked HFDU were worth including? I�ll also > readily admit that this could have been found in the WG archives, but > I didn�t search them. > We didn't consider this. We were only concentrating of the extension field specification and MAC. This was never meant as a proposed REF5905bis. > 1) s3: Might be worth noting that the �OLD� text includes the errata > text. I can�t remember whether you can normatively or informatively > point to errata (sorry). > > 2) The new s7.5 includes: > > If a host receives an extension field with an unknown Field Type > value � > > I was like hmm there�s a Field Type value, which is # that goes in > Field Type and there�s the Value field for the Field Type. Maybe > dropping �value� from the quoted sentence makes it clearer that > you�re really talking about the # that goes in Field Type and not the > Value? It's supposed to be the value of the field type. > > 2) s5: Might be worth a reference to the NTP Extension Field Type > IANA registry. Though obviously folks reading the base spec and > extensions are going to find it though. > true. > spt > > PS - RFC 5905 KoD packets are my favorite packets now. > From nobody Wed Sep 16 10:31:43 2015 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 88D911B40AE for ; Wed, 16 Sep 2015 10:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 qBdLzmnMS_Ya for ; Wed, 16 Sep 2015 10:31:41 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c: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 077B01B40AD for ; Wed, 16 Sep 2015 10:31:41 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so84210990wic.1 for ; Wed, 16 Sep 2015 10:31:39 -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:content-type; bh=Wb50QZFsIvSZweBzvo7wIuFxAwScvzyeNDp+Qsi4D7M=; b=LHGqhsYV/bP9dU1y98LBniOGEJeKU9zwpaPAlv3Z9f6n1OBAU9TvriUhgPTHsX/SpK XhMTpicA00JszJ+nn0rDq1pBpX5QRPNwn/UyS3qy4GFMw7w0osG9MlEzMUAresVrZEpS nz1CoKrx8rnLC1tYIETXaNNLqPSfRW8HPyd3cOzsvdTnjGD17+5MZhwpLCp17y2/P2t2 RMGhm7iaU4jfElXpV/qwK9r+GBjA6jhv6oIgmHTjXnwB1voqoE0VsswNKdEEwkBxQ3l2 d5pYLXIsg3oKZFJFpQnejX4FfARvJq7DMwKZuBDq/siD17BWrABdhhV20WdGSXLKA5+v 9YvQ== MIME-Version: 1.0 X-Received: by 10.194.205.68 with SMTP id le4mr26213744wjc.74.1442424699516; Wed, 16 Sep 2015 10:31:39 -0700 (PDT) Received: by 10.27.130.200 with HTTP; Wed, 16 Sep 2015 10:31:39 -0700 (PDT) In-Reply-To: References:

<2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> Date: Wed, 16 Sep 2015 10:31:39 -0700 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: Randall Gellens Content-Type: multipart/alternative; boundary=001a11c33fa8d47f29051fe0ab14 Archived-At: Cc: "secdir@ietf.org" , draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 17:31:42 -0000 --001a11c33fa8d47f29051fe0ab14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just a personal remark: BCP 195 still allows earlier versions of TLS, even TLS 1.0. I felt that for a new application like this, one could go stronger. Maybe a combo - where you rely on BCP 195 but mandate TLS 1.2 (or later)? On Wed, Sep 16, 2015 at 9:14 AM, Randall Gellens wrote: > At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote: > > On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=C3=B6m wrote: >> >>> Yes, at least mandating TLS 1.2 or higher and recommending as per abov= e >>> seems reasonable. >>> The references for the GCM suites would be RFC 5288 and RFC 5289. >>> >> >> BCP195 has recent recommendations for most TLS options. I'd say it'd be >> best to use those or if not figure out why they're not correct for this >> context. >> > > Just to be clear: are you suggesting that we replace text suggested by > Magnus: > > TLS MUST be version 1.2 or later. It is RECOMMENDED to use only > cypher suites that offer Perfect Forward Secrecy (PFS) and avoid > Cipher Block Chaining (CBC), for example, > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. > > With this: > > TLS MUST be version 1.2 or later. It is RECOMMENDED follow > [BCP195]. > > > Note that BCP 195 does not address CBC (but does discuss PFS). I just > want to be clear before making the change, so please confirm that this > works. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > If the odds are a million to one against something occurring, chances > are 50-50 it will. > --=20 -- Magnus --001a11c33fa8d47f29051fe0ab14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Just a personal remark: BCP 195 still allows earlier versi= ons of TLS, even TLS 1.0. I felt that for a new application like this, one = could go stronger. Maybe=C2=A0 a combo - where you rely on BCP 195 but mand= ate TLS 1.2 (or later)?

On Wed, Sep 16, 2015 at 9:14 AM, Randall Gellens <randy@q= ti.qualcomm.com> wrote:

At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote:

=C2=A0On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=C3=B6m wrote:

=C2=A0Yes, at least mandating TLS 1.2 or higher and recommending as per abo= ve
=C2=A0seems reasonable.
=C2=A0The references for the GCM suites would be RFC 5288 and RFC 5289.

=C2=A0BCP195 has recent recommendations for most TLS options. I'd say i= t'd be best to use those or if not figure out why they're not corre= ct for this context.

Just to be clear: are you suggesting that we replace text suggested by Magn= us:

=C2=A0 =C2=A0TLS MUST be version 1.2 or later.=C2=A0 It is RECOMMENDED to u= se only
=C2=A0 =C2=A0cypher suites that offer Perfect Forward Secrecy (PFS) and avo= id
=C2=A0 =C2=A0Cipher Block Chaining (CBC), for example,
=C2=A0 =C2=A0TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
=C2=A0 =C2=A0TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
=C2=A0 =C2=A0TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
=C2=A0 =C2=A0TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
=C2=A0 =C2=A0TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
=C2=A0 =C2=A0TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289].

With this:

=C2=A0 =C2=A0TLS MUST be version 1.2 or later.=C2=A0 It is RECOMMENDED foll= ow
=C2=A0 =C2=A0[BCP195].

Note that BCP 195 does not address CBC (but does discuss PFS).=C2=A0 I just= want to be clear before making the change, so please confirm that this wor= ks.

--
Randall Gellens
Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I speak= for myself only
-------------- Randomly selected tag: ---------------
If the odds are a million to one against something occurring, chances
are 50-50 it will.

-- Magnus

--001a11c33fa8d47f29051fe0ab14-- From nobody Wed Sep 16 10:58:08 2015 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 2E2FE1A7014 for ; Wed, 16 Sep 2015 10:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.986 X-Spam-Level: X-Spam-Status: No, score=-5.986 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, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=0.723, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Zx9ATeVvgkVd for ; Wed, 16 Sep 2015 10:58:04 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF24B1A6FFE for ; Wed, 16 Sep 2015 10:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442426284; x=1473962284; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=n4b4XZHQOvSaA15lJxspBMv6Z07zvbkhdgiIpEJNRiE=; b=uLtfeES28TE5ElLvFOtpCjUXLEpQe6v36MNmzZzkWUcz69nFkGklGz0C nk2SAuVDnx8wjcf2JRieqslmi7oFvQfdWK4XrF3kwkw1ZVk6yYEpqoulg LkgQfl47pD81fWmK2eWhxnW/6gSx+BsSDYKcdqqzYhDtCWe3rozuDVcUH U=; X-IronPort-AV: E=McAfee;i="5700,7163,7926"; a="97979683" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Sep 2015 10:58:04 -0700 X-IronPort-AV: E=Sophos;i="5.17,540,1437462000"; d="scan'208,217";a="1002870692" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Sep 2015 10:58:04 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 16 Sep 2015 10:58:03 -0700 Message-ID: In-Reply-To: References:

<2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie>

X-Mailer: Eudora for Mac OS X Date: Wed, 16 Sep 2015 10:57:59 -0700 To: Magnus =?iso-8859-1?Q?Nystr=F6m?= From: Randall Gellens MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: "secdir@ietf.org" , draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 17:58:06 -0000 Re: [secdir] Secdir review of draft-ietf-ecrit-additional-

At 10:31 AM -0700 9/16/15, Magnus Nystr=F6m wrote:

Just a personal remark: BCP 195 still allows earlier versions of TLS, even TLS 1.0. I felt that for a new application like this, one could go stronger. Maybe a combo - where you rely on BCP 195 but mandate TLS 1.2 (or later)?

And not mention CBC?

On Wed, Sep 16, 2015 at 9:14 AM, Randall Gellens <randy@qti.qualcomm.com> wrote:

At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote:

On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=F6m wrote:

Yes, at least mandating TLS 1.2 or higher and recommending as per above
seems reasonable.
The references for the GCM suites would be RFC 5288 and RFC 5289.

BCP195 has recent recommendations for most TLS options. I'd say it'd be best to use those or if not figure out why they're not correct for this context.

Just to be clear: are you suggesting that we replace text suggested by Magnus:

TLS MUST be version 1.2 or later. It is RECOMMENDED to use only
cypher suites that offer Perfect Forward Secrecy (PFS) and avoid
Cipher Block Chaining (CBC), for example,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289].

With this:

TLS MUST be version 1.2 or later. It is RECOMMENDED follow
[BCP195].

Note that BCP 195 does not address CBC (but does discuss PFS). I just want to be clear before making the change, so please confirm that this works.

--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly selected tag: ---------------
If the odds are a million to one against something occurring, chances
are 50-50 it will.

--

-- Magnus

--

Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly selected tag: ---------------
Between two evils, I always pick the one I never tried before.
--Mae West.

From nobody Wed Sep 16 11:02:41 2015 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 9186C1B40CE for ; Wed, 16 Sep 2015 11:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 34cBcKHnFh3l for ; Wed, 16 Sep 2015 11:02:37 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 69D031B40B9 for ; Wed, 16 Sep 2015 11:02:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8435122405FB; Wed, 16 Sep 2015 20:02:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6rsYsiFrzV1; Wed, 16 Sep 2015 20:02:36 +0200 (CEST) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id A30DF22404D9; Wed, 16 Sep 2015 20:02:35 +0200 (CEST) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Sep 2015 14:02:33 -0400 Message-Id: <6FD706E2-FEAC-4EF2-BCE8-43D16095BB11@deployingradius.com> To: secdir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: draft-ietf-ippm-owamp-registry@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-ippm-owamp-registry-03 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, 16 Sep 2015 18:02:39 -0000 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. This document requests IANA allocation of registries for OWAMP. As = such, it has minimal security impact. One practical note is the request to assign an "Experimentation" = OWAMP-Control Command Number. Experience shows that such numbers are = either never used, or used as experiments... which then get widely = deployed before standards action catches up to practical needs. It may be good to add some discussion as to *how* experiments are = done, and how experiments can transition from the "Experimentation" = number to a standard number. One suggestion would be to change the label from "Experimentation" to = "Site-Local". That would still allow sites to experiment with = OWAMP-Control commands, but would make it clearer that such = experimentation is only for the local site, and MUST NOT be used in a = wider context.= From nobody Wed Sep 16 11:19:17 2015 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 EE72F1A87E9 for ; Wed, 16 Sep 2015 11:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 ZzIaEpJgH1Ru for ; Wed, 16 Sep 2015 11:19:13 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 4BD0E1A87C9 for ; Wed, 16 Sep 2015 11:19:13 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so82289489wic.0 for ; Wed, 16 Sep 2015 11:19:11 -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:content-type; bh=sJYrtsU3RpzFpwTFYeJyDKCjH+Sm4TgNKgzDKMEfZCs=; b=qviTXQ9eQstrOX4baepNb9jtll6mRVuJmcWKJ/R8silLAr6jldpPKP+N4TsAMOutwc 4Z/k/EiqpjKgOHrHcdZ6UbMU7smyZqDyTvr1XliGrnR3/h76QAqAxe+KMaygho2y20Al aSAN8NLJzl5wj03xCtita2uQ6DDrpZsrIoy49Mq2eAqWXtPUPNrFJFvuwTkDSyTjcwzB w4O4WtJ3Q/s5Ap10X3EbuRTeGNkOY8Y/uQatLsxdAoQu66A6i4eveFbDXTddWMsUZuMI rSqCzQISpGH/UjZaR98CPzUIm4SZr+X3svu1Quu3O/TxctKiB/WaMPdKHa9e7LMfqOOG cw+A== MIME-Version: 1.0 X-Received: by 10.194.205.68 with SMTP id le4mr26673021wjc.74.1442427551870; Wed, 16 Sep 2015 11:19:11 -0700 (PDT) Received: by 10.27.130.200 with HTTP; Wed, 16 Sep 2015 11:19:11 -0700 (PDT) In-Reply-To: References:

<2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie>

Date: Wed, 16 Sep 2015 11:19:11 -0700 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: Randall Gellens Content-Type: multipart/alternative; boundary=001a11c33fa8d7f419051fe1559c Archived-At: Cc: "secdir@ietf.org" , draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 18:19:15 -0000 --001a11c33fa8d7f419051fe1559c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, yes, also mention no CBC On Wed, Sep 16, 2015 at 10:57 AM, Randall Gellens wrote: > At 10:31 AM -0700 9/16/15, Magnus Nystr=C3=B6m wrote: > > Just a personal remark: BCP 195 still allows earlier versions of TLS, eve= n > TLS 1.0. I felt that for a new application like this, one could go > stronger. Maybe a combo - where you rely on BCP 195 but mandate TLS 1.2 > (or later)? > > > > And not mention CBC? > > > > On Wed, Sep 16, 2015 at 9:14 AM, Randall Gellens > wrote: > > At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote: > > On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=C3=B6m wrote: > > Yes, at least mandating TLS 1.2 or higher and recommending as per above > seems reasonable. > The references for the GCM suites would be RFC 5288 and RFC 5289. > > > BCP195 has recent recommendations for most TLS options. I'd say it'd be > best to use those or if not figure out why they're not correct for this > context. > > > Just to be clear: are you suggesting that we replace text suggested by > Magnus: > > TLS MUST be version 1.2 or later. It is RECOMMENDED to use only > cypher suites that offer Perfect Forward Secrecy (PFS) and avoid > Cipher Block Chaining (CBC), for example, > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. > > With this: > > TLS MUST be version 1.2 or later. It is RECOMMENDED follow > [BCP195]. > > > Note that BCP 195 does not address CBC (but does discuss PFS). I just > want to be clear before making the change, so please confirm that this > works. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > If the odds are a million to one against something occurring, chances > are 50-50 it will. > > > > > -- > > -- Magnus > > > > > -- > > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > Between two evils, I always pick the one I never tried before. > --Mae West. > --=20 -- Magnus --001a11c33fa8d7f419051fe1559c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sorry, yes, also mention no CBC

On Wed, Sep 16, 2015 at 10:57 AM, Rand= all Gellens <randy@qti.qualcomm.com> wrote:

At 10:31 AM -0700 9/16/15, Magnus Nystr=C3=B6m wrote:

Just a personal remark: BCP 195 still allows earlier versions of TLS, even TLS 1.0. I felt that for a new application like this, one could go stronger. Maybe=C2=A0 a combo - where you rely on BCP 195 but mandate TLS 1.2 (or later)?

And not mention CBC?

On Wed, Sep 16, 2015 at 9:14 AM, Randall Gellens <ran= dy@qti.qualcomm.com> wrote:

At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote:

=C2=A0On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=C3=B6m wrote:

=C2=A0Yes, at least mandating TLS 1.2 or higher and recommending as per above
=C2=A0seems reasonable.
=C2=A0The references for the GCM suites would be RFC 5288 and RFC 5289.

=C2=A0BCP195 has recent recommendations for most TLS options. I'd say it'd be best to use those or if not figure out why they're not corr= ect for this context.

Just to be clear: are you suggesting that we replace text suggested by Magnus:

=C2=A0 =C2=A0TLS MUST be version 1.2 or later.=C2=A0 It is RECOMMENDED to use only
=C2=A0 =C2=A0cypher suites that offer Perfect Forward Secrecy (PFS) and avoid
=C2=A0 =C2=A0Cipher Block Chaining (CBC), for example,
=C2=A0 =C2=A0TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
=C2=A0 =C2=A0TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
=C2=A0 =C2=A0TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
=C2=A0 =C2=A0TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
=C2=A0 =C2=A0TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
=C2=A0 =C2=A0TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289].

With this:

=C2=A0 =C2=A0TLS MUST be version 1.2 or later.=C2=A0 It is RECOMMENDED follow
=C2=A0 =C2=A0[BCP195].

Note that BCP 195 does not address CBC (but does discuss PFS).=C2=A0 I just want to be clear before making the change, so please confirm that this works.

--
Randall Gellens
Opinions are personal;=C2=A0=C2=A0=C2=A0 facts are suspect;=C2=A0=C2=A0=C2=A0 I speak for myself only
-------------- Randomly selected tag: ---------------
If the odds are a million to one against something occurring, chances
are 50-50 it will.

--

-- Magnus

--=20

Randall Gellens
Opinions are personal;=C2=A0=C2=A0=C2=A0 facts are suspect;=C2=A0=C2=A0=C2=A0 I speak for myself only
-------------- Randomly selected tag: ---------------

Between two evils, I always pick the one I never tried before.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0--Mae West.

-- Magnus

--001a11c33fa8d7f419051fe1559c-- From nobody Wed Sep 16 11:25:45 2015 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 7E8A21A8AF5 for ; Wed, 16 Sep 2015 11:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.711 X-Spam-Level: X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 x9M6wOAxPhrX for ; Wed, 16 Sep 2015 11:25:43 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7AB1A8AB2 for ; Wed, 16 Sep 2015 11:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442427943; x=1473963943; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=TiouLSSqjy1DmCbzJTYZdGcpoWmnIIvzh9L0RIsTArw=; b=GaKFXPIHYdDSY5p1Kysg4Jfo1kkAEpHfG4tp9COriQCVIUGIupjCGi1e EwEr4B1a56BY1tzzXIH2HJ/bsARK3jNK32rWrPPxd1og9HBEwC4wR5GfX ZniUnOiAGBiAuiAP2ygAyW07VIbxfE0wWGUM01SJZdKB/9MMKzQTLbOUI 8=; X-IronPort-AV: E=McAfee;i="5700,7163,7926"; a="97981420" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 16 Sep 2015 11:25:42 -0700 X-IronPort-AV: E=Sophos;i="5.17,540,1437462000"; d="scan'208";a="33681572" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Sep 2015 11:25:41 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 16 Sep 2015 11:25:40 -0700 Message-ID: In-Reply-To: References:

<2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie>

X-Mailer: Eudora for Mac OS X Date: Wed, 16 Sep 2015 11:25:37 -0700 To: Magnus =?iso-8859-1?Q?Nystr=F6m?= From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01E.na.qualcomm.com (10.85.0.31) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: "secdir@ietf.org" , draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 18:25:44 -0000 How do we want to word this? The original wording based on your suggestions was: TLS MUST be version 1.2 or later. It is RECOMMENDED to use only cypher suites that offer Perfect Forward Secrecy (PFS) and avoid Cipher Block Chaining (CBC), for example, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. The next revision was: TLS MUST be version 1.2 or later. It is RECOMMENDED follow [BCP195]. So how to we want to work CBC in to this? And if=20 we do, does that mean we need to also mention the=20 specific cypher suites? At 11:19 AM -0700 9/16/15, Magnus Nystr=F6m wrote: > Sorry, yes, also mention no CBC > > On Wed, Sep 16, 2015 at 10:57 AM, Randall=20 > Gellens=20 > <randy@qti.qualcomm.com>=20 > wrote: > > At 10:31 AM -0700 9/16/15, Magnus Nystr=F6m wrote: > >> Just a personal remark: BCP 195 still allows=20 >> earlier versions of TLS, even TLS 1.0. I felt=20 >> that for a new application like this, one=20 >> could go stronger. Maybe a combo - where you=20 >> rely on BCP 195 but mandate TLS 1.2 (or later)? >> > > > And not mention CBC? > > >> > On Wed, Sep 16, 2015 at 9:14 AM, Randall=20 > Gellens=20 > <randy@qti.qualcomm.com>=20 > wrote: > > At 7:38 AM +0000 9/16/15,=20 > stephen.farrell@cs.tcd.ie=20 > wrote: > > On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=F6m wrote: > > Yes, at least mandating TLS 1.2 or higher and recommending as per above > seems reasonable. > The references for the GCM suites would be RFC 5288 and RFC 5289. > > > BCP195 has recent recommendations for most TLS=20 > options. I'd say it'd be best to use those or=20 > if not figure out why they're not correct for=20 > this context. > > > Just to be clear: are you suggesting that we=20 > replace text suggested by Magnus: > > TLS MUST be version 1.2 or later. It is RECOMMENDED to use only > cypher suites that offer Perfect Forward Secrecy (PFS) and avoid > Cipher Block Chaining (CBC), for example, > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. > > With this: > > TLS MUST be version 1.2 or later. It is RECOMMENDED follow > [BCP195]. > > > Note that BCP 195 does not address CBC (but=20 > does discuss PFS). I just want to be clear=20 > before making the change, so please confirm=20 > that this works. > > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > If the odds are a million to one against something occurring, chances > are 50-50 it will. > > > > > -- > > -- Magnus > > > > > -- > > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > > Between two evils, I always pick the one I never tried before. > --Mae West. > > > > > -- > > -- Magnus -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Total deregulation would allow anybody to fly any route, a situation that is unlikely ever to occur. --New York Times Magazine, 9 May 1976. From nobody Wed Sep 16 11:50:29 2015 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 8C0021A8A9B for ; Wed, 16 Sep 2015 11:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 I7T9Y08ff3FS for ; Wed, 16 Sep 2015 11:50:22 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (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 0AD6A1A8A75 for ; Wed, 16 Sep 2015 11:50:22 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so83754820wic.1 for ; Wed, 16 Sep 2015 11:50:20 -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:content-type; bh=IoIKU/t3lFrhphbAUq2z9z5Yvum8dH8lbKuaajUwFHk=; b=NzGXyuGatCUMAI9YRsMdRz1lP18iGk4txwTJUhBRycUo63Fhh4dQ0l/sdUd4/S4MVV eu6zvDH+TK1inJLBy3XAHT9Vwome3PIgQxhH4YMfJwNgpWdCObROCjYG7roge3mdt5/M NNHk8AxwMSZM9xFWCR2pnwV6w5/pTtwyGk7KcVVGGsewkt0yMOPcZBljN3lFUM8Y4ptZ z/jWzCD1S6Hii6RfthSLq4C5HjbWayCRkW0hs+n+5y6L0CHbN/IgXqV+rLWKDBa+Q7F7 fmq7DAS3qW2l7DTMD85Unu4gX/fdyQUkTH9U4lVGYN0x0cNK8QBdU5lescboJO/iRhvS p7gw== MIME-Version: 1.0 X-Received: by 10.180.21.137 with SMTP id v9mr21168519wie.8.1442429420584; Wed, 16 Sep 2015 11:50:20 -0700 (PDT) Received: by 10.27.130.200 with HTTP; Wed, 16 Sep 2015 11:50:20 -0700 (PDT) In-Reply-To: <4EE7311A-C4AA-4153-8B19-2C3175F03D89@brianrosen.net> References:

<2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> <4EE7311A-C4AA-4153-8B19-2C3175F03D89@brianrosen.net> Date: Wed, 16 Sep 2015 11:50:20 -0700 Message-ID: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= To: Brian Rosen Content-Type: multipart/alternative; boundary=047d7b873c423a466e051fe1c572 Archived-At: Cc: "secdir@ietf.org" , Randall Gellens , draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 18:50:23 -0000 --047d7b873c423a466e051fe1c572 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That looks good to me. On Wed, Sep 16, 2015 at 11:32 AM, Brian Rosen wrote: > TLS MUST be version 1.2 or later. It is RECOMMENDED to use only > cipher suites that offer Perfect Forward Secrecy (PFS), avoid > Cipher Block Chaining (CBC) and follow the recommendations in BCP195. > > > On Sep 16, 2015, at 12:14 PM, Randall Gellens > wrote: > > > > At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote: > > > >> On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=C3=B6m wrote: > >>> Yes, at least mandating TLS 1.2 or higher and recommending as per abo= ve > >>> seems reasonable. > >>> The references for the GCM suites would be RFC 5288 and RFC 5289. > >> > >> BCP195 has recent recommendations for most TLS options. I'd say it'd b= e > best to use those or if not figure out why they're not correct for this > context. > > > > Just to be clear: are you suggesting that we replace text suggested by > Magnus: > > > > TLS MUST be version 1.2 or later. It is RECOMMENDED to use only > > cypher suites that offer Perfect Forward Secrecy (PFS) and avoid > > Cipher Block Chaining (CBC), for example, > > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, > > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, > > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. > > > > With this: > > > > TLS MUST be version 1.2 or later. It is RECOMMENDED follow > > [BCP195]. > > > > > > Note that BCP 195 does not address CBC (but does discuss PFS). I just > want to be clear before making the change, so please confirm that this > works. > > > > -- > > Randall Gellens > > Opinions are personal; facts are suspect; I speak for myself only > > -------------- Randomly selected tag: --------------- > > If the odds are a million to one against something occurring, chances > > are 50-50 it will. > > --=20 -- Magnus --047d7b873c423a466e051fe1c572 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

That looks good to me.

On Wed, Sep 16, 2015 at 11:32 AM, Brian Rosen <= span dir=3D"ltr"><br@brianrosen.net> wrote:

= TLS MUST be version 1.2 or later.=C2=A0 It is RECOMMENDED to use only=
=C2=A0 cipher suites that offer Perfect Forward Secrecy (PFS), avoid=
=C2=A0 Cipher Block Chaining (CBC) and follow the recommendations in BCP195= .

> On Sep 16, 2015, at 12:14 PM, Randall Gellens <randy@qti.qualcomm.com> wrote:
>
> At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote:
>
>> On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=C3=B6m wrote: >>> Yes, at least mandating TLS 1.2 or higher and recommending as = per above
>>> seems reasonable.
>>> The references for the GCM suites would be RFC 5288 and RFC 52= 89.
>>
>> BCP195 has recent recommendations for most TLS options. I'd sa= y it'd be best to use those or if not figure out why they're not co= rrect for this context.
>
> Just to be clear: are you suggesting that we replace text suggested by= Magnus:
>
>=C2=A0 =C2=A0TLS MUST be version 1.2 or later.=C2=A0 It is RECOMMENDED = to use only
>=C2=A0 =C2=A0cypher suites that offer Perfect Forward Secrecy (PFS) and= avoid
>=C2=A0 =C2=A0Cipher Block Chaining (CBC), for example,
>=C2=A0 =C2=A0TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
>=C2=A0 =C2=A0TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
>=C2=A0 =C2=A0TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
>=C2=A0 =C2=A0TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
>=C2=A0 =C2=A0TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
>=C2=A0 =C2=A0TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. >
> With this:
>
>=C2=A0 =C2=A0TLS MUST be version 1.2 or later.=C2=A0 It is RECOMMENDED = follow
>=C2=A0 =C2=A0[BCP195].
>
>
> Note that BCP 195 does not address CBC (but does discuss PFS).=C2=A0 I= just want to be clear before making the change, so please confirm that thi= s works.
>
> --
> Randall Gellens
> Opinions are personal;=C2=A0 =C2=A0 facts are suspect;=C2=A0 =C2=A0 I = speak for myself only
> -------------- Randomly selected tag: ---------------
> If the odds are a million to one against something occurring, chances<= br> > are 50-50 it will.

-- Magnus

--047d7b873c423a466e051fe1c572-- From nobody Wed Sep 16 11:52:26 2015 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 701C71A8897 for ; Wed, 16 Sep 2015 11:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.821 X-Spam-Level: X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 k4eR4_2pdgrk for ; Wed, 16 Sep 2015 11:32:52 -0700 (PDT) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) (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 26B3F1A88A0 for ; Wed, 16 Sep 2015 11:32:49 -0700 (PDT) Received: by qkfq186 with SMTP id q186so90299958qkf.1 for ; Wed, 16 Sep 2015 11:32:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=sdJKgzJfazeDHOSnFVjpw+8pBdBGGWsJcH1kvZv8+Y8=; b=h0z47MwIdlNObSnw6OCehymTB4ADqqoQHIpZpEdCG4v7rzDepJKLMaoTNSy5OK4Opf 2W/YG/Ljyig/MGfrhqQO6HiDI5suV04VOENFRrU3/jVHDdj9gyNcR1z2gNPnrMJtf0fg kaYQmVT4qjtuhtQbNkZHjsKu22fnObAK34l8TyErGkb6UAGhn5rd49mSqpbl46R4sHI4 XNH4IGcBi3NasH42qbelDzGcSRqbF/N2rAtXQdtTQnXyHEMj2zZx7DMyPuGf2lkjsNON nN8Zyg3zsVG6i6YGXlVazzxIaEJazQ45z+gMl43PFEPiSgmKx/p/U4PQoDjY93wJhom5 bjcg== X-Gm-Message-State: ALoCoQnxayrzE8Zuyl8szuVSWsQ4B41F/Awjl4i124/nJig4OCdPWB31ANtKTYwYc9wkKmWhiKfs X-Received: by 10.55.198.11 with SMTP id b11mr43779372qkj.53.1442428368294; Wed, 16 Sep 2015 11:32:48 -0700 (PDT) Received: from [10.33.192.36] (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id v34sm10495711qge.47.2015.09.16.11.32.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Sep 2015 11:32:47 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 $2104$) From: Brian Rosen In-Reply-To: Date: Wed, 16 Sep 2015 14:32:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4EE7311A-C4AA-4153-8B19-2C3175F03D89@brianrosen.net> References:

<2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> To: Randall Gellens X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Wed, 16 Sep 2015 11:52:23 -0700 Cc: secdir@ietf.org, draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 18:32:53 -0000 TLS MUST be version 1.2 or later. It is RECOMMENDED to use only cipher suites that offer Perfect Forward Secrecy (PFS), avoid Cipher Block Chaining (CBC) and follow the recommendations in BCP195. > On Sep 16, 2015, at 12:14 PM, Randall Gellens = wrote: >=20 > At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote: >=20 >> On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=F6m wrote: >>> Yes, at least mandating TLS 1.2 or higher and recommending as per = above >>> seems reasonable. >>> The references for the GCM suites would be RFC 5288 and RFC 5289. >>=20 >> BCP195 has recent recommendations for most TLS options. I'd say it'd = be best to use those or if not figure out why they're not correct for = this context. >=20 > Just to be clear: are you suggesting that we replace text suggested by = Magnus: >=20 > TLS MUST be version 1.2 or later. It is RECOMMENDED to use only > cypher suites that offer Perfect Forward Secrecy (PFS) and avoid > Cipher Block Chaining (CBC), for example, > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. >=20 > With this: >=20 > TLS MUST be version 1.2 or later. It is RECOMMENDED follow > [BCP195]. >=20 >=20 > Note that BCP 195 does not address CBC (but does discuss PFS). I just = want to be clear before making the change, so please confirm that this = works. >=20 > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > If the odds are a million to one against something occurring, chances > are 50-50 it will. From nobody Wed Sep 16 12:22:50 2015 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 E7DD11A00EF for ; Wed, 16 Sep 2015 12:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Aw3hhSaUw_Nq for ; Wed, 16 Sep 2015 12:22:47 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78A01A000F for ; Wed, 16 Sep 2015 12:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442431367; x=1473967367; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=qwZtK5lUxaRf9PD7+I2A8aRYEHnmE6DudQsyCZv17k0=; b=tJe0RY22xW3Gp3A0bhXpt9c+MnO+w2dtNx/9kKPjJEcSFYKfnSoOTeI7 eNabw6IFEKApqyoj2WmWuFJILViNcZykMLQxTi+JbjKxwNVtilxsU/8VI GVj6x4BLjmaj1Gk9+i8J2wP9lQctwcEzMiL2IlKavXcwkdv6NTRC8dzFl Q=; X-IronPort-AV: E=McAfee;i="5700,7163,7926"; a="138971862" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Sep 2015 12:22:47 -0700 X-IronPort-AV: E=Sophos;i="5.17,541,1437462000"; d="scan'208";a="1002915462" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 16 Sep 2015 12:22:47 -0700 Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 16 Sep 2015 12:22:46 -0700 Message-ID: In-Reply-To: <4EE7311A-C4AA-4153-8B19-2C3175F03D89@brianrosen.net> References:

<2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> <4EE7311A-C4AA-4153-8B19-2C3175F03D89@brianrosen.net> X-Mailer: Eudora for Mac OS X Date: Wed, 16 Sep 2015 12:22:42 -0700 To: Brian Rosen , Randall Gellens From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: secdir@ietf.org, draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 19:22:49 -0000 At 2:32 PM -0400 9/16/15, Brian Rosen wrote: > TLS MUST be version 1.2 or later. It is RECOMMENDED to use only > cipher suites that offer Perfect Forward Secrecy (PFS), avoid > Cipher Block Chaining (CBC) and follow the recommendations in BCP195. Do we need to give examples of such suites? > >> On Sep 16, 2015, at 12:14 PM, Randall Gellens=20 >> wrote: >> >> At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote: >> >>> On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=F6m wrote: >>>> Yes, at least mandating TLS 1.2 or higher and recommending as per abov= e >>>> seems reasonable. >>>> The references for the GCM suites would be RFC 5288 and RFC 5289. >>> >>> BCP195 has recent recommendations for most=20 >>> TLS options. I'd say it'd be best to use=20 >>> those or if not figure out why they're not=20 >>> correct for this context. >> >> Just to be clear: are you suggesting that we=20 >> replace text suggested by Magnus: >> >> TLS MUST be version 1.2 or later. It is RECOMMENDED to use only >> cypher suites that offer Perfect Forward Secrecy (PFS) and avoid >> Cipher Block Chaining (CBC), for example, >> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, >> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, >> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, >> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, >> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, >> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. >> >> With this: >> >> TLS MUST be version 1.2 or later. It is RECOMMENDED follow >> [BCP195]. >> >> >> Note that BCP 195 does not address CBC (but=20 >> does discuss PFS). I just want to be clear=20 >> before making the change, so please confirm=20 >> that this works. >> >> -- >> Randall Gellens >> Opinions are personal; facts are suspect; I speak for myself only >> -------------- Randomly selected tag: --------------- >> If the odds are a million to one against something occurring, chances >> are 50-50 it will. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- It takes a wonderful brain and exquisite senses to produce a few stupid ideas. --Santayana From nobody Wed Sep 16 12:39:06 2015 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 2032A1A01A5 for ; Wed, 16 Sep 2015 12:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] 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 cnnGKQ-ji6WR for ; Wed, 16 Sep 2015 12:39:02 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (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 DDC3D1A0197 for ; Wed, 16 Sep 2015 12:39:01 -0700 (PDT) Received: by qgx61 with SMTP id 61so181332251qgx.3 for ; Wed, 16 Sep 2015 12:39:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=a5VRwzcifVbZf2RDeBn/InhnZMne9BlkZAWmpHPpOhQ=; b=iTTwpLAie/BvtGhasqGU/X7XRl1S3g/LyC0fFfGny8zYP19CQL+s8JKepDnQ9a2tq2 XCsyFJvxzUizIGioPXPrd0ik3VMnmv93MlhB0euUzbqC3Qx3686+2wrCbYuSVFHMUFwX TPP6lJhgugv6g95cHD8MFjpGxKMYdhJd8t8M3GrYM3P83D3n24VF1czzwY3SyuCY2WQ6 wTYSFYgIAHJgWD4YyuluXIVbOrx2HyhwammnDJn3RyFnZLlI4guyK8tIc4LWHrF0DKm3 ThBKQTFM0eenupw0p6670JYMW+93uegEAjf3HLvPRdlOzXLUeqrVvyXU9OulI7tky+u/ Gicw== X-Gm-Message-State: ALoCoQmxVW5qKWdGg+e39DNiBIruYVoi/+PpilWCpxVK70DMh/PHS/jOtodOVruPTOGp5CkpjZ/p X-Received: by 10.140.38.167 with SMTP id t36mr44926457qgt.66.1442432340988; Wed, 16 Sep 2015 12:39:00 -0700 (PDT) Received: from [10.33.192.36] (neustargw.va.neustar.com. [209.173.53.233]) by smtp.gmail.com with ESMTPSA id 139sm8364324qhh.43.2015.09.16.12.38.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Sep 2015 12:39:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_69645160-2823-4270-979D-03EE37D0A698" Mime-Version: 1.0 (Mac OS X Mail 8.2 $2104$) From: Brian Rosen In-Reply-To: Date: Wed, 16 Sep 2015 15:38:55 -0400 Message-Id: <70E145DD-8A93-4136-BBD2-82E1385A58FD@brianrosen.net> References:

<2do7j0.nurejh.2vaeqo-qmf@mercury.scss.tcd.ie> <4EE7311A-C4AA-4153-8B19-2C3175F03D89@brianrosen.net> To: Randall Gellens X-Mailer: Apple Mail (2.2104) Archived-At: Cc: secdir@ietf.org, draft-ietf-ecrit-additional-data@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data 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, 16 Sep 2015 19:39:04 -0000 --Apple-Mail=_69645160-2823-4270-979D-03EE37D0A698 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Don=92t think so. Brian > On Sep 16, 2015, at 3:22 PM, Randall Gellens = wrote: >=20 > At 2:32 PM -0400 9/16/15, Brian Rosen wrote: >=20 >> TLS MUST be version 1.2 or later. It is RECOMMENDED to use only >> cipher suites that offer Perfect Forward Secrecy (PFS), avoid >> Cipher Block Chaining (CBC) and follow the recommendations in = BCP195. >=20 > Do we need to give examples of such suites? >=20 >>=20 >>> On Sep 16, 2015, at 12:14 PM, Randall Gellens = wrote: >>>=20 >>> At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote: >>>=20 >>>> On Wed Sep 16 04:09:03 2015 GMT+0100, Magnus Nystr=F6m wrote: >>>>> Yes, at least mandating TLS 1.2 or higher and recommending as per = above >>>>> seems reasonable. >>>>> The references for the GCM suites would be RFC 5288 and RFC 5289. >>>>=20 >>>> BCP195 has recent recommendations for most TLS options. I'd say = it'd be best to use those or if not figure out why they're not correct = for this context. >>>=20 >>> Just to be clear: are you suggesting that we replace text suggested = by Magnus: >>>=20 >>> TLS MUST be version 1.2 or later. It is RECOMMENDED to use only >>> cypher suites that offer Perfect Forward Secrecy (PFS) and avoid >>> Cipher Block Chaining (CBC), for example, >>> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, >>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, >>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, >>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, >>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, >>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] [RFC5289]. >>>=20 >>> With this: >>>=20 >>> TLS MUST be version 1.2 or later. It is RECOMMENDED follow >>> [BCP195]. >>>=20 >>>=20 >>> Note that BCP 195 does not address CBC (but does discuss PFS). I = just want to be clear before making the change, so please confirm that = this works. >>>=20 >>> -- >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself = only >>> -------------- Randomly selected tag: --------------- >>> If the odds are a million to one against something occurring, = chances >>> are 50-50 it will. >=20 >=20 >=20 > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > It takes a wonderful brain and exquisite senses to produce a few > stupid ideas. --Santayana --Apple-Mail=_69645160-2823-4270-979D-03EE37D0A698 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Don=92t think so.

Brian

On Sep 16, 2015, at 3:22 PM, = Randall Gellens <randy@qti.qualcomm.com> wrote:

At 2:32 PM -0400 9/16/15, Brian Rosen = wrote:

TLS MUST be version 1.2 or later. It is = RECOMMENDED to use only
  cipher suites that = offer Perfect Forward Secrecy (PFS), avoid
  Cipher Block Chaining (CBC) and follow the = recommendations in BCP195.

Do we need to give examples of such = suites?

On = Sep 16, 2015, at 12:14 PM, Randall Gellens <randy@qti.qualcomm.com> wrote:

At 7:38 AM +0000 9/16/15, stephen.farrell@cs.tcd.ie wrote:

On Wed Sep 16 04:09:03 = 2015 GMT+0100, Magnus Nystr=F6m wrote:
Yes, at least mandating TLS 1.2 or higher and = recommending as per above
seems reasonable.
The references for the GCM suites would be RFC 5288 and RFC = 5289.

BCP195 has recent = recommendations for most TLS options. I'd say it'd be best to use those = or if not figure out why they're not correct for this context.

Just to be clear: are you = suggesting that we replace text suggested by Magnus:

  TLS MUST be version 1.2 or later. It is = RECOMMENDED to use only
  cypher suites that = offer Perfect Forward Secrecy (PFS) and avoid
  Cipher Block Chaining (CBC), for example,
  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
  TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
  TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288] = [RFC5289].

With this:

  TLS MUST be version 1.2 or later. It is = RECOMMENDED follow
  [BCP195].

Note that BCP 195 does not address CBC (but = does discuss PFS). I just want to be clear before making the = change, so please confirm that this works.

--
Randall Gellens
Opinions are = personal;    facts are suspect;    I speak = for myself only
-------------- Randomly selected tag: = ---------------
If the odds are a million to one against = something occurring, chances
are 50-50 it will.

--
Randall Gellens
Opinions are personal;    facts = are suspect;    I speak for myself only
-------------- Randomly selected tag: = ---------------
It takes a wonderful brain = and exquisite senses to produce a few
stupid ideas. =             &n= bsp;           &nbs= p;            =   --Santayana

= --Apple-Mail=_69645160-2823-4270-979D-03EE37D0A698-- From nobody Wed Sep 16 22:14:59 2015 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 7DF7A1B31F0 for ; Wed, 16 Sep 2015 22:14:57 -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 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 nZqyzZaLyMMa for ; Wed, 16 Sep 2015 22:14:55 -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 11DC11B31EE for ; Wed, 16 Sep 2015 22:14:54 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t8H5EpMF018375 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Sep 2015 08:14:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t8H5EpKT023783; Thu, 17 Sep 2015 08:14:51 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22010.19531.253544.215699@fireball.acr.fi> Date: Thu, 17 Sep 2015 08:14:51 +0300 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, 17 Sep 2015 05:14:57 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Chris Inacio is next in the rotation. For telechat 2015-09-17 Reviewer LC end Draft Dave Cridland T 2015-09-08 draft-ietf-pals-vccv-for-gal-05 Chris Inacio T 2015-07-29 draft-ietf-homenet-dncp-09 Ben Laurie T 2015-08-11 draft-ietf-dnsop-dns-terminology-04 Hannes Tschofenig TR2015-09-17 draft-wkumari-dhc-capport-16 For telechat 2015-10-01 John Bradley T 2015-09-03 draft-ietf-mpls-lsp-ping-reply-mode-simple-04 Daniel Kahn Gillmor T 2015-09-17 draft-ietf-tzdist-caldav-timezone-ref-04 Dan Harkins T 2015-09-24 draft-ietf-bess-spbm-evpn-01 Tom Yu T 2015-09-08 draft-ietf-dhc-dhcpv4-active-leasequery-06 Dacheng Zhang T 2015-09-04 draft-ietf-dice-profile-16 Last calls and special requests: Derek Atkins 2015-09-23 draft-kivinen-ipsecme-oob-pubkey-11 Donald Eastlake 2015-09-11 draft-ietf-dane-openpgpkey-05 Shawn Emery 2015-09-23 draft-ietf-pwe3-iccp-stp-04 Daniel Kahn Gillmor E None draft-ietf-rtcweb-security-08 Tobias Gondrom E None draft-ietf-rtcweb-security-arch-11 Tobias Gondrom 2015-09-22 draft-ietf-v6ops-siit-dc-02 Olafur Gudmundsson 2015-09-22 draft-ietf-v6ops-siit-dc-2xlat-01 Phillip Hallam-Baker 2015-09-22 draft-ietf-v6ops-siit-eam-01 Steve Hanna 2015-10-09 draft-blanchet-ccsds-urn-00 Sam Hartman 2015-09-30 draft-ietf-teas-fast-lsps-requirements-01 Paul Hoffman 2015-09-24 draft-ietf-teas-rsvp-te-srlg-collect-02 Christian Huitema 2015-09-30 draft-ietf-teas-te-express-path-03 Jeffrey Hutzelman 2015-09-30 draft-ietf-v6ops-pmtud-ecmp-problem-04 Brian Weis 2015-09-23 draft-housley-sow-author-statistics-00 -- kivinen@iki.fi From nobody Thu Sep 17 02:44:13 2015 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 79A371B2C2A; Thu, 17 Sep 2015 02:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 YSKUo8oUYVqM; Thu, 17 Sep 2015 02:44:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E981B29F4; Thu, 17 Sep 2015 02:44:07 -0700 (PDT) Received: from [192.168.10.183] ([134.76.0.127]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0ML6XF-1ZcmiC1mYD-000MEi; Thu, 17 Sep 2015 11:43:49 +0200 To: Warren Kumari , Hannes Tschofenig References:

From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <55FA8B49.7040303@gmx.net> Date: Thu, 17 Sep 2015 11:43:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="deTV7UsFLDceDVec7nE68uNoBmXAopegD" X-Provags-ID: V03:K0:dHX7a23A0l9aYAnnZ0/qq5/XWE/K6DslrWiTdBuVlKcTX4KPeKF ctasznCIkDiSZPKs0ibvCtROwell1NJuuWd6XO9WmtiPj7+RBHNSkj8LLaTgSdT8jnuZqOO 5dVfNlfCD39IWIuI7J6tukqaELZlMvylMmj2bvKWqwvu/TnJy4NudYT0O8KPI1iVTDCKJRB ysK3XiYK+7hqk5VWRoZBA== X-UI-Out-Filterresults: notjunk:1;V01:K0:o9nXMWaiQAU=:R+jxVGDt+EmQpDa4p86Jp3 Sl3umek6rNQ2WyrKdlxop3Sgw2aMR2d37bVhzhqJEjHyEd/Yv5Soudlp5P8DsRd/nRHxFLaTI gSnBG8BEMHQsJpmGlTmVftQML4jtQiufdfDEVyU1XLAQwrWN+W1RzMFnbRETEiJfPFv58DIga cJ3xXZr55QTqlAw2XHscmzemENXb3m9NHAX6WwToLbW6UC51HF0PRlMhs3rjsuqv894tjofno SoiH0hgRlOxHgZWI7RQ3tH+7x5Kyb8fQhIZsLE59eTXxMQDr6VJmuShtUNmpXquIK/fXXzbpA I3sR6L71e/Bjz4KJc+YAca6Pbnql6b0THF24HZ3sOu3VtzRgwurcqKrW+yL9nMJ6O0rHqAnQx AHnSdh0j7q2NgrrMqp91lCdqivzsqJIQf3UEHc3wHVKcczCv/+QRNChPMcuNHP0vvIC+5hqdG uBUpsgMQ7C9cKO21S3xOqfy306A4bQPNWbZBeROYTXrAY/3k1zgx+H0i7aD3+o3EMojuREt/K 0wWN7TlEyIZxrU3zgc9fyELB1iIH8IbX+MEwLGFScpQRyjor0VPtud4YTs2q81b33bINlACpT OM5N0YTJa/0XebcbUZIs29T0RwzSB1SquW1EYnIilbankcXqzmlBVnORLTallwBj2Ffps4Z2j JKgB+qsKXMWrx+HUhFAmTbb1PWNFAuW9iYR2JuXX4Xf0ZXwWg+jRT3BUSWyuMrcrLKsKEY7RJ M3wwAsfl0LBD/0W8 Archived-At: Cc: "draft-wkumari-dhc-capport.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-wkumari-dhc-capport-13 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, 17 Sep 2015 09:44:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --deTV7UsFLDceDVec7nE68uNoBmXAopegD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Warren, ~snip~ >> The motivation of the document makes sense, namely to avoid intercepti= on of >> traffic, and the document is an easy extension to already available >> mechanisms (RA/DHCP). I was expecting to see a reference to Hotspot 2.= 0, >> which aims to make the interaction between hotspot providers and end d= evices >> more intelligent (but covers a much larger scope). >=20 > I originally had this as an editor's note: > https://github.com/wkumari/draft-wkumari-dhc-capport/blob/de293471faef5= 62517978b709aaca762d1d78dbe/README.md >=20 > "[ Ed note: This solution is somewhat similar / complements 802.11u / > WiFi Passpoint Online Sign-up, but is much simpler, easier to deploy= , > and works on wired as well ] > " >=20 > I spent some time looking at the Hotspot 2.0 stuff, but after slogging > through much 4 color glossy type material it seemed that it more > allowed you to use different reaming providers / snap a RADIUS > connection back to another provider. I even spent some $$$ on > purchasing a spec, which I found largely unintelligible. > So, I decided to remove the vague / editorial note... :-) >=20 > If you happen to have any suggested text I'm happy to stick it in... Good to hear that you took the work into account. It is fine for me if you came up with the conclusion that it is too complex. (Btw, the specifications are now available for download for free at http://www.wi-fi.org/discover-wi-fi/specifications) Ciao Hannes --deTV7UsFLDceDVec7nE68uNoBmXAopegD 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.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV+otJAAoJEGhJURNOOiAtr8MH/jc1VU2le2A42RAlWUIdV4p/ lUc2wK8YJJf6SIoZZAUlal2d00CXG3bBdRBIT3zBh6ryKLP6pPeMbO46jjZ6mYk1 ghT52otBI0ZxEwjjmX3HDEqQOZbxDl+12iYI9rijHeBdjZ9q2iMetqy9zrIblK+x od0fu6xXzFqVty4CZ5A/nljDcI5lkM4UgAC5BPjkFHjRuwoYTThNqEbJPIs6bt/b 5O1E9FbFgfiQipopYFdUCxLNaPpCtKmXmdbTwN7JOzAYXkLioe5i0vZcBiHmpZXE m8drxsPhvAfZAz1VjKWBMhbFaBZVF2vLWbMlmp8FmB0zodYQFJwYlU28wVgNQFk= =5G7x -----END PGP SIGNATURE----- --deTV7UsFLDceDVec7nE68uNoBmXAopegD-- From nobody Thu Sep 17 07:02:57 2015 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 30A591A0015; Thu, 17 Sep 2015 07:02:55 -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_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 VET4-lxMYEur; Thu, 17 Sep 2015 07:02:53 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5D21A00B9; Thu, 17 Sep 2015 07:02:50 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id CC28D1229CD; Thu, 17 Sep 2015 10:28:53 -0400 (EDT) Received: from exchange.research.att.com (njfpsrvexg0.research.att.com [135.207.255.124]) by mail-green.research.att.com (Postfix) with ESMTP id 91E99E101C; Thu, 17 Sep 2015 10:01:14 -0400 (EDT) Received: from NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90]) by NJFPSRVEXG0.research.att.com ([fe80::108a:1006:9f54:fd90%25]) with mapi; Thu, 17 Sep 2015 10:02:50 -0400 From: "MORTON, ALFRED C (AL)" To: Alan DeKok , "secdir@ietf.org" Date: Thu, 17 Sep 2015 10:02:49 -0400 Thread-Topic: Secdir review of draft-ietf-ippm-owamp-registry-03 Thread-Index: AdDwr+ejrlXABYCpRsygInVxFp7LpAAn3HQw Message-ID: <4AF73AA205019A4C8A1DDD32C034631D0BB4581583@NJFPSRVEXG0.research.att.com> References: <6FD706E2-FEAC-4EF2-BCE8-43D16095BB11@deployingradius.com> In-Reply-To: <6FD706E2-FEAC-4EF2-BCE8-43D16095BB11@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ippm-ads@ietf.org" , "ippm-chairs@ietf.org" , "draft-ietf-ippm-owamp-registry@tools.ietf.org" , "ippm@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-owamp-registry-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post:

= --Apple-Mail-347-713037693-- From nobody Mon Sep 21 17:34:55 2015 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 3A1E31ACDE5 for ; Mon, 21 Sep 2015 17:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 RUF0ZmwRrmuM for ; Mon, 21 Sep 2015 17:34:51 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id DD57D1ACDC3 for ; Mon, 21 Sep 2015 17:34:50 -0700 (PDT) Received: (qmail 7463 invoked by uid 0); 22 Sep 2015 00:34:49 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 22 Sep 2015 00:34:49 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id L0ai1r00U2SSUrH010alu0; Mon, 21 Sep 2015 18:34:47 -0600 X-Authority-Analysis: v=2.1 cv=C6F6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ff-B7xzCdYMA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=0RAR5D2yBdQrwp53PsoA:9 a=bCDC00nOpVNyUGZ6:21 a=BcFdZkG3eSuyAsUL:21 a=QEXdDO2ut3YA:10 a=XIqpo32RAAAA:8 a=WwByOlHt4hu4xHjUyu4A:9 a=D5SfZVLvXdNvwCW6:21 a=zMY0fasZuyrZ7ieZ:21 a=SpSLK2-eWlx-8gb-:21 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=EetcH9YsOCJOq+a9icPv48lgXRYpYGlUj6PBfHqWkXk=; b=jnRHjZc05EY8lpG2+WjpAHSoytN3JlB28pfENRSCtSDx+K7nDValVm0wo5phwNPwwTB63g6oeNSNyMhRxLC8wkVkltl2yppnPPl/vflPPG6y2b8ke4zrUJPHEK9ALxaU; Received: from box313.bluehost.com ([69.89.31.113]:33356 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZeBXf-0008Nt-FN; Mon, 21 Sep 2015 18:34:44 -0600 To: "BRUNGARD, DEBORAH A" , "Andrew G. Malis" , Sam Hartman References:

From: Lou Berger X-Enigmail-Draft-Status: N1110 Message-ID: <5600A20E.9060607@labn.net> Date: Mon, 21 Sep 2015 20:34:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070209020303010003080806" X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: "sec-ads@ietf.org" , "draft-ietf-teas-fast-lsps-requirements.all@ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir Review of draft-ietf-teas-fast-lsps-requirements-01 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, 22 Sep 2015 00:34:54 -0000 This is a multi-part message in MIME format. --------------070209020303010003080806 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sam, To add to Deborah's point re requirements. A lot of time was spent discussing the requirements to ensure they were phrased in terms that were generally applicable. Since these were published we have seen a number of documents and other new work which are all focused on scaling and some of the other related requirements. If your concern is that the requirements represent just one organization's viewpoint that have been rubber stamped, rest assured that this was/is not the case. Lou PS Disclaimer: I contributed to getting this document revised from it's original form to what you see now. On 9/21/2015 5:09 PM, BRUNGARD, DEBORAH A wrote: > > Hi Sam, > > > > Thanks for your review. > > > > I see basically two concerns, one questioning the security aspects, > the other on the general level questioning the document itself. > > > > As the general level concern is much more serious, let’s address it > first. Maybe some background would help. I was chair of CCAMP and then > TEAS when the document transitioned to TEAS. At first the document was > written in the style of being quite negative on GMPLS as the > identified problems were based on incorrect interpretation of the RFCs > (broken implementations). So the WG asked the authors to first be > precise on their requirements before assuming new solutions were > needed. After several spins, the WG was comfortable with the > requirements. Folks didn’t question the requirements themselves as > GMPLS is targeted at applications for improving connection set up > times for large mesh networks vs. using a PCE/management system. And > when asked, the authors said this was not targeted for wavelengths > (where the physical connectivity is more constraining than the control > plane signaling) but OTN (Optical Transport Network is a digital > frame) e.g. from March 2014 CCAMP Meeting Notes: > > “Lou Berger: [poll] how many have read the document [] how many think > this is an interesting problem to discuss? [a good number for each] > > George Swallow: What is achievable for OTN is much closer to your > requirements than what is achievable for optical. I was wondering if > requirements apply to both. > > Andy Malis: They apply to both, we have possible solutions for both > but before coming with solutions we want an agreement on requirements. > > Rajan Rao: If we have separate data plane and control plane > requirements, if the traffic doesn’t come out, what does it really mean? > > Lou Berger: question for the list. > > Adrian Farrel: I like this set of requirements, I hate you say you > can't solve them with existing stuff. Push requirements and then we > can work on an applicability to see if existing solutions can meet them.” > > > > The Shepherd writeup provides more detail. And this is not the first > document discussing optimizing set up times. RFC6383 was on > optimizations and recently the MPLS WG has just completed > draft-ietf-mpls-self-ping. > > > > If you still are uncomfortable with these requirements, it would be > best if you express your concerns with the TEAS WG. I noted you did > not include them on your review. > > > > On your second concern, the security implications. This is an > informational document. As the shepherd writeup notes “The > requirements put forth in this document may be the basis for future > documents, some of which may be simply informational, while others may > describe specific GMPLS protocol extensions. While some of these > requirements may be have implications on implementations, the intent > > is for the requirements to apply to GMPLS protocols and their > standardized mechanisms.” > > > > So it is unclear at this time if only an applicability statement is > needed (informational on the “correct” use of GMPLS > protocols/mechanisms and an understanding of the signaling aspects vs. > the processing/implementation dependent aspects) or if new > extensions/mechanisms are needed. For the security section, it was > written based on the assumption that either this will only need an > applicability document and, if it needs more, than one has something > to base a security considerations. With this background, do you have > suggestions to help the authors improve this section? > > > > Again, thanks for your review- > > Deborah > > > > > > *From:*Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* Monday, September 21, 2015 12:29 PM > *To:* Sam Hartman > *Cc:* secdir@ietf.org; sec-ads@ietf.org; IESG; > draft-ietf-teas-fast-lsps-requirements.all@ietf.org > *Subject:* Re: Secdir Review of draft-ietf-teas-fast-lsps-requirements-01 > > > > Sam, > > > > Thanks for your comments. We (the authors) will await further review > from the IESG before taking any particular action. > > > > Cheers, > > Andy > > > > > > On Mon, Sep 21, 2015 at 11:55 AM, Sam Hartman

> wrote: > > > Hi. > I am the assigned secdir reviewer for this draft on requirements for > very fast GMPLS path establishment. > > This draft outlines scaling requirements for new applications of GMPLS. > > I'd like to flag this draft for particular review from the security ADs > and recommend that the IESG consider a process question and get input > from the sponsoring AD. > > So, for the security ADS: > The security considerations section reads in its entirety: > > . Security Considerations > > Being able to support very fast setup and a high churn rate of GMPLS > LSPs is not expected to adversely affect the underlying security > issues associated with existing GMPLS signaling. > > > however the draft talks about increasing the number of cases where GMPLS > paths cross administrative boundaries and significantly increasing the > scale of GMPLS applications. > > I don't think we have good security solutions for cases where we're > trying to do PCE-like things across mutually suspicious or potentially > hostile administrative boundaries. > And yes it's reasonable to assume that there are business relationships > in place here, but we also understand from our experience with BGP and > other internet-scale services the limitations of that. > > I think significantly more security work is consider. > > On a general level, there's basically no justification for the > requirements given. > For example, the document talks about how cloud computing is an > application that will drive these requirements. The document neither > talks about nor cites any explanation of what it is about cloud > computing that creates that need nor gives the reader any ability to > evaluate whether the need is real. > The depth of analysis is similar for all the other cited applications. > We jump from very broad staments like "cloud computing, datacenters and > data visualization will need this," to specific requirements in terms of > requests per second. > > I'd particularly like to call out section 2: > 2. Background > > The Defense Advanced Research Projects Agency (DARPA) Core Optical > Networks (CORONET) program [Chiu], is an example target > environment > that includes IP and optical commercial and government > networks, with > a focus on highly dynamic and resilient multi-terabit > core networks. > It anticipates the need for rapid (sub-second) > setup and SONET/SDH- > like restoration times for high-churn (up to > tens of requests per > second network-wide and holding times as > short as one second) on- > demand wavelength, sub-wavelength and > packet services for a variety > of applications (e.g., grid computing, > cloud computing, data > visualization, fast data transfer, > etc.). This must be done while > meeting stringent call blocking > requirements, and while minimizing > the use of resources such as > time slots, switch ports, wavelength > conversion, etc. > > I recommend that someone take a look at the material on that DARPA > project and see how well the DARPA requirements align with the > recommendations in this spec. > I'm somewhat concerned that DARPA put together a research project and > said "Hey we'd like these things," and now the IETF, without any > significant independent analysis is rubber stamping that as our > requirements in this space. > > I don't know that's what happened here, thus I have not copied > ietf@ietf.org . > However, DARPA's request should not represent an informed consensus of > the IETF. > I'd like to see the IESG evaluate whether we actually have done our own > analysis here and whether there is an informed consensus behind this > document. > > Thanks for your consideration, > > --Sam > > > --------------070209020303010003080806 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Sam,
To add to Deborah's point re requirements. A lot of time was spent discussing the requirements to ensure they were phrased in terms that were generally applicable. Since these were published we have seen a number of documents and other new work which are all focused on scaling and some of the other related requirements. If your concern is that the requirements represent just one organization's viewpoint that have been rubber stamped, rest assured that this was/is not the case.

Lou

PS Disclaimer: I contributed to getting this document revised from it's original form to what you see now.

On 9/21/2015 5:09 PM, BRUNGARD, DEBORAH A wrote:

Hi Sam,

Thanks for your review.

I see basically two concerns, one questioning the security aspects, the other on the general level questioning the document itself.

As the general level concern is much more serious, let’s address it first. Maybe some background would help. I was chair of CCAMP and then TEAS when the document transitioned to TEAS. At first the document was written in the style of being quite negative on GMPLS as the identified problems were based on incorrect interpretation of the RFCs (broken implementations). So the WG asked the authors to first be precise on their requirements before assuming new solutions were needed. After several spins, the WG was comfortable with the requirements. Folks didn’t question the requirements themselves as GMPLS is targeted at applications for improving connection set up times for large mesh networks vs. using a PCE/management system. And when asked, the authors said this was not targeted for wavelengths (where the physical connectivity is more constraining than the control plane signaling) but OTN (Optical Transport Network is a digital frame) e.g. from March 2014 CCAMP Meeting Notes:

“Lou Berger: [poll] how many have read the document [] how many think this is an interesting problem to discuss? [a good number for each]

George Swallow: What is achievable for OTN is much closer to your requirements than what is achievable for optical. I was wondering if requirements apply to both.

Andy Malis: They apply to both, we have possible solutions for both but before coming with solutions we want an agreement on requirements.

Rajan Rao: If we have separate data plane and control plane requirements, if the traffic doesn’t come out, what does it really mean?

Lou Berger: question for the list.

Adrian Farrel: I like this set of requirements, I hate you say you can't solve them with existing stuff. Push requirements and then we can work on an applicability to see if existing solutions can meet them.”

The Shepherd writeup provides more detail. And this is not the first document discussing optimizing set up times. RFC6383 was on optimizations and recently the MPLS WG has just completed draft-ietf-mpls-self-ping.

If you still are uncomfortable with these requirements, it would be best if you express your concerns with the TEAS WG. I noted you did not include them on your review.

On your second concern, the security implications. This is an informational document. As the shepherd writeup notes “The requirements put forth in this document may be the basis for future documents, some of which may be simply informational, while others may describe specific GMPLS protocol extensions. While some of these requirements may be have implications on implementations, the intent

is for the requirements to apply to GMPLS protocols and their standardized mechanisms.”

So it is unclear at this time if only an applicability statement is needed (informational on the “correct” use of GMPLS protocols/mechanisms and an understanding of the signaling aspects vs. the processing/implementation dependent aspects) or if new extensions/mechanisms are needed. For the security section, it was written based on the assumption that either this will only need an applicability document and, if it needs more, than one has something to base a security considerations. With this background, do you have suggestions to help the authors improve this section?

Again, thanks for your review-

Deborah

From: Andrew G. Malis [mailto:agmalis@gmail.com]
Sent: Monday, September 21, 2015 12:29 PM
To: Sam Hartman
Cc: secdir@ietf.org; sec-ads@ietf.org; IESG; draft-ietf-teas-fast-lsps-requirements.all@ietf.org
Subject: Re: Secdir Review of draft-ietf-teas-fast-lsps-requirements-01

Sam,

Thanks for your comments. We (the authors) will await further review from the IESG before taking any particular action.

Cheers,

Andy

On Mon, Sep 21, 2015 at 11:55 AM, Sam Hartman <hartmans-ietf@mit.edu> wrote:

Hi.
I am the assigned secdir reviewer for this draft on requirements for
very fast GMPLS path establishment.

This draft outlines scaling requirements for new applications of GMPLS.

I'd like to flag this draft for particular review from the security ADs
and recommend that the IESG consider a process question and get input
from the sponsoring AD.

So, for the security ADS:
The security considerations section reads in its entirety:

. Security Considerations

Being able to support very fast setup and a high churn rate of GMPLS
LSPs is not expected to adversely affect the underlying security
issues associated with existing GMPLS signaling.

however the draft talks about increasing the number of cases where GMPLS
paths cross administrative boundaries and significantly increasing the
scale of GMPLS applications.

I don't think we have good security solutions for cases where we're
trying to do PCE-like things across mutually suspicious or potentially
hostile administrative boundaries.
And yes it's reasonable to assume that there are business relationships
in place here, but we also understand from our experience with BGP and
other internet-scale services the limitations of that.

I think significantly more security work is consider.

On a general level, there's basically no justification for the
requirements given.
For example, the document talks about how cloud computing is an
application that will drive these requirements. The document neither
talks about nor cites any explanation of what it is about cloud
computing that creates that need nor gives the reader any ability to
evaluate whether the need is real.
The depth of analysis is similar for all the other cited applications.
We jump from very broad staments like "cloud computing, datacenters and
data visualization will need this," to specific requirements in terms of
requests per second.

I'd particularly like to call out section 2:
2. Background

The Defense Advanced Research Projects Agency (DARPA) Core Optical
Networks (CORONET) program [Chiu], is an example target environment
that includes IP and optical commercial and government networks, with
a focus on highly dynamic and resilient multi-terabit core networks.
It anticipates the need for rapid (sub-second) setup and SONET/SDH-
like restoration times for high-churn (up to tens of requests per
second network-wide and holding times as short as one second) on-
demand wavelength, sub-wavelength and packet services for a variety
of applications (e.g., grid computing, cloud computing, data
visualization, fast data transfer, etc.). This must be done while
meeting stringent call blocking requirements, and while minimizing
the use of resources such as time slots, switch ports, wavelength
conversion, etc.

I recommend that someone take a look at the material on that DARPA
project and see how well the DARPA requirements align with the
recommendations in this spec.
I'm somewhat concerned that DARPA put together a research project and
said "Hey we'd like these things," and now the IETF, without any
significant independent analysis is rubber stamping that as our
requirements in this space.

I don't know that's what happened here, thus I have not copied
ietf@ietf.org.
However, DARPA's request should not represent an informed consensus of
the IETF.
I'd like to see the IESG evaluate whether we actually have done our own
analysis here and whether there is an informed consensus behind this
document.

Thanks for your consideration,

--Sam

--------------070209020303010003080806-- From nobody Wed Sep 23 01:11:22 2015 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 DF6691A9023 for ; Wed, 23 Sep 2015 01:11:19 -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 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 CGVqbXmWqCUW for ; Wed, 23 Sep 2015 01:11:18 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 CD6B81A9006 for ; Wed, 23 Sep 2015 01:11:18 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8N8BHeD025507 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Sep 2015 08:11:18 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t8N8BH3c009119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Sep 2015 08:11:17 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t8N8BHSw005064; Wed, 23 Sep 2015 08:11:17 GMT Received: from [10.159.120.65] (/10.159.120.65) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 23 Sep 2015 01:11:16 -0700 Message-ID: <56025EEB.5060602@oracle.com> Date: Wed, 23 Sep 2015 02:12:27 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: secdir@ietf.org References: <559A155B.6080505@oracle.com> In-Reply-To: <559A155B.6080505@oracle.com> X-Forwarded-Message-Id: <559A155B.6080505@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: draft-ietf-pwe3-iccp-stp.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-pwe3-iccp-stp-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, 23 Sep 2015 08:11:20 -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 draft specifies a Spanning Tree Protocol (STP) application for the Inter-Chassis Communication Protocol (ICCP). The security considerations section does exist and refers to the base ICCP specification, RFC 7275, for applicability. 7275 lists the security constraints and limitations sufficiently when considering the reviewed draft. The section goes on to describe potential DoS attacks as described in 7275 and provides a single example to mitigate such an attack. Even though this coverage is fairly sparse, 7275 outlines a more comprehensive list of thwarting potential threats. General comments: None. Editorial comments: PE, PW, AC, CE, and LDP are never expanded. s/need be active/need to be active/ s/such system/such systems/ s/that support ICCP/that supports ICCP/ s/on CE or PE/on the CE or PE/ s/attack on channel/attack on a channel/ s/careful attack on channel/a careful attack on a channel/ Shawn. -- From nobody Wed Sep 23 01:30:38 2015 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 6414B1A9097 for ; Wed, 23 Sep 2015 01:30:36 -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 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 nCn9Fj_pVszK for ; Wed, 23 Sep 2015 01:30:33 -0700 (PDT) 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 854361A9094 for ; Wed, 23 Sep 2015 01:30:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXY22949; Wed, 23 Sep 2015 08:30:29 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Sep 2015 09:30:28 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0235.001; Wed, 23 Sep 2015 16:30:21 +0800 From: Mingui Zhang To: Shawn M Emery , "secdir@ietf.org" Thread-Topic: Review of draft-ietf-pwe3-iccp-stp-04 Thread-Index: AQHQ9deIDMAYKNPE50evs3I3IKG70J5Jx9Sw Date: Wed, 23 Sep 2015 08:30:20 +0000 Message-ID: <4552F0907735844E9204A62BBDD325E787206621@nkgeml512-mbx.china.huawei.com> References: <559A155B.6080505@oracle.com> <56025EEB.5060602@oracle.com> In-Reply-To: <56025EEB.5060602@oracle.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.146.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "draft-ietf-pwe3-iccp-stp.all@tools.ietf.org" Subject: Re: [secdir] Review of draft-ietf-pwe3-iccp-stp-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, 23 Sep 2015 08:30:36 -0000 Hi Shawn, Thanks for the review! The comments will be incorporated in the new version= . Thanks, Mingui=20 > -----Original Message----- > From: Shawn M Emery [mailto:shawn.emery@oracle.com] > Sent: Wednesday, September 23, 2015 4:12 PM > To: secdir@ietf.org > Cc: draft-ietf-pwe3-iccp-stp.all@tools.ietf.org > Subject: Review of draft-ietf-pwe3-iccp-stp-04 >=20 > I have reviewed this document as part of the security directorate's ongoi= ng > 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 > This draft specifies a Spanning Tree Protocol (STP) application for the > Inter-Chassis Communication Protocol (ICCP). >=20 > The security considerations section does exist and refers to the base ICC= P > specification, RFC 7275, for applicability. 7275 lists the security cons= traints > and limitations sufficiently when considering the reviewed draft. > The section goes on to describe potential DoS attacks as described in 727= 5 and > provides a single example to mitigate such an attack. Even though this > coverage is fairly sparse, 7275 outlines a more comprehensive list of thw= arting > potential threats. >=20 > General comments: >=20 > None. >=20 > Editorial comments: >=20 > PE, PW, AC, CE, and LDP are never expanded. >=20 > s/need be active/need to be active/ >=20 > s/such system/such systems/ >=20 > s/that support ICCP/that supports ICCP/ >=20 > s/on CE or PE/on the CE or PE/ >=20 > s/attack on channel/attack on a channel/ >=20 > s/careful attack on channel/a careful attack on a channel/ >=20 > Shawn. > -- From nobody Wed Sep 23 10:49:40 2015 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 C439F1A88FD; Wed, 23 Sep 2015 10:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_ORG=0.611] 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 v3EwaLTpmRfC; Wed, 23 Sep 2015 10:49:35 -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 C071E1A88FC; Wed, 23 Sep 2015 10:49:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 00EC1E2035; Wed, 23 Sep 2015 13:49:34 -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 10447-10; Wed, 23 Sep 2015 13:49:31 -0400 (EDT) Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (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 6C2C6E2034; Wed, 23 Sep 2015 13:49:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1443030571; bh=8N7EGMEIr/zJZQP3OZ1SodyEgerSOrQd/aCnV+nILk0=; h=From:To:Cc:Subject:Date; b=sOOOmCEKvuN3U1uE4vSUlxfE/MogVlpDdfZ0+O2182I/AgIkLFQde7OTtLWN7BF3w PMfGeNfHWonnTdJZ9ri3TW4pwKc8t0zOKAmaOSutBzvS3Apc8eArdWT7NoFbu2x67M L8pOG/hDVpLDo0uMJvTJ7KTYgHclpVKdHGoEm76Q= Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t8NHnUAK010047; Wed, 23 Sep 2015 13:49:30 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Wed, 23 Sep 2015 13:49:30 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Cc: pwouters@redhat.com, ipsecme-chairs@ietf.org Subject: [secdir] sec-dir review of draft-kivinen-ipsecme-oob-pubkey-12 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, 23 Sep 2015 17:49:36 -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 have no issues with this document as written. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Thu Sep 24 03:45:40 2015 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 AF3941A0371; Thu, 24 Sep 2015 03:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.064 X-Spam-Level: X-Spam-Status: No, score=-96.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 fjbfW0f04t5w; Thu, 24 Sep 2015 03:45:36 -0700 (PDT) Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF991A0379; Thu, 24 Sep 2015 03:45:35 -0700 (PDT) Received: from [192.168.43.211] (ip-109-40-100-106.web.vodafone.de [109.40.100.106]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 6E4FD63ABC; Thu, 24 Sep 2015 12:45:31 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=kjk1JtO8Ao9EvQFARkO9RXKeZm2IywW+NhNMhqMMY4mO1RHCaJwghZLYhhGPqTxDHrFnKjO527sakS78oEC3FK20H5Q0ebojMfRrkx5BB42/Z1hwcrk7abdajbYmxA9YYzVB6IQsjhFgBxwAiUp19+T08ePVzqrkkYGfqnZWwlk=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type; Message-ID: <5603D448.3060701@gondrom.org> Date: Thu, 24 Sep 2015 03:45:28 -0700 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org, draft-ietf-v6ops-siit-dc.all@tools.ietf.org Content-Type: multipart/alternative; boundary="------------040602090704080503050005" Archived-At: Cc: tore@redpill-linpro.com Subject: [secdir] secdir review of draft-ietf-v6ops-siit-dc-02 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, 24 Sep 2015 10:45:38 -0000 This is a multi-part message in MIME format. --------------040602090704080503050005 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. The draft aims for informational status and describes a deployment model for traffic from legacy IPv4-only clients (on the Internet) is translated to IPv6 upon reaching the data centre. The document appears mostly ok for publication with a series of comments. One main question: Technically this document looks to me more like standards and not informational as I think we need to enforce consistent behaviour and restrictions to ensure overall consistency. IMO we need to spell this out more explicitly. This is a repeating element, I encountered in this review across multiple sections of the document (see explanations below). COMMENTS: 0. starting with a personal comment:in general it is nice to move again a step closer to a V6, even though these series of baby transition steps are quite small. Whether we need this in addition to other existing 64 protocols, I leave to the V6ops WG who has much better insight into this one than me. 1. This document has two strong requirements, that should be expressed in 2119 language. 1.1. the SIIT algorithm MUST be used. 1.2. And the security considerations section MUST be followed. 2. Section 7 Security Considerations: 2.1. The listed concern is correct. The listed mitigation step may work, I would suggest to also add a sentence when you do choose this distinct translation prefix, you also must configure your FW/GW at the edge to enforce the integrity of that naming scheme (e.g. by dropping packets from that prefix if not coming from a IPv4) to make sure there is no ambiguity or spoofing. We must avoid a blend of translated and untranslated addresses in the same prefix if you use the prefix as a marker. 2.2. I am not sure you covered all the security concerns in this section. 2.2.1. e.g. we might want to expand more on the risk that the DC does by design not see that we translate this down to V4 at the edge and thereby loose some of the capabilities of V6 beyond the edge. Therefore the DC may assume a fully V6 conformant client, which is not the case. This may lead to the need of further filtering or protection mechanisms at the edge. 2.2.2. the authors should expand more on architecture requirements not to put two of these translators in sequence (see possibly conflicts with 2.2.3. the authors should expand more on restrictions of putting this in a mixed environment with NAT64 3. section "4.4. Choice of Translation Prefix" - states: "Either a Network-Specific Prefix (NSP) from the provider's own IPv6 address space or the IANA-allocated Well-Known Prefix 64:ff9b::/96 (WKP) may be used." I think this needs to be a MUST instead of the "may". Also I do not like the ambiguity of prefixes here. We need to make it clear that this translastion MUST be consistent across all edges to the DC. 4. section 4.5. routing considerations: - do we need to specify that all alternate BRs must use the same algorithm and all MUST be able to support SIIT-DC? 5. section 4.6: we say "This should be understood to include all servers," I am not sure this is only a "should". From a lingual perspective it might be meaning that it "it should be understood that it requires..." but as the word "required" is not used, it is a bit unclear to me, whether that is also understood by the author/WG for this protocol. 6. section 4.8.: we use "To facilitate reliable delivery of such ICMPv6 errors n SIIT-DC operator SHOULD implement the recommendations in [RFC6791] in the BRs." Is there a security consideration on the impact what happens if RFC6791 is not followed and ICMPv6 errors are dropped? What would be the security implications of loosing not transmitting these messages? 7. section 4.9. "MTU and Fragmentation": it is good that we spell out the series of key differences between IPv4 and IPv6 relating to packet sizes and fragmentation that one needs to consider when deploying SIIT-DC. I am not sure a "should" is sufficient here. Furthermore, it would be good to consider whether we need to specify and mandate the specific behaviour when encountering these limitations to avoid inconsistent behaviour from the BR if these parameters are encountered and this might be exploited as an attack vector. Thank you and best regards. Tobias --------------040602090704080503050005 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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 aims for informational status and describes a deployment model for traffic from legacy IPv4-only clients (on the Internet) is translated to IPv6 upon reaching the data centre.

The document appears mostly ok for publication with a series of comments.
One main question: Technically this document looks to me more like standards and not informational as I think we need to enforce consistent behaviour and restrictions to ensure overall consistency. IMO we need to spell this out more explicitly. This is a repeating element, I encountered in this review across multiple sections of the document (see explanations below).

COMMENTS:
0. starting with a personal comment:in general it is nice to move again a step closer to a V6, even though these series of baby transition steps are quite small. Whether we need this in addition to other existing 64 protocols, I leave to the V6ops WG who has much better insight into this one than me.

1. This document has two strong requirements, that should be expressed in 2119 language.
1.1. the SIIT algorithm MUST be used.
1.2. And the security considerations section MUST be followed.

2. Section 7 Security Considerations:
2.1. The listed concern is correct. The listed mitigation step may work, I would suggest to also add a sentence when you do choose this distinct translation prefix, you also must configure your FW/GW at the edge to enforce the integrity of that naming scheme (e.g. by dropping packets from that prefix if not coming from a IPv4) to make sure there is no ambiguity or spoofing. We must avoid a blend of translated and untranslated addresses in the same prefix if you use the prefix as a marker.
2.2. I am not sure you covered all the security concerns in this section.
2.2.1. e.g. we might want to expand more on the risk that the DC does by design not see that we translate this down to V4 at the edge and thereby loose some of the capabilities of V6 beyond the edge. Therefore the DC may assume a fully V6 conformant client, which is not the case. This may lead to the need of further filtering or protection mechanisms at the edge.
2.2.2. the authors should expand more on architecture requirements not to put two of these translators in sequence (see possibly conflicts with 2.2.3. the authors should expand more on restrictions of putting this in a mixed environment with NAT64

3. section "4.4. Choice of Translation Prefix"
- states: "Either a Network-Specific Prefix (NSP) from the provider's own IPv6 address space or the IANA-allocated Well-Known Prefix 64:ff9b::/96 (WKP) may be used."
I think this needs to be a MUST instead of the "may". Also I do not like the ambiguity of prefixes here. We need to make it clear that this translastion MUST be consistent across all edges to the DC.

4. section 4.5. routing considerations:
- do we need to specify that all alternate BRs must use the same algorithm and all MUST be able to support SIIT-DC?

5. section 4.6:
we say "This should be understood to include all servers,"
I am not sure this is only a "should". From a lingual perspective it might be meaning that it "it should be understood that it requires..." but as the word "required" is not used, it is a bit unclear to me, whether that is also understood by the author/WG for this protocol.

6. section 4.8.:
we use "To facilitate reliable delivery of such ICMPv6 errors n SIIT-DC operator SHOULD implement the recommendations in [RFC6791] in the BRs." Is there a security consideration on the impact what happens if RFC6791 is not followed and ICMPv6 errors are dropped? What would be the security implications of loosing not transmitting these messages?

7. section 4.9. "MTU and Fragmentation":
it is good that we spell out the series of key differences between IPv4 and IPv6 relating to packet sizes and fragmentation that one needs to consider when deploying SIIT-DC. I am not sure a "should" is sufficient here. Furthermore, it would be good to consider whether we need to specify and mandate the specific behaviour when encountering these limitations to avoid inconsistent behaviour from the BR if these parameters are encountered and this might be exploited as an attack vector.

Thank you and best regards.

Tobias

--------------040602090704080503050005-- From nobody Thu Sep 24 06:12:30 2015 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 9EB611ACED9 for ; Thu, 24 Sep 2015 06:12:29 -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 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 wOj9mCmjHo0b for ; Thu, 24 Sep 2015 06:12:28 -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 EF5681ACEDC for ; Thu, 24 Sep 2015 06:12:27 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t8ODCPXa026798 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 24 Sep 2015 16:12:25 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t8ODCPAQ001042; Thu, 24 Sep 2015 16:12:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22019.63161.744165.150321@fireball.acr.fi> Date: Thu, 24 Sep 2015 16:12:25 +0300 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, 24 Sep 2015 13:12:29 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Scott Kelly is next in the rotation. For telechat 2015-10-01 Reviewer LC end Draft John Bradley T 2015-09-03 draft-ietf-mpls-lsp-ping-reply-mode-simple-04 Daniel Kahn Gillmor T 2015-09-17 draft-ietf-tzdist-caldav-timezone-ref-04 Dan Harkins T 2015-09-24 draft-ietf-bess-spbm-evpn-01 Christian Huitema T 2015-09-30 draft-ietf-teas-te-express-path-03 Chris Inacio T 2015-07-29 draft-ietf-homenet-dncp-10 Sean Turner TR2015-09-25 draft-ietf-mpls-lsp-ping-relay-reply-10 Tom Yu T 2015-09-08 draft-ietf-dhc-dhcpv4-active-leasequery-06 Dacheng Zhang T 2015-09-04 draft-ietf-dice-profile-16 For telechat 2015-10-15 Steve Hanna T 2015-10-09 draft-blanchet-ccsds-urn-00 Benjamin Kaduk T 2015-10-13 draft-ietf-ospf-node-admin-tag-04 Charlie Kaufman T 2015-10-05 draft-ietf-trill-cmt-08 Last calls and special requests: Donald Eastlake 2015-09-11 draft-ietf-dane-openpgpkey-05 Daniel Kahn Gillmor E None draft-ietf-rtcweb-security-08 Tobias Gondrom E None draft-ietf-rtcweb-security-arch-11 Olafur Gudmundsson 2015-09-22 draft-ietf-v6ops-siit-dc-2xlat-01 Phillip Hallam-Baker 2015-09-22 draft-ietf-v6ops-siit-eam-01 Paul Hoffman 2015-09-24 draft-ietf-teas-rsvp-te-srlg-collect-02 Jeffrey Hutzelman 2015-09-30 draft-ietf-v6ops-pmtud-ecmp-problem-04 Chris Inacio 2015-10-02 draft-ietf-lwig-ikev2-minimal-03 Leif Johansson 2015-10-02 draft-ietf-mpls-self-ping-04 Simon Josefsson 2015-10-07 draft-ietf-netconf-call-home-11 -- kivinen@iki.fi From nobody Thu Sep 24 17:24:53 2015 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 F2F141B42CC for ; Thu, 24 Sep 2015 17:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 cq86hLUzyi_Q for ; Thu, 24 Sep 2015 17:24:50 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (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 BB63E1B33DE for ; Thu, 24 Sep 2015 17:24:49 -0700 (PDT) Received: by lacdq2 with SMTP id dq2so26470868lac.1 for ; Thu, 24 Sep 2015 17:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=O+BxD70blJm/tW95h/TMSaAwktxSoeqL5vtVnsIssIE=; b=rIGTOyCJFUbpK51wferIkd6AOnYjFY9q0cHbhEGvEA6KsPljHthtfz/bRF4Iin1Ivn hxEY3qrv8LwdfyWAbpaxNK9iImNxl2fVOo0DdtsG1PmXE32WfMoBi1KINzLoRqmd9wsm XIwSdeoYF3oLTSAX/U0QnSd2VJAfjcsEyKZk/WfHTxhjHzqME6o+wL0VX+KoGXKgdOPX FUDiPiLnTQZFcWr/9xk9RqY+qAQpV5xNoh0tT0BM5eJbmF4QMsf2RNeyCw5xwdL9KQZr /RUVeIyF50+d0Zn7fl+KtHvZZTL0gtgGcsHWRbs60IZYgL1uivdWv252VJifmd6+Ogho N9/A== MIME-Version: 1.0 X-Received: by 10.112.168.194 with SMTP id zy2mr730808lbb.79.1443140687943; Thu, 24 Sep 2015 17:24:47 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.2.163 with HTTP; Thu, 24 Sep 2015 17:24:47 -0700 (PDT) Date: Thu, 24 Sep 2015 20:24:47 -0400 X-Google-Sender-Auth: pHGcZN2WFLRoLjmrTc30DMDTr_M Message-ID: From: Phillip Hallam-Baker To: "secdir@ietf.org" Content-Type: multipart/alternative; boundary=001a11c333f210e0a205208760a0 Archived-At: Subject: [secdir] Security Review of draft-ietf-v6ops-siit-eam-01 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: Fri, 25 Sep 2015 00:24:52 -0000 --001a11c333f210e0a205208760a0 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. The draft is essentially describing an extension to the IPv4/6 mapping mechanism to allow a mixture of mappings determined by fixed function and mappings determined by an address table. 7 . Security Considerations The EAM algorithm does not introduce any new security issues beyond those that are already discussed in Section 7 of [RFC6145] . Which points to. 7 . Security Considerations The use of stateless IP/ICMP translators does not introduce any new security issues beyond the security issues that are already present in the IPv4 and IPv6 protocols and in the routing protocols that are used to make the packets reach the translator. Both statements are incorrect. If we were to write out a modern Internet architecture we would no doubt decide that addresses have no significance above the transport layer and should not be visible to applications. But that isn't the Internet architecture we have today. Further most Internet services make use of IP addresses for various types of abuse mitigation. This is something that these mapping functions will have a significant impact on. Adding an address table capability provides even more potential to play various types of application layer routing games. This needs a comprehensive analysis. --001a11c333f210e0a205208760a0 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 ef= fort to review all IETF documents being processed by the IESG.=C2=A0 These = comments were written primarily for the benefit of the security area direct= ors.=C2=A0 Document editors and WG chairs should treat these comments just = like any other last call comments.

The draft is essentially describing an extension to= the IPv4/6 mapping mechanism to allow a mixture of mappings determined by = fixed function and mappings determined by an address table.

7.  Security Considerations

   The EAM algorithm does not introduce any new security issues beyond
   those that are already discussed in Section=C2=A07 of [RFC6145].

Which points to.

7=
.  Security Considerations

   The use of stateless IP/ICMP translators does not introduce any new
   security issues beyond the security issues that are already present
   in the IPv4 and IPv6 protocols and in the routing protocols that are
   used to make the packets reach the translator.

Both statements are=
 incorrect.
If we were to=
 write out a modern Internet architecture we would no doubt decide that add=
resses have no significance above the transport layer and should not be vis=
ible to applications. But that isn't the Internet architecture we have =
today.

Further most Inter=
net services  make use of IP addresses for various types of abuse mitigatio=
n. This is something that these mapping functions will have a significant i=
mpact on.

<=
/font>
Adding an addre=
ss table capability provides even more potential to play various types of a=
pplication layer routing games.


Thi=
s needs a comprehensive analysis.

--001a11c333f210e0a205208760a0-- From nobody Sun Sep 27 15:36:46 2015 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 1DA301B2FE3 for ; Sun, 27 Sep 2015 15:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553] 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 eE3zZ41-rrI9 for ; Sun, 27 Sep 2015 15:36:44 -0700 (PDT) Received: from hoffman.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 485031B2FE2 for ; Sun, 27 Sep 2015 15:36:44 -0700 (PDT) Received: from [10.32.60.60] (142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t8RMage1065170 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 27 Sep 2015 15:36:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123] claimed to be [10.32.60.60] From: "Paul Hoffman" To: secdir Date: Sun, 27 Sep 2015 15:36:42 -0700 Message-ID: <7BA110B0-7550-45EB-BA79-192551043742@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: [secdir] Secdir review of draft-ietf-teas-rsvp-te-srlg-collect 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: Sun, 27 Sep 2015 22:36:45 -0000 Greetings. This draft defines a new extension for RSVP-TE for collecting additional information. I could not see any security issues with the collection process or the proposed uses. The Security Considerations section is short, mostly hand-waving "you should be careful when doing this", but I couldn't think of anything better to say about any perceived threats. --Paul Hoffman From nobody Sun Sep 27 17:03:14 2015 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 396D81A1BCF for ; Sun, 27 Sep 2015 17:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 wiczf54iEica for ; Sun, 27 Sep 2015 17:03:12 -0700 (PDT) Received: from smtp90.iad3a.emailsrvr.com (smtp90.iad3a.emailsrvr.com [173.203.187.90]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A141A1BCA for ; Sun, 27 Sep 2015 17:03:12 -0700 (PDT) Received: from smtp20.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp20.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0548F18024B; Sun, 27 Sep 2015 20:03:11 -0400 (EDT) Received: by smtp20.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 5B8BA180237; Sun, 27 Sep 2015 20:03:10 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from [192.168.0.11] (c-98-210-197-105.hsd1.ca.comcast.net [98.210.197.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Mon, 28 Sep 2015 00:03:11 GMT From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_34AEB11C-E102-4143-8938-5F083E4B1A23" Date: Sun, 27 Sep 2015 20:03:08 -0400 Message-Id: To: draft-ietf-v6ops-siit-dc-2xlat@ietf.org, vg6ops@ietf.org, The IESG 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-ietf-v6ops-siit-dc-2xlat 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, 28 Sep 2015 00:03:13 -0000 --Apple-Mail=_34AEB11C-E102-4143-8938-5F083E4B1A23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have read the draft and it is well written.=20 I was not able to see any security issues with this draft that are not = covered in the security considerations or in the security considerations = of its accompanying draft ietf-v6ops-siit-dc Olafur --Apple-Mail=_34AEB11C-E102-4143-8938-5F083E4B1A23 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

I have read the draft and it is well written.

I was not able to see any security issues with this draft that are not covered in the security considerations or in the security considerations of its accompanying draft ietf-v6ops-siit-dc

Olafur

--Apple-Mail=_34AEB11C-E102-4143-8938-5F083E4B1A23-- From nobody Mon Sep 28 07:18:21 2015 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 B1BFC1A9245 for ; Mon, 28 Sep 2015 07:18:19 -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, 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 MHMz4PSDkDo3 for ; Mon, 28 Sep 2015 07:18:18 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 33AAC1A9231 for ; Mon, 28 Sep 2015 07:18:18 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so103787974wic.1 for ; Mon, 28 Sep 2015 07:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TnS1tsuZ4O0PWe+OzWndLx3RsK5ehSMQGBybT1twedY=; b=Qxc7BHitJ+dULPqr+kQLCyzSe9RYw5lBWIlOgyrDVzzLTIYtNOyMk8Y93lmp5qVoZK gUF5STLgEF+NolMNugwL2zGTjewBSEOD+xVDPheQr2Jrl6jscK0x5nSx9+fkBtHHqj2N 63g44MmqBre+IZjREFV7yFf8MKmOW0xtRq83U3xRmqnIwbxntIzE0QS9r+O4/vmnxr0S 2peEFnb7oh4OBGNvv55hGnpP+KKnsPQ2mTwiQwy2DAcmAJ40PN9lYvhABy4R50J61UT0 +K2ru7KR0iiWOa2WjZyE29bARy51XT91UZvcfmVijL7yaUnEf61fdBzi11iYKNbVyno0 X5ZA== MIME-Version: 1.0 X-Received: by 10.180.75.38 with SMTP id z6mr17890099wiv.36.1443449896756; Mon, 28 Sep 2015 07:18:16 -0700 (PDT) Received: by 10.28.214.213 with HTTP; Mon, 28 Sep 2015 07:18:16 -0700 (PDT) Date: Mon, 28 Sep 2015 10:18:16 -0400 Message-ID: From: Kathleen Moriarty To: "secdir@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Promoting a draft - tweet 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, 28 Sep 2015 14:18:19 -0000 Hi, If anyone else tweets, I think it would be good to raise awareness on this draft that is in IESG review this week: https://datatracker.ietf.org/doc/draft-ietf-dice-profile/ It is a very well-written draft that should go a long way in helping IoT/constrained device vendors integrate session encryption with DTLS/TLS. I tweeted already if you just want to retweet. @KathleeMoriarty -- Best regards, Kathleen From nobody Mon Sep 28 21:57:42 2015 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 1B1AE1A03AA for ; Mon, 28 Sep 2015 21:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 gr1iRobg1G1T for ; Mon, 28 Sep 2015 21:57:37 -0700 (PDT) Received: from xsmtp12.mail2web.com (xsmtp12.mail2web.com [168.144.250.177]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11B851A03A5 for ; Mon, 28 Sep 2015 21:57:37 -0700 (PDT) Received: from internal.xmail02.myhosting.com ([10.5.2.12] helo=xmail02.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1Zgmys-0006Yo-8I for secdir@ietf.org; Tue, 29 Sep 2015 00:57:36 -0400 Received: (qmail 18569 invoked from network); 29 Sep 2015 04:57:32 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Sep 2015 04:57:32 -0000 From: "Christian Huitema" To: , "'secdir'" , Date: Mon, 28 Sep 2015 21:57:36 -0700 Message-ID: <00c301d0fa73$5d0053f0$1700fbd0$@huitema.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C4_01D0FA38.B0A17BF0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdD6cUGBKeVv7UUNSbGaXvmeokPjrg== Content-Language: en-us Archived-At: Subject: [secdir] Secdir review of draft-ietf-teas-te-express-path-03 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, 29 Sep 2015 04:57:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C4_01D0FA38.B0A17BF0 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=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 This document is ready for publication as an informational RFC. =20 Draft-ietf-teas-te-express-path provides considerations on the use of performance criteria such as delay, loss and jitter when performing path selection when using routing protocols IS-IS or OSPF. The document = warns developers against using poor criteria and causing oscillation. It = provides guidance on the handling of paths whose measured criteria have changed. =20 The security section states that =93This document is not currently = believed to introduce new security concerns.=94 Well, I currently believe that the = authors may be correct about that. The only potential attack that I can think of would involve subtle manipulations of the criteria measurements in order = to induce path oscillations. Such attack scenario does not feel very = realistic or very serious. In any case that would not be a =93new=94 attack due to = this specific draft, but rather an existing attack on IS-IS or OSPF. =20 -- Christian Huitema =20 =20 =20 =20 ------=_NextPart_000_00C4_01D0FA38.B0A17BF0 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

ongoing effort to review all IETF documents = being processed by the

IESG.=A0 These comments were written = primarily for the benefit of the

security area directors.=A0 Document editors = and WG chairs should treat

these comments just like any other last call = comments.

This document is ready for publication as an = informational RFC.

Draft-ietf-teas-te-express-path provides = considerations on the use of performance criteria such as delay, loss = and jitter when performing path selection when using routing protocols = IS-IS or OSPF. The document =A0warns developers against using poor = criteria and causing oscillation. It provides guidance on the handling = of paths whose measured criteria have = changed.

The security section states that “This = document is not currently believed to introduce new security = concerns.” Well, I currently believe that the authors may be = correct about that. The only potential attack that I can think of would = involve subtle manipulations of the criteria measurements in order to = induce path oscillations. Such attack scenario does not feel very = realistic or very serious. In any case that would not be a = “new” attack due to this specific draft, but rather an = existing attack on IS-IS or OSPF.

-- Christian = Huitema

------=_NextPart_000_00C4_01D0FA38.B0A17BF0-- From nobody Tue Sep 29 19:44:21 2015 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 1513C1B5A00; Tue, 29 Sep 2015 19:44:18 -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 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 1okQHwf-ri3N; Tue, 29 Sep 2015 19:44:16 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BCEE1B2D4C; Tue, 29 Sep 2015 19:44:16 -0700 (PDT) X-AuditID: 12074423-f793f6d000007fc1-2e-560b4c7e815e 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 dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 22.48.32705.E7C4B065; Tue, 29 Sep 2015 22:44:14 -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 t8U2iENh012081; Tue, 29 Sep 2015 22:44:14 -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 t8U2iCGZ024382; Tue, 29 Sep 2015 22:44:13 -0400 From: Tom Yu To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dhc-dhcpv4-active-leasequery.all@tools.ietf.org Date: Tue, 29 Sep 2015 22:44:12 -0400 Message-ID: Lines: 19 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixG6nolvnwx1mMPepiUXPriXMFjP+TGS2 +LDwIYsDs8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlbF/Tz97wU72imd/DrE1MLawdTFy ckgImEi0LP/DBGGLSVy4tx4ozsUhJLCYSWLB2X0sIAkhgY2MEt+asiESbxglOt/vYgVJsAlI Sxy/vAusW0QgXeLy9u2MXYwcHMICLhLbNxmBhFkEVCX+TvoGVs4roCvxYdIFdhCbR4BTomfD L6i4oMTJmU/AdjELaEnc+PeSaQIj7ywkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbp munlZpbopaaUbmIEB5SL8g7GPweVDjEKcDAq8fC+EOAOE2JNLCuuzD3EKMnBpCTKe80LKMSX lJ9SmZFYnBFfVJqTWnyIUYKDWUmE96kFUI43JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZq akFqEUxWhoNDSYI33RuoUbAoNT21Ii0zpwQhzcTBCTKcB2i4O0gNb3FBYm5xZjpE/hSjLseC H7fXMgmx5OXnpUqJ80aDFAmAFGWU5sHNAScCIcZ9rxjFgd4S5p0PUsUDTCJwk14BLWECWjJX lwtkSUkiQkqqgXHCxX1vp9mznXsW5+awsPLR3H/T54ef1G/6X+F+W+eA26Iwtk+mCS+Ljl1p 4dTbaql85OHOo9sCTN9UvQqat6f/vbcHx8fXM/Wl5wQVCzc/OBozz/6LRxN31Y4qD4YV/rf+ sXULH+2//n/jkgDRnM8qE4xFdh46+okzTOaerMKZ+TJ16Vm3GMKVWIozEg21mIuKEwH9xotg 3wIAAA== Archived-At: Subject: [secdir] secdir review of draft-ietf-dhc-dhcpv4-active-leasequery-06 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, 30 Sep 2015 02:44:18 -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 Security Considerations of the draft seem reasonably complete. There could be a minor traffic analysis risk in some environments due to the real-time nature of Active Leasequery -- if the connection between an authorized requester and the DHCP server traverses network paths monitored by an adversary, the adversary could learn about the timing of DHCP events, and might be able distinguish among different types of events by the relative sizes of the messages. This could be true even if TLS is in use. I suspect that the risk is minimal in typical deployments. -Tom

7. Security Considerations

7= . Security Considerations