From nobody Thu Dec 1 03:14:56 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38191295D9; Thu, 1 Dec 2016 03:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCEfH1OISOwO; Thu, 1 Dec 2016 03:14:45 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 0B095129648; Thu, 1 Dec 2016 03:12:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1480590758; d=isode.com; s=june2016; i=@isode.com; bh=vftTWUcKKse+9PC3btGazs6qnof4/maPfGCeQrxEPZ0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=qmVHKcvyBA02UY+KHy4J7SrxpD65m7j+I4tsTZlbp1wvjM3xkazMgztwBQpQud8IWWCxMW 1KnPHD9uyaACYIy47v2mVcPjUY1Rl4k2pzLsXTFH4r/uwDHY8cpUAL1dePU8E1+NBPiQ3M 1Pn4DMb88WBCD5xMK0TFDwfEPmk9a5A=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 1 Dec 2016 11:12:38 +0000 To: Donald Eastlake , "iesg@ietf.org" , draft-ietf-appsawg-mdn-3798bis.all@ietf.org References: From: Alexey Melnikov Message-ID: <7b6ae784-bcdf-53e9-e878-d542f9fc1ed7@isode.com> Date: Thu, 1 Dec 2016 11:12:21 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------3E68C0BAE89FE91D5D50979E" Archived-At: Cc: "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-appsawg-mdn-3798bis-15 SECDIR Review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 11:14:48 -0000 --------------3E68C0BAE89FE91D5D50979E Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Donald, Thank you for your comments. On 01/12/2016 02:02, Donald Eastlake wrote: > My apologies for getting this in late. I have reviewed this document > as part of the security directorate's ongoing effort to review all > IETF documents being processed by the IESG. Document editors and WG > chairs should treat these comments just like any other last call comments. > > This draft appears to be ready for publication with some nits.. > > This draft polishes and advances to Internet Standard level RFC 3798 > on Message Disposition Notifications. > > _Security Considerations:_ > > The Security Considerations seem good except for one minor point: in > my opinion the option to return all or a portion of the original > message significantly increases the possible risk of use MDNs as a > traffic multiplier. I believe this should be mentioned in Section 6.4. Thank you, I've added some text on this to the first paragraph of Section 6.4: Additionally, as generated MDN notifications can include full content of messages that caused them and thus they can be bigger than such messages, they can be used for bandwidth amplification attacks. > > _Miscellaneous:_ > > The style of this draft is to say that you MUST do this and MUST NOT > do that without indicating what action should be taken if this is > violated. This is like saying a protocol field "MUST be zero" without > adding the usual "and is ignored on receipt". For example, in Section > 3 it says that a message disposition notification MUST NOT itself > request an MDN. I believe it should go on and add the few words to > say: "If one does, this is ignored." (unless that's wrong...) I'm not > saying this must always be done but there may be 1 or 2 other cases > like this in the draft where such wording should be added. This is a difficult area, because we typically don't describe how to handle violations of MUSTs. In the case that you mention above, the text is added in order to prevent loops. Not much can be done on recipients end other than usual handling of spam and/or broken implementations. Can you list other possible cases where you wanted some advice to be given? > _Wording:_ > > In Section 3, the wording of the last sentence of point d seems just a > bit obscure. It says > However, in the case of encrypted messages requesting MDNs, > encrypted message text MUST be returned, if it is returned at > all, only in its original encrypted form. > I think it would be a just bit clearer as > However, in the case of encrypted messages requesting MDNs, if > the original message or a portion thereof is returned, it MUST > be in its original encrypted form. I used your text, thank you. > > _Trivia:_ > > I do wonder if the references to X.400 mail are necessary. They seem > archaic. Does anyone run X.400 email any more? Yes :-) > It is just used as an example, along with proprietary mail systems. I > think such proprietary systems still exist, but X.400 mail? I'm not so > sure. If it is going to be retained, maybe there should be an > Informational reference for it. I will try to dig one out. --------------3E68C0BAE89FE91D5D50979E Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable

Hi Donald,

Thank you for your comments.


On 01/12/2016 02:02, Donald Eastlake wrote:
My apologies for getting this in late. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments.

This draft appears to be ready for publication with some nits..

This draft polishes and advances to Internet Standard level RFC 3798 on Message Disposition Notifications.

Security Considerations:

The Security Considerations seem good except for one minor point: in my opinion the option to return all or a portion of the original message significantly increases the possible risk of use MDNs as a traffic multiplier. I believe this should be mentioned in Section 6.4.

Thank you, I've added some text on this to the first paragraph of Section 6.4:

=A0 Additionally, as generated MDN notifications can include full content of messages that caused them
=A0 and thus they can be bigger than such messages, they can be used for bandwidth amplification attacks.


Miscellaneous:

The style of this draft is to say that you MUST do this and MUST NOT do that without indicating what action should be taken if this is violated. This is like saying a protocol field "MUST be zero" without adding the usual "and is ignored on receipt". For example, in Section 3 it says that a message disposition notification MUST NOT itself request an MDN. I believe it should go on and add the few words to say: "If one does, this is ignored." (unless that's wrong...) I'm not saying this must always be done but there may be 1 or 2 other cases like this in the draft where such wording should be added.

This is a difficult area, because we typically don't describe how to handle violations of MUSTs. In the case that you mention above, the text is added in order to prevent loops. Not much can be done on recipients end other than usual handling of spam and/or broken implementations.

Can you list other possible cases where you wanted some advice to be given?

Wording:

In Section 3, the wording of the last sentence of point d seems just a bit obscure. It says
       However, in the case of en=
crypted messages requesting MDNs,
       encrypted message text MUST be returned, if it is returned at
       all, only in its original encrypted form.
I think it would be a just bit clearer as
       However, in the case of en=
crypted messages requesting MDNs, if
       the original message or a =
portion thereof is returned, it MUST
       be in its original encrypt=
ed form.

I used your text, thank you.

Trivia:

I do wonder if the references to X.400 mail are necessary. They seem archaic. Does anyone run X.400 email any more?

Yes :-)

It is just used as an example, along with proprietary mail systems. I think such proprietary systems still exist, but X.400 mail? I'm not so sure. If it is going to be retained, maybe there should be an Informational reference for it.

I will try to dig one out.



--------------3E68C0BAE89FE91D5D50979E-- From nobody Thu Dec 1 04:18:32 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EC1129647; Thu, 1 Dec 2016 04:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKeWSmXfWf6D; Thu, 1 Dec 2016 04:18:28 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0137.outbound.protection.outlook.com [104.47.32.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5309F129687; Thu, 1 Dec 2016 04:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OP2fUCCzQsWd3P9cdUXnrgn0ai5HgH4tapyFoYjEYSg=; b=MeaF4IGXX17FXU5N2OTQ8ao6ee/k6WOHJ5NtXyOx20kOWk9ov87K0+54sarE+MEub2uEot8z20mRbaqRUJ01d/w/it5PayY+Y7WF1bM7wuEH7dZtVcIGdifitxPwRGtnqZZZ21PgZqsVc60VNLmTH/BedhVUMo5jLRMOLDAwLDc= Received: from BN3PR0501MB1554.namprd05.prod.outlook.com (10.161.217.144) by BN3PR0501MB1555.namprd05.prod.outlook.com (10.161.217.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.5; Thu, 1 Dec 2016 12:18:26 +0000 Received: from BN3PR0501MB1554.namprd05.prod.outlook.com ([10.161.217.144]) by BN3PR0501MB1554.namprd05.prod.outlook.com ([10.161.217.144]) with mapi id 15.01.0761.010; Thu, 1 Dec 2016 12:18:26 +0000 From: Yimin Shen To: "Andrew G. Malis" , Chris Lonvick Thread-Topic: SECDIR review of draft-ietf-pals-endpoint-fast-protection-04 Thread-Index: AQHSS2lfmRLku9u1+0Ws0C5Hk3Ol4qDyb7iAgAA/r4A= Date: Thu, 1 Dec 2016 12:18:26 +0000 Message-ID: <98304BC2-6D5C-4472-8AE9-862BE3D51B30@juniper.net> References: <583F6DDB.1070300@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.18.0.160709 authentication-results: spf=none (sender IP is ) smtp.mailfrom=yshen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 8128e551-190a-4e27-12c5-08d419e42716 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1555; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1555; 7:uuyIyfddN/oO9Ya+lgepZltUTKDWSGMJBQRweaKr1/Frwl+Kde1q82pchF/oXDCkBX8CJMwVXxl6iSxbTFlGriurQGy7Yl2LI2F6wtekc0oqUatZlFEhsvHnlIqth9lIelzrP0KFlevexVjDy+kuOZ3IHsj9+QlQ8j5HGlLBrxVS54THB+cJBEyPpfqAK5KuNuATaOvLFbR1YVqzcMvSVfoC5h6xLdSca5nFKlRMX8v7Z2xbSxa8aAL645eIWZMxLBlS2bcsrx+ByvB0hJ3jP3uJ3/e5xxgqnzxeA1Jg7rwbC0TlcVUTYkUHF/VrLOQUXVmi/6PU5iyKj3eYxSKiYTycV/NCabNa8rkl4XRE534S6jjt9eYi+h/V0lauam1YlPEW5RNz3Q97ukyjcD3zx5jNm+xCCoYWYSQ9UGc2fCmExTyW4Do2nqc8xY+bgvwTGyBG34ei8VpHgXrQimD+LA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(192374486261705)(138986009662008)(97927398514766)(95692535739014)(21748063052155)(201166117486090)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(20161123558021)(6072148); SRVR:BN3PR0501MB1555; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1555; x-forefront-prvs: 014304E855 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(189002)(199003)(24454002)(8676002)(81166006)(5660300001)(81156014)(6512003)(606004)(6506003)(97736004)(229853002)(4001350100001)(38730400001)(9326002)(39060400001)(189998001)(5001770100001)(122556002)(66066001)(86362001)(82746002)(99286002)(105586002)(8936002)(3846002)(6116002)(102836003)(106116001)(106356001)(83506001)(36756003)(83716003)(54356999)(76176999)(50986999)(101416001)(92566002)(33656002)(3660700001)(3280700002)(230783001)(2906002)(2900100001)(4326007)(6486002)(39410400001)(39450400002)(77096006)(68736007)(7736002)(2950100002)(7846002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1555; H:BN3PR0501MB1554.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_98304BC26D5C44728AE9862BE3D51B30junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2016 12:18:26.2716 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1555 Archived-At: Cc: "draft-ietf-pals-endpoint-fast-protection.all@ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-pals-endpoint-fast-protection-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 12:18:31 -0000 --_000_98304BC26D5C44728AE9862BE3D51B30junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hyaXMsDQoNClRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHlvdXIgcmV2aWV3ICENCg0KVGhhbmtz LA0KDQotLSBZaW1pbg0KDQoNCkZyb206ICJBbmRyZXcgRy4gTWFsaXMiIDxhZ21hbGlzQGdtYWls LmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgTm92ZW1iZXIgMzAsIDIwMTYgYXQgMTA6MzAgUE0NClRv OiBDaHJpcyBMb252aWNrIDxsb252aWNrLmlldGZAZ21haWwuY29tPg0KQ2M6ICJpZXNnQGlldGYu b3JnIiA8aWVzZ0BpZXRmLm9yZz4sICJzZWNkaXJAaWV0Zi5vcmciIDxzZWNkaXJAaWV0Zi5vcmc+ LCAiZHJhZnQtaWV0Zi1wYWxzLWVuZHBvaW50LWZhc3QtcHJvdGVjdGlvbi5hbGxAaWV0Zi5vcmci IDxkcmFmdC1pZXRmLXBhbHMtZW5kcG9pbnQtZmFzdC1wcm90ZWN0aW9uLmFsbEBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBTRUNESVIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcGFscy1lbmRwb2ludC1m YXN0LXByb3RlY3Rpb24tMDQNClJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0BpZXRmLm9yZz4N ClJlc2VudC1UbzogWWltaW4gU2hlbiA8eXNoZW5AanVuaXBlci5uZXQ+LCA8cmFnZ2Fyd2FfMUB5 YWhvby5jb20+LCA8d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuYmU+LCA8amlhbmd5dWFu bG9uZ0BodWF3ZWkuY29tPiwgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4sIDxhZ21hbGlzQGdt YWlsLmNvbT4sIDxkYXZpZC5zaW5pY3JvcGVAZXJpY3Nzb24uY29tPiwgPGFyZXRhbmFAY2lzY28u Y29tPiwgPGRiMzU0NkBhdHQuY29tPiwgPGFrYXRsYXNAZ21haWwuY29tPiwgU3Rld2FydCBCcnlh bnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4NClJlc2VudC1EYXRlOiBXZWRuZXNkYXksIE5v dmVtYmVyIDMwLCAyMDE2IGF0IDEwOjMxIFBNDQoNCkNocmlzLA0KDQpUaGFua3MgZm9yIHlvdXIg cmV2aWV3IQ0KDQpDaGVlcnMsDQpBbmR5DQooUEFMUyBjby1jaGFpcikNCg0KDQpPbiBXZWQsIE5v diAzMCwgMjAxNiBhdCA3OjI0IFBNLCBDaHJpcyBMb252aWNrIDxsb252aWNrLmlldGZAZ21haWwu Y29tPG1haWx0bzpsb252aWNrLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpIaSwNCg0KSSBoYXZl IHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3Jh dGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHBy b2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmls eSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVu dCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3Qg bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpJJ20gbm90IGZhbWlsaWFyIHdp dGggdGhpcyB0ZWNobm9sb2d5IGJ1dCB0aGUgc3BlY2lmaWNhdGlvbiBhcHBlYXJzIHRvIGFkZHJl c3MgdGhlIHNlY3VyaXR5IGNvbmNlcm5zLiBJIGxpa2UgdGhhdCB0aGUgcmVsZXZhbnQgUkZDcyBm b3IgdGhlIGJhc2UgYW5kIGFzc29jaWF0ZWQgcHJvdG9jb2xzIGFyZSBlYWNoIGxpc3RlZCBpbiB0 aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbi4NCg0KVGhlIGRvY3VtZW50IGFwcGVh cnMgd2VsbCB3cml0dGVuIGFuZCBJIGZvdW5kIG5vIG5pdHMgaW4gbXkgYWxiZWl0IGJyaWVmIHJl dmlldy4NCg0KQmVzdCByZWdhcmRzLA0KQ2hyaXMNCg0K --_000_98304BC26D5C44728AE9862BE3D51B30junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0K CXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1l OiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj5IaSBDaHJpcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij5UaGFua3MgdmVyeSBtdWNoIGZvciB5b3VyIHJldmlldyAhPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+VGhhbmtzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7 Y29sb3I6YmxhY2siPi0tIFlpbWluPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+JnF1b3Q7QW5kcmV3IEcuIE1hbGlz JnF1b3Q7ICZsdDthZ21hbGlzQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVz ZGF5LCBOb3ZlbWJlciAzMCwgMjAxNiBhdCAxMDozMCBQTTxicj4NCjxiPlRvOiA8L2I+Q2hyaXMg TG9udmljayAmbHQ7bG9udmljay5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZx dW90O2llc2dAaWV0Zi5vcmcmcXVvdDsgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtzZWNk aXJAaWV0Zi5vcmcmcXVvdDsgJmx0O3NlY2RpckBpZXRmLm9yZyZndDssICZxdW90O2RyYWZ0LWll dGYtcGFscy1lbmRwb2ludC1mYXN0LXByb3RlY3Rpb24uYWxsQGlldGYub3JnJnF1b3Q7ICZsdDtk cmFmdC1pZXRmLXBhbHMtZW5kcG9pbnQtZmFzdC1wcm90ZWN0aW9uLmFsbEBpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFNFQ0RJUiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wYWxz LWVuZHBvaW50LWZhc3QtcHJvdGVjdGlvbi0wNDxicj4NCjxiPlJlc2VudC1Gcm9tOiA8L2I+Jmx0 O2FsaWFzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+UmVzZW50LVRvOiA8L2I+WWltaW4g U2hlbiAmbHQ7eXNoZW5AanVuaXBlci5uZXQmZ3Q7LCAmbHQ7cmFnZ2Fyd2FfMUB5YWhvby5jb20m Z3Q7LCAmbHQ7d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuYmUmZ3Q7LCAmbHQ7amlhbmd5 dWFubG9uZ0BodWF3ZWkuY29tJmd0OywgJmx0O3N0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbSZndDss ICZsdDthZ21hbGlzQGdtYWlsLmNvbSZndDssICZsdDtkYXZpZC5zaW5pY3JvcGVAZXJpY3Nzb24u Y29tJmd0OywgJmx0O2FyZXRhbmFAY2lzY28uY29tJmd0OywgJmx0O2RiMzU0NkBhdHQuY29tJmd0 OywNCiAmbHQ7YWthdGxhc0BnbWFpbC5jb20mZ3Q7LCBTdGV3YXJ0IEJyeWFudCAmbHQ7c3Rld2Fy dC5icnlhbnRAZ21haWwuY29tJmd0Ozxicj4NCjxiPlJlc2VudC1EYXRlOiA8L2I+V2VkbmVzZGF5 LCBOb3ZlbWJlciAzMCwgMjAxNiBhdCAxMDozMSBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaHJpcywg PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9y IHlvdXIgcmV2aWV3ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4oUEFMUyBjby1jaGFpcik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE5vdiAzMCwgMjAxNiBhdCA3OjI0 IFBNLCBDaHJpcyBMb252aWNrICZsdDs8YSBocmVmPSJtYWlsdG86bG9udmljay5pZXRmQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxvbnZpY2suaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGksPGJyPg0KPGJyPg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBv ZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxs IElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhlc2UgY29tbWVu dHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5 IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMNCiBzaG91bGQg dHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVu dHMuPGJyPg0KPGJyPg0KSSdtIG5vdCBmYW1pbGlhciB3aXRoIHRoaXMgdGVjaG5vbG9neSBidXQg dGhlIHNwZWNpZmljYXRpb24gYXBwZWFycyB0byBhZGRyZXNzIHRoZSBzZWN1cml0eSBjb25jZXJu cy4gSSBsaWtlIHRoYXQgdGhlIHJlbGV2YW50IFJGQ3MgZm9yIHRoZSBiYXNlIGFuZCBhc3NvY2lh dGVkIHByb3RvY29scyBhcmUgZWFjaCBsaXN0ZWQgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zIHNlY3Rpb24uPGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50IGFwcGVhcnMgd2VsbCB3cml0dGVu IGFuZCBJIGZvdW5kIG5vIG5pdHMgaW4gbXkgYWxiZWl0IGJyaWVmIHJldmlldy48YnI+DQo8YnI+ DQpCZXN0IHJlZ2FyZHMsPGJyPg0KQ2hyaXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_98304BC26D5C44728AE9862BE3D51B30junipernet_-- From nobody Thu Dec 1 05:04:15 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7259E1294FE; Thu, 1 Dec 2016 05:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdFPMfrwn4LF; Thu, 1 Dec 2016 05:04:10 -0800 (PST) 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 C1A3B129498; Thu, 1 Dec 2016 05:04:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CFE0DBE2C; Thu, 1 Dec 2016 13:04:06 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2EExNX3XAM8; Thu, 1 Dec 2016 13:04:04 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C0519BECA; Thu, 1 Dec 2016 13:03:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1480597439; bh=WbX4A/EWEjSS+DkI8SkwBayTBDuisa+HNkj55kUN53E=; h=Subject:References:To:Cc:From:Date:In-Reply-To:From; b=Av99dTCZnFKpE3cUIcQdtowQYIkj4D7kF2eC0v6YX/HVJy5GiwcFhF5kIj+OPRWNf wA8SYdCLA7j0zacu6xJyyDgxZTwu+tys/otwxeSnMP9WT17oYkp/EqkTxd9dtysDr+ b+FoAIYb+vL+RfCmRN6RVwjAbAteL0nHpXDdrG2o= References: To: "secdir@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: Message-ID: Date: Thu, 1 Dec 2016 13:03:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090203020201040703090200" Archived-At: Cc: Phillip Hallam-Baker , draft-holmberg-dispatch-received-realm@ietf.org Subject: [secdir] Fwd: Re: SecDIR review of draft-holmberg-dispatch-received-realm-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 13:04:13 -0000 This is a cryptographically signed message in MIME format. --------------ms090203020201040703090200 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable (Just forwarding this here as it the list wasn't cc'd on the discussion but I wanted to be able to point at this in the archive in my ballot.) S -------- Forwarded Message -------- Subject: Re: SecDIR review of draft-holmberg-dispatch-received-realm-10 Date: Thu, 1 Dec 2016 08:52:10 +0000 From: Christer Holmberg To: Phillip Hallam-Baker CC: draft-holmberg-dispatch-received-realm@ietf.org , The IESG Hi, >>>>I have reviewed this document as part of the security directorate's >>>>ongoing effort to review all IETF documents being processed by the >>>>IESG. These comments were written primarily for the benefit of the >>>>security area directors. Document editors and WG chairs should treat >>>>these comments just like any other last call comments. >>> >>>Summary: Needs some additional explanation >>> >>>The basic mechanisms look fine. What I am less happy with are the secu= rity considerations. >>> >>>>The security challenge in SIP is trying to introduce security into a = legacy infrastructure that has none. As such, there is inevitably an elem= ent of attempting to nail jello to a wall: the nails >>>>are strong enough but the jello is not. I think there needs to be mor= e discussion of the potential shortcomings of the input data. >>> >>>I am not sure I understand. Is your comment related to the SIP informa= tion used to create the signature, or? =E2=80=8B>>Yes, how is the interpreter meant to interpret the signed data= ? Just because data is signed does not make it trustworthy. All that is known is who signed it. There are two main sources of concern: >> >>1) The signer may be malicious >> >>2) The signer may be signing data received from an untrustworthy source= =2E >> >>The second is the bigger concern as it may well be inevitable. But it i= s a concern that needs to be explained.=E2=80=8B >> >>Note that the received realm parameter value is inserted, signed, verif= ied and consumed within the same operator network. It is not received fro= m elsewhere. >> >>The other SIP information elements that are used when calculating the s= ignature will be forwarded anyway (which is the reason we use Annex F). >> >>In the initial versions of the draft, the information wasn=E2=80=99t ev= en signed. The operator network entry node simply inserted the received-r= ealm parameter in the SIP request unsigned. >> =E2=80=8B>>That was not apparent when I read the draft. I think it needs = to be made explicit in the security considerations section. =E2=80=8B >> =E2=80=8B>>Intra-organization trust is easier to manage than inter-organi= zation trust.=E2=80=8B > >What about adding the following paragraph to the Security Considerations= ? > >"The received-realm Via header field parameter is inserted, signed, veri= fied and consumed within an operator network. >The operator MUST discard parameters received >from another network, and= the parameter MUST only be inserted by >SIP entities that are able to verify from which adjacent upstream networ= k a SIP request is received." =E2=80=8B>That helps a lot=E2=80=8B Great! I will add it. >>>>The other issue I had was with the requirements for administration of= keys. There is a MUST here: "The operator MUST change the key on a frequ= ent basis." >>>> >>>>What is the security concern driving this requirement? Changing keys = has security costs as well as benefits. It is not something that should b= e done for the sake of it. >>> >>>I think the concern is the same as for keys in general: to avoid a val= id key getting into the "wrong hands". >>> =E2=80=8B>>> Every security control should have a reason. >>> >>> Key rollover limits the damage that a single key compromise can cause= but introduces an additional point of vulnerability. So it is not to be = done just because =E2=80=8B=E2=80=8B it is assumed to be good practice. =E2=80=8B >>> =E2=80=8B>>> Rather than introducing a MUST here, it would be more approp= riate to point to a document on key management. I think EKR wrote one. I will look it up. >> =E2=80=8B>> Given the previous comment, I think it would be rather more u= seful to adopt an approach where every signing device has its own key, the key is bound to the device using hardware techniques that resist extraction and any expiry mechanism is driven by the system for tracking=E2=80=8B =E2=80=8Bthe devices.=E2=80=8B > > In today=E2=80=99s world of clouds, virtualisation etc, where users hav= e little or no influence/access to the hardware, I think it would be diff= icult to mandate such thing. > =E2=80=8B> True, but right now you have a MUST in the security considerat= ions that cuts against that approach. > > I suggest you drop the MUST - which isn't actually enforceable as I see= it and instead state the considerations that should drive key management= =2E=E2=80=8B Ok, I will drop the MUST. Regarding =E2=80=9Cstate the considerations that should drive key managem= ent=E2=80=9D, does the following text help? =E2=80=9CThe operator MUST use a key management policy that protects agai= ns unauthorised access to the stored keys within nodes where they keys are stored, and that protects against crypto analysis attacks using captured data sent on the wire.=E2=80=9D I am sure there is LOTS more details that could be said about key management, but in that case it would probably be better to add a reference rather than copy/paste everything :) Regards, Christer --------------ms090203020201040703090200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMDEx MzAzNThaMC8GCSqGSIb3DQEJBDEiBCBqQOjnjk8zG4eIZgli26jS0Ay229BYm9ppdmazC5Wv lTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAIw7ZVgg7CaTWB5WgTxCoExqFZPDB0hmyX6rwjxf52dN0QMKA71zNu c81Z8QCdqydyxVDCxBKhaWfOEHr3nZwQZH85KxZd0LicHfHvX4niyeYRoXas/YXQNU2X6RTr WCVvFfWLK2G2mWDPUvwgXTxpuG60dqj6za4fpvaftksPSIhcYzLAohLz1v+P0/VsZzXUHb9F tPAz/35wxUxIEK05YIX0tp/DFAc/yDMzPt3I5rs2H4SfhPeKG3u4ySMRJeIQqmgsJdbtewYc FV5lMufGiZ3jRjlbcYU14nDtu3fZiHQatbxzcBPIhD/nU8hLuC4FhXvf+WCZkmg1s++nlsFq AAAAAAAA --------------ms090203020201040703090200-- From nobody Thu Dec 1 06:22:36 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAFD12948A for ; Thu, 1 Dec 2016 06:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzIDHcWgt76Y for ; Thu, 1 Dec 2016 06:22:33 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E222D129468 for ; Thu, 1 Dec 2016 06:22:32 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uB1EMTOq018411 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 1 Dec 2016 16:22:29 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uB1EMToh001816; Thu, 1 Dec 2016 16:22:29 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22592.12837.20660.776823@fireball.acr.fi> Date: Thu, 1 Dec 2016 16:22:29 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 3 min X-Total-Time: 3 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 14:22:35 -0000 We are now in progess of taking the new review team tool to use, and it is already live in the datatracker. So you should able to see your own reviews etc in there. If you want you can also use the tool to close up the review in addition to sending the email to relevant lists, but I also do that if you do not it yet. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Matthew Miller is next in the rotation. For telechat 2016-12-01 Reviewer LC end Draft Shaun Cooley T 2016-11-03 draft-ietf-kitten-pkinit-freshness-07 Phillip Hallam-Baker T 2016-11-23 draft-holmberg-dispatch-received-realm-10 Steve Hanna T 2016-11-10 draft-ietf-dnsop-resolver-priming-09 Leif Johansson T 2016-11-30 draft-ietf-6lo-6lobac-06 Ben Laurie TR2016-10-10 draft-levine-herkula-oneclick-09 Tina TSOU T 2016-11-14 draft-ieee-urn-03 For telechat 2016-12-15 Dan Harkins T 2016-11-16 draft-ietf-dprive-dnsodtls-13 Simon Josefsson T 2016-12-02 draft-ietf-6lo-dect-ule-08 Tero Kivinen TR2016-12-07 draft-ietf-sidr-origin-validation-signaling-10 Warren Kumari TR2016-12-08 draft-wilde-json-seq-suffix-01 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Stephen Kent E None draft-ietf-dnssd-pairing-00 Ben Laurie 2016-12-08 draft-ietf-6lo-dispatch-iana-registry-06 Matt Lepinski 2016-12-14 draft-ietf-avtext-avpf-ccm-layered-03 David Mandelberg 2016-12-26 draft-elie-nntp-tls-recommendations-01 Catherine Meadows 2016-12-13 draft-ietf-oauth-amr-values-04 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-15 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-07 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-10 Dacheng Zhang R2016-12-13 draft-ietf-core-http-mapping-17 -- kivinen@iki.fi From nobody Thu Dec 1 08:19:51 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC9F127058; Thu, 1 Dec 2016 08:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZhvpAqTAAYH; Thu, 1 Dec 2016 08:19:43 -0800 (PST) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (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 A98B11294C5; Thu, 1 Dec 2016 08:19:37 -0800 (PST) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id uB1GJZHY017982 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 1 Dec 2016 11:19:35 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_DCFDC443-C4CC-4C92-B6FE-1CF9E721AF03" Date: Thu, 1 Dec 2016 11:19:35 -0500 Message-Id: To: secdir@ietf.org, iesg@ietf.org, draft-ietf-oauth-amr-values.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Subject: [secdir] SECDIR Review of draft-ietf-oauth-amr-values-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 16:19:46 -0000 --Apple-Mail=_DCFDC443-C4CC-4C92-B6FE-1CF9E721AF03 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This document establishes a registry for Authentication Method Reference = (amr) values used by the OpenID protocol and defines an initial set of = such values. The amr claim is already defined and registered in IANA; this document serves to implement it. The amr provides a field = in which information about the type of authentication being used is = provided, using the amr values. The authors of the document address both security and privacy concerns, = The privacy concern is that the amr claim provides information about the = form of authentication used, which could have privacy implications in some cases, and that this document does not = provide any guidance as to how privacy-relevant credentials, such as = biometric information, are stored and protected. As the authors point out, the latter is beyond the scope of the document. =20 The security concerns are mainly derived from those of the OpenID = protocol. The authors also warn that amr may be more brittle than = another related claim, acr, since acr provides information about whether a particular set of business rules were satisfied, while acm = only tells you whether a particular type of authentication was used. = This could lead to a policy that relies on particular forms of = authentication, which would be harder to update as security needs change. =20 I think that the authors have done a good job of addressing security and = privacy concerns, and I don=E2=80=99t see any issues here. I consider = this document ready. Cathy Meadows Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil = --Apple-Mail=_DCFDC443-C4CC-4C92-B6FE-1CF9E721AF03 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I have reviewed this document as part of the security = directorate's ongoing effort to review all IETF documents being = processed by the IESG. These comments were written primarily for the = benefit of the security area directors. Document editors and WG chairs = should treat these comments just like any other last call = comments.

This document establishes a registry for Authentication = Method Reference (amr) values used by the OpenID protocol and = defines an initial set of such values.   The amr claim is = already defined and registered
in IANA; this = document serves to implement it.  The amr provides a = field in which information about the type of authentication being used = is provided, using the amr values.

The authors of the document address = both security and privacy concerns,  The privacy concern is that = the amr claim provides information about the form of authentication = used, which could have
privacy implications in some = cases, and that this document does not provide any guidance as to how = privacy-relevant credentials, such as biometric information, are stored = and protected.  As the authors
point out, the = latter is beyond the scope of the document.  

The security concerns = are mainly derived from those  of the OpenID protocol.  The = authors also warn that amr may be more brittle than another related = claim, acr, since acr provides information about
whether a particular set of business rules were satisfied, = while acm only tells you whether a particular type of authentication was = used.  This could lead to a policy that relies on particular forms = of authentication,
which would be harder to update = as security needs change.  

I think that the authors have done a = good job of addressing security and privacy concerns, and I don=E2=80=99t = see any issues here. I consider this document ready.

Cathy Meadows



Catherine Meadows
Naval Research = Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: = 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil

= --Apple-Mail=_DCFDC443-C4CC-4C92-B6FE-1CF9E721AF03-- From nobody Thu Dec 1 09:22:07 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99931297CD; Thu, 1 Dec 2016 09:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xl7tL1xy6mA1; Thu, 1 Dec 2016 09:22:03 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 7EFA81297B8; Thu, 1 Dec 2016 09:22:03 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id c21so397907644ioj.1; Thu, 01 Dec 2016 09:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RcBa0QG/PDeOZHGOjzYKq9Ckl2bM1NANddHxCuWLiCw=; b=fW9XxJzy4lSWE8AM040JNfwAjvrvqT5HtG9wNWv1f8vcFrNGHQvwDd/uBQ7SvQyUt2 fFo4n5G1K1E8O39ijtHP6snjHPizaOxC1Y38PyCwtVgyGtsIJVfWu5a7OZby7k3wq80S xJb3+392Gi6QA1gexGYv+U1geIrfbkd5lGGe+tc6U9zJ/HA7x/QNm/tzQPrcUb79Tu03 SRhdEbzsEnJ28zMptYaR55ppLk+nbHHpRWYf+1CK3F9ynJ7Qk63ULO2N7zt+NLX6hzBB kt+4BasdpeJr9BUXW+DFe6ngsO92TgWp21oGG17GuLY+RL+Qqr7nKvOpmv2e4UFE62fC jYNQ== 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:from:date :message-id:subject:to:cc; bh=RcBa0QG/PDeOZHGOjzYKq9Ckl2bM1NANddHxCuWLiCw=; b=NEkwBvKVOJpPinTfr/aAv67eqDMESexOvHPfr51/jt39KQlCgSA+4Q8ZqAdfqFGk+Q 4xd0axIgEYnFV+UxR5ZJj8CTEpmPtIZYoIeHdbLoScfScAvWbTffD0wkBJzLHV6euhtd 2HaAchDiSL65XFUfDlcb5tKyrhWAeu6f/2uawZpRjYodjzX9v0ijiSXoSi3oU0gCr+bt xCs0DNWfecSFjqoJdAe/xHKpYvaYadvmHTLxXTgN5pklXV+c3RgfTWgdRHbS/Ot7sUBM f5V2WfeXtb5DWSf4VYqYni2P1rPZfLmKX0px6HUb4NPs/fJxC98PETqi6ApfPBON/kzb MsSw== X-Gm-Message-State: AKaTC01L2Ja6anvWq1JEKmpoPadKzC45eutwdv+5IJ+YNZiWzwdj507sgWV6ejFygoVHSezD5e9S0xmqCSW8Vg== X-Received: by 10.36.33.151 with SMTP id e145mr31505533ita.14.1480612914759; Thu, 01 Dec 2016 09:21:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.33.6 with HTTP; Thu, 1 Dec 2016 09:21:39 -0800 (PST) In-Reply-To: <7b6ae784-bcdf-53e9-e878-d542f9fc1ed7@isode.com> References: <7b6ae784-bcdf-53e9-e878-d542f9fc1ed7@isode.com> From: Donald Eastlake Date: Thu, 1 Dec 2016 12:21:39 -0500 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a114794eed58ec705429c0e79 Archived-At: Cc: draft-ietf-appsawg-mdn-3798bis.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-appsawg-mdn-3798bis-15 SECDIR Review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 17:22:06 -0000 --001a114794eed58ec705429c0e79 Content-Type: text/plain; charset=UTF-8 Hi, On Thu, Dec 1, 2016 at 6:12 AM, Alexey Melnikov wrote: > Hi Donald, > > Thank you for your comments. > > On 01/12/2016 02:02, Donald Eastlake wrote: > > My apologies for getting this in late. I have reviewed this document as > part of the security directorate's ongoing effort to review all IETF > documents being processed by the IESG. Document editors and WG chairs > should treat these comments just like any other last call comments. > > This draft appears to be ready for publication with some nits.. > > This draft polishes and advances to Internet Standard level RFC 3798 on > Message Disposition Notifications. > > *Security Considerations:* > > The Security Considerations seem good except for one minor point: in my > opinion the option to return all or a portion of the original message > significantly increases the possible risk of use MDNs as a traffic > multiplier. I believe this should be mentioned in Section 6.4. > > > Thank you, I've added some text on this to the first paragraph of Section > 6.4: > > Additionally, as generated MDN notifications can include full content of > messages that caused them > and thus they can be bigger than such messages, they can be used for > bandwidth amplification attacks. > OK. > > > *Miscellaneous:* > > The style of this draft is to say that you MUST do this and MUST NOT do > that without indicating what action should be taken if this is violated. > This is like saying a protocol field "MUST be zero" without adding the > usual "and is ignored on receipt". For example, in Section 3 it says that a > message disposition notification MUST NOT itself request an MDN. I believe > it should go on and add the few words to say: "If one does, this is > ignored." (unless that's wrong...) I'm not saying this must always be done > but there may be 1 or 2 other cases like this in the draft where such > wording should be added. > > > This is a difficult area, because we typically don't describe how to > handle violations of MUSTs. In the case that you mention above, the text is > added in order to prevent loops. Not much can be done on recipients end > other than usual handling of spam and/or broken implementations. > > Can you list other possible cases where you wanted some advice to be given? > Actually, this is the only one that really struck me... > *Wording:* > > In Section 3, the wording of the last sentence of point d seems just a bit > obscure. It says > > However, in the case of encrypted messages requesting MDNs, > encrypted message text MUST be returned, if it is returned at > all, only in its original encrypted form. > > I think it would be a just bit clearer as > > However, in the case of encrypted messages requesting MDNs, if > > the original message or a portion thereof is returned, it MUST > > be in its original encrypted form. > > > I used your text, thank you. > You're welcome. > > > *Trivia:* > > I do wonder if the references to X.400 mail are necessary. They seem > archaic. Does anyone run X.400 email any more? > > > Yes :-) > OK. Didn't know that. > > It is just used as an example, along with proprietary mail systems. I > think such proprietary systems still exist, but X.400 mail? I'm not so > sure. If it is going to be retained, maybe there should be an Informational > reference for it. > > > I will try to dig one out. > OK. I would guess there is some ITU X.400-19xx standard or something... Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --001a114794eed58ec705429c0e79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Thu, Dec 1, 2016 at 6:12 AM, Ale= xey Melnikov <alexey.melnikov@isode.com> wrote:
<= /div>
=20 =20 =20

Hi Donald,

Thank you for your comments.


On 01/12/2016= 02:02, Donald Eastlake wrote:
My apologies for getting this in late. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments.

This draft appears to be ready for publication with some nits..

This draft polishes and advances to Internet Standard level RFC 3798 on Message Disposition Notifications.

Security Considerations:

The Security Considerations seem good except for one minor point: in my opinion the option to return all or a portion of the original message significantly increases the possible risk of use MDNs as a traffic multiplier. I believe this should be mentioned in Section 6.4.

Thank you, I've added some text on this to the first paragraph of Section 6.4:

=C2=A0 Additionally, as generated MDN notifications can include full content of messages that caused them
=C2=A0 and thus they can be bigger than such messages, they can be used for bandwidth amplification attacks.

<= div>OK.
=C2=A0


Miscellaneous:

The style of this draft is to say that you MUST do this and MUST NOT do that without indicating what action should be taken if this is violated. This is like saying a protocol field "MUST be zero" without adding the usual "and= is ignored on receipt". For example, in Section 3 it says that a messag= e disposition notification MUST NOT itself request an MDN. I believe it should go on and add the few words to say: "If on= e does, this is ignored." (unless that's wrong...) I'm= not saying this must always be done but there may be 1 or 2 other cases like this in the draft where such wording should be added.

This is a difficult area, because we typically don't describe how t= o handle violations of MUSTs. In the case that you mention above, the text is added in order to prevent loops. Not much can be done on recipients end other than usual handling of spam and/or broken implementations.

Can you list other possible cases where you wanted some advice to be given?
=C2=A0
Actually, this is the on= ly one that really struck me...

=
Wording:

In Section 3, the wording of the last sentence of point d seems just a bit obscure. It says
    =
   However, in the case of encrypted messages requesting MDNs,
       encrypted message text MUST be returned, if it is returned at
       all, only in its original encrypted form.
I think it would be a just bit clearer as
    =
   However, in the case of encrypted messages requesting MDNs, if
    =
   the original message or a portion thereof is returned, it MUST
    =
   be in its original encrypted form.

I used your text, thank you.

You&= #39;re welcome.
=C2=A0


Trivia:

I do wonder if the references to X.400 mail are necessary. They seem archaic. Does anyone run X.400 email any more?

Yes :-)

OK. Didn't know that.=
=C2=A0

It is just used as an example, along with proprietary mail systems. I think such proprietary systems still exist, but X.400 mail? I'm not so sure. If it is going to be retained, maybe there should be an Informational reference for it.

I will try to dig one out.

OK. I would guess there is some ITU X.400-19xx standard or somet= hing...

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donal= d E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street,= Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com
=C2=A0
--001a114794eed58ec705429c0e79-- From nobody Thu Dec 1 14:21:02 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8E21294DD; Thu, 1 Dec 2016 14:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnfYXS8jSC99; Thu, 1 Dec 2016 14:20:56 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (00191d01.pphosted.com [67.231.149.140]) (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 BE4E1129986; Thu, 1 Dec 2016 14:20:55 -0800 (PST) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uB1JZVv7012558; Thu, 1 Dec 2016 14:43:04 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 272sns1y9f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 01 Dec 2016 14:43:03 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uB1Jh1NX023123; Thu, 1 Dec 2016 14:43:01 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id uB1JgpUb022871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 1 Dec 2016 14:42:56 -0500 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Thu, 1 Dec 2016 19:42:44 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.158]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0319.002; Thu, 1 Dec 2016 14:42:44 -0500 From: "HANSEN, TONY L" To: Alexey Melnikov , Donald Eastlake , "iesg@ietf.org" , "draft-ietf-appsawg-mdn-3798bis.all@ietf.org" Thread-Topic: [secdir] draft-ietf-appsawg-mdn-3798bis-15 SECDIR Review Thread-Index: AQHSS3cWl89FzCeprU+TP5gi4HNBlKDzRHWAgAA6x4A= Date: Thu, 1 Dec 2016 19:42:43 +0000 Message-ID: References: <7b6ae784-bcdf-53e9-e878-d542f9fc1ed7@isode.com> In-Reply-To: <7b6ae784-bcdf-53e9-e878-d542f9fc1ed7@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.110.240.80] Content-Type: multipart/alternative; boundary="_000_EDB1216EE0B349BEAE5D1FBE00AB9483attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-01_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1612010320 Archived-At: Cc: "secdir@ietf.org" Subject: Re: [secdir] draft-ietf-appsawg-mdn-3798bis-15 SECDIR Review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 22:20:59 -0000 --_000_EDB1216EE0B349BEAE5D1FBE00AB9483attcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHdvbmRlcmZ1bCB0aGluZyBhYm91dCBoYXZpbmcgYSBjb2F1dGhvciA1IGhvdXJzIGFoZWFk IG9mIHlvdSBpcyB0aGF0IGJ5IHRoZSB0aW1lIHlvdSBsb2cgaW4gaW4gdGhlIG1vcm5pbmcsIHRo aW5ncyBoYXZlIG9mdGVuIGFscmVhZHkgYmVlbiB0YWtlbiBjYXJlIG9mLiDimLoNCg0KVGhhbmtz IGZvciB0aGUgY29tbWVudHMgRG9uYWxkLg0KDQogICAgICAgICAgICAgICAgVG9ueQ0KDQpGcm9t OiBBbGV4ZXkgTWVsbmlrb3YgPGFsZXhleS5tZWxuaWtvdkBpc29kZS5jb20+DQpEYXRlOiBUaHVy c2RheSwgRGVjZW1iZXIgMSwgMjAxNiBhdCA2OjEyIEFNDQpUbzogRG9uYWxkIEVhc3RsYWtlIDxk M2UzZTNAZ21haWwuY29tPiwgImllc2dAaWV0Zi5vcmciIDxpZXNnQGlldGYub3JnPiwgImRyYWZ0 LWlldGYtYXBwc2F3Zy1tZG4tMzc5OGJpcy5hbGxAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLWFwcHNh d2ctbWRuLTM3OThiaXMuYWxsQGlldGYub3JnPg0KQ2M6ICJzZWNkaXJAaWV0Zi5vcmciIDxzZWNk aXJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NlY2Rpcl0gZHJhZnQtaWV0Zi1hcHBzYXdnLW1k bi0zNzk4YmlzLTE1IFNFQ0RJUiBSZXZpZXcNClJlc2VudC1Gcm9tOiA8YWxpYXMtYm91bmNlc0Bp ZXRmLm9yZz4NClJlc2VudC1UbzogPGFsZXhleS5tZWxuaWtvdkBpc29kZS5jb20+LCA8dG9ueUBh dHQuY29tPiwgPHN1cGVydXNlckBnbWFpbC5jb20+LCA8YmVuQG5vc3RydW0uY29tPiwgPGFsaXNz YUBjb29wZXJ3LmluPiwgPGFhbWVsbmlrb3ZAZmFzdG1haWwuZm0+LCBCYXJyeSBMZWliYSA8YmFy cnlsZWliYUBjb21wdXRlci5vcmc+DQpSZXNlbnQtRGF0ZTogVGh1cnNkYXksIERlY2VtYmVyIDEs IDIwMTYgYXQgNjoxNCBBTQ0KDQoNCkhpIERvbmFsZCwNCg0KVGhhbmsgeW91IGZvciB5b3VyIGNv bW1lbnRzLg0KDQpPbiAwMS8xMi8yMDE2IDAyOjAyLCBEb25hbGQgRWFzdGxha2Ugd3JvdGU6DQpN eSBhcG9sb2dpZXMgZm9yIGdldHRpbmcgdGhpcyBpbiBsYXRlLiBJIGhhdmUgcmV2aWV3ZWQgdGhp cyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcg ZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRo ZSBJRVNHLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNl IGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpUaGlz IGRyYWZ0IGFwcGVhcnMgdG8gYmUgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIHdpdGggc29tZSBuaXRz Li4NCg0KVGhpcyBkcmFmdCBwb2xpc2hlcyBhbmQgYWR2YW5jZXMgdG8gSW50ZXJuZXQgU3RhbmRh cmQgbGV2ZWwgUkZDIDM3OTggb24gTWVzc2FnZSBEaXNwb3NpdGlvbiBOb3RpZmljYXRpb25zLg0K DQpTZWN1cml0eSBDb25zaWRlcmF0aW9uczoNCg0KVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z IHNlZW0gZ29vZCBleGNlcHQgZm9yIG9uZSBtaW5vciBwb2ludDogaW4gbXkgb3BpbmlvbiB0aGUg b3B0aW9uIHRvIHJldHVybiBhbGwgb3IgYSBwb3J0aW9uIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdl IHNpZ25pZmljYW50bHkgaW5jcmVhc2VzIHRoZSBwb3NzaWJsZSByaXNrIG9mIHVzZSBNRE5zIGFz IGEgdHJhZmZpYyBtdWx0aXBsaWVyLiBJIGJlbGlldmUgdGhpcyBzaG91bGQgYmUgbWVudGlvbmVk IGluIFNlY3Rpb24gNi40Lg0KDQpUaGFuayB5b3UsIEkndmUgYWRkZWQgc29tZSB0ZXh0IG9uIHRo aXMgdG8gdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDYuNDoNCg0KICBBZGRpdGlvbmFs bHksIGFzIGdlbmVyYXRlZCBNRE4gbm90aWZpY2F0aW9ucyBjYW4gaW5jbHVkZSBmdWxsIGNvbnRl bnQgb2YgbWVzc2FnZXMgdGhhdCBjYXVzZWQgdGhlbQ0KICBhbmQgdGh1cyB0aGV5IGNhbiBiZSBi aWdnZXIgdGhhbiBzdWNoIG1lc3NhZ2VzLCB0aGV5IGNhbiBiZSB1c2VkIGZvciBiYW5kd2lkdGgg YW1wbGlmaWNhdGlvbiBhdHRhY2tzLg0KDQoNCg0KTWlzY2VsbGFuZW91czoNCg0KVGhlIHN0eWxl IG9mIHRoaXMgZHJhZnQgaXMgdG8gc2F5IHRoYXQgeW91IE1VU1QgZG8gdGhpcyBhbmQgTVVTVCBO T1QgZG8gdGhhdCB3aXRob3V0IGluZGljYXRpbmcgd2hhdCBhY3Rpb24gc2hvdWxkIGJlIHRha2Vu IGlmIHRoaXMgaXMgdmlvbGF0ZWQuIFRoaXMgaXMgbGlrZSBzYXlpbmcgYSBwcm90b2NvbCBmaWVs ZCAiTVVTVCBiZSB6ZXJvIiB3aXRob3V0IGFkZGluZyB0aGUgdXN1YWwgImFuZCBpcyBpZ25vcmVk IG9uIHJlY2VpcHQiLiBGb3IgZXhhbXBsZSwgaW4gU2VjdGlvbiAzIGl0IHNheXMgdGhhdCBhIG1l c3NhZ2UgZGlzcG9zaXRpb24gbm90aWZpY2F0aW9uIE1VU1QgTk9UIGl0c2VsZiByZXF1ZXN0IGFu IE1ETi4gSSBiZWxpZXZlIGl0IHNob3VsZCBnbyBvbiBhbmQgYWRkIHRoZSBmZXcgd29yZHMgdG8g c2F5OiAiSWYgb25lIGRvZXMsIHRoaXMgaXMgaWdub3JlZC4iICh1bmxlc3MgdGhhdCdzIHdyb25n Li4uKSBJJ20gbm90IHNheWluZyB0aGlzIG11c3QgYWx3YXlzIGJlIGRvbmUgYnV0IHRoZXJlIG1h eSBiZSAxIG9yIDIgb3RoZXIgY2FzZXMgbGlrZSB0aGlzIGluIHRoZSBkcmFmdCB3aGVyZSBzdWNo IHdvcmRpbmcgc2hvdWxkIGJlIGFkZGVkLg0KDQpUaGlzIGlzIGEgZGlmZmljdWx0IGFyZWEsIGJl Y2F1c2Ugd2UgdHlwaWNhbGx5IGRvbid0IGRlc2NyaWJlIGhvdyB0byBoYW5kbGUgdmlvbGF0aW9u cyBvZiBNVVNUcy4gSW4gdGhlIGNhc2UgdGhhdCB5b3UgbWVudGlvbiBhYm92ZSwgdGhlIHRleHQg aXMgYWRkZWQgaW4gb3JkZXIgdG8gcHJldmVudCBsb29wcy4gTm90IG11Y2ggY2FuIGJlIGRvbmUg b24gcmVjaXBpZW50cyBlbmQgb3RoZXIgdGhhbiB1c3VhbCBoYW5kbGluZyBvZiBzcGFtIGFuZC9v ciBicm9rZW4gaW1wbGVtZW50YXRpb25zLg0KDQpDYW4geW91IGxpc3Qgb3RoZXIgcG9zc2libGUg Y2FzZXMgd2hlcmUgeW91IHdhbnRlZCBzb21lIGFkdmljZSB0byBiZSBnaXZlbj8NCg0KDQpXb3Jk aW5nOg0KDQpJbiBTZWN0aW9uIDMsIHRoZSB3b3JkaW5nIG9mIHRoZSBsYXN0IHNlbnRlbmNlIG9m IHBvaW50IGQgc2VlbXMganVzdCBhIGJpdCBvYnNjdXJlLiBJdCBzYXlzDQoNCiAgICAgICBIb3dl dmVyLCBpbiB0aGUgY2FzZSBvZiBlbmNyeXB0ZWQgbWVzc2FnZXMgcmVxdWVzdGluZyBNRE5zLA0K DQogICAgICAgZW5jcnlwdGVkIG1lc3NhZ2UgdGV4dCBNVVNUIGJlIHJldHVybmVkLCBpZiBpdCBp cyByZXR1cm5lZCBhdA0KDQogICAgICAgYWxsLCBvbmx5IGluIGl0cyBvcmlnaW5hbCBlbmNyeXB0 ZWQgZm9ybS4NCkkgdGhpbmsgaXQgd291bGQgYmUgYSBqdXN0IGJpdCBjbGVhcmVyIGFzDQoNCiAg ICAgICBIb3dldmVyLCBpbiB0aGUgY2FzZSBvZiBlbmNyeXB0ZWQgbWVzc2FnZXMgcmVxdWVzdGlu ZyBNRE5zLCBpZg0KDQogICAgICAgdGhlIG9yaWdpbmFsIG1lc3NhZ2Ugb3IgYSBwb3J0aW9uIHRo ZXJlb2YgaXMgcmV0dXJuZWQsIGl0IE1VU1QNCg0KICAgICAgIGJlIGluIGl0cyBvcmlnaW5hbCBl bmNyeXB0ZWQgZm9ybS4NCg0KSSB1c2VkIHlvdXIgdGV4dCwgdGhhbmsgeW91Lg0KDQoNClRyaXZp YToNCg0KSSBkbyB3b25kZXIgaWYgdGhlIHJlZmVyZW5jZXMgdG8gWC40MDAgbWFpbCBhcmUgbmVj ZXNzYXJ5LiBUaGV5IHNlZW0gYXJjaGFpYy4gRG9lcyBhbnlvbmUgcnVuIFguNDAwIGVtYWlsIGFu eSBtb3JlPw0KDQpZZXMgOi0pDQoNCg0KSXQgaXMganVzdCB1c2VkIGFzIGFuIGV4YW1wbGUsIGFs b25nIHdpdGggcHJvcHJpZXRhcnkgbWFpbCBzeXN0ZW1zLiBJIHRoaW5rIHN1Y2ggcHJvcHJpZXRh cnkgc3lzdGVtcyBzdGlsbCBleGlzdCwgYnV0IFguNDAwIG1haWw/IEknbSBub3Qgc28gc3VyZS4g SWYgaXQgaXMgZ29pbmcgdG8gYmUgcmV0YWluZWQsIG1heWJlIHRoZXJlIHNob3VsZCBiZSBhbiBJ bmZvcm1hdGlvbmFsIHJlZmVyZW5jZSBmb3IgaXQuDQoNCkkgd2lsbCB0cnkgdG8gZGlnIG9uZSBv dXQuDQoNCg0KDQoNCg== --_000_EDB1216EE0B349BEAE5D1FBE00AB9483attcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5 NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnByZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseTpDb3VyaWVyO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28t c3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9Indo aXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoZSB3b25kZXJmdWwgdGhpbmcg YWJvdXQgaGF2aW5nIGEgY29hdXRob3IgNSBob3VycyBhaGVhZCBvZiB5b3UgaXMgdGhhdCBieSB0 aGUgdGltZSB5b3UgbG9nIGluIGluIHRoZSBtb3JuaW5nLCB0aGluZ3MgaGF2ZSBvZnRlbiBhbHJl YWR5IGJlZW4gdGFrZW4gY2FyZSBvZi4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3MiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ VGhhbmtzIGZvciB0aGUgY29tbWVudHMgRG9uYWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUb255DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5BbGV4ZXkgTWVsbmlr b3YgJmx0O2FsZXhleS5tZWxuaWtvdkBpc29kZS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRo dXJzZGF5LCBEZWNlbWJlciAxLCAyMDE2IGF0IDY6MTIgQU08YnI+DQo8Yj5UbzogPC9iPkRvbmFs ZCBFYXN0bGFrZSAmbHQ7ZDNlM2UzQGdtYWlsLmNvbSZndDssICZxdW90O2llc2dAaWV0Zi5vcmcm cXVvdDsgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtkcmFmdC1pZXRmLWFwcHNhd2ctbWRu LTM3OThiaXMuYWxsQGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pZXRmLWFwcHNhd2ctbWRuLTM3 OThiaXMuYWxsQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7c2VjZGlyQGlldGYu b3JnJnF1b3Q7ICZsdDtzZWNkaXJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJl OiBbc2VjZGlyXSBkcmFmdC1pZXRmLWFwcHNhd2ctbWRuLTM3OThiaXMtMTUgU0VDRElSIFJldmll dzxicj4NCjxiPlJlc2VudC1Gcm9tOiA8L2I+Jmx0O2FsaWFzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+UmVzZW50LVRvOiA8L2I+Jmx0O2FsZXhleS5tZWxuaWtvdkBpc29kZS5jb20mZ3Q7 LCAmbHQ7dG9ueUBhdHQuY29tJmd0OywgJmx0O3N1cGVydXNlckBnbWFpbC5jb20mZ3Q7LCAmbHQ7 YmVuQG5vc3RydW0uY29tJmd0OywgJmx0O2FsaXNzYUBjb29wZXJ3LmluJmd0OywgJmx0O2FhbWVs bmlrb3ZAZmFzdG1haWwuZm0mZ3Q7LCBCYXJyeSBMZWliYSAmbHQ7YmFycnlsZWliYUBjb21wdXRl ci5vcmcmZ3Q7PGJyPg0KPGI+UmVzZW50LURhdGU6IDwvYj5UaHVyc2RheSwgRGVjZW1iZXIgMSwg MjAxNiBhdCA2OjE0IEFNPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwPkhpIERv bmFsZCw8bzpwPjwvbzpwPjwvcD4NCjxwPlRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cy48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDAxLzEyLzIwMTYgMDI6MDIsIERvbmFsZCBF YXN0bGFrZSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk15IGFwb2xvZ2llcyBmb3IgZ2V0dGluZyB0aGlzIGluIGxhdGUu IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRp cmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBi ZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWly cyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMNCiBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3Qg Y2FsbCBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhpcyBkcmFmdCBhcHBlYXJzIHRvIGJlIHJlYWR5IGZvciBwdWJsaWNhdGlv biB3aXRoIHNvbWUgbml0cy4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoaXMgZHJhZnQgcG9saXNoZXMgYW5kIGFkdmFuY2VzIHRvIEludGVy bmV0IFN0YW5kYXJkIGxldmVsIFJGQyAzNzk4IG9uIE1lc3NhZ2UgRGlzcG9zaXRpb24gTm90aWZp Y2F0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHU+U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM6PC91PjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgc2VlbSBnb29kIGV4Y2VwdCBmb3Igb25lIG1pbm9yIHBvaW50OiBpbiBteSBvcGluaW9u IHRoZSBvcHRpb24gdG8gcmV0dXJuIGFsbCBvciBhIHBvcnRpb24gb2YgdGhlIG9yaWdpbmFsIG1l c3NhZ2Ugc2lnbmlmaWNhbnRseSBpbmNyZWFzZXMgdGhlIHBvc3NpYmxlIHJpc2sgb2YgdXNlIE1E TnMgYXMgYSB0cmFmZmljIG11bHRpcGxpZXIuIEkgYmVsaWV2ZSB0aGlzDQogc2hvdWxkIGJlIG1l bnRpb25lZCBpbiBTZWN0aW9uIDYuNC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGFuayB5b3UsIEkndmUg YWRkZWQgc29tZSB0ZXh0IG9uIHRoaXMgdG8gdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBTZWN0aW9u IDYuNDo8YnI+DQo8YnI+DQombmJzcDsgQWRkaXRpb25hbGx5LCBhcyBnZW5lcmF0ZWQgTUROIG5v dGlmaWNhdGlvbnMgY2FuIGluY2x1ZGUgZnVsbCBjb250ZW50IG9mIG1lc3NhZ2VzIHRoYXQgY2F1 c2VkIHRoZW08YnI+DQombmJzcDsgYW5kIHRodXMgdGhleSBjYW4gYmUgYmlnZ2VyIHRoYW4gc3Vj aCBtZXNzYWdlcywgdGhleSBjYW4gYmUgdXNlZCBmb3IgYmFuZHdpZHRoIGFtcGxpZmljYXRpb24g YXR0YWNrcy48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1Pk1pc2NlbGxhbmVvdXM6PC91PjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc3R5bGUgb2Yg dGhpcyBkcmFmdCBpcyB0byBzYXkgdGhhdCB5b3UgTVVTVCBkbyB0aGlzIGFuZCBNVVNUIE5PVCBk byB0aGF0IHdpdGhvdXQgaW5kaWNhdGluZyB3aGF0IGFjdGlvbiBzaG91bGQgYmUgdGFrZW4gaWYg dGhpcyBpcyB2aW9sYXRlZC4gVGhpcyBpcyBsaWtlIHNheWluZyBhIHByb3RvY29sIGZpZWxkICZx dW90O01VU1QgYmUgemVybyZxdW90OyB3aXRob3V0IGFkZGluZyB0aGUgdXN1YWwgJnF1b3Q7YW5k IGlzIGlnbm9yZWQNCiBvbiByZWNlaXB0JnF1b3Q7LiBGb3IgZXhhbXBsZSwgaW4gU2VjdGlvbiAz IGl0IHNheXMgdGhhdCBhIG1lc3NhZ2UgZGlzcG9zaXRpb24gbm90aWZpY2F0aW9uIE1VU1QgTk9U IGl0c2VsZiByZXF1ZXN0IGFuIE1ETi4gSSBiZWxpZXZlIGl0IHNob3VsZCBnbyBvbiBhbmQgYWRk IHRoZSBmZXcgd29yZHMgdG8gc2F5OiAmcXVvdDtJZiBvbmUgZG9lcywgdGhpcyBpcyBpZ25vcmVk LiZxdW90OyAodW5sZXNzIHRoYXQncyB3cm9uZy4uLikgSSdtIG5vdCBzYXlpbmcgdGhpcyBtdXN0 DQogYWx3YXlzIGJlIGRvbmUgYnV0IHRoZXJlIG1heSBiZSAxIG9yIDIgb3RoZXIgY2FzZXMgbGlr ZSB0aGlzIGluIHRoZSBkcmFmdCB3aGVyZSBzdWNoIHdvcmRpbmcgc2hvdWxkIGJlIGFkZGVkLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NClRoaXMgaXMgYSBkaWZmaWN1bHQgYXJlYSwgYmVjYXVzZSB3ZSB0eXBp Y2FsbHkgZG9uJ3QgZGVzY3JpYmUgaG93IHRvIGhhbmRsZSB2aW9sYXRpb25zIG9mIE1VU1RzLiBJ biB0aGUgY2FzZSB0aGF0IHlvdSBtZW50aW9uIGFib3ZlLCB0aGUgdGV4dCBpcyBhZGRlZCBpbiBv cmRlciB0byBwcmV2ZW50IGxvb3BzLiBOb3QgbXVjaCBjYW4gYmUgZG9uZSBvbiByZWNpcGllbnRz IGVuZCBvdGhlciB0aGFuIHVzdWFsIGhhbmRsaW5nIG9mIHNwYW0gYW5kL29yDQogYnJva2VuIGlt cGxlbWVudGF0aW9ucy48YnI+DQo8YnI+DQpDYW4geW91IGxpc3Qgb3RoZXIgcG9zc2libGUgY2Fz ZXMgd2hlcmUgeW91IHdhbnRlZCBzb21lIGFkdmljZSB0byBiZSBnaXZlbj88YnI+DQo8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48dT5Xb3JkaW5nOjwvdT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SW4gU2VjdGlvbiAzLCB0aGUgd29yZGluZyBvZiB0aGUgbGFzdCBzZW50 ZW5jZSBvZiBwb2ludCBkIHNlZW1zIGp1c3QgYSBiaXQgb2JzY3VyZS4gSXQgc2F5czxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBIb3dldmVyLCBpbiB0aGUgY2FzZSBv ZiBlbmNyeXB0ZWQgbWVzc2FnZXMgcmVxdWVzdGluZyBNRE5zLDxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBlbmNyeXB0ZWQgbWVzc2FnZSB0ZXh0IE1VU1QgYmUgcmV0dXJuZWQs IGlmIGl0IGlzIHJldHVybmVkIGF0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGFsbCwgb25seSBpbiBpdHMgb3JpZ2luYWwgZW5jcnlwdGVkIGZvcm0uPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGl0 IHdvdWxkIGJlIGEganVzdCBiaXQgY2xlYXJlciBhczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBIb3dldmVyLCBpbiB0aGUgY2FzZSBvZiBlbmNyeXB0ZWQgbWVzc2Fn ZXMgcmVxdWVzdGluZyBNRE5zLCBpZjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB0aGUgb3JpZ2luYWwgbWVzc2FnZSBvciBhIHBvcnRpb24gdGhlcmVvZiBpcyByZXR1cm5lZCwg aXQgTVVTVDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiZSBpbiBpdHMgb3Jp Z2luYWwgZW5jcnlwdGVkIGZvcm0uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSB1c2VkIHlv dXIgdGV4dCwgdGhhbmsgeW91Ljxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+VHJpdmlhOjwvdT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkbyB3b25kZXIgaWYg dGhlIHJlZmVyZW5jZXMgdG8gWC40MDAgbWFpbCBhcmUgbmVjZXNzYXJ5LiBUaGV5IHNlZW0gYXJj aGFpYy4gRG9lcyBhbnlvbmUgcnVuIFguNDAwIGVtYWlsIGFueSBtb3JlPzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NClllcyA6LSk8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBqdXN0IHVzZWQgYXMgYW4gZXhhbXBsZSwg YWxvbmcgd2l0aCBwcm9wcmlldGFyeSBtYWlsIHN5c3RlbXMuIEkgdGhpbmsgc3VjaCBwcm9wcmll dGFyeSBzeXN0ZW1zIHN0aWxsIGV4aXN0LCBidXQgWC40MDAgbWFpbD8gSSdtIG5vdCBzbyBzdXJl LiBJZiBpdCBpcyBnb2luZyB0byBiZSByZXRhaW5lZCwgbWF5YmUgdGhlcmUgc2hvdWxkIGJlIGFu IEluZm9ybWF0aW9uYWwgcmVmZXJlbmNlIGZvciBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJIHdpbGwg dHJ5IHRvIGRpZyBvbmUgb3V0Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EDB1216EE0B349BEAE5D1FBE00AB9483attcom_-- From nobody Fri Dec 2 06:34:43 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5091296BF; Fri, 2 Dec 2016 06:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlRlfftSundo; Fri, 2 Dec 2016 06:34:40 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B80A1294A6; Fri, 2 Dec 2016 06:34:40 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uB2EYaER003582 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Dec 2016 16:34:36 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uB2EYaYk029074; Fri, 2 Dec 2016 16:34:36 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22593.34428.317530.80624@fireball.acr.fi> Date: Fri, 2 Dec 2016 16:34:36 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sidr-origin-validation-signaling.all@tools.ietf.org X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: Subject: [secdir] Secdir review of draft-ietf-sidr-origin-validation-signaling-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:34:41 -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 is the rereview of the document and the changes made after my previous review fixes the issues I found in my review. This document is Ready. -- kivinen@iki.fi From nobody Fri Dec 2 08:52:14 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729E61295E7; Fri, 2 Dec 2016 08:52:08 -0800 (PST) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJDu_CvK7IfI; Fri, 2 Dec 2016 08:52:01 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 6CDE2129454; Fri, 2 Dec 2016 08:52:01 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id uB2GpvAH023945 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 2 Dec 2016 17:51:58 +0100 X-Hashcash: 1:22:161202:iesg@ietf.org::3NUdoAUKf0hCSNr5:LFX5 X-Hashcash: 1:22:161202:secdir@ietf.org::LOkyyf61HcBZ2B10:HN4j X-Hashcash: 1:22:161202:draft-ietf-6lo-dect-ule.all@ietf.org::1MtOQn9hw0b2ND4L:7/XE From: Simon Josefsson To: iesg@ietf.org, secdir@ietf.org, draft-ietf-6lo-dect-ule.all@ietf.org OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Fri, 02 Dec 2016 17:51:55 +0100 Message-ID: <87polal1ec.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.99.2 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: [secdir] Review of draft-ietf-6lo-dect-ule-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 16:52:08 -0000 --=-=-= Content-Type: text/plain 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 describes how to transmit IPv6 packets over DECT ULE using 6LoWPAN. The document contains a good introduction to DECT, which is particulary helpful to the IETF community. The security consideration already mentions the privacy concern related to link-level MAC addresses, which is something that would otherwise would be easy to criticize. The document uses acronyms which makes it difficult to read but the document strikes me as well written and well thought out anyway. I believe the document is Ready with Nits. Major nits: 1) Security Considerations. I believe the document should state that IPv6 traffic transmitted over DECT ULE should be protected using normal IETF protocols (e.g., IPSEC or TLS) when there is a need for security. The text says DECT ULE is secured using AES-CCM keyed from the DECT ULE pairing, implying that this offers some security. The document does not explain (or inspire confidence) that the pairing process of DECT ULE has sufficient entropy as input to provide good link-level security, nor that it is based on any well established protocol. A word or two about this would be informative, but not really required. The process may be completely secure, but it may also not be. I don't recall any link layer security protocol that haven't had a significant security problem in the past. Regardless, I believe it is warranted to safeguard readers that they should not consider DECT ULE transport a secure transport for protecting data at the transport and/or application level. Implementers need to employ transport and/or application-level security like IPSEC/TLS/CMS/OpenPGP as well. To address my concern, I suggest to add the following after the third paragraph: While DECT ULE offer some link-layer security properties, the transport of data over DECT ULE may require additional transport protocol, or application protocol, security guarantees. When there is a need, the use of IPSEC [RFC XXXX], TLS [RFC YYYY], CMS [RFC ZZZZ], OpenPGP [RFC QQQQ] or similar security protocols, are recommended. Minor nits: A) Spell out DECT in the abstract and title. In the introduction section, change 'DECT (Digital Enhanced Cordless Telecommunications)' into 'Digital Enhanced Cordless Telecommunications (DECT)'. Cheers, /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJYQaasAAoJEIYLf7sy+BGd9UcIAIldVsZyaLZcTWXmCSVgF4Vm 2TMcOq2B28yMO0i4v5RzBofvMZF7L5fQnyoMmTDyFp8y05/KLmpHm7oHvX4TeS/W cDIsDlCVtM4Wy45O8zZXZeXZbn4UOXcCmnxY5vmEO3s63zXfzu7OjOBggdL9cj1N o/1rtSDnOC/Ee6qj6fhcWxBL1uONOYFYMtq0JHDehJ4gnMl8g2QAZpAuX6j+yJ1p n7044ffNM1hUzp1jNSzn1e5rUEratV7ggqBOzlRTPW0pzMdxSDcz8odKFBS0jyFf OCriehD7QWFHXW5tkLLevP72qMhej2U1avfuO6UnzwyxouD6tqA1QrEjoXte0AI= =GMJR -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 2 10:34:00 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD7612984B; Fri, 2 Dec 2016 09:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1480701205; bh=ItjeqOtATLIITTHVe1uVm8aIMRoCGXTFOnGjJC+Z79Y=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=gzKPeo+Gv9EVmm+AgrwBq7sq18K0iNGAJjaxKFXfSEcWVA9AVltW5xuU7iCwSc4aW 5VQkvq33o+w7pmOdr+ZzKq8id3M7XhoeWZcbRuYn27+wwsNi7VYVMtB5fm2nLeuxCZ uLlM31ZNOMOHz9i4eBK3eaTeM8oNjVAYXN+5DUJc= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD561296F6 for ; Fri, 2 Dec 2016 09:53:19 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: Message-ID: <148070119931.29664.14758835736272600053.idtracker@ietfa.amsl.com> Date: Fri, 02 Dec 2016 09:53:19 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 02 Dec 2016 10:33:59 -0800 Subject: [secdir] [new-work] WG Review: Concise Binary Object Representation Maintenance and Extensions (cbor) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 17:53:25 -0000 A new IETF WG 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@ietf.org) by 2016-12-12. Concise Binary Object Representation Maintenance and Extensions (cbor) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Ben Campbell Alissa Cooper Alexey Melnikov Mailing list: Address: cbor@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/cbor Archive: https://www.ietf.org/mail-archive/web/cbor/current/maillist.html Charter: https://datatracker.ietf.org/doc/charter-ietf-cbor/ Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 7159) data model to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., CORE, ANIMA GRASP) as a message format. The CBOR working group will update RFC 7049 to fix verified errata. Security issues and clarifications may be addressed, but changes to the document will ensure backward compatibility for popular deployed codebases. The resulting document will be targeted at becoming an Internet Standard. Similar to the way ABNF (RFC 5234/7405) can be used to describe the set of valid messages in a text representation, it would be useful if protocol specifications could use a description format for the data in CBOR-encoded messages. The CBOR data definition language (CDDL, based on draft-greevenbosch-appsawg-cbor-cddl) is a proposal for such a description technique that has already been used in CORE, ANIMA, CDNI, and efforts outside the IETF. The CBOR WG will complete the development of this specification by creating an Informational or Standards Track RFC. In parallel to the work on CDDL, the WG will examine the CBOR extension for tagging of Typed Arrays (based on draft-jroatch-cbor-tags) and the CBOR extension for tagging of Object Identifiers and UUIDs (based on draft-bormann-cbor-tags-oid) that use CBOR's extensibility mechanisms to provide additional data types as used in certain applications. Where these proposals are deemed useful and do not require significant new development, the CBOR WG will complete these specifications as well. The WG will recharter before working on any further CBOR extensions. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sun Dec 4 10:22:09 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D541212958D for ; Sun, 4 Dec 2016 10:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2D_oBkFPXKn for ; Sun, 4 Dec 2016 10:22:06 -0800 (PST) Received: from nm25-vm10.access.bullet.mail.bf1.yahoo.com (nm25-vm10.access.bullet.mail.bf1.yahoo.com [216.109.115.201]) (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 A6C9812958C for ; Sun, 4 Dec 2016 10:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1480875724; bh=Rfsfq3QEd1inEoDmHZE5orf7ii5VBQ5LKKFRMxeeXOE=; h=To:From:Subject:Date:From:Subject; b=QMgQ5VaJqA7OQxOXj/QtB1uRrEF8e23v2EXa9XVKcNI4VHBDPQr/E5yl1nKhvLtvn8ESUmvgVbzqjH4NAV2PFa5wbYy2GzlB/6PMS035cHK2354m1sbGQg7IGCovaxHLYly9PTzkSwR9Zh0pZ5iHESXYaIhzKZfyiR5rPHjJYzMHIbrLspobLplBhiPDd/v1NwtVPQgIes7BTVaT3cojt9iiPVHriSCHg5+ncp76EMjT2AyXLdkR5WO0/mh28vdvBCk4wCLKhB7lPEPF6RXXhAV37dPMy3LIY8zf+XakugsOAsRpqtwc6QYEoKAnk3kcs9Bij+6QzmGL0StQPdsC+g== Received: from [66.196.81.164] by nm25.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Dec 2016 18:22:04 -0000 Received: from [98.138.226.240] by tm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 04 Dec 2016 18:22:04 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.ne1.yahoo.com with NNFMP; 04 Dec 2016 18:22:04 -0000 X-Yahoo-Newman-Id: 30420.60146.bm@smtp111.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: QNjwQLoVM1lm7sfUNn3mo29PmxnTGqjR8MC3optLPMu69OA 8uc8yWDu5Uu3PGRauiIwmgB5b4saal7OCweHjSoBPgejbp7HJ3GKM_i8cmwD xFn2maEoQaDAofaHk09FIzfIATYzutT7K3nX0uGAMwnopYGJ897wbRPDds9k LUtDLpS89HclFjtpF5YFfDlH5_A7I.IzhhJfMGwXjrIUmFggaXH_xC1C01JR uib3pwV0sN.nubIxX9XDCoSdO.k48ocnSpjWamDM5h9FzUu7vey1_OxB95PD a9MbeM2cuAcr5tCubPtWkxctucdlnoejXfjXO5TjlTzulMAS46nxy7ihMB_9 eb36ciu3sLDhnl4oE.._mI8gag4VnyDlOqsjweo34rQd8ltrjmoCY7hH3.IE d_Qks5BmUlF9v.uwjwUsiIW8YdLdYtib7VGwzXoXvloKGsE9LURGNKyZoxsx sNUE306l1Tnlr8QA.xDUuRkXzZhlaEbG7sfTOfEmqDweh43PreZY3OmmWI00 mOm4NMwplN1zVFnni_Cq3.vuJ2e2GOQeRfBGlg57nDg-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id E3B051C6033; Sun, 4 Dec 2016 13:22:02 -0500 (EST) To: iesg@ietf.org, secdir@ietf.org, draft-elie-nntp-tls-recommendations.all@ietf.org From: David Mandelberg Message-ID: <022c6479-4bac-f18e-928a-796a0d7ebde3@mandelberg.org> Date: Sun, 4 Dec 2016 13:21:59 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VMXma9nvU3n1mfnlHnRlGw6FBe9FMgcSP" Archived-At: Subject: [secdir] secdir review of draft-elie-nntp-tls-recommendations-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 18:22:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VMXma9nvU3n1mfnlHnRlGw6FBe9FMgcSP Content-Type: multipart/mixed; boundary="PIOmPhO5cb78BltUSwQcjNLAwrPdGf0wX" From: David Mandelberg To: iesg@ietf.org, secdir@ietf.org, draft-elie-nntp-tls-recommendations.all@ietf.org Message-ID: <022c6479-4bac-f18e-928a-796a0d7ebde3@mandelberg.org> Subject: secdir review of draft-elie-nntp-tls-recommendations-01 --PIOmPhO5cb78BltUSwQcjNLAwrPdGf0wX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I think this document is ready with nits. Section 2.4: I think the second to last bullet (about lack of STARTTLS) should be expanded in scope to say "during any previous connection within a (possibly configurable) time frame" instead of "during the previous connection." Otherwise, a human might not see the warning the first time, and the warning would disappear immediately after that. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --PIOmPhO5cb78BltUSwQcjNLAwrPdGf0wX-- --VMXma9nvU3n1mfnlHnRlGw6FBe9FMgcSP 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 iEYEARECAAYFAlhEXscACgkQRKlmUHCg4sDXWgCfT94rUGttRFbGQsrhL6BT1RKs Tz4AoISlULnIWq0m0D3gZwr4sjUEcZL8 =bvof -----END PGP SIGNATURE----- --VMXma9nvU3n1mfnlHnRlGw6FBe9FMgcSP-- From nobody Sun Dec 4 16:50:47 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAE4129677; Sun, 4 Dec 2016 16:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=idirect.net 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 YyCXOOYKhx60; Sun, 4 Dec 2016 16:50:44 -0800 (PST) Received: from mx0b-00229401.pphosted.com (mx0a-00229401.pphosted.com [148.163.157.249]) (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 14261129667; Sun, 4 Dec 2016 16:50:44 -0800 (PST) Received: from pps.filterd (m0097894.ppops.net [127.0.0.1]) by mx0b-00229401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uB50lDOD012606; Sun, 4 Dec 2016 19:50:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=idirect.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=dk1; bh=/7EZasPMIMGsLMh53k/BpXMfkH09cyPktJJMncb6t0U=; b=iAIDFWqvzmIRsftQX7+BkfZu/cYbcy0sDx0vU2qr+E78gjju1q/qvkKvbybo9DCSyEhB cqLXtYyLzfmEPyU3yA5pU8WBQAQ7j/FJsSm1zC7NfIvwUrFHOJLqXlFR7HNQUBWI4sCW uV9K1FOUVzpCxuTq6+jvn/rtIJcja/4lKxvr7eepcOrB6vjZJIG0MSD8obatDueJJTNK dCE7wfYQXGMLgdHdyAmp19WDNtYqYdYMaF1uDAp8ToRkUaR8leguuYNomakvcJ48LgGK p09ijH3YZ1WvO1g1BY2Cevk4zPhOIQXRJLYyaKrzGge4d2A4HQJ5qhySlePvq3tiMoUn cg== Received: from webmail.idirect.net ([198.180.159.2]) by mx0b-00229401.pphosted.com with ESMTP id 273tq80vru-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 04 Dec 2016 19:50:34 -0500 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM3.idirect.net (10.250.250.203) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Sun, 4 Dec 2016 19:50:32 -0500 Received: from VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.1236.000; Sun, 4 Dec 2016 19:50:32 -0500 From: "Ratliff, Stanley" To: Christian Huitema , "'Taylor, Rick (External)'" , 'Paul Hoffman' Thread-Topic: [secdir] SecDir review of draft-ietf-manet-dlep Thread-Index: AQHSP9dxooq1deGLb0CN9D0fTSXK8AJp8YIyAbfck2mf1Pcy0ID54YMAgAEuYACAB4ou0A== Date: Mon, 5 Dec 2016 00:50:31 +0000 Message-ID: References: <30706_1479279750_582C0485_30706_8297_7_C7F1D029-C067-4AF6-9F40-436F7BA54311@vpnc.org> <0AE7C2DE-B316-4675-B7BE-EB9AC50ED955@vpnc.org> <4035_1480388659_583CF032_4035_1030_1_003b01d249ed$3f003260$bd009720$@huitema.net> <033801d24aa0$b34f09d0$19ed1d70$@huitema.net> In-Reply-To: <033801d24aa0$b34f09d0$19ed1d70$@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-04_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outboundspam_notspam policy=outboundspam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1612050011 Archived-At: Cc: "draft-ietf-manet-dlep.all@ietf.org" , 'secdir' Subject: Re: [secdir] SecDir review of draft-ietf-manet-dlep X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 00:50:46 -0000 Christian/Paul,=20 Thanks for your time and effort to review DLEP. I have a question inline.=20 > -----Original Message----- > From: Christian Huitema [mailto:huitema@huitema.net] > Sent: Tuesday, November 29, 2016 7:29 PM > To: 'Taylor, Rick (External)' ; 'Paul Ho= ffman' > > Cc: 'secdir' ; draft-ietf-manet-dlep.all@ietf.org > Subject: RE: [secdir] SecDir review of draft-ietf-manet-dlep >=20 > On Tuesday, November 29, 2016 2:09 AM, Rick Taylor wrote: >=20 > >> This layer 2 security model is effectively an implementation of > "perimeter > >> security", and has all the known issues with perimeter security. Two > classic > >> attacks are "finding a way to send packets through the perimeter" and > >> "subvert a node already installed inside the perimeter". The draft > attempts > >> to mitigate the first class of attacks by using the mechanism of RFC > 5082, > >> although it does not actually use it correctly. There is no > >> mitigation > for the > >> "subverted node" attack. > > > > There has been extensive discussion within the WG on this topic, and > > we do fully understand the concerns. The security of DLEP has always > > been a > major > > worry for the authors/WG as we are being pulled in two directions: > > The > sticking > > point is the situation where an implementer has the modem and router > > as > two > > separate modules in a single chassis (or secured perimeter), and wants > > to > avoid > > the perceived complexity/annoyance of implementing TLS. The authors > have >=20 > > received off-the-record comment from major radio vendors stating that > > they > will > > not adopt DLEP if it requires TLS. However, I agree that both your > comments are > > absolutely valid. The question is how to reconcile the difference? >=20 > There may be different deployment scenarios. As is, I would not recommend > deploying DLEP if the Lan provides access to anything else than the router > and the modem. For the other scenarios, you really want to use something > like TLS with appropriate credentials. >=20 > > We are searching for some mechanism that would allow the protocol to: > > > > a) Specify how to secure the session correctly. > > b) Secure the session by default. > > c) Allow either peer to waive the requirement for security in a way > > that > cannot be maliciously > > downgraded. > > > > Is a STARTTLS style approach acceptable? Or is an http/https style two > port approach > > preferred? I'm not asking for the solution, but trying to avoid > > wasting > your and our time. >=20 > Of course, I have no idea of the operational constraints, but at a high l= evel > you seem to have the same problem as various small appliances and devices. > My gut feeling is that the same solutions apply, e.g., a one time "pairin= g" to > establish trust between router and modem, and then using TLS and verifying > the appropriate credentials, e.g., some shared secret. You could make that > optional when the perimeter is really tightly controlled. >=20 Yes, this is a reasonable scenario. Can you point me to a document that des= cribes this one-time "paring", and then uses TLS? That seems like a solutio= n we could leverage.=20 The main issue, as Rick mentions, is that we (the authors) have received si= gnificant push-back from some radio vendors about implementing TLS in exist= ing gear. DLEP has applicability=20 in both the commercial and government-use spaces. Specifically in the gover= nment-use case, there is concern about requiring TLS functionality when bot= h the radio(s) and the router=20 are placed into a "physically secure environment" - for instance, into an a= rmored vehicle, that already contains a high-grade Information Assurance de= vice (like a HAIPE encryptor). In=20 that type of environment, the requirement to use TLS is somewhat redundant.= =20 However, the protocol is useful in the commercial environment as well, and = in those cases (as Rick has already said), we completely agree that proper = security mechanisms should be=20 implemented. We heard earlier in the discussion of the protocol that SecDir= would essentially give us "MUST implement/MAY use" direction with regard t= o TLS - would it be acceptable=20 to state the requirement as "SHOULD implement/MAY use", provided that use o= f TLS is strongly recommended, unless the deployment environment is physica= lly secure?=20 Regards, Stan=20 > >> >> One area we have worked hard on addressing is mandating use of > >> >> RFC5082 (Generalized TTL Security) on the link between router and > >> >> modem (See Section 3.1). > >> > >> Not quite. RFC5082 suggests setting the TTL to 255 and checking the > >> value > on > >> the received message. Your draft suggests setting the TTL value to 1, > >> and checking the received value in the message. You need to fix that. > > > > TTL 1 is required for the discovery mechanism (UDP mcast) in an > > attempt to > restrict > > packets to a single hop (particularly for IPv4), but the TCP > > connection > for the session > > must use TTL 255 as per RFC5082 (The paragraph above). We might > > consider > re-ordering > > the paragraphs if you think it is unclear. >=20 > TTL 255 prevents nodes from receiving packets from outside the LAN, TTL 1 > prevents nodes from leaking packets outside the LAN. An attacker can > format an UDP packet with a TTL just right, so that it arrives on the LAN= with > TTL=3D1. At a minimum, this allows the attacker to trigger multicast UDP = replies, > i.e., a form of DOS attack. Lucky attackers might be able to send a compl= ex > packet and trigger a code fault. That's why "prevent packets from the out= side > in" is generally better than "prevent packets from the inside out" -- mul= ticast > routing normally stops transmission outside the LAN anyhow. >=20 > If you decide to stick to TTL=3D1 for UDP, then you should definitely mak= e the > text explicit, explain the difference of treatment between TCP and UDP. >=20 > -- Christian Huitema >=20 >=20 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender. From nobody Tue Dec 6 17:03:11 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938B512955B; Tue, 6 Dec 2016 17:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-YTVWSUVf7y; Tue, 6 Dec 2016 17:03:00 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0080.outbound.protection.outlook.com [104.47.38.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB74129628; Tue, 6 Dec 2016 17:02:59 -0800 (PST) Received: from MWHPR01MB2670.prod.exchangelabs.com (10.172.165.8) by MWHPR01MB2669.prod.exchangelabs.com (10.172.165.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Wed, 7 Dec 2016 01:02:56 +0000 Received: from MWHPR01MB2670.prod.exchangelabs.com ([10.172.165.8]) by MWHPR01MB2670.prod.exchangelabs.com ([10.172.165.8]) with mapi id 15.01.0761.017; Wed, 7 Dec 2016 01:02:56 +0000 From: Matthew Kerwin To: Barry Leiba , "draft-ietf-appsawg-file-scheme.all@ietf.org" , "secdir@ietf.org" Thread-Topic: SecDir review of draft-ietf-appsawg-file-scheme-14 Thread-Index: AQHSSnFPod93FrypBEOZkfp7dGkXSKD7s1Ve Date: Wed, 7 Dec 2016 01:02:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=matthew.kerwin@qut.edu.au; x-originating-ip: [25.164.163.132] x-ms-office365-filtering-correlation-id: f2be8dee-e67b-4400-8a64-08d41e3cc7d1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR01MB2669; x-microsoft-exchange-diagnostics: 1; MWHPR01MB2669; 7:8B2sYjm6q9XJSukdHbD1Mbh7cl1qtexKNcpcNemkHa92T01p0LVyTbyLDzrHVerGOdAVKMPXl70Y8lk8SUDbiPQuycrXJloLzrbV0qVvfmK3GzFZJisJ/Mxe7cDR2VdDZKvLFj0oxy662mbGEG4puQmKxLke0M/ehujS+faNi1Q/UGyztcGyvxeyLb+r5WnXMLdIdrgTycBOA9GWdzr/ohskJAEGSretaY7WgNPTXwwp0143vi8gmARh1sA7CIBB+0qHLjmnQVazfjWYMGEVLlbGSLn7DJWTAfh3hdOoihnTbUDrmOa9QHNGXFzJt9TiIOjqvM2ZmRxXF0YQQttk/is1ep/xDnSZ+czPVKk0wm0AQ6YtEylo3u93bD+p16ekJs9yV7Zbz5+8OZm8KXNw8lmro55SPtV6cRHbtAK2lRbOnyYGLJqLrszH6c1aeEI4HwbU68St+jaXKup4UQduQg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(54900358751275); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:MWHPR01MB2669; BCL:0; PCL:0; RULEID:; SRVR:MWHPR01MB2669; x-forefront-prvs: 01494FA7F7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(51694002)(199003)(189002)(39410400001)(97736004)(229853002)(5001770100001)(2950100002)(106356001)(189998001)(101416001)(74482002)(4326007)(42882006)(81156014)(66066001)(2906002)(8936002)(38730400001)(106116001)(92566002)(105586002)(6116002)(122556002)(3846002)(88552002)(102836003)(33656002)(81166006)(2201001)(86362001)(2900100001)(8676002)(39450400002)(77096006)(74316002)(68736007)(305945005)(7736002)(5660300001)(6506006)(39860400001)(7696004)(230783001)(2501003)(39840400001)(3280700002)(54356999)(76176999)(39850400001)(9686002)(50986999)(7846002)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR01MB2669; H:MWHPR01MB2670.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: qut.edu.au does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: qut.edu.au X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2016 01:02:56.3800 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: dc0b52a3-68c5-44f7-881d-9383d8850b96 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR01MB2669 Archived-At: Cc: "art@ietf.org" , IETF discussion list , "paul.hoffman@vpnc.org" Subject: Re: [secdir] SecDir review of draft-ietf-appsawg-file-scheme-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 01:03:04 -0000 Thanks Barry (and Paul),=20 I agree with everything you've written here, and I don't think any of it's = too controversial, so I'll work it all in to my copy pretty much exactly a= s you've suggested.=20 The acknowledgements is hung over from the very first versions of the draft= , which cribbed a lot from Paul's old draft. I'm pretty sure it's been comp= letely rewritten several times since then, so I will definitely redo the ac= ks.=20 Cheers -- Matthew Kerwin | Queensland University of Technology | matthew.kerwin@q= ut.edu.au | CRICOS No 00213J ________________________________ From: barryleiba@gmail.com on behalf of Barry Leiba = Sent: 30 November 2016 04:49:12 To: draft-ietf-appsawg-file-scheme.all@ietf.org; secdir@ietf.org Cc: IETF discussion list; art@ietf.org Subject: SecDir review of draft-ietf-appsawg-file-scheme-14 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. Thanks for finally getting this through. I think the document is ready with nits; my detailed comments are below. It=92s a tiny thing, but where the abstract says =93replacing the definition in RFC 1738,=94 one may be led to think (I was) that 1738 has a more robust definition than it does. D=92you mind changing that to something like this: =91This document provides a full specification of the "file" Uniform Resource Identifier (URI) scheme, replacing the very brief definition in Section 3.10 of RFC 1738.=92 The Security Considerations section is well thought out; thanks. The only thing I can think of that might be added is a few words about non-local file URIs. Section 3 says two significant things that should be highlighted in a security consideration: 1. A file URI can be dependably dereferenced or translated to a local file path only if it is local. 2. This specification neither defines nor forbids any set of operations that might be performed on a file identified by a non-local file URI. Given those two things, I think it would be worth explicitly saying that treating a non-local URI as local or otherwise attempting to perform local operations on a non-local URI can result in security problems. Matthew=92s name and address will be on the RFC, of course, but is that really the best choice for contact information for the scheme in the registry? Or would it be better to point people to =93Applications and Real-Time Area =94 ? In general, we seem to have mixed feelings about listing individuals as contact points for things registered by working group documents (and I fall on the =93avoid using specific individuals=94 side, because individuals often come and go over relatively short time). The =93References=94 in the registry template should just be =93this RFC=94= , and this RFC number will appear in the registry. A bit of process geekery: In the Acknowledgments, you say=85 This specification is derived from [RFC1738], [RFC3986], and [I-D.hoffman-file-uri] (expired); the acknowledgements in those documents still apply. I don=92t imagine there=92s actually text from 1738 in here (is there?). How much text is here from 3986? I=92m not talking about concepts, but actual text that was brought over. If there is, have you made sure that all authors of the documents you got text from agree to the terms of BCPs 78 & 79 ? If not, there might need to be a pre-5378 disclaimer in the boilerplate. I suspect we=92re OK, because we=92re mostly talking about Larry, Roy, and TimBL, but I just wanted to check. (I personally think the acknowledgments text above is a bit much, unless you=92ve really copied a lot of text from those RFCs. But that=92s your section to do with as you think best.) References: I don=92t think BCP35 is normative, and I=92d move it to informative. I don=92t think UAX15 is normative, and I=92d move it to informative. I think UTF-8 is normative (as you have it), but UNICODE is not. Others might disagree with that. I think I would make RFC 6454 normative, only because it=92s listed as a reference for =93the most secure option=94 in the Security Considerations. Barry From nobody Tue Dec 6 17:43:08 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732EC129625; Tue, 6 Dec 2016 17:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwJSPBqUba7N; Tue, 6 Dec 2016 17:42:54 -0800 (PST) Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com [209.85.220.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 B71771295C1; Tue, 6 Dec 2016 17:42:54 -0800 (PST) Received: by mail-qk0-f171.google.com with SMTP id x190so399808042qkb.0; Tue, 06 Dec 2016 17:42:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fj8EEAA6BJEvgOwYRd7ysEYlaeXmuvOaML/ZDWTxcVQ=; b=ILhd/XLHbz3TqpqxBKLHgjSBnvpwl0jdFbuV6RZnDn+YusiMimaziIbKaGtv159Niv huR9d53leN9RO2/ejQI+4t8/hKsqVeY8r14xDF/098eo1jsb7UEbU/89vWDmreyEkOOT eNhVO7LJ6q6yii9gClDjdIqc7X+6LdHP0pAH3FhStyGPnP0TbfPKAzk35RSnyFigmBTw S4aV+6ZsncOK5K5PbAVQKaHP3VE8aj/BSU7zjzpqfcnPWZZIdVuL22fQfgZQ2xbs2TEu 9Y1RUM3SUAqq2GqwqosBmvYFgC71/OelQ/105B5S+5XTanVAbFJSdHA0pHchclJeIxlO nJ4Q== X-Gm-Message-State: AKaTC02j8rL6UvMV1gPGgx3svztYcmJYZ0fIxUoWSOHKw19ePOG0V/kTZKWAsR/BSk1DbcjJzoFnT1UU9sU52g== X-Received: by 10.233.232.133 with SMTP id a127mr62773570qkg.235.1481074973843; Tue, 06 Dec 2016 17:42:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Wed, 07 Dec 2016 01:42:43 +0000 Message-ID: To: Matthew Kerwin , "draft-ietf-appsawg-file-scheme.all@ietf.org" , "secdir@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c034bfcb3a70b054307a3cc Archived-At: Cc: "art@ietf.org" , IETF discussion list , "paul.hoffman@vpnc.org" Subject: Re: [secdir] SecDir review of draft-ietf-appsawg-file-scheme-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 01:42:57 -0000 --94eb2c034bfcb3a70b054307a3cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Matthew! b On Tue, Dec 6, 2016 at 7:03 PM Matthew Kerwin wrote: > Thanks Barry (and Paul), > > I agree with everything you've written here, and I don't think any of it'= s > too controversial, so I'll work it all in to my copy pretty much exactly > as you've suggested. > > The acknowledgements is hung over from the very first versions of the > draft, which cribbed a lot from Paul's old draft. I'm pretty sure it's be= en > completely rewritten several times since then, so I will definitely redo > the acks. > > Cheers > -- > Matthew Kerwin | Queensland University of Technology | > matthew.kerwin@qut.edu.au | CRICOS No 00213J > ________________________________ > From: barryleiba@gmail.com on behalf of Barry > Leiba > Sent: 30 November 2016 04:49:12 > To: draft-ietf-appsawg-file-scheme.all@ietf.org; secdir@ietf.org > Cc: IETF discussion list; art@ietf.org > Subject: SecDir review of draft-ietf-appsawg-file-scheme-14 > > 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. > > Thanks for finally getting this through. I think the document is > ready with nits; my detailed comments are below. > > It=E2=80=99s a tiny thing, but where the abstract says =E2=80=9Creplacing= the > definition in RFC 1738,=E2=80=9D one may be led to think (I was) that 173= 8 has > a more robust definition than it does. D=E2=80=99you mind changing that = to > something like this: =E2=80=98This document provides a full specification= of > the "file" Uniform Resource Identifier (URI) scheme, replacing the > very brief definition in Section 3.10 of RFC 1738.=E2=80=99 > > The Security Considerations section is well thought out; thanks. The > only thing I can think of that might be added is a few words about > non-local file URIs. Section 3 says two significant things that > should be highlighted in a security consideration: > 1. A file URI can be dependably dereferenced or translated to a local > file path only if it is local. > 2. This specification neither defines nor forbids any set of > operations that might be performed on a file identified by a non-local > file URI. > > Given those two things, I think it would be worth explicitly saying > that treating a non-local URI as local or otherwise attempting to > perform local operations on a non-local URI can result in security > problems. > > Matthew=E2=80=99s name and address will be on the RFC, of course, but is = that > really the best choice for contact information for the scheme in the > registry? Or would it be better to point people to =E2=80=9CApplications= and > Real-Time Area =E2=80=9D ? In general, we seem to have mix= ed > feelings about listing individuals as contact points for things > registered by working group documents (and I fall on the =E2=80=9Cavoid u= sing > specific individuals=E2=80=9D side, because individuals often come and go= over > relatively short time). > > The =E2=80=9CReferences=E2=80=9D in the registry template should just be = =E2=80=9Cthis RFC=E2=80=9D, > and this RFC number will appear in the registry. > > A bit of process geekery: > In the Acknowledgments, you say=E2=80=A6 > This specification is derived from [RFC1738], [RFC3986], and > [I-D.hoffman-file-uri] (expired); the acknowledgements in those > documents still apply. > > I don=E2=80=99t imagine there=E2=80=99s actually text from 1738 in here (= is there?). > How much text is here from 3986? I=E2=80=99m not talking about concepts,= but > actual text that was brought over. If there is, have you made sure > that all authors of the documents you got text from agree to the terms > of BCPs 78 & 79 ? If not, there might need to be a pre-5378 > disclaimer in the boilerplate. I suspect we=E2=80=99re OK, because we=E2= =80=99re > mostly talking about Larry, Roy, and TimBL, but I just wanted to > check. > > (I personally think the acknowledgments text above is a bit much, > unless you=E2=80=99ve really copied a lot of text from those RFCs. But t= hat=E2=80=99s > your section to do with as you think best.) > > References: > I don=E2=80=99t think BCP35 is normative, and I=E2=80=99d move it to info= rmative. > I don=E2=80=99t think UAX15 is normative, and I=E2=80=99d move it to info= rmative. > I think UTF-8 is normative (as you have it), but UNICODE is not. > Others might disagree with that. > I think I would make RFC 6454 normative, only because it=E2=80=99s listed= as a > reference for =E2=80=9Cthe most secure option=E2=80=9D in the Security Co= nsiderations. > > Barry > --94eb2c034bfcb3a70b054307a3cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Matthew!

b

On Tue, Dec 6, 2016 at 7:03 PM Matt= hew Kerwin <matthew.kerwin@= qut.edu.au> wrote:
Thanks B= arry (and Paul),

I agree with everything you've written here, and I don't think any = of it's too controversial,=C2=A0 so I'll work it all in to my copy = pretty much exactly as you've suggested.

The acknowledgements is hung over from the very first versions of the draft= , which cribbed a lot from Paul's old draft. I'm pretty sure it'= ;s been completely rewritten several times since then, so I will definitely= redo the acks.

Cheers
--
Matthew Kerwin=C2=A0 |=C2=A0 Queensland University of Technology=C2=A0 |=C2= =A0 matthew.kerwin@qut.edu.au=C2=A0 |=C2=A0 CRICOS No 00213J ________________________________
From: barryleiba@gmail.com <barryleiba@gmail.com> on be= half of Barry Leiba <barryleiba@computer.org>
Sent: 30 November 2016 04:49:12
To: draft-ietf-appsawg-file-scheme.all@ietf.org; secdir@ietf.org
Cc: IETF discussion list; art@ietf.org
Subject: SecDir review of draft-ietf-appsawg-file-scheme-14

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

Thanks for finally getting this through.=C2=A0 I think the document is
ready with nits; my detailed comments are below.

It=E2=80=99s a tiny thing, but where the abstract says =E2=80=9Creplacing t= he
definition in RFC 1738,=E2=80=9D one may be led to think (I was) that 1738 = has
a more robust definition than it does.=C2=A0 D=E2=80=99you mind changing th= at to
something like this: =E2=80=98This document provides a full specification o= f
the "file" Uniform Resource Identifier (URI) scheme, replacing th= e
very brief definition in Section 3.10 of RFC 1738.=E2=80=99

The Security Considerations section is well thought out; thanks.=C2=A0 The<= br class=3D"gmail_msg"> only thing I can think of that might be added is a few words about
non-local file URIs.=C2=A0 Section 3 says two significant things that
should be highlighted in a security consideration:
1. A file URI can be dependably dereferenced or translated to a local
file path only if it is local.
2. This specification neither defines nor forbids any set of
operations that might be performed on a file identified by a non-local
file URI.

Given those two things, I think it would be worth explicitly saying
that treating a non-local URI as local or otherwise attempting to
perform local operations on a non-local URI can result in security
problems.

Matthew=E2=80=99s name and address will be on the RFC, of course, but is th= at
really the best choice for contact information for the scheme in the
registry?=C2=A0 Or would it be better to point people to =E2=80=9CApplicati= ons and
Real-Time Area <art@ietf.org>=E2=80=9D ?=C2=A0 In general, we seem to = have mixed
feelings about listing individuals as contact points for things
registered by working group documents (and I fall on the =E2=80=9Cavoid usi= ng
specific individuals=E2=80=9D side, because individuals often come and go o= ver
relatively short time).

The =E2=80=9CReferences=E2=80=9D in the registry template should just be = =E2=80=9Cthis RFC=E2=80=9D,
and this RFC number will appear in the registry.

A bit of process geekery:
In the Acknowledgments, you say=E2=80=A6
=C2=A0 =C2=A0This specification is derived from [RFC1738], [RFC3986], and =C2=A0 =C2=A0[I-D.hoffman-file-uri] (expired); the acknowledgements in thos= e
=C2=A0 =C2=A0documents still apply.

I don=E2=80=99t imagine there=E2=80=99s actually text from 1738 in here (is= there?).
How much text is here from 3986?=C2=A0 I=E2=80=99m not talking about concep= ts, but
actual text that was brought over.=C2=A0 If there is, have you made sure that all authors of the documents you got text from agree to the terms
of BCPs 78 & 79 ?=C2=A0 If not, there might need to be a pre-5378
disclaimer in the boilerplate.=C2=A0 I suspect we=E2=80=99re OK, because we= =E2=80=99re
mostly talking about Larry, Roy, and TimBL, but I just wanted to
check.

(I personally think the acknowledgments text above is a bit much,
unless you=E2=80=99ve really copied a lot of text from those RFCs.=C2=A0 Bu= t that=E2=80=99s
your section to do with as you think best.)

References:
I don=E2=80=99t think BCP35 is normative, and I=E2=80=99d move it to inform= ative.
I don=E2=80=99t think UAX15 is normative, and I=E2=80=99d move it to inform= ative.
I think UTF-8 is normative (as you have it), but UNICODE is not.
Others might disagree with that.
I think I would make RFC 6454 normative, only because it=E2=80=99s listed a= s a
reference for =E2=80=9Cthe most secure option=E2=80=9D in the Security Cons= iderations.

Barry
--94eb2c034bfcb3a70b054307a3cc-- From nobody Tue Dec 6 18:03:27 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A18312955B; Tue, 6 Dec 2016 18:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ir86h-_mHEtB; Tue, 6 Dec 2016 18:03:15 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0046.outbound.protection.outlook.com [104.47.37.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FA981293E1; Tue, 6 Dec 2016 18:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=j/uOZL8fKkUFTW0NaF2nL1ZDaYxOdXC4qcqwicl403g=; b=NX4bH12C+pVPidPi9+YP1SU0PLTssLgDazfKtM2WsJPRSyoQl816mi9YJ68M16yJLgiOLVneYC2lQpt3fnSEuDC6mXKMhvLMlp33gDk6pQqwmDUHFYx8F7TzvUVc+31/PD/YF2lBqotPJE/q64pqxgUhEgXs1p/gXiV+Av3VMWc= Received: from CY1PR0201MB1530.namprd02.prod.outlook.com (10.163.139.21) by CY1PR0201MB1530.namprd02.prod.outlook.com (10.163.139.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Wed, 7 Dec 2016 02:03:13 +0000 Received: from CY1PR0201MB1530.namprd02.prod.outlook.com ([10.163.139.21]) by CY1PR0201MB1530.namprd02.prod.outlook.com ([10.163.139.21]) with mapi id 15.01.0761.017; Wed, 7 Dec 2016 02:03:13 +0000 From: Larry Masinter To: Matthew Kerwin , Barry Leiba , "draft-ietf-appsawg-file-scheme.all@ietf.org" , "secdir@ietf.org" Thread-Topic: SecDir review of draft-ietf-appsawg-file-scheme-14 Thread-Index: AQHSSnFVunzqwIpXrEWQJ/jl2GkxXqD7tmcA//+KuYA= Date: Wed, 7 Dec 2016 02:03:13 +0000 Message-ID: <76D997B0-226E-4994-B6D1-E42A7A6A8E43@adobe.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.18.0.160709 authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.150.10.207] x-ms-office365-filtering-correlation-id: 821e9304-0229-446f-b6a5-08d41e4533c8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0201MB1530; x-microsoft-exchange-diagnostics: 1; CY1PR0201MB1530; 7:oB2C9uRAw3RPcc+YTac29fep4Dp92Y7JpP3U8mUC/wFEVOK+KQC14UfQT7tjIjqxVrC+3vNw9fzHLVaLRCSvepUgQ6izlAynl+zFC6zIOUiHbqEg+XsU6Nrum5LieXt579L4LxQX/Yamy2gHDaoxEKBzwUuRH3jTOFOpQeqhFLjlP2L4YZYEGEgDPxnmqhbH52uajP0AbVjrtW75R9YjOVevZFpfbRkWncM3w9KDgcY97Rk1DdrogXHKuSQUw0u5/0ik8HB7uZDk+ROLGnertzFWxtfX8wAnmOnbyXldGyAH+m0gba7anFniva+2LMxEB4gHKcOkdUR1FHrO49J4CybJW8ZXzxZsZ9dYgb6M8/wPX9NFKunDdvajttMFdjtzgc462Xq/+57s4tWBMLiaIMloEmcY85iE4i1Gd14m8ZcrqGw6x4juIjvdze6hVj9mQiwzidJ4qbsxlLLJxQ16jg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558021)(6072148); SRVR:CY1PR0201MB1530; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0201MB1530; x-forefront-prvs: 01494FA7F7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(82746002)(68736007)(83506001)(5660300001)(33656002)(101416001)(54356999)(229853002)(76176999)(50986999)(7736002)(305945005)(7846002)(4326007)(2906002)(189998001)(81166006)(92566002)(97736004)(2950100002)(10090500001)(4001350100001)(5001770100001)(36756003)(3280700002)(230783001)(81156014)(102836003)(3660700001)(6116002)(3846002)(2171001)(83716003)(66066001)(2900100001)(105586002)(99286002)(6506006)(39840400001)(8676002)(6512006)(106116001)(77096006)(6486002)(122556002)(39850400001)(39450400002)(86362001)(2501003)(2201001)(8936002)(39860400001)(39410400001)(38730400001)(106356001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0201MB1530; H:CY1PR0201MB1530.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2016 02:03:13.2758 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0201MB1530 Archived-At: Cc: "art@ietf.org" , IETF discussion list , "paul.hoffman@vpnc.org" Subject: Re: [secdir] SecDir review of draft-ietf-appsawg-file-scheme-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 02:03:17 -0000 DQogICAgIEl04oCZcyBhIHRpbnkgdGhpbmcsIGJ1dCB3aGVyZSB0aGUgYWJzdHJhY3Qgc2F5cyDi gJxyZXBsYWNpbmcgdGhlDQogICAgZGVmaW5pdGlvbiBpbiBSRkMgMTczOCzigJ0gb25lIG1heSBi ZSBsZWQgdG8gdGhpbmsgKEkgd2FzKSB0aGF0IDE3MzggaGFzDQogICAgYSBtb3JlIHJvYnVzdCBk ZWZpbml0aW9uIHRoYW4gaXQgZG9lcy4gIETigJl5b3UgbWluZCBjaGFuZ2luZyB0aGF0IHRvDQog ICAgc29tZXRoaW5nIGxpa2UgdGhpczog4oCYVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIGZ1bGwg c3BlY2lmaWNhdGlvbiBvZg0KICAgIHRoZSAiZmlsZSIgVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlm aWVyIChVUkkpIHNjaGVtZSwgcmVwbGFjaW5nIHRoZQ0KICAgIHZlcnkgYnJpZWYgZGVmaW5pdGlv biBpbiBTZWN0aW9uIDMuMTAgb2YgUkZDIDE3Mzgu4oCZDQogICAgDQpzL2Z1bGwvbW9yZSBjb21w bGV0ZS8NCg0KQSDigJxmdWxs4oCdIHNwZWNpZmljYXRpb24gb2YgZmlsZTogVVJJcyBtaWdodCBp bmNsdWRlIGEgc2V0IG9mIHBsYXRmb3JtIGFuZCBmaWxlLXN5c3RlbSBzcGVjaWZpYyBpbXBsZW1l bnRhdGlvbiBhZHZpY2UgYWJvdXQgaG93IHRvIGhhbmRsZSBmaWxlIG5hbWluZywgdmFyaWF0aW9u cyBpbiBVbmljb2RlIG5vcm1hbGl6YXRpb24sIGNhc2Ugc2Vuc2l0aXZpdHksIGFuZCBzbyBmb3J0 aC4NCiANCg0K From nobody Tue Dec 6 21:45:40 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A227A12967A; Tue, 6 Dec 2016 21:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CShZUu91GUfp; Tue, 6 Dec 2016 21:45:36 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0066.outbound.protection.outlook.com [104.47.41.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B2A12967E; Tue, 6 Dec 2016 21:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=H0oHKAzjxhXGK/m0DbYj1e8N3dmuX/7GP0sTL1Q6kto=; b=K/dw0XAT3pFLbxl/G+A4CPGkxZyF+qJGOF15EtER2lzBpA4vnYv7KvZsnId7zpNSHPrRCO9/gRHEWcV/oh31zPkkt7V2mbpkAEHhIyToYm+1onm/xDlI0wpOd8jKqgJIWsSjqRF2iRk9mJP/up9DkLXgNDo1jTGmvQUr05g45nk= Received: from CY1PR0201MB1530.namprd02.prod.outlook.com (10.163.139.21) by CY1PR0201MB1529.namprd02.prod.outlook.com (10.163.139.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Wed, 7 Dec 2016 05:45:32 +0000 Received: from CY1PR0201MB1530.namprd02.prod.outlook.com ([10.163.139.21]) by CY1PR0201MB1530.namprd02.prod.outlook.com ([10.163.139.21]) with mapi id 15.01.0761.018; Wed, 7 Dec 2016 05:45:32 +0000 From: Larry Masinter To: Larry Masinter , Matthew Kerwin , Barry Leiba , "draft-ietf-appsawg-file-scheme.all@ietf.org" , "secdir@ietf.org" Thread-Topic: SecDir review of draft-ietf-appsawg-file-scheme-14 Thread-Index: AQHSSnFVunzqwIpXrEWQJ/jl2GkxXqD7tmcA//+KuYCAAMBVEA== Date: Wed, 7 Dec 2016 05:45:32 +0000 Message-ID: References: <76D997B0-226E-4994-B6D1-E42A7A6A8E43@adobe.com> In-Reply-To: <76D997B0-226E-4994-B6D1-E42A7A6A8E43@adobe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; x-originating-ip: [50.184.24.49] x-microsoft-exchange-diagnostics: 1; CY1PR0201MB1529; 7:GgIIGFlpgyR8wV0s8o5koAxXgfxo6GHhe8j87La5NAk2OlE8az+bt0nM5CAP/uazZl/fdORznh6JU21ua4rVWamA1BFXSIeuSrdUpzBW10FSEU/oDY584+cAP8iiyNlnlEuG/KTYgBZkHEFfx60X671uEucIn9GMdAwZrM/o1ikeySOZRJC2y8DezuxE9zuDhC+Q1cyYw11nNRw4Cvu3uUc+ZgSY67v18k4qwuNAyLvlCacVz/mu4kKlFsj3yGoFt3JVB0yiyJrSEGoGc2Mpn70612rSiJ2wJum3BZhPcUK8BBRMw36xM7+O16EMU/5OwIrm2Z6YFm5+aFk8rAznyDLb822JzbFrEDkA59K+P3fE295HBxrnTXO+eAFVH9w+Fx5Fqbs3xwXzcZiw1AUmwUOW5hbdllAiuVJXq9a8ArolluOvg6wqzsIRWbEgEjSciPNhSwpW1YAX+oWzw9u+VA== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(13464003)(199003)(189002)(377454003)(81156014)(66066001)(5660300001)(230783001)(3660700001)(2906002)(2501003)(122556002)(5001770100001)(3280700002)(7696004)(2950100002)(38730400001)(50986999)(8936002)(101416001)(77096006)(6506006)(33656002)(189998001)(54356999)(105586002)(97736004)(9686002)(8676002)(81166006)(106356001)(2900100001)(92566002)(99286002)(76576001)(16601075003)(10090500001)(8990500004)(68736007)(76176999)(106116001)(587094005)(229853002)(3846002)(102836003)(6116002)(7846002)(305945005)(4326007)(86362001)(2171001)(74316002)(7736002)(2201001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0201MB1529; H:CY1PR0201MB1530.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: de1987f6-fb4c-4f1b-0e25-08d41e64425c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0201MB1529; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(54900358751275); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6042181)(6072148); SRVR:CY1PR0201MB1529; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0201MB1529; x-forefront-prvs: 01494FA7F7 received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2016 05:45:32.2162 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0201MB1529 Archived-At: Cc: "art@ietf.org" , IETF discussion list , "paul.hoffman@vpnc.org" Subject: Re: [secdir] SecDir review of draft-ietf-appsawg-file-scheme-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 05:45:39 -0000 SnVzdCB0byBiZSBjbGVhcjogSSB0aGluayB0aGUgbGV2ZWwgb2Ygc3BlY2lmaWNhdGlvbiBpbiB0 aGlzIGRvY3VtZW50DQppcyBhcHByb3ByaWF0ZSBhbmQgYSAiZnVsbCIgc3BlY2lmaWNhdGlvbiB3 b3VsZCBiZSBpbnRyYWN0YWJsZS4NCiANCkJ1dCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gYmUganVz dCBhIGJpdCBtb3JlIGV4cGxpY2l0IGFib3V0IHRoZSB0aGluZ3MNCnRoYXQgeW91IHNob3VsZCBm aWd1cmUgb3V0IGJlZm9yZSBpbXBsZW1lbnRpbmcgKGFib3V0IHdoYXQNCm90aGVyIGltcGxlbWVu dGF0aW9ucyBkbyBvbiB0aGUgc2FtZSBwbGF0Zm9ybSkuDQoNCkxhcnJ5DQotLQ0KaHR0cDovL2xh cnJ5Lm1hc2ludGVyLm5ldA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IGlldGYgW21haWx0bzppZXRmLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMYXJyeSBN YXNpbnRlcg0KPiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciA2LCAyMDE2IDY6MDMgUE0NCj4gVG86 IE1hdHRoZXcgS2Vyd2luIDxtYXR0aGV3LmtlcndpbkBxdXQuZWR1LmF1PjsgQmFycnkgTGVpYmEN Cj4gPGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPjsgZHJhZnQtaWV0Zi1hcHBzYXdnLWZpbGUtDQo+ IHNjaGVtZS5hbGxAaWV0Zi5vcmc7IHNlY2RpckBpZXRmLm9yZw0KPiBDYzogYXJ0QGlldGYub3Jn OyBJRVRGIGRpc2N1c3Npb24gbGlzdCA8aWV0ZkBpZXRmLm9yZz47DQo+IHBhdWwuaG9mZm1hbkB2 cG5jLm9yZw0KPiBTdWJqZWN0OiBSZTogU2VjRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWFwcHNh d2ctZmlsZS1zY2hlbWUtMTQNCj4gDQo+IA0KPiAgICAgIEl04oCZcyBhIHRpbnkgdGhpbmcsIGJ1 dCB3aGVyZSB0aGUgYWJzdHJhY3Qgc2F5cyDigJxyZXBsYWNpbmcgdGhlDQo+ICAgICBkZWZpbml0 aW9uIGluIFJGQyAxNzM4LOKAnSBvbmUgbWF5IGJlIGxlZCB0byB0aGluayAoSSB3YXMpIHRoYXQg MTczOCBoYXMNCj4gICAgIGEgbW9yZSByb2J1c3QgZGVmaW5pdGlvbiB0aGFuIGl0IGRvZXMuICBE 4oCZeW91IG1pbmQgY2hhbmdpbmcgdGhhdCB0bw0KPiAgICAgc29tZXRoaW5nIGxpa2UgdGhpczog 4oCYVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIGZ1bGwgc3BlY2lmaWNhdGlvbiBvZg0KPiAgICAg dGhlICJmaWxlIiBVbmlmb3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSkgc2NoZW1lLCByZXBs YWNpbmcgdGhlDQo+ICAgICB2ZXJ5IGJyaWVmIGRlZmluaXRpb24gaW4gU2VjdGlvbiAzLjEwIG9m IFJGQyAxNzM4LuKAmQ0KPiANCj4gcy9mdWxsL21vcmUgY29tcGxldGUvDQo+IA0KPiBBIOKAnGZ1 bGzigJ0gc3BlY2lmaWNhdGlvbiBvZiBmaWxlOiBVUklzIG1pZ2h0IGluY2x1ZGUgYSBzZXQgb2Yg cGxhdGZvcm0gYW5kDQo+IGZpbGUtc3lzdGVtIHNwZWNpZmljIGltcGxlbWVudGF0aW9uIGFkdmlj ZSBhYm91dCBob3cgdG8gaGFuZGxlIGZpbGUNCj4gbmFtaW5nLCB2YXJpYXRpb25zIGluIFVuaWNv ZGUgbm9ybWFsaXphdGlvbiwgY2FzZSBzZW5zaXRpdml0eSwgYW5kIHNvDQo+IGZvcnRoLg0KPiAN Cg0K From nobody Tue Dec 6 23:11:07 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E491294CC; Tue, 6 Dec 2016 23:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7anet28lyE0e; Tue, 6 Dec 2016 23:11:00 -0800 (PST) Received: from butterfly.maple.relay.mailchannels.net (butterfly.maple.relay.mailchannels.net [23.83.214.27]) (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 8A42E129695; Tue, 6 Dec 2016 23:10:58 -0800 (PST) X-Sender-Id: webafrica|x-authuser|info@allaboutmzansi.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 049B91BC8E0; Wed, 7 Dec 2016 07:10:57 +0000 (UTC) Received: from srv09.hostserv.co.za (ip-10-27-139-41.us-west-2.compute.internal [10.27.139.41]) by relay.mailchannels.net (Postfix) with ESMTPA id 8F44A1BD7CA; Wed, 7 Dec 2016 07:10:52 +0000 (UTC) X-Sender-Id: webafrica|x-authuser|info@allaboutmzansi.com Received: from srv09.hostserv.co.za (srv09.hostserv.co.za [10.107.128.240]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.7.8); Wed, 07 Dec 2016 07:10:56 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: webafrica|x-authuser|info@allaboutmzansi.com X-MailChannels-Auth-Id: webafrica X-MC-Loop-Signature: 1481094655514:2606586813 X-MC-Ingress-Time: 1481094655514 Received: from [105.15.1.252] (port=30096 helo=AllistairPC) by srv09.hostserv.co.za with esmtpa (Exim 4.87) (envelope-from ) id 1cEWNF-003cN4-B1; Wed, 07 Dec 2016 09:10:41 +0200 From: "Allistair Brown" To: "'Larry Masinter'" , "'Matthew Kerwin'" , "'Barry Leiba'" , , References: <76D997B0-226E-4994-B6D1-E42A7A6A8E43@adobe.com> In-Reply-To: Date: Wed, 7 Dec 2016 09:10:45 +0200 Organization: All About Mzansi Message-ID: <002a01d25059$08ac32a0$1a0497e0$@allaboutmzansi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKu8cL81g0nNe6soJub8E5PgLz56AHA20IDAd4w1qkCgesC658RxpiQ Content-Language: en-za X-AuthUser: info@allaboutmzansi.com Archived-At: Cc: art@ietf.org, 'IETF discussion list' , paul.hoffman@vpnc.org Subject: Re: [secdir] [art] SecDir review of draft-ietf-appsawg-file-scheme-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: info@allaboutmzansi.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 07:11:03 -0000 Hi everyone, please remove me from this email thread. Thank you. -----Original Message----- From: art [mailto:art-bounces@ietf.org] On Behalf Of Larry Masinter Sent: 07 December 2016 07:46 AM To: Larry Masinter; Matthew Kerwin; Barry Leiba; = draft-ietf-appsawg-file-scheme.all@ietf.org; secdir@ietf.org Cc: art@ietf.org; IETF discussion list; paul.hoffman@vpnc.org Subject: Re: [art] SecDir review of draft-ietf-appsawg-file-scheme-14 Just to be clear: I think the level of specification in this document is = appropriate and a "full" specification would be intractable. =20 But it would be useful to be just a bit more explicit about the things = that you should figure out before implementing (about what other = implementations do on the same platform). Larry -- http://larry.masinter.net > -----Original Message----- > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Larry Masinter > Sent: Tuesday, December 6, 2016 6:03 PM > To: Matthew Kerwin ; Barry Leiba=20 > ; draft-ietf-appsawg-file-=20 > scheme.all@ietf.org; secdir@ietf.org > Cc: art@ietf.org; IETF discussion list ;=20 > paul.hoffman@vpnc.org > Subject: Re: SecDir review of draft-ietf-appsawg-file-scheme-14 >=20 >=20 > It=E2=80=99s a tiny thing, but where the abstract says = =E2=80=9Creplacing the > definition in RFC 1738,=E2=80=9D one may be led to think (I was) = that 1738 has > a more robust definition than it does. D=E2=80=99you mind = changing that to > something like this: =E2=80=98This document provides a full = specification of > the "file" Uniform Resource Identifier (URI) scheme, replacing the > very brief definition in Section 3.10 of RFC 1738.=E2=80=99 >=20 > s/full/more complete/ >=20 > A =E2=80=9Cfull=E2=80=9D specification of file: URIs might include a = set of platform=20 > and file-system specific implementation advice about how to handle=20 > file naming, variations in Unicode normalization, case sensitivity,=20 > and so forth. >=20 _______________________________________________ art mailing list art@ietf.org https://www.ietf.org/mailman/listinfo/art From nobody Thu Dec 8 04:03:28 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83145129D7C for ; Thu, 8 Dec 2016 04:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if1eQh69LokU for ; Thu, 8 Dec 2016 04:03:25 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E76129D73 for ; Thu, 8 Dec 2016 04:02:41 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uB8C2bac010105 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 8 Dec 2016 14:02:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uB8C2b8d018590; Thu, 8 Dec 2016 14:02:37 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22601.19421.234943.131644@fireball.acr.fi> Date: Thu, 8 Dec 2016 14:02:37 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 3 min X-Total-Time: 0 min Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 12:03:27 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Melinda Shore is next in the rotation. For telechat 2016-05-05 Reviewer LC end Draft Rifaat Shekh-Yusef T 2016-04-15 draft-ietf-sidr-as-migration-06 For telechat 2016-12-15 Dan Harkins T 2016-11-16 draft-ietf-dprive-dnsodtls-13 Warren Kumari TR2016-12-08 draft-wilde-json-seq-suffix-01 Ben Laurie T 2016-12-08 draft-ietf-6lo-dispatch-iana-registry-06 Dacheng Zhang TR2016-12-13 draft-ietf-core-http-mapping-17 For telechat 2017-01-05 Russ Housley T 2016-12-16 draft-ietf-sidr-bgpsec-protocol-20 Tero Kivinen T 2016-12-20 draft-ietf-6tisch-minimal-17 Sandy Murphy T 2016-12-20 draft-ietf-6tisch-minimal-17 Hilarie Orman T 2017-01-03 draft-ietf-i2rs-yang-l3-topology-06 Eric Osterweil T 2016-12-19 draft-ietf-i2rs-yang-network-topo-09 Radia Perlman T 2016-12-16 draft-ietf-idr-deprecate-30-31-129-00 Vincent Roca T 2016-12-16 draft-ietf-idr-large-community-11 Joe Salowey T 2016-12-20 draft-ietf-manet-olsrv2-sec-threats-03 Rich Salz T 2016-12-21 draft-ietf-sidr-bgpsec-ops-12 Yaron Sheffer T 2016-12-19 draft-ietf-sidr-bgpsec-pki-profiles-18 Last calls and special requests: Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Daniel Kahn Gillmor E 2016-02-01 draft-ietf-rtcweb-security-08 Stephen Kent E None draft-ietf-dnssd-pairing-00 Matt Lepinski 2016-12-14 draft-ietf-avtext-avpf-ccm-layered-03 Matthew Miller 2017-01-13 draft-harkins-owe-05 Yoav Nir 2016-12-16 draft-ietf-curdle-cms-chacha20-poly1305-04 Magnus Nystrom 2016-12-16 draft-ietf-curdle-dnskey-eddsa-02 Hannes Tschofenig E None draft-ietf-ntp-network-time-security-15 Hannes Tschofenig E None draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig E None draft-ietf-ntp-using-nts-for-ntp-07 Brian Weis E 2016-02-01 draft-ietf-cdni-uri-signing-10 -- kivinen@iki.fi From nobody Thu Dec 8 08:27:09 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CA4129489 for ; Thu, 8 Dec 2016 08:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kHTQDmy0_qU for ; Thu, 8 Dec 2016 08:27:04 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A82129FD3 for ; Thu, 8 Dec 2016 08:27:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C85BE300272 for ; Thu, 8 Dec 2016 11:16:46 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3cWMq7rXTBUU for ; Thu, 8 Dec 2016 11:16:45 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id A11F030026D; Thu, 8 Dec 2016 11:16:44 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 8 Dec 2016 11:26:26 -0500 Message-Id: To: draft-ietf-sidr-bgpsec-protocol.all@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF SecDir Subject: [secdir] SecDir Review of draft-ietf-sidr-bgpsec-protocol-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 16:27:08 -0000 I 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 authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-sidr-bgpsec-protocol-20 Reviewer: Russ Housley Review Date: 2016-12-08 IETF LC End Date: 2016-12-16 IESG Telechat date: Unknown Summary: Almost Ready I also did a review for Gen-ART. This SecDir review is identical to that Gen-ART review. I was involved in the design of BGPsec, but I have not reviewed the document for a long time. Question I do not see any guidance on the handling of private AS numbers. I'm not sure whether it belongs in the document or not. I am thinking about a BGP stub customer that employs a private AS. If I understand properly, that stub customer cannot publish a ROA for the private AS number and the prefixes that it uses. So, the stub customer cannot become a BGPsec speaker. So, my question is about the BGPsec speaker that receives an announcement from the stub customer. Does that BGPsec speaker strip the private AS and sign an announcement? Will their ROA that cover the prefixes used by the stub customer? Major Concerns Section 2.2 says: ... A BGP speaker MAY announce BGPsec capability only if it supports the BGP multiprotocol extension [RFC4760]. ... This needs to be worded as a MUST NOT statement. The current wording does not align with the definition of MAY in RFC 2119. I think an additional consideration is needed in Section 6.2. This protocol design assumes a signer will compute a message digest and then digitally sign that digest. If someone wants to use a digital signature that works differently, there may be a significant change to this protocol. It is very unusual for the IANA Considerations to contain a figure, and Figure 10 really seems out of place. The version number can be put in an IANA registry, but there really is no need until a second value is needed. There is no reason to put Dir in an IANA registry, there are only two values and both are fully specified in this document. The unassigned bits must be zero until a new version is specified. Minor Concerns I find the Abstract misses some important information. Also, the old wording suggests that the attribute contains a single digital signature. I suggest: This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems (ASes) through which a BGP update message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each autonomous system that propagates the update message. The digital signatures provide confidence that every AS on the path of ASes listed in the update message has explicitly authorized the advertisement of the route. Section 2.1 says: ... The BGP speaker sets this bit to 0 to indicate the capability to receive BGPsec update messages. The BGP speaker sets this bit to 1 to indicate the capability to send BGPsec update messages. It seems a bit wasteful to repeat the whole capability for each direction. Wouldn't it be better to follow the example used in other capability definitions (such as RFC 7911) by using one of the unassigned bits? The Send/Receive pair of bits would have these semantics: This field indicates whether the sender is (a) able to receive BGPsec update messages from its peer (value 1), (b) able to send BGPsec update messages to its peer (value 2), or (c) both (value 3) for the address family identified in the AFI. For completeness, please add a paragraph to the end of Section 3.1 that describes the 4-octet AS Number field. Please state how an old 16-bit AS number is carried. In Section 3.2, the Signature Length within the Signature Segment does not count the length field itself. It seems that all of the other length values in this specification count the size of the length too. Consistency will avoid implementation errors. Section 4.2 references the MP_REACH_NLRI attribute; please add a citation to the RFC that defines that attribute. Nits Section 2.1 says: The second and third octets contain the 16-bit Address Family Identifier (AFI) which indicates the address family for which the BGPsec speaker is advertising support for BGPsec. This document only specifies BGPsec for use with two address families, IPv4 and IPv6, AFI values 1 and 2 respectively. BGPsec for use with other address families may be specified in future documents. Please reference RFC 4760 for a place to learn about AFI. In Section 4.1, the comma is in the wrong place, but when I tried to offer a correction, I thought that a slight rewording would also improve the clarity: OLD: If a BGPsec router has received only a non-BGPsec update message (without the BGPsec_Path attribute), containing the AS_PATH attribute, from a peer for a given prefix then it MUST NOT ... NEW: If a BGPsec router has received only a non-BGPsec update message containing the AS_PATH attribute (instead of the BGPsec_Path attribute) from a peer for a given prefix, then it MUST NOT ... Please reword the first paragraph of Section 4.2 to avoid the phrase "said route advertisement". While it is not wrong, it does feel very awkward. This is not a patent claim. The acronym "ASN" is not used until Section 4.4, and it is not expanded there. I suggest that all uses of ASM should be expanded to AS number. From nobody Thu Dec 8 13:47:42 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4F1129421 for ; Thu, 8 Dec 2016 13:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljp6c1d9FoGw for ; Thu, 8 Dec 2016 13:47:38 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp10.smtpout.orange.fr [80.12.242.132]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8DB1298B9 for ; Thu, 8 Dec 2016 13:47:37 -0800 (PST) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d86 with ME id HZna1u00817Lgi403Znbgn; Thu, 08 Dec 2016 22:47:36 +0100 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Thu, 08 Dec 2016 22:47:36 +0100 X-ME-IP: 92.170.5.52 To: David Mandelberg References: <022c6479-4bac-f18e-928a-796a0d7ebde3@mandelberg.org> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <6eb3ef06-c3f0-462e-0cc1-573e585cc221@trigofacile.com> Date: Thu, 8 Dec 2016 22:47:34 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <022c6479-4bac-f18e-928a-796a0d7ebde3@mandelberg.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-elie-nntp-tls-recommendations.all@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-elie-nntp-tls-recommendations-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 21:47:40 -0000 Hi David, > I think this document is ready with nits. Many thanks for having taken the time to review the document. > Section 2.4: I think the second to last bullet (about lack of STARTTLS) > should be expanded in scope to say "during any previous connection > within a (possibly configurable) time frame" instead of "during the > previous connection." Otherwise, a human might not see the warning the > first time, and the warning would disappear immediately after that. Oh, you're totally right. That's a pretty good catch. I've adopted your wording in the future revised I-D. Incidentally, I would like to point out that I received in the (concluded) IETF NNTP a suggestion of answer for the 3rd question in Appendix E: https://lists.eyrie.org/pipermail/ietf-nntp/2016-November/006249.html https://lists.eyrie.org/pipermail/ietf-nntp/2016-December/006251.html FYI, the use of ports 119 and 433 is described in Sections 3.4.1 and 3.4.2 of RFC 3977: The official TCP port for the NNTP service is 119. However, if a host wishes to offer separate servers for transit and reading clients, port 433 SHOULD be used for the transit server and 119 for the reading server. I believe it is OK to take the following text into account for the ports to use for NNTP over TLS, but I prefer to share with you the wording in case you have any comments about it. (Maybe it is not clear enough!) We would then have in Appendix A of the document: The third and fourth paragraphs in Section 1 of [RFC4642] are replaced with the following text: TCP port 563 is dedicated to NNTP over TLS, and registered in the IANA Service Name and Transport Protocol Port Number Registry for that usage. NNTP implementations using TCP port 563 begin the TLS negotiation immediately upon connection and then continue with the initial steps of an NNTP session. This use of strict TLS on a separate port is the preferred way of using TLS with NNTP. If a host wishes to offer separate servers for transit and reading clients, TCP port 563 SHOULD be used for the reading server using strict TLS. If a transit server offers strict TLS, it SHOULD use TCP port 433 if it does not accept unencrypted connections, but can alternatively use another unused port of its choice. If it accepts dynamic upgrade from unencrypted to TLS-protected traffic, it SHOULD use TCP port 433 for that usage, and another unused port of its choice for strict TLS. In either case, the port used for strict TLS should be clearly communicated to the client, and specifically that no plain-text communication occurs before the TLS session is negotiated. -- Julien ÉLIE « – Et si vous ne trouvez pas, je vous fais bouillir et servir aux lions avec de la sauce à la menthe !!! – Mais c'est horrible ça ! – Oui, pauvres bêtes ! » (Astérix) From nobody Thu Dec 8 14:19:11 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294D3129B52 for ; Thu, 8 Dec 2016 14:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKyzQRq7FA8C for ; Thu, 8 Dec 2016 14:19:02 -0800 (PST) Received: from nm23-vm9.access.bullet.mail.bf1.yahoo.com (nm23-vm9.access.bullet.mail.bf1.yahoo.com [216.109.115.168]) (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 28899129ECC for ; Thu, 8 Dec 2016 14:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1481235339; bh=GUggcJ9uOuFZWUJwvgz1pHtq+LTAAOmgF2Vf83xs5d8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From:Subject; b=BNd51Tfx+k6LRLKPgodLj2DvhKcR/l12zuwexf2geSHmsHoBfhPsMN7nmZXtHMfWQRizGe3bt2Qr9l0I9yUCkaDiklnYmEcAFhyzI9V0CjtflEd9Ebb58y/XI+sf/VnqUc0psEm1NCjSg7IDdeHo6HVINVRBnkxQErEiMbo2ZK+9Db024J3QMOa+9BASGcvqXx64VMMVbueqvIvbTJk4bsbjqW/8/1GdBlsIGePKbcdjCYVltV3G1qqTHMjkzV7mxZ+9n4TSv+0ZdPhrMoYS6i1ujp6LQVKrl+k2LzUKU0ukak7qszJ7pn5bghESmgKVxsgbISDkhR7T2rRVVHXEvA== Received: from [66.196.81.157] by nm23.access.bullet.mail.bf1.yahoo.com with NNFMP; 08 Dec 2016 22:15:39 -0000 Received: from [98.138.104.98] by tm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 08 Dec 2016 22:15:39 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.ne1.yahoo.com with NNFMP; 08 Dec 2016 22:15:39 -0000 X-Yahoo-Newman-Id: 529772.43473.bm@smtp118.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: NcTO8zoVM1lxs7QQv6rUAirr.uDr4xyg7SjbTXEpSJIhT1q 4fUkmph1Bu0Ch_mh9GepWb0PjXLn59cxqy6ZWyYEHHf3us9CnIiN_dWxe_4Z AJiZr5vcuBuq2BlXIbMVQgR2TzmhMuOjNbjwqP6an.GPwN9NT5Bmd7GPRqTF 5RAwq9F1ADGo3O.bskxQLoo3cYfO3.IL9J8bSSqhx6QbXvpTN7RunnDotK2G QbxnRbkbgPeGv0levPIXvdx1maXvqdH4M4XU1rdBY912I_OXSOhRI4pILyDe gVet0dloyfFtXMrU5UPvC_As.t3ZXBQsbHKrDIZkxeZ9WNXLbBzPVjggnVji Kr0uB6f8V8LuYebB_fzrJoXubT9cQOgPTf4D7z4QnEl5IsMQB3JjcLAz51bq 3OsHgXgMCfTk0ZVvQgjzbb9eAPxCKnCOQ9GxyqiUO9iRa401WMNpUNNmpiol tjnbRd5oLok61hhv4OQaj8VqZHChkENkxYwT99NVY3vSLAcXif7_WVG4rB0G 6tPxcV3n_L0k0.KIXP7aKSp.njUosXUJSP2ikcHaAGg-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id E04FA1C6033; Thu, 8 Dec 2016 17:09:25 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Thu, 08 Dec 2016 17:09:25 -0500 From: David Mandelberg To: =?UTF-8?Q?Julien_=C3=89LIE?= In-Reply-To: <6eb3ef06-c3f0-462e-0cc1-573e585cc221@trigofacile.com> References: <022c6479-4bac-f18e-928a-796a0d7ebde3@mandelberg.org> <6eb3ef06-c3f0-462e-0cc1-573e585cc221@trigofacile.com> Message-ID: <6d25826996009a1792e721b6de78a1fd@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/1.1.5 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-elie-nntp-tls-recommendations.all@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-elie-nntp-tls-recommendations-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 22:19:04 -0000 On 2016-12-08 16:47, Julien =C3=89LIE wrote: > I believe it is OK to take the following text into account for the > ports to use for NNTP over TLS, but I prefer to share with you the > wording in case you have any comments about it. (Maybe it is not > clear enough!) > We would then have in Appendix A of the document: >=20 > The third and fourth paragraphs in Section 1 of [RFC4642] are > replaced with the following text: >=20 > TCP port 563 is dedicated to NNTP over TLS, and registered in the > IANA Service Name and Transport Protocol Port Number Registry for > that usage. NNTP implementations using TCP port 563 begin the TLS > negotiation immediately upon connection and then continue with the > initial steps of an NNTP session. This use of strict TLS on a > separate port is the preferred way of using TLS with NNTP. >=20 > If a host wishes to offer separate servers for transit and reading > clients, TCP port 563 SHOULD be used for the reading server using > strict TLS. If a transit server offers strict TLS, it SHOULD use TCP > port 433 if it does not accept unencrypted connections, but can > alternatively use another unused port of its choice. If it accepts > dynamic upgrade from unencrypted to TLS-protected traffic, it SHOULD > use TCP port 433 for that usage, and another unused port of its > choice for strict TLS. In either case, the port used for strict TLS > should be clearly communicated to the client, and specifically that > no plain-text communication occurs before the TLS session is > negotiated. From a security point of view, I have no objection to this text. I'm a bit surprised that you're using the same port (433) for both plain=20 TLS and for STARTTLS, but as long as clients and servers are configured=20 correctly, that should work. I assume there's no protocol switching=20 attack between TLS and NNTP? --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Fri Dec 9 07:49:10 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA84D129864 for ; Fri, 9 Dec 2016 07:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nkqOPYh0EUc for ; Fri, 9 Dec 2016 07:49:04 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C379F12987F for ; Fri, 9 Dec 2016 07:48:47 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id p16so19469978qta.0 for ; Fri, 09 Dec 2016 07:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ajB/vyse9t2o7czvAyguuv9fksZ5F5jmTwilxVYrGbQ=; b=mB1moMML0zbAAdCCVJlu79DOkigFjVYF2w+1ePETs/bkNytGlK/7fS6/z1vIJ1m+o/ i6Dy8TCTpVxNsr1o2f7WAaaiyqftgLROQs8CLXw5aALrXgqh0SBHnXkTVjuDVndLHD6K xa3add841kT2FtFypJS7NwMoqcCA4ICnKy8FeTfvCGmuu5cMfmoz+WWZ9O/nfXXXMgLQ xg2gvqTqTIL/Ks8vdIQFRUxzzYehsJTc0T9xLD5AJWKat4iJrEvGGBffQbnRGBIv1mnD 9Al7LPmaMiPQs4gM8RyaBKcC/VABa/zchLY7h56r42r1skbOhlRWpHGr3JApluiMeHer qr3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ajB/vyse9t2o7czvAyguuv9fksZ5F5jmTwilxVYrGbQ=; b=FPQEFbatYjLuK3CjtnFiexJ5q46w4Bh51I0WlpczKAUZYBo1qcOAmt7vjPwYzfg+j4 n70HCRBB8nj/q+HLAWPVVjSBN/syopYIBLgRHf6ewF/qSw4Hr+nOnwrGXHg3EFd+kWhb Wvsh5wbJSedkSYJX695HMNlBZdBZUsYQIWB02KsdamqPhjJaizhZ7rWeqzPEMwnHCwuO npX5iBy+D3l/gnnP8kRxlA9X1TwD4T1j46Khuo7PA35xdFhFV1tJ+mgnJ8neMpRyLy6b SL9ZHjlEeK9HvBaLM+eWCTCw8StvqMZs6dUQtq0ko//DJ1+cEqdWT2IjHI7+wKV4Jubp vF4g== X-Gm-Message-State: AKaTC03S/ITevY5fvHIS3oPfdmTwy2HbxW56YIB9eZZI2/5I1WlXTFlKiiuee10JU9dIPNODTgb4wco/UpP7EKwR X-Received: by 10.200.43.5 with SMTP id 5mr70289747qtu.279.1481298526658; Fri, 09 Dec 2016 07:48:46 -0800 (PST) MIME-Version: 1.0 References: <91f59711-84e0-853c-8dd0-8157c7807a93@dret.net> In-Reply-To: <91f59711-84e0-853c-8dd0-8157c7807a93@dret.net> From: Warren Kumari Date: Fri, 09 Dec 2016 15:48:36 +0000 Message-ID: To: Erik Wilde , Alexey Melnikov , The IESG , IETF Security Directorate , draft-wilde-json-seq-suffix.all@ietf.org Content-Type: multipart/alternative; boundary=001a1147596a7cfa2705433bb0e0 Archived-At: Cc: Martin Thomson , Sean Gillies Subject: Re: [secdir] Secdir review of: draft-wilde-json-seq-suffix X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 15:49:09 -0000 --001a1147596a7cfa2705433bb0e0 Content-Type: text/plain; charset=UTF-8 [ Top-post ] Ok, thanks for the explanation and updates -- I'm fine with the document now that I understand some of the history, etc. Part of what threw me was that I write IANA considerations as instructions to the IANA instead of writing it the way you did (e.g I would write "The IANA is requested to add the "+json-seq" structured syntax suffix to the registry at with the following information" instead of "IANA has added the following "+json-seq" structured syntax suffix to its registry of structured syntax suffixes"...) A quick skim of RFC 5226 doesn't really say which is the right thing, but RFC 7322, section-4.8.3 implies that writing it as instructions is "correct" ("The RFC Editor will update text accordingly after the IANA assignments have been made.") -- anyway, this is bike-shedding, etc. W On Mon, Nov 28, 2016 at 1:00 PM Erik Wilde wrote: > hello. > > thanks a lot for the review! > > On 2016-11-28 05:34, Alexey Melnikov wrote: > > On 28/11/2016 13:16, Warren Kumari wrote: > >> I don't see any *security* issues, but the document is very unclear. > >> It *looks* like it just tries to add "+json-seq" to the IANA > >> Structured Syntax Suffix Registry, but I don't see why it is Standards > >> Track, or why it need to be an RFC at all; the registry is Expert > >> Review, and RFC 6838 Section 6 seems clear. > > While this indeed can be just sent in an email, IMHO, it is better to > > register Media Type suffixes in RFCs. All existing Media Type suffixes > > were registered in RFCs. > > It probably doesn't need to be Standards Track. > > I would be happy to follow IESG's advice on how to handle this document. > > https://github.com/dret/I-D/commit/8694a1efce71dcb96410be3bd6be8d0373383703 > switches the draft to experimental. to be honest, i do get conflicting > info on this, and depending on the people dealing with a draft, some > seem to prefer one status over the other. i have no strong opinion about > this and thus i am happy to switch to the status people think is most > appropriate. > > > This suffix was incorrectly being used in a media type registration, so > > this document is now trying to register the suffix to fix the brokenness. > > that is the only reason this draft exists: register the suffix in a way > that it is properly defined and registered and that the registration can > be referenced. so yes, this is a simple draft, and intentionally so. > > >> Other issues: > >> It does not contain a Security Considerations section, and there are a > >> number of broken references (e.g: it says: "Online access to all > >> versions and files is available on github [2]." - but [2] is a link > >> to: http://www.rfc-editor.org/info/rfc6838) > > Yes, this needs to be fixed. > > that's the good old xml2rfc bug that still is around. sorry for this, > https://github.com/dret/I-D/commit/ee5838e5ddf53cf7084022abb7a275ac4a30a028 > is the best workaround there is for this bug, afaict. > > https://github.com/dret/I-D/commit/1efd188ff60f2dbe7f414082d730091e803faa77 > fixes another broken reference. > > >> It is a -00, submitted Sept 23rd 2016, and the document on which it > >> was based (draft-json-seq-suffix-00) was also a -00, submitted Sept > >> 19th 2016. The only changes between the 2 are the metadata (name, > >> date). There has been basically no discussion (at least, that I can > >> find), closest > >> is: > https://mailarchive.ietf.org/arch/search/?email_list=art&index=AxC0J7zxKU_wH1jOrkZ0ZZUUcs4 > ? > > The document is rather trivial (and yes, it does contain annoying > > omissions). Chairs of GeoJSON WG reached out to me for AD sponsoring of > > this document, because one of their documents used the prefix > incorrectly. > > all correct, and apologies for missing these things so far. > > - the two versions exist because i accidentally named the initial > submission incorrectly. the current version simply was a re-submission > with the fixed submission name. > > - i will submit a -01 version with the changes discussed in this message > today. > > - apart from the missing security considerations section (added via > https://github.com/dret/I-D/commit/f57746b52ffc9d9b89b3af392be41c80ba530743 > ), > is there anything else that seems to be missing? > > >> I *think* that it is simply trying to add "+json-seq" to the IANA > >> Structured Syntax Suffix Registry > >> ( > http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml > ) > > Yes. > >> -- unfortunately it does this very poorly. > > that indeed is the only intent of this document. > > >> It starts off by saying (note tense): "IANA has added the following > >> "+json-seq" structured syntax suffix to its registry of structured > >> syntax suffixes established by [2]". > > that's how it's supposed to read once approved (at which point the > addition will have been done), and that's how i have written this in > previous documents. > > >> [2] references to RFC 6838 - "Media Type Registration", which creates > >> a number of registries - while looking I found > >> "http://www.iana.org/assignments/media-types/media-types.xhtml", which > >> does indeed have "json-seq". Because of the "IANA has added" I assumed > >> that this was what was being referenced. > > RFC 6838 established more than one registry. one is that of media types. > another one is that of structured syntax suffixes. it is that latter one > that is targeted by this document: > > > http://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml#structured-syntax-suffix > > this one does not have the "+json-seq" structured syntax suffix in there > and the goal of the document is to add it. this registry is specifically > called out in the IANA considerations section. > > >> The IANA considerations section needs work... > > in which particular way? the section says that it updates the structured > syntax suffixes registry and contains all the necessary fields to do > that. what are you missing? > > >> Nits: > >> Section 1: > >> how a media type can signal that it is based on another media type as > >> [O] way of how a media type can signal [P] way for a media type to > >> signal [R] readability; original was a bit awkward > > thanks! > https://github.com/dret/I-D/commit/672780ac2aafd2732e696ae85dec72e9c315ddc7 > > >> Section 3: > >> Applications encountering such a media type then can either simply > >> [O] then can either > >> [P] can then either > >> [R] readability > > thanks! > https://github.com/dret/I-D/commit/f4d915490f1b05551b9b424f3b9e69b617de3645 > > https://tools.ietf.org/html/draft-wilde-json-seq-suffix-01 is the > updated version of the draft. once again, thanks a lot for the review > and feedback, this is greatly appreciated! > > cheers, > > dret. > > -- > erik wilde | mailto:erik.wilde@dret.net | > | http://dret.net/netdret | > | http://twitter.com/dret | > > --001a1147596a7cfa2705433bb0e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[ Top-post ]

Ok, thanks for = the explanation and updates -- I'm fine with the document now that I un= derstand some of the history, etc.

Part of what th= rew me was that I write IANA considerations as instructions to the IANA ins= tead of writing it the way you did (e.g I would write "The IANA is req= uested to add the "+json-seq" structured syntax suffix to the reg= istry at <URL> with the following information" =C2=A0instead of = "IANA has added the following "+json-seq" structured syntax = suffix to its registry of structured syntax suffixes"...)
A quick skim of RFC 5226 doesn't really say which is the r= ight thing, but RFC 7322, section-4.8.3 implies that writing it as instruct= ions is "correct" ("The = RFC Editor will update text accordingly after the IANA=C2=A0assignments have been made.") -- anyway, t= his is bike-shedding, etc.

W



On Mon, Nov 28, 2016 at= 1:00 PM Erik Wilde <erik.wilde@d= ret.net> wrote:
hello.

thanks a lot for the review!

On 2016-11-28 05:34, Alexey Melnikov wrote:
> On 28/11/2016 13:16, Warren Kumari wrote:
>> I don't see any *security* issues, but the document is very un= clear.
>> It *looks* like it just tries to add "+json-seq" to the = IANA
>> Structured Syntax Suffix Registry, but I don't see why it is S= tandards
>> Track, or why it need to be an RFC at all;=C2=A0 the registry is E= xpert
>> Review, and RFC 6838 Section 6 seems clear.
> While this indeed can be just sent in an email, IMHO, it is better to<= br class=3D"gmail_msg"> > register Media Type suffixes in RFCs. All existing Media Type suffixes=
> were registered in RFCs.
> It probably doesn't need to be Standards Track.
> I would be happy to follow IESG's advice on how to handle this doc= ument.

https= ://github.com/dret/I-D/commit/8694a1efce71dcb96410be3bd6be8d0373383703<= br class=3D"gmail_msg"> switches the draft to experimental. to be honest, i do get conflicting
info on this, and depending on the people dealing with a draft, some
seem to prefer one status over the other. i have no strong opinion about this and thus i am happy to switch to the status people think is most
appropriate.

> This suffix was incorrectly being used in a media type registration, s= o
> this document is now trying to register the suffix to fix the brokenne= ss.

that is the only reason this draft exists: register the suffix in a way
that it is properly defined and registered and that the registration can be referenced. so yes, this is a simple draft, and intentionally so.

>> Other issues:
>> It does not contain a Security Considerations section, and there a= re a
>> number of broken references (e.g: it says: "Online access to = all
>> versions and files is available on github [2]." - but [2] is = a link
>> to: http://www.rfc-editor.org/inf= o/rfc6838)
> Yes, this needs to be fixed.

that's the good old xml2rfc bug that still is around. sorry for this, https= ://github.com/dret/I-D/commit/ee5838e5ddf53cf7084022abb7a275ac4a30a028<= br class=3D"gmail_msg"> is the best workaround there is for this bug, afaict.

https= ://github.com/dret/I-D/commit/1efd188ff60f2dbe7f414082d730091e803faa77<= br class=3D"gmail_msg"> fixes another broken reference.

>> It is a -00, submitted Sept 23rd 2016, and the document on which i= t
>> was based (draft-json-seq-suffix-00) was also a -00, submitted Sep= t
>> 19th 2016. The only changes between the 2 are the metadata (name,<= br class=3D"gmail_msg"> >> date). There has been basically no discussion (at least, that I ca= n
>> find), closest
>> is: https://mailarchive.ietf.org/arch/search/?= email_list=3Dart&index=3DAxC0J7zxKU_wH1jOrkZ0ZZUUcs4 ?
> The document is rather trivial (and yes, it does contain annoying
> omissions). Chairs of GeoJSON WG reached out to me for AD sponsoring o= f
> this document, because one of their documents used the prefix incorrec= tly.

all correct, and apologies for missing these things so far.

- the two versions exist because i accidentally named the initial
submission incorrectly. the current version simply was a re-submission
with the fixed submission name.

- i will submit a -01 version with the changes discussed in this message today.

- apart from the missing security considerations section (added via
https= ://github.com/dret/I-D/commit/f57746b52ffc9d9b89b3af392be41c80ba530743)= ,
is there anything else that seems to be missing?

>> I *think* that it is simply trying to add "+json-seq" to= the IANA
>> Structured Syntax Suffix Registry
>> (http://www.iana.org/assignments/media-type-structu= red-suffix/media-type-structured-suffix.xhtml)
> Yes.
>> -- unfortunately it does this very poorly.

that indeed is the only intent of this document.

>> It starts off by saying (note tense): "IANA has added the fol= lowing
>> "+json-seq" structured syntax suffix to its registry of = structured
>> syntax suffixes established by [2]".

that's how it's supposed to read once approved (at which point the<= br class=3D"gmail_msg"> addition will have been done), and that's how i have written this in previous documents.

>> [2] references to RFC 6838 - "Media Type Registration", = which creates
>> a number of registries - while looking I found
>> "http= ://www.iana.org/assignments/media-types/media-types.xhtml", which<= br class=3D"gmail_msg"> >> does indeed have "json-seq". Because of the "IANA h= as added" I assumed
>> that this was what was being referenced.

RFC 6838 established more than one registry. one is that of media types. another one is that of structured syntax suffixes. it is that latter one that is targeted by this document:

http://www.iana.org/assignments/med= ia-type-structured-suffix/media-type-structured-suffix.xhtml#structured-syn= tax-suffix

this one does not have the "+json-seq" structured syntax suffix i= n there
and the goal of the document is to add it. this registry is specifically called out in the IANA considerations section.

>> The IANA considerations section needs work...

in which particular way? the section says that it updates the structured syntax suffixes registry and contains all the necessary fields to do
that. what are you missing?

>> Nits:
>> Section 1:
>> how a media type can signal that it is based on another media type= as
>> [O] way of how a media type can signal [P] way for a media type to=
>> signal [R] readability; original was a bit awkward

thanks!
https= ://github.com/dret/I-D/commit/672780ac2aafd2732e696ae85dec72e9c315ddc7<= br class=3D"gmail_msg">
>> Section 3:
>> Applications encountering such a media type then can either simply=
>> [O] then can either
>> [P] can then either
>> [R] readability

thanks!
https= ://github.com/dret/I-D/commit/f4d915490f1b05551b9b424f3b9e69b617de3645<= br class=3D"gmail_msg">
https://tools.ietf.or= g/html/draft-wilde-json-seq-suffix-01 is the
updated version of the draft. once again, thanks a lot for the review
and feedback, this is greatly appreciated!

cheers,

dret.

--
erik wilde | mailto:erik.wilde@dret.net |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | http://dret.n= et/netdret=C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | http://twitte= r.com/dret=C2=A0 =C2=A0 |

--001a1147596a7cfa2705433bb0e0-- From nobody Fri Dec 9 08:32:59 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE43812984A; Fri, 9 Dec 2016 04:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1481288228; bh=F1z5VfEwMi3fzIFW7ViMtb6D9Ia0f773c/Vwe/AXPls=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=P0zIRikY4Iuz9+QIx3v9EK/GHHjgOu9moigeWp92a+EmMgIguBKXqyRTJg+dWAnTS YiqV0pmpapBkxatFwSKKNA21JoKMeMWjAgQvWpb5emJwhZlgAvJybaRcOar5wUslmW C2lE61qXneltVZb3WAyW1iRQ8UEOsXzmQ6nLXkOQ= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0757D12984A for ; Fri, 9 Dec 2016 04:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, LOTTO_DEPT=1.999, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlBZVlGN6J5Y for ; Fri, 9 Dec 2016 04:57:05 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C36129A61 for ; Fri, 9 Dec 2016 04:55:57 -0800 (PST) Received: from suzuki.awa.sfc.keio.ac.jp ([133.27.18.149] helo=[10.11.35.12]) by raoul.w3.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1cFKiS-0003O8-3N for new-work@ietf.org; Fri, 09 Dec 2016 12:55:56 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: <00c35a7a-7b71-d312-5753-a050fd205b9b@w3.org> Date: Fri, 9 Dec 2016 20:57:08 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 09 Dec 2016 08:32:58 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Verifiable Claims Working Group (until 2017-01-15) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 12:57:09 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Verifiable Claims Working Group: https://www.w3.org/2017/vc/charter As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2017-01-15 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Phil Archer, W3C Team Contact . Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Dec 9 10:27:08 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61ABD129502; Fri, 9 Dec 2016 10:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0CLw1OxHmA6; Fri, 9 Dec 2016 10:27:05 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0: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 1DF0B128AB0; Fri, 9 Dec 2016 10:27:02 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id p9so12814391vkd.3; Fri, 09 Dec 2016 10:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=K9C4Xusx+I91YMrfAjd0Qqdcc3IiwLR/6HRJH1rod3s=; b=vTVDDL9WxjzHySghR652kERFPKXPE1U6Bn+IV6lh5kD6M4jQhHLGrEWOTnXoRx8xmT 0ymE5psR/Cf6+CNvg+FkBMLm4Luh/9hiEf3yTnUA+C7IbUMctzOG61qMkGRprQPR46wC FCUJ5MtID48i42d+WORYlMMaOW2acwEsWdfIpKrvAm9YM4DsGS3HvccqdU1fTvADAxPe ++77SAkxEDfRVZ8X1ZgDXmfOelWbD3K7Q+4sf6xUO3kx7hRtV0mPDrzJg1sB0QCGDBYg pZ2cZxN+0oGm8JU4jpCl6ojAo+V+icsHVXB5Oooc5UufEThIKx1sgFWW84zIXRlXHYJA 504A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=K9C4Xusx+I91YMrfAjd0Qqdcc3IiwLR/6HRJH1rod3s=; b=b8Qny/D3Xb37P+ra1+vt/RFoaYkWrg/CRM1sjVNm4qBTlpLuIGBQ+gjipeo2O5yp6g tOuVB0Nv3g6t958KY4l+UzkJVwBpddq8eiVAhDsUH4Te9nwSBvfUfCUlth1EEm8FKsuK gaALyvf8b8L7leCextnBRukKy5N3SJuoDCCwXqcAGNHJ6XJQVxVRoZVUysu4ongfg7TR U+XKvP7BdTnP4Q0ZxNdT0GnwzyzbjLWengoGOU/U/H6VjHD1BRdH+SEheLsd/H8D4cwS FpF+27lHmBXfBE0DzvS+TWWlJvArPSdPvu3ZhIdvVOWg733GWOPnxoTcK7JbPND4Xu8n I61w== X-Gm-Message-State: AKaTC03k6H9665n/oT+AnhjBw2KEr5CtCq++G560VJ6Rfl8qnaw5SDnCGupzUG+M03GtR1e0ZoGATCn4OEB9XA== X-Received: by 10.31.54.193 with SMTP id d184mr27089907vka.120.1481308020859; Fri, 09 Dec 2016 10:27:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.48.146 with HTTP; Fri, 9 Dec 2016 10:27:00 -0800 (PST) From: Rifaat Shekh-Yusef Date: Fri, 9 Dec 2016 13:27:00 -0500 Message-ID: To: secdir@ietf.org, draft-ietf-sidr-as-migration.all@ietf.org Content-Type: multipart/alternative; boundary=001a1143915862eae705433de6fd Archived-At: Subject: [secdir] SecDir review of: draft-ietf-sidr-as-migration-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 18:27:07 -0000 --001a1143915862eae705433de6fd Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. *Summary: Ready with nits* I think the proposed security mechanism is a reasonable solution, but I think that the document could benefit from few clarifications in few places: * Page 6, Section 5 Solution, first paragraph, second sentence: "so a simple solution would be to retain the keys for AS64510 on PE1,..." I guess by "keys for AS64510" you mean the private key associated with PE1; is that correct? Are there any other keys? if so, could you please clarify what other keys? * Page 7, Section 5 Solution, third paragraph, third sentence: "Each routing update that is received from or destined to an eBGP neighbor that is still using the old ASN (64510) will be signed twice, once with the ASN to be hidden and once with the ASN that will remain visible. " I am assuming that the routing update will be signed using the private key associated with the specific ASN. If so, could you please clarify that? * Page 7/8, Section 5 Solution, third paragraph, fifth sentence: "This will result in a properly secured AS Path in the affected route updates, because the PE router will be provisioned with valid keys for both AS64500 and AS64510." I am assuming that by "keys" you mean the two private keys: one associated with AS64500 and another with AS64510; is that correct? * page 10, notations: "The origin BGPSEC signature attribute takes the form: sig(, Origin ASN, pCount, NLRI Prefix) key" Is there any significance to the use of angle brackets around the first attribute ()? Also, I guess the "key" provided at the end of the attributes is the private key of the router signing the update message; you might want to explicitly state that. * page 11: "CE-2 to PE-2: sig(<64500>, O=64499, pCount=1, N)K_64499-CE2 [sig1]" The value of the last attribute is 'N'; I guess this is a short for Null, because there is no previous signatures to point to? * page 9, second paragraph, second sentence: "This requires any router using this solution to be provisioned with valid keys for both the migrated and subsumed ASN so that it can generate valid signatures for each of the two ASNs it is adding to the path. " I think that the first part of the above sentence might be clearer by stating that "... any router *that is being migrated* using this solution...", because all other routers are not affected by this change;right? Nits ---- Page 3, section 2, second paragraph, first sentence: Remove one of the reference to section 5.4. Page 4, section 3.1, first paragraph, first sentence: "Route Origin Validation as defined by RFC 6480 [RFC6480] does not modification..." Did you mean to say "...does not *allow* modification..."? Regards, Rifaat --001a1143915862eae705433de6fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security= directorate's
ongoing effort to review all IETF documents be= ing processed by the
IESG.=C2=A0 These comments were written prim= arily for the benefit of the
security area directors.=C2=A0 Docum= ent editors and WG chairs should treat
these comments just like a= ny other last call comments.


Summary: Ready with nits

I think the propo= sed security mechanism is a reasonable solution,
but I think that= the document could benefit from few clarifications in=C2=A0
few = places:

* Page 6, Section 5 Solution, first paragr= aph, second sentence:
"so a simple solution would be to reta= in the keys for AS64510 on PE1,..."

I guess b= y "keys for AS64510" you mean the private key associated with PE1= ; is that correct?
Are there any other keys? if so, could you ple= ase clarify what other keys?


* Page= 7, Section 5 Solution, third paragraph, third sentence:

"Each routing update that is received from or destined to an eB= GP neighbor
=C2=A0 =C2=A0that is still using the old ASN (64510) = will be signed twice, once
=C2=A0 =C2=A0with the ASN to be hidden= and once with the ASN that will remain
=C2=A0 =C2=A0visible. &qu= ot;

I am assuming that the routing update will be = signed using the private key
associated with the specific ASN. If= so, could you please clarify that?


* Page 7/8, Section 5 Solution, third paragraph, fifth sentence:

"This will result in a properly secured AS Path in the= affected route
updates, because the PE router will be provisione= d with valid keys
for both AS64500 and AS64510."
<= br>
I am assuming that by "keys" you mean the two priva= te keys: one associated
with AS64500 and another with AS64510; is= that correct?


* page 10, notations= :

"The origin BGPSEC signature attribute take= s the form: sig(<Target ASN>,
Origin ASN, pCount, NLRI Pref= ix) key"

Is there any significance to the use= of angle brackets around the first
attribute (<Target ASN>= )?

Also, I guess the "key" provided at t= he end of the attributes is the private
key of the router signing= the update message; you might want to explicitly
state that.


* page 11:

&q= uot;CE-2 to PE-2: =C2=A0sig(<64500>, O=3D64499, pCount=3D1, N)K_64499= -CE2 =C2=A0[sig1]"

The value of the last attr= ibute is 'N'; I guess this is a short for Null,
because t= here is no previous signatures to point to?


* page 9, second paragraph, second sentence:

<= div>"This requires any router using this solution to be
=C2= =A0 =C2=A0provisioned with valid keys for both the migrated and subsumed AS= N so
=C2=A0 =C2=A0that it can generate valid signatures for each = of the two ASNs it is
=C2=A0 =C2=A0adding to the path. "

I think that the first part of the above sentence mig= ht be clearer by
stating that "... any router *that is being= migrated* using
this solution...", because all other router= s are not affected by this change;right?



Nits
----

Page 3, s= ection 2, second paragraph, first sentence:
Remove one of the ref= erence to section 5.4.


Page 4, sect= ion 3.1, first paragraph, first sentence:

"Ro= ute Origin Validation as defined by RFC 6480 [RFC6480] does not
m= odification..."

Did you mean to say "...= does not *allow* modification..."?


=
Regards,
=C2=A0Rifaat

--001a1143915862eae705433de6fd-- From nobody Fri Dec 9 14:27:37 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E15129570 for ; Fri, 9 Dec 2016 14:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRpucnGrtpNx for ; Fri, 9 Dec 2016 14:27:34 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) by ietfa.amsl.com (Postfix) with ESMTP id AD42E12953C for ; Fri, 9 Dec 2016 14:27:33 -0800 (PST) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d83 with ME id HyL11u00117Lgi403yL1zh; Fri, 09 Dec 2016 23:20:02 +0100 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Fri, 09 Dec 2016 23:20:02 +0100 X-ME-IP: 92.170.5.52 To: David Mandelberg References: <022c6479-4bac-f18e-928a-796a0d7ebde3@mandelberg.org> <6eb3ef06-c3f0-462e-0cc1-573e585cc221@trigofacile.com> <6d25826996009a1792e721b6de78a1fd@mail.mandelberg.org> From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <9cb07e03-fd9f-a9ee-2409-1cafe164007e@trigofacile.com> Date: Fri, 9 Dec 2016 23:20:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <6d25826996009a1792e721b6de78a1fd@mail.mandelberg.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-elie-nntp-tls-recommendations.all@ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-elie-nntp-tls-recommendations-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 22:27:35 -0000 Hi David, > On 2016-12-08 16:47, Julien ÉLIE wrote: >> I believe it is OK to take the following text into account for the >> ports to use for NNTP over TLS, but I prefer to share with you the >> wording in case you have any comments about it. (Maybe it is not >> clear enough!) >> We would then have in Appendix A of the document: >> >> The third and fourth paragraphs in Section 1 of [RFC4642] are >> replaced with the following text: >> >> TCP port 563 is dedicated to NNTP over TLS, and registered in the >> IANA Service Name and Transport Protocol Port Number Registry for >> that usage. NNTP implementations using TCP port 563 begin the TLS >> negotiation immediately upon connection and then continue with the >> initial steps of an NNTP session. This use of strict TLS on a >> separate port is the preferred way of using TLS with NNTP. >> >> If a host wishes to offer separate servers for transit and reading >> clients, TCP port 563 SHOULD be used for the reading server using >> strict TLS. If a transit server offers strict TLS, it SHOULD use TCP >> port 433 if it does not accept unencrypted connections, but can >> alternatively use another unused port of its choice. If it accepts >> dynamic upgrade from unencrypted to TLS-protected traffic, it SHOULD >> use TCP port 433 for that usage, and another unused port of its >> choice for strict TLS. In either case, the port used for strict TLS >> should be clearly communicated to the client, and specifically that >> no plain-text communication occurs before the TLS session is >> negotiated. > > From a security point of view, I have no objection to this text. ... unless if it can lead to "protocol switching attack between TLS and NNTP" as you hint at below: > I'm a bit surprised that you're using the same port (433) for both plain > TLS and for STARTTLS, but as long as clients and servers are configured > correctly, that should work. I assume there's no protocol switching > attack between TLS and NNTP? Well, you're right there's something weird here. In fact, I was suggesting to use port 433 for strict TLS when the transit server only allows encrypted connections. If some clients use unencrypted connections and some other clients use TLS-protected connections, then port 433 was to be used for unencrypted connections as well as connections using dynamic upgrade from unencrypted to TLS-protected traffic; and another port of its choice for strict TLS. I agree it finally looks weird and inconsistent. The rationale behind was: - the common case is both reading&transit via port 119 (unencrypted, with possible use of STARTTLS), and strict TLS for reading via port 563; - servers handling reading&transit on the same port can of course use strict TLS for transit via port 563; - a few servers offer transit via port 433 (unencrypted, with possible use of STARTTLS), and keep ports 119/563 for reading. Note that there is no IANA registered port for transit-only exchanges over TLS. IANA registered ports are 119 (NNTP), 433 (NNSP) and 563 (NNTP/TLS). So I believe we have two alternatives right now: a/ asking IANA to register a new port for NNSP/TLS and then explicitly say to use that port for transit with strict TLS; b/ explicitly say to use another port than 433 for transit with strict TLS. Alternative a/ is cleanest but maybe that new port will never be used in practice... That's why I suggest b/ but of course I would be OK if a/ is chosen. ** Alexey, do you have any opinion about that? Considering b/ (that I will adopt unless decided otherwise), the text becomes: TCP port 563 is dedicated to NNTP over TLS, and registered in the IANA Service Name and Transport Protocol Port Number Registry for that usage. NNTP implementations using TCP port 563 begin the TLS negotiation immediately upon connection and then continue with the initial steps of an NNTP session. This use of strict TLS on a separate port is the preferred way of using TLS with NNTP. If a host wishes to offer separate servers for transit and reading clients, TCP port 563 SHOULD be used for strict TLS with the reading server, and an unused port of its choice different than TCP port 433 SHOULD be used for strict TLS with the transit server. The ports used for strict TLS should be clearly communicated to the clients, and specifically that no plain-text communication occurs before the TLS session is negotiated. I hope that's better in a security point of view (we do not rely on the quality of the configuration, and there cannot be any protocol switching attacks). -- Julien ÉLIE « – Poussez pas derrière ! – Pas si vite devant ! » (Astérix) From nobody Sun Dec 11 05:14:20 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8DB12968E; Sun, 11 Dec 2016 05:14:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148146205925.29990.2056127161677925002.idtracker@ietfa.amsl.com> Date: Sun, 11 Dec 2016 05:14:19 -0800 Archived-At: Cc: curdle@ietf.org, draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org, ietf@ietf.org Subject: [secdir] Review of draft-ietf-curdle-cms-chacha20-poly1305-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 13:14:19 -0000 Reviewer: Yoav Nir Review result: Has Nits Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Ready with nits. Introduction ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit key and a 96-bit nonce. ChaCha20 is described in [FORIETF]. ChaCha20 is described in DJB's paper. RFC 7539 just repeats the definition with more detail, examples and test vectors. Same for Poly1305 in the next paragraph. Section 3 describes how to use AEAD_CHACHA20_POLY1305 with AuthEnvelopedData. The algorithm, as stated in section 1.1 has four inputs: a 256-bit key, a 96-bit nonce, an arbitrary length plaintext, and an arbitrary length additional authenticated data (AAD). The key is generated by one of the methods in section 2 (Key Management); the nonce is generated by the sender. The text requires that it be unique, but does not mandate of suggest a way of doing this. This is fine. The plaintext according to section 3 is "the content located in the AuthEnvelopedData EncryptedContentInfo encryptedContent field". and the tag is stored in the AuthEnvelopedData mac field. What's missing is the AAD. I could not find what goes into the AAD. This is described in section 2.2 of RFC 5083, but it should be either repeated here or referenced. It's jarring that the other inputs are described while this one is omitted. The Security Considerations section seems fine. Yoav From nobody Sun Dec 11 17:44:22 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CF51279EB; Sun, 11 Dec 2016 17:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EqLQsnV9nVG; Sun, 11 Dec 2016 17:44:19 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::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 AD797129549; Sun, 11 Dec 2016 17:44:19 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id t125so54380414ywc.1; Sun, 11 Dec 2016 17:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=E8zQJKiciD09nHBYEDQoR68lihvh69t9027H7iPZBH8=; b=vY4qnmSBVDjJQlpWZDfgZ1vYG3iOUr4e7vWxfeEgw0ZX85mEPdLjrdRnBWauyQO2i6 xwXr0BgVHx7eSP4NdSp2/8FT2Aihhp6xQQCkOBdIJFU87bn0JPk6ymgKLV7EkiXBufHo UDlQBEHhYsOGpANnsdGis2obJge2eQauZXmK8DaQB+yx+SEOfPzkvG1pknQyNR6mP7u6 Y8910YSJUrYGEX9ASyISSgCm9MKwYvn8v4Y5+ADi5gBKWvxGpE3q84UUkMBEJnMkcjiF WnyOQsmxzkAcfa4QbGcGNu58PqqgFvmnOEEyIBHeuU0BYrc0qRYjQxGf5oP/aILzHhX/ 7GJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=E8zQJKiciD09nHBYEDQoR68lihvh69t9027H7iPZBH8=; b=NbH+lzENLloJ0hNsJAaaagjN+6Psx7mc0AWjtQQZTjyxC8+0BA+W+1UkcoquTeRbaZ +ROnKQrDQ+xpWSjaay+9QLmD5sjSQkyrJAK2UsvSCqgRwQHycLeLFeTPQLtqJivwHH/b gtXA03PHCDHhcBCBVA5l8H5honHfmnULPTZEO/XfyXfwWBDrUNJ80DFA+thlY18/Uv9G 1bPYMak4dqI6g0FpS/MDDJJNgYRSRcfXplLppEBJJ3fYWYexKD7VIM76WZ7wSGt8gEGc +z2OdWjCMF9MY1H8s2ZJs+cJd0GR6kjGCQsdjIgJvQCvk7caxohZHVlLsgfXY9vVEuEl dEcQ== X-Gm-Message-State: AKaTC00zjhaAo8Kibo1uh7wDxBkEw6lok5EoywEaXNO5mdVmP55wppGsrt7yBcc2uC35RnItr9WSQERQWjkBBQ== X-Received: by 10.13.250.3 with SMTP id k3mr84786510ywf.276.1481507058837; Sun, 11 Dec 2016 17:44:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.195.195 with HTTP; Sun, 11 Dec 2016 17:44:18 -0800 (PST) From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Sun, 11 Dec 2016 17:44:18 -0800 Message-ID: To: "secdir@ietf.org" , draft-ietf-curdle-dnskey-eddsa@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Secdir review of draft-ietf-curdle-dnskey-eddsa-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 01:44:21 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how to use two two specific Edwards Curves (Elliptic Curves) in conjunction with DNSSEC, namely ed25519 and ed448. The only comment I have on this document is that the Security Considerations section plainly states, without any reference or proof: "Ed25519 and Ed448 offers improved security properties and implementation characteristics compared to RSA and ECDSA algorithms" I suggest either adding references to proofs of these statements or alternatively just remove the sentence (since it doesn't really add anything to the memo); the remaining paragraphs in the Security Considerations section is what really covers what someone implementing the memo should know or be aware of. -- Magnus From nobody Mon Dec 12 01:38:46 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31F61294DA; Mon, 12 Dec 2016 01:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 Pq9mXwdxcYkr; Mon, 12 Dec 2016 01:38:42 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1541295A3; Mon, 12 Dec 2016 01:38:37 -0800 (PST) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id 23F1F6127A; Mon, 12 Dec 2016 10:38:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481535516; bh=jNR6LblXm7uu3HC68mpBMXkzX/1jNjqaQ19OG3h2Gqg=; h=Date:From:To; b=o6mtY4yNkWZUGFgPgF4ZHhalIhT3badJi/qoxJwJGDw07jV+6yNU9QgkiDfgcCEfy GtSCQPQYrJfuR7Oo5tQMcKF+uQbgxvVBbbk3Dd420hRKukxSjHw90ZFIjXuJheKhUP qIagOogkL48nUP/kXGGGW6KgmiNvQfiq9g7KeQ8M= Date: Mon, 12 Dec 2016 10:38:35 +0100 (CET) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: Magnus =?utf-8?Q?Nystr=C3=B6m?= , Dan Romascanu Message-ID: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - FF50 (Linux)/8.7.0_GA_1659) Thread-Topic: Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) Thread-Index: LzflipimV17IlkcBn4a2Ul/QhkSYmA== X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: curdle , ietf@ietf.org, secdir@ietf.org, gen-art@ietf.org, curdle-chairs , draft-ietf-curdle-dnskey-eddsa Subject: Re: [secdir] Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 09:38:45 -0000 Magnus and Dan, thanks for the review. Magnus, you are right, I have removed the first full paragraph about "security properties" from Security Considerations from my git version as the security properties of EdDSA are better described in Normative references anyway. https://gitlab.labs.nic.cz/labs/ietf/commit/7b52c8e2bbe44042a279a81b960270f= dd103d9a2 Dan, good catches, I fixed the nits in the git: https://gitlab.labs.nic.cz/labs/ietf/commit/bbfc7ce43fb1f46c91fb7f5de564d90= 7d035aadf I would be happy to upload next revision after Last Call is finished or just let the RFC editors to fix it. Cheers, -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "Magnus Nystr=C3=B6m" > To: secdir@ietf.org, "draft-ietf-curdle-dnskey-eddsa" > Sent: Monday, 12 December, 2016 02:44:18 > Subject: Secdir review of draft-ietf-curdle-dnskey-eddsa-02 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > This document describes how to use two two specific Edwards Curves > (Elliptic Curves) in conjunction with DNSSEC, namely ed25519 and > ed448. >=20 > The only comment I have on this document is that the Security > Considerations section plainly states, without any reference or proof: >=20 > "Ed25519 and Ed448 offers improved security properties and > implementation characteristics compared to RSA and ECDSA algorithms" >=20 > I suggest either adding references to proofs of these statements or > alternatively just remove the sentence (since it doesn't really add > anything to the memo); the remaining paragraphs in the Security > Considerations section is what really covers what someone implementing > the memo should know or be aware of. >=20 > -- Magnus ~~~~ ----- Original Message ----- > From: "Dan Romascanu" > To: gen-art@ietf.org > Cc: "draft-ietf-curdle-dnskey-eddsa all" , "curdle" , > ietf@ietf.org > Sent: Sunday, 11 December, 2016 12:21:25 > Subject: Review of draft-ietf-curdle-dnskey-eddsa-02 > Reviewer: Dan Romascanu > Review result: Ready with Nits >=20 > Summary: Ready, with nits >=20 > I am not an expert in this field, but the document seems to meet its > goals, it's clear and precise >=20 > Major issues: >=20 > Minor issues: >=20 > Nits/editorial comments: >=20 > 1. Section 4: s/Section5.1.7/Sections 5.1.7/ >=20 > 2. Section 8: 'The following entry has been added to > the registry' - I may be wrong, but the section seems to define two > new entries in the registry rather than one From nobody Mon Dec 12 03:24:33 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744C11295FF; Mon, 12 Dec 2016 03:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YK3bSZ3Ctutf; Mon, 12 Dec 2016 03:24:22 -0800 (PST) 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 EFD38129602; Mon, 12 Dec 2016 03:24:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1D795BE2F; Mon, 12 Dec 2016 11:24:19 +0000 (GMT) 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 ZZGtARDRuDPP; Mon, 12 Dec 2016 11:24:19 +0000 (GMT) Received: from [134.226.63.183] (cswireless63-183.scss.tcd.ie [134.226.63.183]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 68DE2BE2E; Mon, 12 Dec 2016 11:24:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1481541858; bh=XvdeJNpPToY+29lAuA4x8cJZk6w+nHJJKxaJzkiMnO4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=xuZfQnzb1DMkT7Qiolz6/IUwJ9JT8jbYpHT1VdI5I8XU7ZTI+LGIAg1vcEhg4Nuzu 8aiM0vR7HETxCDOYKAKnx8/ms6pQq56utbrR1bfCeMZifTKaTjtQDbRmA0cqqRwki9 gMRbKoxY/dkxwlV9IjoiFsKds40eiYdnvBSmpLOk= To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= , =?UTF-8?Q?Magnus_Nystr=c3=b6m?= , Dan Romascanu References: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 12 Dec 2016 11:24:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070201090804090507050903" Archived-At: Cc: curdle , ietf@ietf.org, secdir@ietf.org, gen-art@ietf.org, curdle-chairs , draft-ietf-curdle-dnskey-eddsa Subject: Re: [secdir] Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 11:24:24 -0000 This is a cryptographically signed message in MIME format. --------------ms070201090804090507050903 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ond=C5=99ej, On 12/12/16 09:38, Ond=C5=99ej Sur=C3=BD wrote: > I would be happy to upload next revision after Last Call > is finished or just let the RFC editors to fix it. Please do upload a new version at the end of last call with these and any other non-controversial changes. Thabks, S. --------------ms070201090804090507050903 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMTIx MTI0MThaMC8GCSqGSIb3DQEJBDEiBCBGXewgzTXP4DFS2BwG04y9PM5VZPlGbXxcIMDbzy61 MDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAK+e6ptJMDATxmeqvSe2WbC+LHJvaZum2KBcf9+/a7q3dAypnIifWm 5RMv7cBLy6264BsBRUZKvDWgOpSyhU08z32nbRCo4J6EwNBxA22I+khK/CxUc+QXNQca4nAt mHRMwVlN3pNMawgvd34r2bluKKrJg5oqvVATjwJvoOIyUvsC4hJAVe1NEe4WyIRTrVvM4gpG E503MhshUusmsCm6H7wmshNFIGCOrOYBkCZKvYBEPgyprHuO28fWPDbf4PYC3VK6Feke9rwd Moe2leYJ+H+Yez5SXcVzPskRHnvCUFl3NHC3j5Q3/wqqcGritt1vem65xLgoIlhXoHaqATel AAAAAAAA --------------ms070201090804090507050903-- From nobody Mon Dec 12 03:34:44 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7894E129628; Mon, 12 Dec 2016 03:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-kGziC1ZhaE; Mon, 12 Dec 2016 03:34:36 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 15F85129605; Mon, 12 Dec 2016 03:34:36 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id c47so72757759qtc.2; Mon, 12 Dec 2016 03:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uzxsrosCRe73vJ0ngxRkzoBpj5gmH+0x4aSVHay3sAQ=; b=yWh33Wqg2bmZAKPsXv8d+zHuLbfnN+RRDF1oKAroiV44fJsgICJDr0eCorUj4eA4mH rnDcKqovMz/1myTuDQjt9YWPTmExsR2YRdZVUetq8bwilXO391pRFOZFvemWBaRZ9kjL 6Dj31zFRmNkHpqh79Ko3X54odnw4vD+WfxvohPjaunxVoGgS4nwTr10Q7oEwv3XsIXyq xPJXbagULWSOxjp5582kZqwoUYHxhWqx4JC8WeDBMscGZm0UbcRQ3P1CT7v7G0XlO/Fr CvUaGBqm2rQDTRjJrxThguIaHt8m+IGmBJxNDN53VL6KRImF/wbjAVcarIOYsCj74qAF fDIg== 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:from:date :message-id:subject:to:cc; bh=uzxsrosCRe73vJ0ngxRkzoBpj5gmH+0x4aSVHay3sAQ=; b=cFyFJ//NWxqlOtVdrlV7cYAPcd0oFScZFVjwRGchpq8F3wfpE50YTW+exvx2YVVMyR D3vHhbasJ/WOEN46+Ir8Yd2sDhikpKLijPJscTpX3YhDNBN3fLY56ohhy81l10ioiymY MELmpvh5F7j5S85B7X7n679ImjTWVjmKQHkPkxiihRKxQxVeULNa9ED7/YL5xgN1zV1v qqZ4y1kvRlXuCjrDp9nkdvjF1Di331IgZTa91QhDD1qpbhdTqiu956RL+eliMBwRlktB NIXYu1hqUb4jli9C72p2BNLPyQ8H0kDJ1bY/PlahdHl55WHInNvActUWO5tnh3BWNsZp lBpw== X-Gm-Message-State: AKaTC005YhrGplzr+BbnZ8+UKa3w6HcE8H3pcQWyUqMEasQU5L31iDWIzTunI2u4EG+5ZH7+WkVpMGGgXpc0Vw== X-Received: by 10.200.48.44 with SMTP id f41mr79590033qte.94.1481542475151; Mon, 12 Dec 2016 03:34:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.40.114 with HTTP; Mon, 12 Dec 2016 03:34:34 -0800 (PST) In-Reply-To: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> References: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> From: Dan Romascanu Date: Mon, 12 Dec 2016 13:34:34 +0200 Message-ID: To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=001a1137aa56f37e510543747c6a Archived-At: Cc: curdle , ietf@ietf.org, secdir@ietf.org, gen-art@ietf.org, curdle-chairs , draft-ietf-curdle-dnskey-eddsa Subject: Re: [secdir] Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 11:34:38 -0000 --001a1137aa56f37e510543747c6a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ondrej, Thanks for addressing my comments. The nits can be fixed at any time you find more convenient before publication. Regards, Dan On Mon, Dec 12, 2016 at 11:38 AM, Ond=C5=99ej Sur=C3=BD wrote: > Magnus and Dan, > > thanks for the review. > > Magnus, you are right, I have removed the first full paragraph > about "security properties" from Security Considerations > from my git version as the security properties of EdDSA > are better described in Normative references anyway. > > https://gitlab.labs.nic.cz/labs/ietf/commit/7b52c8e2bbe44042a279a81b96027= 0 > fdd103d9a2 > > Dan, > > good catches, I fixed the nits in the git: > > https://gitlab.labs.nic.cz/labs/ietf/commit/bbfc7ce43fb1f46c91fb7f5de564d= 9 > 07d035aadf > > I would be happy to upload next revision after Last Call > is finished or just let the RFC editors to fix it. > > Cheers, > -- > Ond=C5=99ej Sur=C3=BD -- Technical Fellow > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.sury@nic.cz https://nic.cz/ > -------------------------------------------- > > ----- Original Message ----- > > From: "Magnus Nystr=C3=B6m" > > To: secdir@ietf.org, "draft-ietf-curdle-dnskey-eddsa" < > draft-ietf-curdle-dnskey-eddsa@ietf.org> > > Sent: Monday, 12 December, 2016 02:44:18 > > Subject: Secdir review of draft-ietf-curdle-dnskey-eddsa-02 > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > This document describes how to use two two specific Edwards Curves > > (Elliptic Curves) in conjunction with DNSSEC, namely ed25519 and > > ed448. > > > > The only comment I have on this document is that the Security > > Considerations section plainly states, without any reference or proof: > > > > "Ed25519 and Ed448 offers improved security properties and > > implementation characteristics compared to RSA and ECDSA algorithms" > > > > I suggest either adding references to proofs of these statements or > > alternatively just remove the sentence (since it doesn't really add > > anything to the memo); the remaining paragraphs in the Security > > Considerations section is what really covers what someone implementing > > the memo should know or be aware of. > > > > -- Magnus > > ~~~~ > > ----- Original Message ----- > > From: "Dan Romascanu" > > To: gen-art@ietf.org > > Cc: "draft-ietf-curdle-dnskey-eddsa all" eddsa.all@ietf.org>, "curdle" , > > ietf@ietf.org > > Sent: Sunday, 11 December, 2016 12:21:25 > > Subject: Review of draft-ietf-curdle-dnskey-eddsa-02 > > > Reviewer: Dan Romascanu > > Review result: Ready with Nits > > > > Summary: Ready, with nits > > > > I am not an expert in this field, but the document seems to meet its > > goals, it's clear and precise > > > > Major issues: > > > > Minor issues: > > > > Nits/editorial comments: > > > > 1. Section 4: s/Section5.1.7/Sections 5.1.7/ > > > > 2. Section 8: 'The following entry has been added to > > the registry' - I may be wrong, but the section seems to define two > > new entries in the registry rather than one > > --001a1137aa56f37e510543747c6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ondrej,

Thanks for address= ing my comments. The nits can be fixed at any time you find more convenient= before publication.

Regards,

Dan



On Mon, Dec 12= , 2016 at 11:38 AM, Ond=C5=99ej Sur=C3=BD <ondrej.sury@nic.cz> wrote:
Magnus and Dan,

thanks for the review.

Magnus, you are right, I have removed the first full paragraph
about "security properties" from Security Considerations
from my git version as the security properties of EdDSA
are better described in Normative references anyway.

https://gitlab.l= abs.nic.cz/labs/ietf/commit/7b52c8e2bbe44042a279a81b960270fd= d103d9a2

Dan,

good catches, I fixed the nits in the git:

https://gitlab.l= abs.nic.cz/labs/ietf/commit/bbfc7ce43fb1f46c91fb7f5de564d907= d035aadf

I would be happy to upload next revision after Last Call
is finished or just let the RFC editors to fix it.

Cheers,
--
=C2=A0Ond=C5=99ej Sur=C3=BD -- Technical Fellow
=C2=A0--------------------------------------------
=C2=A0CZ.NIC, z.s.p.o.=C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0Laborato=C5=99e C= Z.NIC
=C2=A0Milesovska 5, 130 00 Praha 3, Czech Republic
=C2=A0mailto:ondrej.sury@nic.cz= =C2=A0 =C2=A0 https://nic.cz/
=C2=A0--------------------------------------------

----- Original Message -----
> From: "Magnus Nystr=C3=B6m" <magnusn@gmail.com>
> To: secdir@ietf.org, "draf= t-ietf-curdle-dnskey-eddsa" <draft-ietf-curdle-dnskey-eddsa@ietf.org&= gt;
> Sent: Monday, 12 December, 2016 02:44:18
> Subject: Secdir review of draft-ietf-curdle-dnskey-eddsa-02

> I have reviewed this document as part of the security directorate'= s
> ongoing effort to review all IETF documents being processed by the
> IESG. These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments.
>
> This document describes how to use two two specific Edwards Curves
> (Elliptic Curves) in conjunction with DNSSEC, namely ed25519 and
> ed448.
>
> The only comment I have on this document is that the Security
> Considerations section plainly states, without any reference or proof:=
>
> "Ed25519 and Ed448 offers improved security properties and
> implementation characteristics compared to RSA and ECDSA algorithms&qu= ot;
>
> I suggest either adding references to proofs of these statements or > alternatively just remove the sentence (since it doesn't really ad= d
> anything to the memo); the remaining paragraphs in the Security
> Considerations section is what really covers what someone implementing=
> the memo should know or be aware of.
>
> -- Magnus

~~~~

----- Original Message -----
> From: "Dan Romascanu" <dromasca@gmail.com>
> To: gen-art@ietf.org
> Cc: "draft-ietf-curdle-dnskey-eddsa all" <draft-ietf-curdle-dnsk= ey-eddsa.all@ietf.org>, "curdle" <curdle@ietf.org>,
> ietf@ietf.org
> Sent: Sunday, 11 December, 2016 12:21:25
> Subject: Review of draft-ietf-curdle-dnskey-eddsa-02

> Reviewer: Dan Romascanu
> Review result: Ready with Nits
>
> Summary: Ready, with nits
>
> I am not an expert in this field, but the document seems to meet its > goals, it's clear and precise
>
> Major issues:
>
> Minor issues:
>
> Nits/editorial comments:
>
> 1. Section 4: s/Section5.1.7/Sections 5.1.7/
>
> 2. Section 8: 'The following entry has been added to
>=C2=A0 =C2=A0the registry' - I may be wrong, but the section seems = to define two
> new entries in the registry rather than one


--001a1137aa56f37e510543747c6a-- From nobody Mon Dec 12 13:52:00 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40948129DAE for ; Mon, 12 Dec 2016 13:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYqAtFKV25oo for ; Mon, 12 Dec 2016 13:51:48 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D74E129D15 for ; Mon, 12 Dec 2016 13:51:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 59560300295 for ; Mon, 12 Dec 2016 16:41:31 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9T4mBt4ZPd0y for ; Mon, 12 Dec 2016 16:41:29 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 1395B300093; Mon, 12 Dec 2016 16:41:29 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <148146205925.29990.2056127161677925002.idtracker@ietfa.amsl.com> Date: Mon, 12 Dec 2016 16:51:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <112F7397-2F82-4573-B552-B7BE69E2F24C@vigilsec.com> References: <148146205925.29990.2056127161677925002.idtracker@ietfa.amsl.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: curdle@ietf.org, draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org, IETF SecDir Subject: Re: [secdir] Review of draft-ietf-curdle-cms-chacha20-poly1305-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 21:51:53 -0000 Yoav: Thanks for the review. The document will be more clear about the = handling of AAD because you reviewed it. > Reviewer: Yoav Nir > Review result: Has Nits >=20 > Hi, >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > Summary: Ready with nits. >=20 > Introduction > ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit = key > and a 96-bit nonce. ChaCha20 is described in [FORIETF]. >=20 > ChaCha20 is described in DJB's paper. RFC 7539 just repeats the > definition with more detail, examples and test vectors. Same for > Poly1305 in the next paragraph. The point of RFC 7539, I believe, is a reference that is readily = available to the Internet community. Does this rewording resolve your = concern? [FORIETF] provides a detailed algorithm description, examples, and test = vectors of ChaCha20. [FORIETF] also provides a detailed algorithm description, examples, and = test vectors of Poly1305. > Section 3 describes how to use AEAD_CHACHA20_POLY1305 with > AuthEnvelopedData. The algorithm, as stated in section 1.1 has four > inputs: a 256-bit key, a 96-bit nonce, an arbitrary length plaintext, > and an arbitrary length additional authenticated data (AAD). The key > is generated by one of the methods in section 2 (Key Management); the > nonce is generated by the sender. The text requires that it be unique, > but does not mandate of suggest a way of doing this. This is fine. The > plaintext according to section 3 is "the content located in the > AuthEnvelopedData EncryptedContentInfo encryptedContent field". and > the tag is stored in the AuthEnvelopedData mac field. >=20 > What's missing is the AAD. I could not find what goes into the AAD. > This is described in section 2.2 of RFC 5083, but it should be either > repeated here or referenced. It's jarring that the other inputs are > described while this one is omitted. I suggest the following replacement for the third paragraph in Section = 3. The AEAD_CHACHA20_POLY1305 algorithm is used to authenticate the attributes located in the AuthEnvelopedData authAttrs field, if any are present, encipher the content located in the AuthEnvelopedData EncryptedContentInfo encryptedContent field, and to provide the message authentication code (MAC) located in the AuthEnvelopedData mac field. The authenticated attributes are DER encoded to produce the AAD input value to the AEAD_CHACHA20_POLY1305 algorithm. The ciphertext and the MAC are the two outputs of the AEAD_CHACHA20_POLY1305 algorithm. Note that the MAC, which is called the authentication tag in [FORIETF], provides integrity protection for both the AuthEnvelopedData authAttrs and the AuthEnvelopedData EncryptedContentInfo encryptedContent. Thanks, Russ From nobody Mon Dec 12 14:12:00 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC91B12943B; Mon, 12 Dec 2016 14:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.797 X-Spam-Level: X-Spam-Status: No, score=-4.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mlk2zrq5eIFd; Mon, 12 Dec 2016 14:11:47 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBBC9129793; Mon, 12 Dec 2016 14:11:43 -0800 (PST) Received: from hebrews (173.8.216.38) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 12 Dec 2016 14:31:18 -0800 From: Jim Schaad To: 'Yoav Nir' , References: <148146205925.29990.2056127161677925002.idtracker@ietfa.amsl.com> In-Reply-To: <148146205925.29990.2056127161677925002.idtracker@ietfa.amsl.com> Date: Mon, 12 Dec 2016 14:11:34 -0800 Message-ID: <0e1501d254c4$b542c1e0$1fc845a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQNAj1+knqelScWc7hRTFF3lbOB1zp4oahLg Content-Language: en-us X-Originating-IP: [173.8.216.38] Archived-At: Cc: curdle@ietf.org, draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org, ietf@ietf.org Subject: Re: [secdir] [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 22:11:51 -0000 > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Yoav Nir > Sent: Sunday, December 11, 2016 5:14 AM > To: secdir@ietf.org > Cc: curdle@ietf.org; draft-ietf-curdle-cms-chacha20-poly1305.all@ietf.org; > ietf@ietf.org > Subject: [Curdle] Review of draft-ietf-curdle-cms-chacha20-poly1305-04 > > Reviewer: Yoav Nir > Review result: Has Nits > > Hi, > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area directors. > Document editors and WG chairs should treat these comments just like any > other last call comments. > > Summary: Ready with nits. > > Introduction > ChaCha20 is the 20-round variant of ChaCha; it requires a 256-bit key > and a 96-bit nonce. ChaCha20 is described in [FORIETF]. > > ChaCha20 is described in DJB's paper. RFC 7539 just repeats the definition with > more detail, examples and test vectors. Same for > Poly1305 in the next paragraph. ChaCha20 was originally described in DJB's paper. There is still a complete description of the algorithm in [FORIETF]. Once could argue that it is a more complete description since it includes examples and test vectors. > > Section 3 describes how to use AEAD_CHACHA20_POLY1305 with > AuthEnvelopedData. The algorithm, as stated in section 1.1 has four > inputs: a 256-bit key, a 96-bit nonce, an arbitrary length plaintext, and an > arbitrary length additional authenticated data (AAD). The key is generated by > one of the methods in section 2 (Key Management); the nonce is generated by > the sender. The text requires that it be unique, but does not mandate of suggest > a way of doing this. This is fine. The plaintext according to section 3 is "the > content located in the AuthEnvelopedData EncryptedContentInfo > encryptedContent field". and the tag is stored in the AuthEnvelopedData mac > field. > > What's missing is the AAD. I could not find what goes into the AAD. > This is described in section 2.2 of RFC 5083, but it should be either repeated here > or referenced. It's jarring that the other inputs are described while this one is > omitted. That seems reasonable to add. Jim > > The Security Considerations section seems fine. > > Yoav > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Dec 13 10:31:21 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE1F12945A for ; Tue, 13 Dec 2016 10:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.095 X-Spam-Level: X-Spam-Status: No, score=-7.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shywiuMtHVXB for ; Tue, 13 Dec 2016 10:31:15 -0800 (PST) Received: from PCH.mit.edu (pch.mit.edu [18.7.21.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABB512966F for ; Tue, 13 Dec 2016 10:31:12 -0800 (PST) Received: from pch.mit.edu (localhost.localdomain [127.0.0.1]) by PCH.mit.edu (8.13.8/8.12.8) with ESMTP id uBDIVBnJ028934 for ; Tue, 13 Dec 2016 13:31:11 -0500 Received: from mailhub-dmz-2.mit.edu (mailhub-dmz-2.mit.edu [18.7.62.37]) by PCH.mit.edu (8.13.8/8.12.8) with ESMTP id uBDIV9IT028931 for ; Tue, 13 Dec 2016 13:31:09 -0500 Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by mailhub-dmz-2.mit.edu (8.13.8/8.9.2) with ESMTP id uBDIV466020422 for ; Tue, 13 Dec 2016 13:31:09 -0500 X-AuditID: 12074422-cd3ff70000002073-7d-58503e6b1d11 Received: from dfw-mailout2.raytheon.com (dfw-mailout2.raytheon.com [199.46.199.208]) (using TLS with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 26.59.08307.C6E30585; Tue, 13 Dec 2016 13:31:08 -0500 (EST) Received: from ma-mailout10.rtnmail.ray.com (ma-mailout10.rtnmail.ray.com [147.25.130.27]) by dfw-mailout2.raytheon.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id uBDIV6RI028148 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 13 Dec 2016 18:31:07 GMT Received: from 008-smtp-out.ray.com ([23.103.8.216]) by ma-mailout10.rtnmail.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id uBDIV5P0034440 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 13 Dec 2016 18:31:05 GMT Received: from CY1PR0601MB023.008f.mgd2.msft.net (23.103.8.215) by CY1PR0601MB024.008f.mgd2.msft.net (23.103.8.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.19; Tue, 13 Dec 2016 18:31:04 +0000 Received: from CY1PR0601MB023.008f.mgd2.msft.net ([23.103.8.215]) by CY1PR0601MB023.008f.mgd2.msft.net ([23.103.8.215]) with mapi id 15.01.0721.017; Tue, 13 Dec 2016 18:31:04 +0000 From: Steve KENT To: "secdir@mit.edu" Thread-Topic: early SECDIR review of draft-dnssd-pairing-00.txt Thread-Index: AQHSTxPmnjGXWxLWtEGQYvtncuYbW6EGP9Vv Date: Tue, 13 Dec 2016 18:31:04 +0000 Message-ID: <022cf9ab3832452b9d155aeb04be6400@CY1PR0601MB023.008f.mgd2.msft.net> References: <8eb7b12d9b434797bb1e07caffb1c974@CY1PR0601MB023.008f.mgd2.msft.net> In-Reply-To: <8eb7b12d9b434797bb1e07caffb1c974@CY1PR0601MB023.008f.mgd2.msft.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [23.103.8.196] MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-13_11:, , signatures=0 Authentication-Results: symauth.service.identifier X-Brightmail-Tracker: H4sIAAAAAAAAA1WSbUgTcRzH97+7befw7Nxm+7ca5VFvjKmpQQ8+EZJhgutFZBbW5U433Kbt NtFRMQsttFBfSGaCBmYpGWkvlHwIDJPMpwZKmIiUmU5QCGuLwrrzn7beHB++3+/v970fdySu bJBpSa7YwdltrIWRKYihyKEJvSXRkBn95feRQ+ULPbJkcOL6yCBuAFmKeCNnMRdx9qjEiwqT 39tDFH5zFc+OlUvdYCm3AgSRkI6DjbVtWAVQkEq6HYNV/R2EaCjpfgxOtiYgvonB2VILCt3C YPWHUTkyugF854sWWUZHwNXPXiCymt4H2zuXN1hFJ8K2iToC6Ulw5C2aVdMxcO7rlExkQsi3 PL69oVO0Af4cXwRovwH2dlVu6EH0KfjrZRUuMqC3Q9/wE0xknNbA6flGDF1Dw+becRxxGFz6 tC5FvAc+bGiSo3wBrGnoAKgrFL65N0+gTD78sfJKhvbHwJ4xr7QawPqAivqA8fqAcaRHw9Wx RhzxftjyYPkvR8GOtVEQqDcBeRvQGa0uvZU1W3guR8/nsDYbZ9cfjLSaHZGc0dkJhE+rlKcw 3aBmPW0A0CRggim/ypCplLJFfIl1AOwgMSaMyo4WpJBLBcYSE8ubLtidFo4fAJDEGTUF4gWP MrIlLs5esGntJAlGQ3nMqZlKOo91cPkcV8jZN12MlA+AXSTJQColQZgOtXN5XHGu2eIIzASJ D4VYEyzUxItBii9krbw5D4WGQbhWQ0lEgxYNk9O2tWDzp/UAnVZFAYlEogwW3kA4/H/fCzTC 0SoqS9wSbLY5trZ7hWJMKA5rzhCLHew/S+sGpd47/jVLROqe9Ef33R+3VX0/2VLftRJbm+XO nUlv8oWwsmcxdccy+ObdlWrsauykq/3uce755dPJN95PXdO1wjMmhb9kb5xHMTo3kzw9mH5Y sVh2/rXcdzS7r7tP5T7XgZ1dC7rydCE8LqlBs7akeuGJSvMMQWdbmT6JKdf5GYI3sQcicDvP /gEgQGxFrwMAAA== X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: multipart/mixed; boundary="===============3168291692721933762==" Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Archived-At: Subject: [secdir] Fw: early SECDIR review of draft-dnssd-pairing-00.txt X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 18:31:19 -0000 --===============3168291692721933762== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_022cf9ab3832452b9d155aeb04be6400CY1PR0601MB023008fmgd2m_" --_000_022cf9ab3832452b9d155aeb04be6400CY1PR0601MB023008fmgd2m_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable sent to authors on 12/5, but I forgot to copy the list ... ---- I generated an early review of this document as part of the security direct= orate's ongoing effort to review all IETF documents being processed by the = IESG. These comments were written with the intent of improving security re= quirements and considerations in IETF drafts. Comments not addressed in la= st call may be included in AD reviews during the IESG review. Document edi= tors and WG chairs should treat these comments just like any other last cal= l comments. This document proposes a mechanism for a pair of (human-operated) devices t= o establish a secure binding to one another. The binding must put in place = crypto keys that enable authenticated, encrypted communication between the = devices. There is also a desire to establish device IDs that will hide the = identities of these devices from other entities. The document is written in the style of a paper that might appear in a con= ference proceedings. If it were destined to become an informational RFC tha= t would be OK. However, the style seems inappropriate for a standards track= document. I suggest splitting the i-D into two documents: sections 1-3 cou= ld become an informational RFC. Sections 4, and 5 could become a standards = track document. With references to the former, informational document as ne= eded. Section 2 provides a statement of the problem, examines requirements for ca= ndidate solutions, and discusses why existing pairing mechanisms are not pe= rceived as adequate. It notes that the goal of this mechanism is to be inde= pendent of underlying (local net) technology, in contrast to extant BlueToo= th and WiFi pairing protocols. The authors want a solution that works over = any IP-capable network, and which addresses UI limitations that have arisen= in previously-proposed mechanism. This section provided a detailed analysi= s of the perceived shortcomings of existing pairing methods, including susc= eptibility to MITM attacks. They plan to effect discovery of the devices to= be paired, using DNS service discovery, making use of either =93friendly= =94 or random names, depending on the context in which the pairing takes pl= ace. The authors elect to use TLS with extensions for short authentication = string verification, and =93commit before disclose=94 mechanisms. The secti= on ends with an explanation of why they reject the use of QR codes. The arg= uments presented here seem a bit weak, compared to those in prior subsectio= ns. In particular, they note that a MITM attack can cause the procedure to = fail, and thus prevent it from being fully automated. Although that=92s tru= e, one might argue that in the vast majority of cases there will be no MITM= , and thus the procedure will be simpler for most users almost all of the t= ime. Section 3 provides an overview of the pairing mechanism design. The design = is separated into three phases: (device) discovery, (key) agreement, and au= thentication. I was a bit surprised to see the discovery phase discuss optional use of QR= codes, after Section 2.7 criticized them, but their use here is limited to= device discovery. The authors the observe that QR codes are attractive he= re if supported by both devices; I agree with this sentiment. The non-QR ap= proach relies on DNS-SD, which is not required if QR codes are employed. Th= e agreement phase also offers two options: one uses short authentication st= rings and the other uses QR codes. The discussion of intra-user pairing (wh= ere one user controls both devices) introduces the notion of using an USB d= evice to create an OOB channel. This seems somewhat at odds with the prior = discussions where the focus is on a user reading a display or using a camer= a to acquire a QR code from a display. This subsection needs more work, as = the authors note. There is also a very brief discussion of how a user might= leverage pairing with one device from a friend into pairing with other dev= ices associated with the same individual. This seems like a useful feature,= but the discussion here is too brief. Section 4 presents the solution selected by the authors. As the authors not= e at the beginning of this section, it needs more work. The structure of th= e section is good, dividing the solution description into discovery vs. ag= reement and authentication. Use of existing, standard mechanisms (DNS-SD an= d mDNS) for discovery seems reasonable, with use of a QR code as an optiona= l OOB method. (As the authors note, the format for the QR code data needs t= o be specified.) Use of TLS 1.2 for the agreement and authentication also seems like a good = choice. However, the specification seems to be a bit too flexible here, in = some respects. For example, the TLS cipher suite TLS_DH_anon_WITH_AES_256_C= BC_SHA256 is a SHOULD, not a MUST, which means that the text does not manda= te any cipher suite as MTI, hence no guarantee of interoperability. The adm= onition contained here to upgrade to TLS 1.3 isn=92t useful in a standards = track document, as there is not yet an RFC for that protocol. The Security Considerations section (5) notes the requirement to maintain p= rivacy by hiding the pairing between devices, and states that the chosen di= scovery mechanism does that. It would be good to remind the reader of the a= ssumed context associated with this assertion; specifically, the client and= user are in close, physical proximity and thus a human user can visually a= cquire and verify the pairing information. In a more general context the us= e of DNS probably would not confer the desired privacy. There is mention of the need for nodes to store the shared secret =93safely= =94 and the need to be able to =93quickly revoke=94 a compromised pairing. = Absent illustrative examples, the quoted terms are ambiguous. --_000_022cf9ab3832452b9d155aeb04be6400CY1PR0601MB023008fmgd2m_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

sent to authors on 12/5, but I forgot to copy the list ...


----


<= span style=3D"font-family:Courier">I generated an early review of this docu= ment as part of the security directorate's ongoing effort to review all IET= F documents being processed by the IESG.  These comments were written with the intent of improving security re= quirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews du= ring the IESG review.  Document editors and WG chairs should treat these comments just like= any other last call comments.

<= span style=3D"font-family:Courier"> 

<= span style=3D"font-family:Courier">This document proposes a mechanism for a= pair of (human-operated) devices to establish a secure binding to one anot= her. The binding must put in place crypto keys that enable authenticated, encrypted communication between the device= s. There is also a desire to establish device IDs that will hide the identi= ties of these devices from other entities.

<= span style=3D"font-family:Courier"> 

<= span style=3D"font-family:Courier">The document is written in the style of = a paper that might appear in  a conference proceedings. If it were destined to become an informati= onal RFC that would be OK. However, the style seems inappropriate for a sta= ndards track document. I suggest splitting the i-D into two documents: sect= ions 1-3 could become an informational RFC. Sections 4, and 5 could become a standards track document. With refer= ences to the former, informational document as needed.

<= span style=3D"font-family:Courier"> 

<= span style=3D"font-family:Courier">Section 2 provides a statement of the pr= oblem, examines requirements for candidate solutions, and discusses why exi= sting pairing mechanisms are not perceived as adequate. It notes that the goal of this mechanism is to be independent= of underlying (local net) technology, in contrast to extant BlueTooth and = WiFi pairing protocols. The authors want a solution that works over any IP-= capable network, and which addresses UI limitations that have arisen in previously-proposed mechanism. This sec= tion provided a detailed analysis of the perceived shortcomings of existing= pairing methods, including susceptibility to MITM attacks. They plan to ef= fect discovery of the devices to be paired, using DNS service discovery, making use of either =93friendly= =94 or random names, depending on the context in which the pairing takes pl= ace. The authors elect to use TLS with extensions for short authentication = string verification, and =93commit before disclose=94 mechanisms. The section ends with an explanation of why they r= eject the use of QR codes. The arguments presented here seem a bit weak, co= mpared to those in prior subsections. In particular, they note that a MITM = attack can cause the procedure to fail, and thus prevent it from being fully automated. Although that=92s tr= ue, one might argue that in the vast majority of cases there will be no MIT= M, and thus the procedure will be simpler for most users almost all of the = time.

<= span style=3D"font-family:Courier"> 

<= span style=3D"font-family:Courier">Section 3 provides an overview of the pa= iring mechanism design. The design is separated into three phases: (device)= discovery, (key) agreement, and authentication.

<= span style=3D"font-family:Courier"> 

<= span style=3D"font-family:Courier">I was a bit surprised to see the discove= ry phase discuss optional use of QR codes, after Section 2.7 criticized the= m, but their use here is limited to device discovery. The authors the observe  th= at QR codes are attractive here if supported by both devices; I agree with = this sentiment. The non-QR approach relies on DNS-SD, which is not required= if QR codes are employed. The agreement phase also offers two options: one uses short authentication strings and t= he other uses QR codes. The discussion of intra-user pairing (where one use= r controls both devices) introduces the notion of using an USB device to cr= eate an OOB channel. This seems somewhat at odds with the prior discussions where the focus is on a user r= eading a display or using a camera to acquire a QR code from a display. Thi= s subsection needs more work, as the authors note. There is also a very bri= ef discussion of how a user might leverage pairing with one device from a friend into pairing with other dev= ices associated with the same individual. This seems like a useful feature,= but the discussion here is too brief.

<= span style=3D"font-family:Courier"> 

<= span style=3D"font-family:Courier">Section 4 presents the solution selected= by the authors. As the authors note at the beginning of this section, it n= eeds more work. The structure of the section is good, dividing the solution description into&n= bsp; discovery vs. agreement and authentication. Use of existing, st= andard mechanisms (DNS-SD and mDNS) for discovery seems reasonable, with us= e of a QR code as an optional OOB method. (As the authors note, the format for the QR code data needs to be specifie= d.)

<= span style=3D"font-family:Courier"> 

<= span style=3D"font-family:Courier">Use of TLS 1.2 for the agreement and aut= hentication also seems like a good choice. However, the specification seems= to be a bit too flexible here, in some respects. For example, the TLS cipher suite TLS_DH_anon_WITH_AES_256_CBC_SHA256 is a SHOULD, not a MUST, w= hich means that the text does not mandate any cipher suite as MTI, hence no= guarantee of interoperability. The admonition contained here to upgrade to TLS 1.3 isn=92t useful in a standa= rds track document, as there is not yet an RFC for that protocol.

<= span style=3D"font-family:Courier"> 

<= span style=3D"font-family:Courier">The Security Considerations section (5) = notes the requirement to maintain privacy by hiding the pairing between dev= ices, and states that the chosen discovery mechanism does that. It would be good to remind the reader of the assumed = context associated with this assertion; specifically, the client and user a= re in close, physical proximity and thus a human user can visually acquire = and verify the pairing information. In a more general context the use of DNS probably would not confer the des= ired privacy.

<= span style=3D"font-family:Courier"> 

<= span style=3D"font-family:Courier">There is mention of the need for nodes t= o store the shared secret =93safely=94 and the need to be able to =93quickl= y revoke=94 a compromised pairing. Absent illustrative examples, the quoted terms are ambiguous.


--_000_022cf9ab3832452b9d155aeb04be6400CY1PR0601MB023008fmgd2m_-- --===============3168291692721933762== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir --===============3168291692721933762==-- From nobody Tue Dec 13 16:08:52 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A60129C69; Tue, 13 Dec 2016 16:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkoEqxCIh-9q; Tue, 13 Dec 2016 16:08:37 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0071.outbound.protection.outlook.com [104.47.37.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC373129C2D; Tue, 13 Dec 2016 16:05:05 -0800 (PST) Received: from MWHPR01MB2670.prod.exchangelabs.com (10.172.165.8) by MWHPR01MB2671.prod.exchangelabs.com (10.172.165.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Wed, 14 Dec 2016 00:05:04 +0000 Received: from MWHPR01MB2670.prod.exchangelabs.com ([10.172.165.8]) by MWHPR01MB2670.prod.exchangelabs.com ([10.172.165.8]) with mapi id 15.01.0771.014; Wed, 14 Dec 2016 00:05:04 +0000 From: Matthew Kerwin To: Barry Leiba , "secdir@ietf.org" Thread-Topic: SecDir review of draft-ietf-appsawg-file-scheme-14 Thread-Index: AQHSSnFPod93FrypBEOZkfp7dGkXSKD7s1VegAAOL4CACuIVkA== Date: Wed, 14 Dec 2016 00:05:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=matthew.kerwin@qut.edu.au; x-originating-ip: [131.181.125.63] x-ms-office365-filtering-correlation-id: 58812475-8580-4de9-7d47-08d423b4db05 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:MWHPR01MB2671; x-microsoft-exchange-diagnostics: 1; MWHPR01MB2671; 7:pjXVMwpvVVC1aGC1r8ls7+CaxUAZHzi/O0Ay9Ttyl2F6E5mZet3Vhsbt7ohbOXSnSdoxTfjJkJWba804yqHSg0SaR8Jl/brSfVA7/qOIE6G92G8+GgN65BTGHUrYK2L0n5mGxAHsFlxKvRfTaA7ebZx2pfOrf3V/BEd06vrmJ/3j9idlK4w1Pe+VqfyZKjL8LPOXynnaTkmmfLU2276BdvX6xvtL26SqTSgWlspbm7+geegFYUd8AEGy6K7mAiSRYZOCDMVgSKq84lCe5kfBj911KNnMSwGw/fDFwkoXU01LDS/LJDfciY1F+J03u5q9LtXzn5q5c3i3hSyoBfjVg9Xztb2p96lOBCjhsy4xrukIDHtY9N3zMjiT1VL38BBK1ZDWuANHxmAneh7vkb4solX0sIDePQkEb0UOoyLVJrG1WltK/pD4NPLJJxuvynqH94tMEQ3n0p9rjlxDNd81ow== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155)(54900358751275); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:MWHPR01MB2671; BCL:0; PCL:0; RULEID:; SRVR:MWHPR01MB2671; x-forefront-prvs: 01565FED4C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(39840400002)(39410400002)(377454003)(51694002)(24454002)(189002)(199003)(97736004)(7696004)(8676002)(50986999)(7736002)(790700001)(54356999)(7906003)(6506006)(76176999)(77096006)(5660300001)(68736007)(3846002)(189998001)(102836003)(6436002)(38730400001)(66066001)(6116002)(229853002)(74482002)(42882006)(2950100002)(81156014)(3280700002)(5001770100001)(92566002)(8936002)(101416001)(99936001)(2501003)(3660700001)(9686002)(4326007)(122556002)(230783001)(2906002)(81166006)(606005)(106116001)(2900100001)(74316002)(106356001)(33656002)(105586002)(88552002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR01MB2671; H:MWHPR01MB2670.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: qut.edu.au does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0052_01D255F1.88BFB4B0" MIME-Version: 1.0 X-OriginatorOrg: qut.edu.au X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2016 00:05:03.8645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: dc0b52a3-68c5-44f7-881d-9383d8850b96 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR01MB2671 Archived-At: Cc: "draft-ietf-appsawg-file-scheme.all@ietf.org" , "paul.hoffman@vpnc.org" , Larry Masinter Subject: Re: [secdir] SecDir review of draft-ietf-appsawg-file-scheme-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 00:08:44 -0000 ------=_NextPart_000_0052_01D255F1.88BFB4B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0053_01D255F1.88BFB4B0" ------=_NextPart_001_0053_01D255F1.88BFB4B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Barry, all (I trimmed the CC list, hopefully fewer disinterested = people are seeing this) =20 I published the -15 version yesterday. =20 This update includes your changes to the abstract, with Larry = Masinter=E2=80=99s tweak. =20 I took your suggested security considerations text pretty much verbatim; = it=E2=80=99s a bit vague, but I think it works as a red flag. =20 And the acknowledgements has been redone. I don=E2=80=99t know if = mentioning some people by name there is socially acceptable, especially = when it comes to those people whose names I didn=E2=80=99t mention. I = can leave the list out if it offends anybody =E2=80=93 please let me = know. =20 Cheers --=20 Matthew Kerwin | QUT =20 From: Barry Leiba [mailto:barryleiba@computer.org]=20 Sent: Wednesday, 7 December 2016 11:43 To: Matthew Kerwin; draft-ietf-appsawg-file-scheme.all@ietf.org; = secdir@ietf.org Cc: IETF discussion list; art@ietf.org; paul.hoffman@vpnc.org Subject: Re: SecDir review of draft-ietf-appsawg-file-scheme-14 =20 Thanks, Matthew! b =20 On Tue, Dec 6, 2016 at 7:03 PM Matthew Kerwin = wrote: Thanks Barry (and Paul), I agree with everything you've written here, and I don't think any of = it's too controversial, so I'll work it all in to my copy pretty much = exactly as you've suggested. The acknowledgements is hung over from the very first versions of the = draft, which cribbed a lot from Paul's old draft. I'm pretty sure it's = been completely rewritten several times since then, so I will definitely = redo the acks. Cheers -- Matthew Kerwin | Queensland University of Technology | = matthew.kerwin@qut.edu.au | CRICOS No 00213J ________________________________ From: barryleiba@gmail.com on behalf of Barry = Leiba Sent: 30 November 2016 04:49:12 To: draft-ietf-appsawg-file-scheme.all@ietf.org; secdir@ietf.org Cc: IETF discussion list; art@ietf.org Subject: SecDir review of draft-ietf-appsawg-file-scheme-14 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. Thanks for finally getting this through. I think the document is ready with nits; my detailed comments are below. It=E2=80=99s a tiny thing, but where the abstract says = =E2=80=9Creplacing the definition in RFC 1738,=E2=80=9D one may be led to think (I was) that = 1738 has a more robust definition than it does. D=E2=80=99you mind changing that = to something like this: =E2=80=98This document provides a full = specification of the "file" Uniform Resource Identifier (URI) scheme, replacing the very brief definition in Section 3.10 of RFC 1738.=E2=80=99 The Security Considerations section is well thought out; thanks. The only thing I can think of that might be added is a few words about non-local file URIs. Section 3 says two significant things that should be highlighted in a security consideration: 1. A file URI can be dependably dereferenced or translated to a local file path only if it is local. 2. This specification neither defines nor forbids any set of operations that might be performed on a file identified by a non-local file URI. Given those two things, I think it would be worth explicitly saying that treating a non-local URI as local or otherwise attempting to perform local operations on a non-local URI can result in security problems. Matthew=E2=80=99s name and address will be on the RFC, of course, but is = that really the best choice for contact information for the scheme in the registry? Or would it be better to point people to = =E2=80=9CApplications and Real-Time Area =E2=80=9D ? In general, we seem to have = mixed feelings about listing individuals as contact points for things registered by working group documents (and I fall on the =E2=80=9Cavoid = using specific individuals=E2=80=9D side, because individuals often come and = go over relatively short time). The =E2=80=9CReferences=E2=80=9D in the registry template should just be = =E2=80=9Cthis RFC=E2=80=9D, and this RFC number will appear in the registry. A bit of process geekery: In the Acknowledgments, you say=E2=80=A6 This specification is derived from [RFC1738], [RFC3986], and [I-D.hoffman-file-uri] (expired); the acknowledgements in those documents still apply. I don=E2=80=99t imagine there=E2=80=99s actually text from 1738 in here = (is there?). How much text is here from 3986? I=E2=80=99m not talking about = concepts, but actual text that was brought over. If there is, have you made sure that all authors of the documents you got text from agree to the terms of BCPs 78 & 79 ? If not, there might need to be a pre-5378 disclaimer in the boilerplate. I suspect we=E2=80=99re OK, because = we=E2=80=99re mostly talking about Larry, Roy, and TimBL, but I just wanted to check. (I personally think the acknowledgments text above is a bit much, unless you=E2=80=99ve really copied a lot of text from those RFCs. But = that=E2=80=99s your section to do with as you think best.) References: I don=E2=80=99t think BCP35 is normative, and I=E2=80=99d move it to = informative. I don=E2=80=99t think UAX15 is normative, and I=E2=80=99d move it to = informative. I think UTF-8 is normative (as you have it), but UNICODE is not. Others might disagree with that. I think I would make RFC 6454 normative, only because it=E2=80=99s = listed as a reference for =E2=80=9Cthe most secure option=E2=80=9D in the Security = Considerations. Barry ------=_NextPart_001_0053_01D255F1.88BFB4B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi= Barry, all (I trimmed the CC list, hopefully fewer disinterested people = are seeing this)

 

I = published the -15 version yesterday.

 

Th= is update includes your changes to the abstract, with Larry = Masinter=E2=80=99s tweak.

 

I = took your suggested security considerations text pretty much verbatim; = it=E2=80=99s a bit vague, but I think it works as a red = flag.

 

An= d the acknowledgements has been redone. I don=E2=80=99t know if = mentioning some people by name there is socially acceptable, especially = when it comes to those people whose names I didn=E2=80=99t mention. I = can leave the list out if it offends anybody =E2=80=93 please let me = know.

 

Ch= eers

-- =

= Matthew Kerwin=  | QUT

 

From:= Barry = Leiba [mailto:barryleiba@computer.org]
Sent: Wednesday, 7 = December 2016 11:43
To: Matthew Kerwin; = draft-ietf-appsawg-file-scheme.all@ietf.org; = secdir@ietf.org
Cc: IETF discussion list; art@ietf.org; = paul.hoffman@vpnc.org
Subject: Re: SecDir review of = draft-ietf-appsawg-file-scheme-14

 

Thanks, = Matthew!

b

 

On = Tue, Dec 6, 2016 at 7:03 PM Matthew Kerwin <matthew.kerwin@qut.edu.au&g= t; wrote:

Thanks = Barry (and Paul),

I agree with everything you've written here, = and I don't think any of it's too controversial,  so I'll work it = all in to my copy pretty much exactly as you've suggested.

The = acknowledgements is hung over from the very first versions of the draft, = which cribbed a lot from Paul's old draft. I'm pretty sure it's been = completely rewritten several times since then, so I will definitely redo = the acks.

Cheers
--
Matthew Kerwin  |  Queensland = University of Technology  |  matthew.kerwin@qut.edu.au  |  CRICOS No = 00213J
________________________________
From: barryleiba@gmail.com <barryleiba@gmail.com> on behalf of Barry Leiba = <barryleiba@computer.org>
Sent: 30 November = 2016 04:49:12
To: draft-ietf-appsawg-file-scheme.all@ietf.org; secdir@ietf.org
Cc: IETF discussion list; art@ietf.org
Subject: SecDir review of = draft-ietf-appsawg-file-scheme-14

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.

Thanks for = finally getting this through.  I think the document is
ready = with nits; my detailed comments are below.

It=E2=80=99s a tiny = thing, but where the abstract says =E2=80=9Creplacing the
definition = in RFC 1738,=E2=80=9D one may be led to think (I was) that 1738 has
a = more robust definition than it does.  D=E2=80=99you mind changing = that to
something like this: =E2=80=98This document provides a full = specification of
the "file" Uniform Resource Identifier = (URI) scheme, replacing the
very brief definition in Section 3.10 of = RFC 1738.=E2=80=99

The Security Considerations section is well = thought out; thanks.  The
only thing I can think of that might = be added is a few words about
non-local file URIs.  Section 3 = says two significant things that
should be highlighted in a security = consideration:
1. A file URI can be dependably dereferenced or = translated to a local
file path only if it is local.
2. This = specification neither defines nor forbids any set of
operations that = might be performed on a file identified by a non-local
file = URI.

Given those two things, I think it would be worth explicitly = saying
that treating a non-local URI as local or otherwise attempting = to
perform local operations on a non-local URI can result in = security
problems.

Matthew=E2=80=99s name and address will be = on the RFC, of course, but is that
really the best choice for contact = information for the scheme in the
registry?  Or would it be = better to point people to =E2=80=9CApplications and
Real-Time Area = <art@ietf.org>=E2=80=9D ?  In general, we = seem to have mixed
feelings about listing individuals as contact = points for things
registered by working group documents (and I fall = on the =E2=80=9Cavoid using
specific individuals=E2=80=9D side, = because individuals often come and go over
relatively short = time).

The =E2=80=9CReferences=E2=80=9D in the registry template = should just be =E2=80=9Cthis RFC=E2=80=9D,
and this RFC number will = appear in the registry.

A bit of process geekery:
In the = Acknowledgments, you say=E2=80=A6
   This specification is = derived from [RFC1738], [RFC3986], and
  =  [I-D.hoffman-file-uri] (expired); the acknowledgements in = those
   documents still apply.

I don=E2=80=99t = imagine there=E2=80=99s actually text from 1738 in here (is = there?).
How much text is here from 3986?  I=E2=80=99m not = talking about concepts, but
actual text that was brought over.  = If there is, have you made sure
that all authors of the documents you = got text from agree to the terms
of BCPs 78 & 79 ?  If not, = there might need to be a pre-5378
disclaimer in the = boilerplate.  I suspect we=E2=80=99re OK, because = we=E2=80=99re
mostly talking about Larry, Roy, and TimBL, but I just = wanted to
check.

(I personally think the acknowledgments text = above is a bit much,
unless you=E2=80=99ve really copied a lot of = text from those RFCs.  But that=E2=80=99s
your section to do = with as you think best.)

References:
I don=E2=80=99t think = BCP35 is normative, and I=E2=80=99d move it to informative.
I = don=E2=80=99t think UAX15 is normative, and I=E2=80=99d move it to = informative.
I think UTF-8 is normative (as you have it), but UNICODE = is not.
Others might disagree with that.
I think I would make RFC = 6454 normative, only because it=E2=80=99s listed as a
reference for = =E2=80=9Cthe most secure option=E2=80=9D in the Security = Considerations.

Barry

------=_NextPart_001_0053_01D255F1.88BFB4B0-- ------=_NextPart_000_0052_01D255F1.88BFB4B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOOzCCBDYw ggMeoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRy dXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZ QWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0wMDA1MzAxMDQ4MzhaFw0yMDA1MzAxMDQ4Mzha MG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3Qg RXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3Qw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC39xoz5vIABC054E5b7R+8bA/Ntfojts7e mxEzl6QpTH2Tn71KvJPtAxrjj8/lbVBa1pcplFqAsEl62y6V/bjKvzc4LR4+kUGtcFbH8E8/6DKe dMrIkFTpxl8PeJ2aQDwOrGGqXhSPnoehalDc15pOrwWzpnGUnHGzUGAKxxOdOAeGAqjpqGkmGJCr TLBPI6s6T4TY386f4Wlvu9dC12tE5Met7m1BX3JacQg3s3llpFmglDf3AC8NwpJy2tA4ctsUqEXE XSp9t7TWxO6szRNEt8kr3UMAJfphuWlqWCMRt6czj1Z1WfXNKddGtworZbbTQm8Vsrh7++/pXVPV NFonAgMBAAGjgdwwgdkwHQYDVR0OBBYEFK29mHo0tCb3+sQmVO8DveAky1QaMAsGA1UdDwQEAwIB BjAPBgNVHRMBAf8EBTADAQH/MIGZBgNVHSMEgZEwgY6AFK29mHo0tCb3+sQmVO8DveAky1QaoXOk cTBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0 IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 ggEBMA0GCSqGSIb3DQEBBQUAA4IBAQCwm+CFJcLWI+IPlgaSnUGYnNmEeYHZHlsUByM2ZY+w2He7 rEFsR2CDUbD5Mj3n/PYmE8eAFqW/WvyHz3h5iSGa4kwHCoY1vPLeUcTSlrfcfk7ucP0cOesMAlEU LY69FuDB30Z15ySt7PRCtIWTcBBnup0GNUoY0yt6zFFCoXpj0ea7ocUrwja+Ew3mvWN+eXunCQ1A q2rdj4rD9vaMGkIFUdRF9Z+nYiFoFSBDPJnnfL0k2KmRF3OIP1YbMTgYtHEPms3IDp6OLhvhjJiD yx8x8URMxgRzSXZgD8f4vReAay7pzEwOWpp5DyAKLtWeYyYeVZKU2IIXWnvQvMePToYEMIIErzCC A5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkGA1UEBhMCU0Ux FDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0 d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEyMjIwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxWpgYmt7hJ4Jbn Uavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW/qGHqS5DUkMW fK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8GsLGsk0C5tQiT OpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAtMX9ZvVI3sDNp LUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5GOld0YVC+xkA/ y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNV HQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgwBgYEVR0gADBE BgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1c3RFeHRlcm5h bENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2Vy dHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2ErwAkQI5kPxWZq b7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9YG+MiY5xS+LsF Nqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENumNzToe+ABEKWc yjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqGNAe5LMrmHErY mQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2ShAaJvp8ivub MIIFSjCCBDKgAwIBAgIRAK/v1MJibleITlV6u6HSb0owDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNjA4MTcwMDAwMDBaFw0xNzA4 MTcyMzU5NTlaMCoxKDAmBgkqhkiG9w0BCQEWGW1hdHRoZXcua2Vyd2luQHF1dC5lZHUuYXUwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDT3fY0gaDk5GB0K34O7KeBMmf1hzV72xxo3Up5 EI7Mp2qno/Ve52BQPEsWOpcjt98umYTINMHz6rgD9L9wEqjKhMlEwOWy3LQWjlaHbgbCzPxaMUXU JU0hPjQiQZhLA3Q+q+sSEE+NrOu7OYZmNu9l05U+ByLCsbs/oFNID1II4z75GPJIaRo/OGFtVszM Y97U/KrjSZt+zQPy4XfRXc4Gd+Z7ufQaRhR7Bxbibkb1LO5o8SLMcA2cTl2QWvglUzF/mcaj8U0/ oOpQJlPbxEEoUw38D8eqSEaoX3lYWVMDlx4vTmDcpOadUbHDIlcToLIHsUHrJnE71bw2SxHsxhA9 AgMBAAGjggH3MIIB8zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU kxk8MrQjvuf1voEIPhE5qekDVtYwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCQGA1UdEQQdMBuBGW1hdHRoZXcua2Vyd2luQHF1dC5lZHUuYXUw DQYJKoZIhvcNAQELBQADggEBAHMTjM07nV0WXWToj2eBzrNb3jbs3kvlzCLfBPQKmNOujFeVScE2 YcdanetyMqCuVc9v3Co9gshjOM4FT9UDNcbz+KHkDV8ANhsNBruwGjeLAhzzbnNn/j/tOE08ys7Y vRW8zQIWAMhIwagfVkfsncRSYmDr+GPLUAyZe1bHw5I54HAj/7IxBqvb8+obWk8mDc+pSlKzKBYN 2V8dBjFFzPbY0yepp9Mt4fLSVhqbJwKmy7aaXLM8Ry6WatZO59cJ14z6oohQPhIGbrS747kWwTHw ZcR6ctfLx6fY/z/WMmfeS+LPCR+U8evDamVGanf6d9e7COjkvhIwmfX9AQ5uAmwxggR0MIIEcAIB ATCBsTCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE BxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBT SEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAr+/UwmJu V4hOVXq7odJvSjAJBgUrDgMCGgUAoIIClzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjEyMTQwMDA1MDFaMCMGCSqGSIb3DQEJBDEWBBRgYpm6s0p/beGU3+QrDj6w vLV2nzCBqwYJKoZIhvcNAQkPMYGdMIGaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZI hvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIB QDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCG SAFlAwQCATCBwgYJKwYBBAGCNxAEMYG0MIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGlt aXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCv79TCYm5XiE5Veruh0m9KMIHEBgsqhkiG9w0BCRACCzGBtKCBsTCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAr+/UwmJuV4hOVXq7 odJvSjANBgkqhkiG9w0BAQEFAASCAQCxg5E5FGYX5SRGCheC4XGWfSu3nBfyK0kAzk+Q0d1L56EK ei3F1xeqb6ARcln4isL2M9k21DmP3qyxExr3veYTwiW4cpJpmalEHHhnLTfVQDFPk5LUqfQtJIbu f+Pco/QXl+igfgx3YLi13xbTNXVbXKDgmxNjiAFYVTSK6s2iJ3W6mhqhWraSYY6eHn5scnqt3IrM a62+zGzyPA0pO/fUB9hY5AUtvwp8vtvNa5GtSiRZbtP72REBJ7LYybTyXUHA7pP2t0w15lzDcjUY evOvV+AO6Czs/pMNhINN8lkXXP4szqOuCkUWUkRapk3FgAABqj4u33DkrU/PxR0NQRvkAAAAAAAA ------=_NextPart_000_0052_01D255F1.88BFB4B0-- From nobody Thu Dec 15 04:22:38 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B636D12A07A; Thu, 15 Dec 2016 04:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.116 X-Spam-Level: X-Spam-Status: No, score=-7.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZkEhp3JzC8e; Thu, 15 Dec 2016 04:22:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0654212A077; Thu, 15 Dec 2016 04:13:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCQ02372; Thu, 15 Dec 2016 12:13:07 +0000 (GMT) Received: from SZXEMI415-HUB.china.huawei.com (10.86.210.48) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 15 Dec 2016 12:12:56 +0000 Received: from SZXEMI502-MBX.china.huawei.com ([169.254.5.216]) by SZXEMI415-HUB.china.huawei.com ([10.86.210.48]) with mapi id 14.03.0235.001; Thu, 15 Dec 2016 20:12:52 +0800 From: zhangdacheng To: "iesg@ietf.org" , "secdir@ietf.org" Thread-Topic: SecDir review of draft-ietf-core-http-mapping- Thread-Index: AdJWzFwgsemGZeBfSda2gCe8a9p0vg== Date: Thu, 15 Dec 2016 12:12:52 +0000 Message-ID: <879E76B64CF340468BF5E4DE504C2242C128AB@szxemi502-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.167.227] Content-Type: multipart/alternative; boundary="_000_879E76B64CF340468BF5E4DE504C2242C128ABszxemi502mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.585288D4.0530, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.216, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d16f97bb32396a1203860b024ddd9fea Archived-At: Cc: "draft-ietf-core-http-mapping.all@tools.ietf.org" Subject: [secdir] SecDir review of draft-ietf-core-http-mapping- X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 12:22:30 -0000 --_000_879E76B64CF340468BF5E4DE504C2242C128ABszxemi502mbxchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. I think from the security considerations in this version is better than tho= se in -15 and ready for publication. Cheers Dacheng --_000_879E76B64CF340468BF5E4DE504C2242C128ABszxemi502mbxchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

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

 

I think from the security conside= rations in this version is better than those in -15 and ready for publicati= on.

 

Cheers

 

Dacheng

 

--_000_879E76B64CF340468BF5E4DE504C2242C128ABszxemi502mbxchina_-- From nobody Thu Dec 15 04:56:17 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49574129CDF for ; Thu, 15 Dec 2016 04:56:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Tero Kivinen" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148180657626.27590.15984435997993699323.idtracker@ietfa.amsl.com> Date: Thu, 15 Dec 2016 04:56:16 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 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, 15 Dec 2016 12:56:16 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2016-12-15 Reviewer LC end Draft Dan Harkins 2016-11-16 draft-ietf-dprive-dnsodtls-13 Warren Kumari R2016-12-08 draft-wilde-json-seq-suffix-02 Ben Laurie 2016-12-08 draft-ietf-6lo-dispatch-iana-registry-07 Dacheng Zhang R2016-12-13 draft-ietf-core-http-mapping-17 For telechat 2017-01-05 Reviewer LC end Draft Tero Kivinen 2016-12-20 draft-ietf-6tisch-minimal-17 Sandra Murphy 2016-12-20 draft-ietf-6tisch-minimal-17 Hilarie Orman None draft-ietf-i2rs-yang-l3-topology-06 Eric Osterweil 2016-12-19 draft-ietf-i2rs-yang-network-topo-09 Radia Perlman 2016-12-16 draft-ietf-idr-deprecate-30-31-129-00 Vincent Roca 2016-12-16 draft-ietf-idr-large-community-11 Joseph Salowey 2016-12-20 draft-ietf-manet-olsrv2-sec-threats-03 Rich Salz 2016-12-21 draft-ietf-sidr-bgpsec-ops-12 Yaron Sheffer 2016-12-19 draft-ietf-sidr-bgpsec-pki-profiles-18 Last calls: Reviewer LC end Draft Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Matt Lepinski 2016-12-14 draft-ietf-avtext-avpf-ccm-layered-03 Matthew Miller 2017-01-13 draft-harkins-owe-05 Melinda Shore 2017-01-09 draft-holmberg-dispatch-mcptt-rp-namespace-03 Robert Sparks 2017-01-18 draft-mohali-dispatch-cause-for-service-number-12 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Hannes Tschofenig 2016-03-18 draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig 2016-03-18 draft-ietf-ntp-network-time-security-15 Hannes Tschofenig 2016-03-18 draft-ietf-ntp-using-nts-for-ntp-07 Brian Weis 2016-02-01 draft-ietf-cdni-uri-signing-10 Next in the reviewer rotation: Takeshi Takahashi Hannes Tschofenig Tina Tsou Sean Turner Carl Wallace David Waltermire Sam Weiler Brian Weis Klaas Wierenga Paul Wouters From nobody Thu Dec 15 14:05:15 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362EE1294D1; Thu, 15 Dec 2016 14:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rtx1.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-hTHgWmTcmG; Thu, 15 Dec 2016 14:05:09 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0074.outbound.protection.outlook.com [104.47.2.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC66129552; Thu, 15 Dec 2016 14:05:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RTX1.onmicrosoft.com; s=selector1-rtx-dk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/vU/3BqUZdCWwyPLQEsW4pdMgDQjD1CGgsCqrpmc3D4=; b=keSLD7hGusLeBFtkS8dR0uJsIIVDm3RJUVqkUbhJlikpiCoxXwJrEkRUO5w3zq4Y6fSWf4ATa5dexiHfkedLhWuGRdnS7wktPjPhEGuYNsDGM2lmLik1/2vKQDj/S3xYziEJ29hdST1fjwT+sGCnyHCLm3LiKtZrs1C44NzBpjU= Received: from AM5PR0401MB2595.eurprd04.prod.outlook.com (10.169.245.22) by AM5PR0401MB2594.eurprd04.prod.outlook.com (10.169.245.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Thu, 15 Dec 2016 22:05:05 +0000 Received: from AM5PR0401MB2595.eurprd04.prod.outlook.com ([10.169.245.22]) by AM5PR0401MB2595.eurprd04.prod.outlook.com ([10.169.245.22]) with mapi id 15.01.0771.014; Thu, 15 Dec 2016 22:05:05 +0000 From: Jens Toftgaard Petersen To: Simon Josefsson , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-6lo-dect-ule.all@ietf.org" Thread-Topic: Review of draft-ietf-6lo-dect-ule-08 Thread-Index: AQHSTLxu1C7wFwQzMUGYIZ37fEFByqEJKQ8w Date: Thu, 15 Dec 2016 22:05:04 +0000 Message-ID: References: <87polal1ec.fsf@latte.josefsson.org> In-Reply-To: <87polal1ec.fsf@latte.josefsson.org> Accept-Language: da-DK, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jtp@rtx.dk; x-originating-ip: [77.68.246.85] x-ms-office365-filtering-correlation-id: 74a78b5c-4b65-4beb-0cb9-08d425366cdc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0401MB2594; x-microsoft-exchange-diagnostics: 1; AM5PR0401MB2594; 7:0IFX7RX25V2WEB1S3qVjxj7P6V5DY/5kHpAhG42F9MbwUO8L1Hg96DbO5nx2zOAyqdUuIUENJHSCeH95cfeBbIpqKnvFN4As5wRz88R12OwtubCRNu6EFjvBSLp+FbjvuTfkV+Lhw3mnHvcHohOXXNn4b9vJCdxheGoOEyy0NXFYTNrsMmPaR0CaIULW20nCZENjFzObVKhuxvsc/hc3As04VyAbCRWRQkDmBUVBsIKNHMHtZJS5ktTPXDE21wqxYJ7VtwVsj3xeNMgt4KJu/DUX9hkuRAvRefUrJiaIp/PnL7w9dsvEjFWar+hx+pVfv2vJKcGLNyx2VN5xRpB3iB80SvJSVAgXG172ewEhvjLl/4xJsnQZkte9T9jSdid0dwbUMM3KAKpxCcJEHUBavKzht/hkPyxhryAlfYhTmjMTw11eGIexcAY2k0YCd3KFAhv13zpWLMGv8tLRQQvR1w== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148)(6047074); SRVR:AM5PR0401MB2594; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0401MB2594; x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39840400002)(39850400002)(39410400002)(39450400003)(199003)(66654002)(189002)(13464003)(38730400001)(77096006)(5660300001)(76576001)(106356001)(229853002)(76176999)(74482002)(122556002)(68736007)(66066001)(2501003)(6506006)(25786008)(50986999)(2950100002)(54356999)(106116001)(92566002)(101416001)(9686002)(81166006)(33656002)(81156014)(8936002)(7736002)(3660700001)(2900100001)(7696004)(2906002)(8676002)(74316002)(3846002)(102836003)(6436002)(5001770100001)(305945005)(2201001)(6116002)(86362001)(189998001)(107886002)(97736004)(3280700002)(105586002)(230783001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0401MB2594; H:AM5PR0401MB2595.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: rtx.dk does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rtx.dk X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2016 22:05:05.0074 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9a968248-e61d-46fd-b8d1-5c62247712e5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0401MB2594 Archived-At: Subject: Re: [secdir] Review of draft-ietf-6lo-dect-ule-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 22:05:11 -0000 Hi Simon, Many thanks for your review. See my comments and answers inline below. Best regards, Jens -----Original Message----- From: Simon Josefsson [mailto:simon@josefsson.org]=20 Sent: 2. december 2016 17:52 To: iesg@ietf.org; secdir@ietf.org; draft-ietf-6lo-dect-ule.all@ietf.org Subject: Review of draft-ietf-6lo-dect-ule-08 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 describes how to transmit IPv6 packets over DECT ULE using 6LoWPA= N. The document contains a good introduction to DECT, which is particulary= helpful to the IETF community. The security consideration already mention= s the privacy concern related to link-level MAC addresses, which is somethi= ng that would otherwise would be easy to criticize. The document uses acro= nyms which makes it difficult to read but the document strikes me as well w= ritten and well thought out anyway. I believe the document is Ready with Nits. Major nits: 1) Security Considerations. I believe the document should state that IPv6 traffic transmitted over DECT ULE should be protected using normal IET= F protocols (e.g., IPSEC or TLS) when there is a need for security. The text says DECT ULE is secured using AES-CCM keyed from the DECT ULE pai= ring, implying that this offers some security. The document does not expla= in (or inspire confidence) that the pairing process of DECT ULE has suffici= ent entropy as input to provide good link-level security, nor that it is ba= sed on any well established protocol. A word or two about this would be in= formative, but not really required. The process may be completely secure, = but it may also not be. I don't recall any link layer security protocol th= at haven't had a significant security problem in the past. Regardless, I b= elieve it is warranted to safeguard readers that they should not consider D= ECT ULE transport a secure transport for protecting data at the transport a= nd/or application level. Implementers need to employ transport and/or appl= ication-level security like IPSEC/TLS/CMS/OpenPGP as well. To address my c= oncern, I suggest to add the following after the third paragraph: While DECT ULE offer some link-layer security properties, the transport of data over DECT ULE may require additional transport protocol, or application protocol, security guarantees. When there is a need, the use of IPSEC [RFC XXXX], TLS [RFC YYYY], CMS [RFC ZZZZ], OpenPGP [RFC QQQQ] or similar security protocols, are recommended. [Jens]: I have added more information and recommendation in new revision -0= 9 Minor nits: A) Spell out DECT in the abstract and title. In the introduction section, = change 'DECT (Digital Enhanced Cordless Telecommunications)' into 'Digital Enhanced Cordless Telecommunications (DECT)'. [Jens]: I prefer to keep the title, but change the abstract and introductio= n as you suggested. Cheers, /Simon From nobody Thu Dec 15 15:55:05 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A332129AE1; Thu, 15 Dec 2016 15:55:04 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQV3t3B_G2mJ; Thu, 15 Dec 2016 15:55:02 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 A154A129ADA; Thu, 15 Dec 2016 15:55:02 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id 3so7678955uaz.3; Thu, 15 Dec 2016 15:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VY33MIUd7EEUW5f6Y33BerzsXZEpSwcg6WSYmgrtBaE=; b=MVPXF3eDrNUkRxjZdY0LXJna1dJA4KuPSY2Oriw2nqjyQ+oTvto1eJEATyKHF8fmIg Az+Q9xc+22ArLrKhB5Wm2ZK4vCBB6WHU9erM/FXnoCxYimGTQJfLrnqFE2tABuH0bAor j3u5H6qPXMFr1NjFmBYH8e4Cd1sD+gxaq/2TBA54rEMrJvKOmyjs3J0oJon9nGjLnYqK C7CMFDOqUZ1HOaXlrJkmrVBJqA5iSyth8nO8Iy2tnhh/1ta599CWGgGKnCE1NVd/e13D pq5VC7J0MyrqBuHoTfPK5KzxmcGh+eZLU7JzVSiEoB2vLnen+qf0ul/vJHLyifJW2oP/ C+VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VY33MIUd7EEUW5f6Y33BerzsXZEpSwcg6WSYmgrtBaE=; b=jmz7mcOCHV9iAdqW/4+nQXX4LPY8B2Qwk8XCoLCn+C+KehJQVXGIMT04yCG9mvCjyz OY8Snz5OghdMCmWaw+yLjZ/Gxizwb46r6c8RiWDxSQo8n0ZMkT2iOh1ZEIGfbc/DFm87 NsknS0fMeln2QFhP/9EhfMfO/ujnxvwogkHkQTVNpCCxjwZMs2RlAlKWy2hq7srR9Qpv rbrC5fByhix8u3u9HLSCb24dBIO/636bGYT/ZpZv9CK5Z4gSjIcwfwJMbxdvM18ct3J9 UOKj8VWQf1hQumu3+TDHnnnNqqhT6oUoIj3MhnsL/6QMfefe8xKzreEZOXAMEPbRjGRU 2F6A== X-Gm-Message-State: AIkVDXKZGZTIWk6T61e9CvrRc1+R7+w2T7wca6DnlkYvRJKhepU/2G833YG2sa9WLNLcpaj1pEulQMi9M1zrhQ== X-Received: by 10.176.68.68 with SMTP id m62mr135428uam.65.1481846101756; Thu, 15 Dec 2016 15:55:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.36.203 with HTTP; Thu, 15 Dec 2016 15:55:01 -0800 (PST) From: Radia Perlman Date: Thu, 15 Dec 2016 18:55:01 -0500 Message-ID: To: "secdir@ietf.org" , The IESG , draft-snijders-idr-deprecate-30-31-129.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a114c14a481d05e0543bb2e3d Archived-At: Subject: [secdir] Secdir review of draft-snijders-idr-deprecate-30-31-129-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 23:55:04 -0000 --001a114c14a481d05e0543bb2e3d Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This very brief document simply notes that people have been using unassigned BGP path attribute values, and thus "Per this document, IANA has marked the BGP Path Attributes registry entries for values 30, 31, 129 as "deprecated"." As the document correctly states, there are no security considerations for this. Radia --001a114c14a481d05e0543bb2e3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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

This very = brief document simply notes that people have been using unassigned BGP path= attribute values, and thus "Per this document, IANA has marked the BGP Path Attribut= es registry
   entries for va=
lues 30, 31, 129 as "deprecated"."

As the documen= t correctly states, there are no security considerations for this.

Ra= dia

=C2=A0

--001a114c14a481d05e0543bb2e3d-- From nobody Fri Dec 16 08:13:16 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7129112A03D; Fri, 16 Dec 2016 08:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYR0DPeaxcaO; Fri, 16 Dec 2016 08:13:11 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8116612A117; Fri, 16 Dec 2016 08:08:45 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uBGG8guR009265 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 Dec 2016 18:08:42 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uBGG8fRp015774; Fri, 16 Dec 2016 18:08:41 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22612.4489.659549.39031@fireball.acr.fi> Date: Fri, 16 Dec 2016 18:08:41 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-6tisch-minimal.all@tools.ietf.org, 6tisch@ietf.org X-Edit-Time: 89 min X-Total-Time: 135 min Archived-At: Subject: [secdir] Secdir review of draft-ietf-6tisch-minimal-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 16:13:13 -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 is my extra security review of this draft, this document was also assigned another security reviewer, but as I am very familiar with 802.15.4-2015 I wanted to review this document also. This draft explains how the IEEE Std 802.15.4 TSCH mode can be used with IETF protocols, and what would be the minimal setup to get the network running so much that more complicated things can be done over it. This document has serious issues. First of all there is no security considerations section at all. There is section 4.6 which contains certain security related issues, but it mostly just lists the required security features (or misfeatures) but does not do any kind of security analysis. Secondly this document includes text suggesting fixed cryptographic key ("6TiSCH minimal15") which can be used to protect some parts of the 6TiSCH network. As there is no security considerations there is no analysis what attacker can do when it knows this key K1. We have seen several attacks lately against IoT devices where attackers have found out the default admin key and used it to attack the network. By proposing static fixed key in the RFC it gives indication that such setup might be secure, thus vendors implementing this might do similar thing, and use fixed key. As this key would be known by everybody joining the network, it will not stay secret, and that will mean it will leak out and it does not protect anything anymore. This document should require that both K1 and K2 keys MUST be unique to the network and the bootstrapping procedures specified later (there is already work ongoing in the 6TiSCH WG to do them) will be used to distribute them to new joining nodes. ---------------------------------------------------------------------- Another major issue is that the section 4.6 also forbids using any clear text frames, even for the joining process. This will make it impossible to actually to run the bootstrap procedure over the same network that will be used later for normal traffic. The IEEE Std 802.15.4 do allow exemptions so that nodes which have configured security to be on for all frames, can temporarely receive clear text frames from the certain nodes just for this kind of joining procedures. This document does not explain how they can be used, and actually forbids using them. ---------------------------------------------------------------------- The missing security section should include at least following information: - If attacker knows the K1 key, what kind of damage can it do. This is especially important even if unique keys are used per network, as those keys might be shared using weak methods and might be short to make the setup easy. Even if we say in this document that static K1 MUST NOT be used, people are going to use it, so we need to tell implementors what the attackers can then do. - Most likely also explain that running networks might not want to accept completely new set of parameters through the EBs even if they are authenticated, and perhaps suggest that the whole networks is first shut down before new set parameters are taken in to use. - Explain that using static key is never safe if there is possibility that the network might be restarted, as the security of the AES CCM relies on that the ASN never goes back (which might happen if the network is restarted). - Explain that 802.15.4 link security do provide authentication and encryption, but it DOES NOT provide replay protection for the TSCH mode. This means that all protocols run over 802.15.4 TSCH network must provide replay protection themselves. There might be others, but this came to my mind in few minutes of thinking this issue. ---------------------------------------------------------------------- Other serious issues are (and actually some of the things above in more detail): -- Section 4.6 has text saying that: All link-layer frames MUST be secured by the link-layer security mechanisms defined in IEEE802.15.4 [IEEE802154-2015]: link-layer authentication and link-layer encryption. Enhanced Beacons cannot have link-encryption as the joining node needs to be able to see the ASN contained in the payload IE. Thus Enhanced Beacons MUST be authenticated, but MUST NOT be encrypted. All other frames MUST be both encrypted and authenticated. Also the initial joining node does not know the K1 nor K2, thus it cannot use link-layer security mechanisms at all, thus this paragraph is completely wrong. Remove this whole paragraph. -- Section 4.6 has text saying: Key K1 is used to authenticate EBs. As defined in Section 4.5.2, EBs MUST be authenticated only (no encryption). This facilitates logical segregation of distinct networks. This is also wrong. Firstly the 4.5.2 does not define that EBs MUST be authenticated. Perhaps it is trying to say that "EBs, as defined in section 4.5.2, MUST be authenticated only (no encryption)." The last sentence "This facilitates logical segregation of distinct networks." does not have any meaning. The extended address and the PAN ID of the coordinator sending EB, will tell which network this is. The K1 is not visible in the frames, thus it cannot provide logical segregation. If unique K1 key is used for every single network, it can provide good way of verifying that the node sending the EB is part of the same network than the receiving node. I would just remove the last sentence. -- Section 4.6 has text saying: For early interoperability testing, value 36 54 69 53 43 48 20 6D 69 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15") MAY be used for K1. This text does not belong to this document at all. We do have policy saying we do not do clear text passwords in the IETF, and having fixed password in clear in the RFC do count as clear text password at least for me. Also if we provide any key in the RFC, the changes are that most implementations will simply use that key, meaning the K1 does not provide any protection at all after that. Remove the whole section, or if you want to keep it, then replace the title of the section to "Link-Layer Insecurity", and add note in the abstract telling that this document proposes insecure way of doing things. Note, that K1 is used to authenticate the EB, thus anybody who knows the K1, can start sending fake EB messages, and mess up the network by changing the channel offsets or similars, i.e., knowning K1 will provide very easy way of doing DoS attack against the whole network, and the network will most likely need to be completely reformed before the single packet DoS attack is recovered. Also early interoperability testing keys should be agreed with the people doing interoperability testings, or in the interoperability events, not in the drafts or RFCs. ---------------------------------------------------------------------- Nits, and smaller issues: -- I think IEEE wants that their standards are referenced as "IEEE Std 802.15.4", not IEEE802.15.4. Might be good idea to replace use that, and if shorter version is needed just add "802.15.4" to terminology and define it to mean IEEE Std 802.15.4, and then use the shorter version in rest o fthe document. We would not want people to write "RFC.6550", as that would just look funny... -- In this document the term "Slotframe length" is used to specify the number of timeslots in slotframe. All other documents (802.15.4-2015, 802.15.4e-2012 and draft-ietf-6tisch-terminology-07) use term "Slotframe size" for that. See IEEE Std 802.15.4-2015 section 7.4.4.3 TSCH Slotframe and Link IE. Why not use same term for the same thing? -- IEEE Std 802.15.4-2015 also section 7.4.4.3 TSCH Slotframe and Link IE also has field called "Number of Links", which match Number of scheduled cells (active) in Figure 1. Terminology document has both Cell and Link, and Link uses the IETF meaning of it, not the IEEE meaning of it. Should we provide both names for the field, especially as the Appendix A uses the IEEE naming. Same for other names (slotOffset == Timeslot, chOffset == Channel Offset). Also the IEEE Std 802.15.4-2015 moved away from using link Options as hex number (0x0f), and instead lists the separate bit-fields in it (tx, rx, shared, timekeeping), as does the Appendix A. Also as slotOffset/Timeslot and chOffset/Channel Offset are 16-bit numbers, it might be better to express them as 0x0000 instead of 0x00. The macLinkType is bit funny as it is one TSCH MAC PIB attribute in per link structure in macLinkTable. It might be better to refer it as LinkType given to the MLME-SET-LINK.request primitive, which will then create the new entry for the macLinkTable and fill in the values given to the primitive. Note, that this value is not transmitted in the EB, it specifies that this link is used to send EBs. -- In Figure 2 the legend specifies TX and RX, but the actual figure uses Tx and Rx. Change the legend to use Tx and Rx too. -- In the section 4.5.1 the reference to the IEEE Std 802.15.4-2015 is wrong. The value of the PAN ID compression bit is not in the Table 7-6, but is Table 7-2. I.e. change The value of the PAN ID Compression bit is specified in Table 7-6 of the IEEE802.15.4 2015 specification, and depends on the type of the destination and source link-layer addresses (short, extended, not present). to: The value of the PAN ID Compression bit is specified in Table 7-2 of the IEEE Std 802.15.4-2015 specification, and depends on the type of the destination and source link-layer addresses (short, extended, not present). (also change the 802.15.4 2015 to 802.15.4-2015). -- The text While listening for EBs, a joining node set its own PAN ID to 0xffff in order to meet the filtering rules in the IEEE802.15.4 specification [IEEE802154-2015]. is wrong and should be removed. The IEEE Std 802.15.4-2011 required setting PAN ID to 0xffff when doing active or passive scan, but that kludge was removed in the IEEE Std 802.15.4-2015, and now the filtering rules specifically checks whether we are doing scanning and if so, we do not do normal filtering rules, but do special filtering rules needed for scanning. -- Typo in 4.5.2 the TSCH Slotframe and Link IE is misspelled with SlotFrame. Replace SlotFrame with Slotframe. -- In section 7.2 there is text saying: Frame types BEACON and COMMAND are queued with higher priority than frame types DATA and ACK. This is wrong. The ACK is sent inside the same timeslot than the frame it is acking to. It is never sent through queue. Remove the "and ACK" from the sentence. -- In the appendix the examples have mostly the same field names than in the IEEE Std 802.15.4-2015, but some of the fields have bit different spelliongs. Is there reason for this? Spelling changes: "GroupID" vs "Group ID" "SubID" vs "Sub-ID" (all MLME IEs) "TimeSlot" vs "Timeslot" "TimeSlot template ID" vs "Timeslot ID" "Ch. Hopping" vs "Channel Hopping" "Channel Hopping Sequence ID" vs "Hopping Sequence ID" "SlotFrame Handle" vs "Slotframe handle" "SlotFrame Size" vs "Slotframe size" "Link Option" vs "Link Options" "tx,rx,shared,timekeeping" vs "TX Link, RX Link, Shared Link, Timekeeping" -- In the A.4 example the example uses old name for the bit 6, i.e. the "Frame Counter Size" was renamed to "ASN in Nonce" in 802.15.4-2015 to better reflect what it really means. -- kivinen@iki.fi From nobody Fri Dec 16 23:02:08 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D562129452; Fri, 16 Dec 2016 23:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.896 X-Spam-Level: X-Spam-Status: No, score=-9.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 HFSFsqNzrchj; Fri, 16 Dec 2016 23:01:49 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A885129555; Fri, 16 Dec 2016 23:01:49 -0800 (PST) Received: from zimbra.rfc1925.org (calcifer.labs.nic.cz [217.31.192.138]) by mail.nic.cz (Postfix) with ESMTP id A53886094A; Sat, 17 Dec 2016 08:01:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1481958107; bh=UVGXi5RusZjFr3BlmDxFTN++IWScuuxHFt84KpFaLKg=; h=Date:From:To; b=QYntcLkvsEAfoqBxYpznLFZ8W3fHxk+VDLhCZR8GrGjSkefAjTX7cPA08EOZaSkm9 TLFNw0hHVZ95NOnQYSpfRAUoG3Kx8j0W05FRrUYXlpTFQknwimFVQ7DNWYEPwt2xdc 2dXuGl3y3gTQ5OQjz80YMFW63q1CWhlpYrcF8CxM= Date: Sat, 17 Dec 2016 08:01:47 +0100 (CET) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= To: Magnus =?utf-8?Q?Nystr=C3=B6m?= , Dan Romascanu , Tim Chown Message-ID: <2109497203.7399.1481958107415.JavaMail.zimbra@nic.cz> In-Reply-To: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> References: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [217.31.192.138] X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - SAF10 (Linux)/8.7.0_GA_1659) Thread-Topic: Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) Thread-Index: LzflipimV17IlkcBn4a2Ul/QhkSYmDP6HbRZ X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: curdle , ietf , secdir , gen-art , ops-dir@ietf.org, draft-ietf-curdle-dnskey-eddsa.all@ietf.org Subject: Re: [secdir] Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 07:01:51 -0000 Hi all, the IETF review has ended, so I have uploaded -03 version. Magnus, Dan, the -03 version addresses all your comments. Tim, I left the irtf documents in Normative as per Stephan's comments. I believe that Section 8 correctly references IANA registry: http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xht= ml by its name. The paragraph with nit has been removed altogether per Magnus's request. Thank you all very much for the reviews. Cheers, -- Ond=C5=99ej Sur=C3=BD -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: "Ond=C5=99ej Sur=C3=BD" > To: "Magnus Nystr=C3=B6m" , "Dan Romascanu" > Cc: "secdir" , "draft-ietf-curdle-dnskey-eddsa" , "gen-art" > , "ietf" , "curdle-chairs" , "curdle" > Sent: Monday, 12 December, 2016 10:38:35 > Subject: Re: Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir= review of draft-ietf-curdle-dnskey-eddsa-02) > Magnus and Dan, >=20 > thanks for the review. >=20 > Magnus, you are right, I have removed the first full paragraph > about "security properties" from Security Considerations > from my git version as the security properties of EdDSA > are better described in Normative references anyway. >=20 > https://gitlab.labs.nic.cz/labs/ietf/commit/7b52c8e2bbe44042a279a81b96027= 0fdd103d9a2 >=20 > Dan, >=20 > good catches, I fixed the nits in the git: >=20 > https://gitlab.labs.nic.cz/labs/ietf/commit/bbfc7ce43fb1f46c91fb7f5de564d= 907d035aadf >=20 > I would be happy to upload next revision after Last Call > is finished or just let the RFC editors to fix it. >=20 > Cheers, > -- > Ond=C5=99ej Sur=C3=BD -- Technical Fellow > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.sury@nic.cz https://nic.cz/ > -------------------------------------------- >=20 > ----- Original Message ----- >> From: "Magnus Nystr=C3=B6m" >> To: secdir@ietf.org, "draft-ietf-curdle-dnskey-eddsa" >> >> Sent: Monday, 12 December, 2016 02:44:18 >> Subject: Secdir review of draft-ietf-curdle-dnskey-eddsa-02 >=20 >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >>=20 >> This document describes how to use two two specific Edwards Curves >> (Elliptic Curves) in conjunction with DNSSEC, namely ed25519 and >> ed448. >>=20 >> The only comment I have on this document is that the Security >> Considerations section plainly states, without any reference or proof: >>=20 >> "Ed25519 and Ed448 offers improved security properties and >> implementation characteristics compared to RSA and ECDSA algorithms" >>=20 >> I suggest either adding references to proofs of these statements or >> alternatively just remove the sentence (since it doesn't really add >> anything to the memo); the remaining paragraphs in the Security >> Considerations section is what really covers what someone implementing >> the memo should know or be aware of. >>=20 >> -- Magnus >=20 > ~~~~ >=20 > ----- Original Message ----- >> From: "Dan Romascanu" >> To: gen-art@ietf.org >> Cc: "draft-ietf-curdle-dnskey-eddsa all" >> , "curdle" , >> ietf@ietf.org >> Sent: Sunday, 11 December, 2016 12:21:25 >> Subject: Review of draft-ietf-curdle-dnskey-eddsa-02 >=20 >> Reviewer: Dan Romascanu >> Review result: Ready with Nits >>=20 >> Summary: Ready, with nits >>=20 >> I am not an expert in this field, but the document seems to meet its >> goals, it's clear and precise >>=20 >> Major issues: >>=20 >> Minor issues: >>=20 >> Nits/editorial comments: >>=20 >> 1. Section 4: s/Section5.1.7/Sections 5.1.7/ >>=20 >> 2. Section 8: 'The following entry has been added to >> the registry' - I may be wrong, but the section seems to define two > > new entries in the registry rather than one From nobody Fri Dec 16 23:11:18 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA95E1294E9; Fri, 16 Dec 2016 23:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joCzmFY3C1EL; Fri, 16 Dec 2016 23:11:05 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 56094129452; Fri, 16 Dec 2016 23:11:05 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id w33so106326376qtc.3; Fri, 16 Dec 2016 23:11:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4oo0PYw5wXkM+at8CMads1k/KxW6cuUBrhaJI5/frrw=; b=YdjkC43E0ZyG8q334vTRMEe+egHHTqqUodT7AXKzJCGG3mGxqenzNFPE+aEM08zyo5 Hl+9ElUO2a+skC2zZCQS3063UlU286dsqlqy9EZ1mFuuYvlnevflHk3nfX2XfAoXsk0w noSoqWxiOd8il+MA5mhSqYao7fsaOKa0xk/aIRG1xlY7t3P+eyDt5wKG9pyjqZ5Vixn5 GvT4YZJoqagq9xaKDwirY4t5bW4qzSo3UotNrJAKUuznSpEUdyKVrEyH0iraoLpXuXI9 /igTu4sXFND4+swEnIYUJhH1KVI7X3uBGNdo7+ePt3tJ4VUaCku5UaCPtnbrkNz8ePz4 kAXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4oo0PYw5wXkM+at8CMads1k/KxW6cuUBrhaJI5/frrw=; b=rfi+tKN08Q7pUDC1Oh0+AxH+sS6uIm3EDaJJWMIpHUSme22wM6ryScfYJYPUEVZ7cT Ka94FoCxDLf/Zovsw1hsJt60+3S7ChoC1KiVAiCBuBa5hOGhZNBkQprM9LvkZMB6nCi1 4YIClOaV9p3T9TWx1/4MJj+4LP3VEiRy7hJ5X50X45n1kLhNSaFJ12+kgUuKQGRYvCYd 0Do6iGTZPtwdcmMi3dDm14Ojmsd+yCVo732juPSj5u24bsBksqud/vORf4hCosxWpCvP /t0P4dfYnF0e7yLJR6urfZC4gjTnloRXOro8zXDnh6z4p0iC5q6/2hzi8dHdT6LA1IXN PqNA== X-Gm-Message-State: AIkVDXIGouwLPbeCEZ9T78LjignZY/kDRK5JHvsdv3PuLHQ/b6Sd6DigfCSXb8Z+t/jgluuaYmN0yhCy5/WpdQ== X-Received: by 10.200.48.44 with SMTP id f41mr6234013qte.94.1481958664421; Fri, 16 Dec 2016 23:11:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.40.114 with HTTP; Fri, 16 Dec 2016 23:11:03 -0800 (PST) In-Reply-To: <2109497203.7399.1481958107415.JavaMail.zimbra@nic.cz> References: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> <2109497203.7399.1481958107415.JavaMail.zimbra@nic.cz> From: Dan Romascanu Date: Sat, 17 Dec 2016 09:11:03 +0200 Message-ID: To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=001a1137aa56c3c6d40543d563e3 Archived-At: Cc: ops-dir@ietf.org, ietf , secdir , gen-art , curdle , Tim Chown , draft-ietf-curdle-dnskey-eddsa.all@ietf.org Subject: Re: [secdir] Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 07:11:08 -0000 --001a1137aa56c3c6d40543d563e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for addressing my comments. Regards, Dan On Sat, Dec 17, 2016 at 9:01 AM, Ond=C5=99ej Sur=C3=BD = wrote: > Hi all, > > the IETF review has ended, so I have uploaded -03 version. > > Magnus, Dan, > > the -03 version addresses all your comments. > > Tim, > > I left the irtf documents in Normative as per Stephan's comments. > > I believe that Section 8 correctly references IANA registry: > http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers. > xhtml > by its name. > > The paragraph with nit has been removed altogether per Magnus's request. > > Thank you all very much for the reviews. > > Cheers, > -- > Ond=C5=99ej Sur=C3=BD -- Technical Fellow > -------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Milesovska 5, 130 00 Praha 3, Czech Republic > mailto:ondrej.sury@nic.cz https://nic.cz/ > -------------------------------------------- > > ----- Original Message ----- > > From: "Ond=C5=99ej Sur=C3=BD" > > To: "Magnus Nystr=C3=B6m" , "Dan Romascanu" < > dromasca@gmail.com> > > Cc: "secdir" , "draft-ietf-curdle-dnskey-eddsa" < > draft-ietf-curdle-dnskey-eddsa@ietf.org>, "gen-art" > > , "ietf" , "curdle-chairs" < > curdle-chairs@ietf.org>, "curdle" > > Sent: Monday, 12 December, 2016 10:38:35 > > Subject: Re: Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: > Secdir review of draft-ietf-curdle-dnskey-eddsa-02) > > > Magnus and Dan, > > > > thanks for the review. > > > > Magnus, you are right, I have removed the first full paragraph > > about "security properties" from Security Considerations > > from my git version as the security properties of EdDSA > > are better described in Normative references anyway. > > > > https://gitlab.labs.nic.cz/labs/ietf/commit/ > 7b52c8e2bbe44042a279a81b960270fdd103d9a2 > > > > Dan, > > > > good catches, I fixed the nits in the git: > > > > https://gitlab.labs.nic.cz/labs/ietf/commit/ > bbfc7ce43fb1f46c91fb7f5de564d907d035aadf > > > > I would be happy to upload next revision after Last Call > > is finished or just let the RFC editors to fix it. > > > > Cheers, > > -- > > Ond=C5=99ej Sur=C3=BD -- Technical Fellow > > -------------------------------------------- > > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > > Milesovska 5, 130 00 Praha 3, Czech Republic > > mailto:ondrej.sury@nic.cz https://nic.cz/ > > -------------------------------------------- > > > > ----- Original Message ----- > >> From: "Magnus Nystr=C3=B6m" > >> To: secdir@ietf.org, "draft-ietf-curdle-dnskey-eddsa" > >> > >> Sent: Monday, 12 December, 2016 02:44:18 > >> Subject: Secdir review of draft-ietf-curdle-dnskey-eddsa-02 > > > >> I have reviewed this document as part of the security directorate's > >> ongoing effort to review all IETF documents being processed by the > >> IESG. These comments were written primarily for the benefit of the > >> security area directors. Document editors and WG chairs should treat > >> these comments just like any other last call comments. > >> > >> This document describes how to use two two specific Edwards Curves > >> (Elliptic Curves) in conjunction with DNSSEC, namely ed25519 and > >> ed448. > >> > >> The only comment I have on this document is that the Security > >> Considerations section plainly states, without any reference or proof: > >> > >> "Ed25519 and Ed448 offers improved security properties and > >> implementation characteristics compared to RSA and ECDSA algorithms" > >> > >> I suggest either adding references to proofs of these statements or > >> alternatively just remove the sentence (since it doesn't really add > >> anything to the memo); the remaining paragraphs in the Security > >> Considerations section is what really covers what someone implementing > >> the memo should know or be aware of. > >> > >> -- Magnus > > > > ~~~~ > > > > ----- Original Message ----- > >> From: "Dan Romascanu" > >> To: gen-art@ietf.org > >> Cc: "draft-ietf-curdle-dnskey-eddsa all" > >> , "curdle" < > curdle@ietf.org>, > >> ietf@ietf.org > >> Sent: Sunday, 11 December, 2016 12:21:25 > >> Subject: Review of draft-ietf-curdle-dnskey-eddsa-02 > > > >> Reviewer: Dan Romascanu > >> Review result: Ready with Nits > >> > >> Summary: Ready, with nits > >> > >> I am not an expert in this field, but the document seems to meet its > >> goals, it's clear and precise > >> > >> Major issues: > >> > >> Minor issues: > >> > >> Nits/editorial comments: > >> > >> 1. Section 4: s/Section5.1.7/Sections 5.1.7/ > >> > >> 2. Section 8: 'The following entry has been added to > >> the registry' - I may be wrong, but the section seems to define two > > > new entries in the registry rather than one > --001a1137aa56c3c6d40543d563e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for addressing my comments.

Regards,

Dan


<= div class=3D"gmail_quote">On Sat, Dec 17, 2016 at 9:01 AM, Ond=C5=99ej Sur= =C3=BD <ondrej.sury@nic.cz> wrote:
Hi all,

the IETF review has ended, so I have uploaded -03 version.

Magnus, Dan,

the -03 version addresses all your comments.

Tim,

I left the irtf documents in Normative as per Stephan's comments.

I believe that Section 8 correctly references IANA registry:
http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml by its name.

The paragraph with nit has been removed altogether per Magnus's request= .

Thank you all very much for the reviews.

Cheers,
--
=C2=A0Ond=C5=99ej Sur=C3=BD -- Technical Fellow
=C2=A0--------------------------------------------
=C2=A0CZ.NIC, z.s.p.o.=C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0Laborato=C5=99e C= Z.NIC
=C2=A0Milesovska 5, 130 00 Praha 3, Czech Republic
=C2=A0mailto:ondrej.sury@nic.cz= =C2=A0 =C2=A0 https://nic.cz/
=C2=A0--------------------------------------------

----- Original Message -----
> From: "Ond=C5=99ej= Sur=C3=BD" <ondrej.sury@nic.= cz>
> To: "Magnus Nystr=C3=B6m" <magnusn@gmail.com>, "Dan Romascanu" <dromasca@gmail.com>
> Cc: "secdir" <secdir@i= etf.org>, "draft-ietf-curdle-dnskey-eddsa" <draft-ietf-curdle-dnsk= ey-eddsa@ietf.org>, "gen-art"
> <gen-art@ietf.org>, &quo= t;ietf" <ietf@ietf.org>, &q= uot;curdle-chairs" <curdl= e-chairs@ietf.org>, "curdle" <curdle@ietf.org>
> Sent: Monday, 12 December, 2016 10:38:35
> Subject: Re: Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was= : Secdir review of draft-ietf-curdle-dnskey-eddsa-02)

> Magnus and Dan,
>
> thanks for the review.
>
> Magnus, you are right, I have removed the first full paragraph
> about "security properties" from Security Considerations
> from my git version as the security properties of EdDSA
> are better described in Normative references anyway.
>
> https://git= lab.labs.nic.cz/labs/ietf/commit/7b52c8e2bbe44042a279a81b960270fdd103d9a2
>
> Dan,
>
> good catches, I fixed the nits in the git:
>
> https://git= lab.labs.nic.cz/labs/ietf/commit/bbfc7ce43fb1f46c91fb7f5de564d907d035aadf
>
> I would be happy to upload next revision after Last Call
> is finished or just let the RFC editors to fix it.
>
> Cheers,
> --
> Ond=C5=99ej Sur=C3=BD -- Technical Fellow
> --------------------------------------------
> CZ.NIC, z.s.p.o.=C2=A0 =C2=A0 --=C2=A0 =C2=A0 =C2=A0Laborato=C5=99e CZ= .NIC
> Milesovska 5, 130 00 Praha 3, Czech Republic
> mailto:ondrej.sury@nic.cz=C2= =A0 =C2=A0 https://nic.cz/
> --------------------------------------------
>
> ----- Original Message -----
>> From: "Magnus Nystr=C3=B6m" <magnusn@gmail.com>
>> To: secdir@ietf.org, "= draft-ietf-curdle-dnskey-eddsa"
>> <dra= ft-ietf-curdle-dnskey-eddsa@ietf.org>
>> Sent: Monday, 12 December, 2016 02:44:18
>> Subject: Secdir review of draft-ietf-curdle-dnskey-eddsa-02 >
>> I have reviewed this document as part of the security directorate&= #39;s
>> ongoing effort to review all IETF documents being processed by the=
>> IESG. These comments were written primarily for the benefit of the=
>> security area directors. Document editors and WG chairs should tre= at
>> these comments just like any other last call comments.
>>
>> This document describes how to use two two specific Edwards Curves=
>> (Elliptic Curves) in conjunction with DNSSEC, namely ed25519 and >> ed448.
>>
>> The only comment I have on this document is that the Security
>> Considerations section plainly states, without any reference or pr= oof:
>>
>> "Ed25519 and Ed448 offers improved security properties and >> implementation characteristics compared to RSA and ECDSA algorithm= s"
>>
>> I suggest either adding references to proofs of these statements o= r
>> alternatively just remove the sentence (since it doesn't reall= y add
>> anything to the memo); the remaining paragraphs in the Security >> Considerations section is what really covers what someone implemen= ting
>> the memo should know or be aware of.
>>
>> -- Magnus
>
> ~~~~
>
> ----- Original Message -----
>> From: "Dan Romascanu" <dromasca@gmail.com>
>> To: gen-art@ietf.org
>> Cc: "draft-ietf-curdle-dnskey-eddsa all"
>> <draft-ietf-curdle-dnskey-eddsa.all@ietf.org>, "curdle&quo= t; <curdle@ietf.org>,
>> ietf@ietf.org
>> Sent: Sunday, 11 December, 2016 12:21:25
>> Subject: Review of draft-ietf-curdle-dnskey-eddsa-02
>
>> Reviewer: Dan Romascanu
>> Review result: Ready with Nits
>>
>> Summary: Ready, with nits
>>
>> I am not an expert in this field, but the document seems to meet i= ts
>> goals, it's clear and precise
>>
>> Major issues:
>>
>> Minor issues:
>>
>> Nits/editorial comments:
>>
>> 1. Section 4: s/Section5.1.7/Sections 5.1.7/
>>
>> 2. Section 8: 'The following entry has been added to
>>=C2=A0 =C2=A0the registry' - I may be wrong, but the section se= ems to define two
> > new entries in the registry rather than one

--001a1137aa56c3c6d40543d563e3-- From nobody Sat Dec 17 09:15:05 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F2E129866; Sat, 17 Dec 2016 09:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHqSxy3qylc7; Sat, 17 Dec 2016 09:14:54 -0800 (PST) Received: from mail-yw0-f196.google.com (mail-yw0-f196.google.com [209.85.161.196]) (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 42A981296D6; Sat, 17 Dec 2016 09:14:54 -0800 (PST) Received: by mail-yw0-f196.google.com with SMTP id a10so6052839ywa.1; Sat, 17 Dec 2016 09:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LbAV1cxEwPPyTUwS9uuFVdb9XbKSn4yB9LbDqrvBaiM=; b=D5XZW4RCKNwNeQKomO0Fn3vq8B6ThYMPSaJqQDs0nZaRQMystwZfeOpDrwtm50tVry kaRxolf4FJvsOKz+qoj1l1EAYnAkIWjWliKUx5JkzQX8sh3YX1C9n0yyPDq0yMbVJKIw crCm4zUlzIgYtWrp++RfrTs+tXgw5qyCGjumUgz0WndCqQ6qGSOqv/ElQ1hY8zbEhBlH 5c0WZBopfZxc7lEMMjSnNs5L3jPKPFi/bHfyNuwnVOaCNzscmwZEykI1HGfBYS6f1M8N 6UalcB7qw9SPm+nOqZpvMC9u1IKjurvoOxgq7NcQzWFu0BvnMejBrDHN0uAt1hZARuvg SjrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LbAV1cxEwPPyTUwS9uuFVdb9XbKSn4yB9LbDqrvBaiM=; b=SEUM5IGQM02x4uFWWZn738es1epr6Zvupjkr5im4e4Z3vlApP585qplvKx2+QUN2Ya bmhs8fRMjv6HGzfYa2ivoZUjTYaonc1NNjHFg5+3Q6EY7ems5k1EtODYWL8ghWY16nqA YHtqkJhMjFWUchHJRAFdSFIZFDOXb9+9Q8eB2ZI8/JVDvQzux+q//kfoRtsvclsPxPPp Hu981HXPkDXG5ED7Bjc5497Iy2PtgPF2cx3SGxbp/866o1//6lbk8kMlVc9bqo7ZgHBp kD2IF4XCGp3/74QQsTpmcG5sUYslAv/SkuWb9PBByFWZAOTQqkdMZeIEwQgMTziYCCow F7Sg== X-Gm-Message-State: AKaTC030woaZfflgUF2m2K+w/Jn8w9kDH1sIEDSxTCwAhS+ChYmaaetGbnf6EY1aOYn25UQM6Oxp6Yra9PyO+w== X-Received: by 10.129.90.67 with SMTP id o64mr6518158ywb.188.1481994833385; Sat, 17 Dec 2016 09:13:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.195.195 with HTTP; Sat, 17 Dec 2016 09:13:52 -0800 (PST) In-Reply-To: References: <1432493802.4506.1481535515981.JavaMail.zimbra@nic.cz> <2109497203.7399.1481958107415.JavaMail.zimbra@nic.cz> From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Sat, 17 Dec 2016 09:13:52 -0800 Message-ID: To: Dan Romascanu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: ops-dir@ietf.org, ietf , secdir , gen-art , curdle , Tim Chown , draft-ietf-curdle-dnskey-eddsa.all@ietf.org, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Subject: Re: [secdir] Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: Secdir review of draft-ietf-curdle-dnskey-eddsa-02) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 17:14:55 -0000 Same here. Thank you! /M On Fri, Dec 16, 2016 at 11:11 PM, Dan Romascanu wrote: > Thank you for addressing my comments. > > Regards, > > Dan > > > On Sat, Dec 17, 2016 at 9:01 AM, Ond=C5=99ej Sur=C3=BD wrote: >> >> Hi all, >> >> the IETF review has ended, so I have uploaded -03 version. >> >> Magnus, Dan, >> >> the -03 version addresses all your comments. >> >> Tim, >> >> I left the irtf documents in Normative as per Stephan's comments. >> >> I believe that Section 8 correctly references IANA registry: >> >> http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.= xhtml >> by its name. >> >> The paragraph with nit has been removed altogether per Magnus's request. >> >> Thank you all very much for the reviews. >> >> Cheers, >> -- >> Ond=C5=99ej Sur=C3=BD -- Technical Fellow >> -------------------------------------------- >> CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC >> Milesovska 5, 130 00 Praha 3, Czech Republic >> mailto:ondrej.sury@nic.cz https://nic.cz/ >> -------------------------------------------- >> >> ----- Original Message ----- >> > From: "Ond=C5=99ej Sur=C3=BD" >> > To: "Magnus Nystr=C3=B6m" , "Dan Romascanu" >> > >> > Cc: "secdir" , "draft-ietf-curdle-dnskey-eddsa" >> > , "gen-art" >> > , "ietf" , "curdle-chairs" >> > , "curdle" >> > Sent: Monday, 12 December, 2016 10:38:35 >> > Subject: Re: Review of draft-ietf-curdle-dnskey-eddsa-02 (Als was: >> > Secdir review of draft-ietf-curdle-dnskey-eddsa-02) >> >> > Magnus and Dan, >> > >> > thanks for the review. >> > >> > Magnus, you are right, I have removed the first full paragraph >> > about "security properties" from Security Considerations >> > from my git version as the security properties of EdDSA >> > are better described in Normative references anyway. >> > >> > >> > https://gitlab.labs.nic.cz/labs/ietf/commit/7b52c8e2bbe44042a279a81b96= 0270fdd103d9a2 >> > >> > Dan, >> > >> > good catches, I fixed the nits in the git: >> > >> > >> > https://gitlab.labs.nic.cz/labs/ietf/commit/bbfc7ce43fb1f46c91fb7f5de5= 64d907d035aadf >> > >> > I would be happy to upload next revision after Last Call >> > is finished or just let the RFC editors to fix it. >> > >> > Cheers, >> > -- >> > Ond=C5=99ej Sur=C3=BD -- Technical Fellow >> > -------------------------------------------- >> > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC >> > Milesovska 5, 130 00 Praha 3, Czech Republic >> > mailto:ondrej.sury@nic.cz https://nic.cz/ >> > -------------------------------------------- >> > >> > ----- Original Message ----- >> >> From: "Magnus Nystr=C3=B6m" >> >> To: secdir@ietf.org, "draft-ietf-curdle-dnskey-eddsa" >> >> >> >> Sent: Monday, 12 December, 2016 02:44:18 >> >> Subject: Secdir review of draft-ietf-curdle-dnskey-eddsa-02 >> > >> >> I have reviewed this document as part of the security directorate's >> >> ongoing effort to review all IETF documents being processed by the >> >> IESG. These comments were written primarily for the benefit of the >> >> security area directors. Document editors and WG chairs should treat >> >> these comments just like any other last call comments. >> >> >> >> This document describes how to use two two specific Edwards Curves >> >> (Elliptic Curves) in conjunction with DNSSEC, namely ed25519 and >> >> ed448. >> >> >> >> The only comment I have on this document is that the Security >> >> Considerations section plainly states, without any reference or proof= : >> >> >> >> "Ed25519 and Ed448 offers improved security properties and >> >> implementation characteristics compared to RSA and ECDSA algorithms" >> >> >> >> I suggest either adding references to proofs of these statements or >> >> alternatively just remove the sentence (since it doesn't really add >> >> anything to the memo); the remaining paragraphs in the Security >> >> Considerations section is what really covers what someone implementin= g >> >> the memo should know or be aware of. >> >> >> >> -- Magnus >> > >> > ~~~~ >> > >> > ----- Original Message ----- >> >> From: "Dan Romascanu" >> >> To: gen-art@ietf.org >> >> Cc: "draft-ietf-curdle-dnskey-eddsa all" >> >> , "curdle" >> >> , >> >> ietf@ietf.org >> >> Sent: Sunday, 11 December, 2016 12:21:25 >> >> Subject: Review of draft-ietf-curdle-dnskey-eddsa-02 >> > >> >> Reviewer: Dan Romascanu >> >> Review result: Ready with Nits >> >> >> >> Summary: Ready, with nits >> >> >> >> I am not an expert in this field, but the document seems to meet its >> >> goals, it's clear and precise >> >> >> >> Major issues: >> >> >> >> Minor issues: >> >> >> >> Nits/editorial comments: >> >> >> >> 1. Section 4: s/Section5.1.7/Sections 5.1.7/ >> >> >> >> 2. Section 8: 'The following entry has been added to >> >> the registry' - I may be wrong, but the section seems to define two >> > > new entries in the registry rather than one > > --=20 -- Magnus From nobody Sat Dec 17 11:36:17 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E4F1296D5 for ; Sat, 17 Dec 2016 11:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzWmSL2Y6jTJ for ; Sat, 17 Dec 2016 11:36:13 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 C22F11296B8 for ; Sat, 17 Dec 2016 11:36:13 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id b132so19656924iti.1 for ; Sat, 17 Dec 2016 11:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=c17Q88DDzmchhy6z2azLAK2d2i6AUb9qv/snhofw0DM=; b=wmolpQIa1ezN3g2dMU7gOIC/+R4VPhLniMCxQU4G9hGxej6ZOdEZq1CWEL2MzOgBLV Mqo2oboYddYF7QwjMcD1c2x/9Y06eziBCFTeY5U7UrnS+dPSKcGfH1Odn5WsZ2pP7QJj mr6RvM/jkpOwWIbszVRDa2s6LgYQYJCuJPaJHhSqhO4vPWba5p+YeXlBlond2N74O409 PP29GfAnSP6GF3Pn7O23Cz5NzdTwrNDbJZF1gFgHOorFmdVXDkXMmH2QB/aEjeItBknL 1Otx6FfkKSnbTbQMTSp+rlxueHvMn6mBcN6EXv5nEvKSxZE7m77hL1UU9RhOZq5JIemB 2zuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=c17Q88DDzmchhy6z2azLAK2d2i6AUb9qv/snhofw0DM=; b=JOyaHWG0odFCt1XLrSGAeL8jboyLJGEc1wl8LvVDgVMfdtXRts1CbRU6X1xx7jw3F9 tqziMXyxRiasM48Op0XknJxWlSMUxPHeQDYv0q47NDs/OxPoKTwNXvv6WjymC3aXtDDX Jk/mtZSq7XZAJZtcGHcmnr+PHFEW+UntUaNsjctVdpDkTE0uqeXgxDFzw2q4bQh7hmUt dwFiwzsFFfhA3CNYlSbvCpThp0Oqgx2VY1/pLyAjrqttnsW+3jUBezsKxnfJ8yf6Ps+t 7HQevFV86cdRjTs6Wdbz3LiPAzpdqylZciZvIGikfHmJZjDIhUo+pB3Aljrq/7WPs6LE LpbA== X-Gm-Message-State: AKaTC00E4/eEdIHgVE1VYTtvL7RxbAoUewVptNmBYhO+ZxhcwQIqjHIQtxnnKrDahf56yX9Vm2Arw7x/F31PDA== X-Received: by 10.36.116.202 with SMTP id o193mr9780653itc.96.1482003373049; Sat, 17 Dec 2016 11:36:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.14.131 with HTTP; Sat, 17 Dec 2016 11:35:52 -0800 (PST) From: Joseph Salowey Date: Sat, 17 Dec 2016 11:35:52 -0800 Message-ID: To: secdir , draft-ietf-manet-olsrv2-sec-threats.all@ietf.org, The IESG Content-Type: multipart/alternative; boundary=001a114ab9129b59ca0543dfcc8d Archived-At: Subject: [secdir] Secdir review of draft-ietf-manet-olsrv2-sec-threats-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2016 19:36:15 -0000 --001a114ab9129b59ca0543dfcc8d Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready with issues. In general, I think the document does a reasonable job of describing some of the threats associated with OLSRv2. There are some places where the document could be clearer and there are some additional variations threats the authors may wish to consider. One issue that I did not see discussed in the draft would be for the attacker to effectively delay packets. For example, the attacker captures packets while jamming to prevent some stations from receiving packets. The attacker can collect a sequence of traffic and replay at a later time, with different timing and in a different location. Not all replay mechanisms will defend against this attack int he same way. Sequence number validation (which appears to be allowed in 7183) may not be as effective as timestamps, depending upon the time skew allowed. The document does discuss timestamps , but I think it should probably make the following clearer: There are several places in sections 4 and 5 where the document says something like "This kind of attack can be mitigated using integrity check mechanisms". I think in most of these instances replay protection is also important. One solution would be to remove these instances and just relay on section 6.2 which has a better description of the available protections. Since it seems that the integrity check could be deployed with just sequence number instead of timestamps it might be good to mention that it is important to include and verify timestamps for replay protection. Thanks, Joe --001a114ab9129b59ca0543dfcc8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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. These comments were written primarily for the benefit of the se= curity area directors. Document editors and WG chairs should treat these co= mments just like any other last call comments.

This docu= ment is ready with issues.

In general, I think the= document does a reasonable job of describing some of the threats associate= d with OLSRv2.=C2=A0 There are some places where the document could be clea= rer and there are some additional variations threats the authors may wish t= o consider. =C2=A0

One issue that I did not see di= scussed in the draft would be for the attacker to effectively delay packets= .=C2=A0 For example, the attacker captures packets while jamming to prevent= some stations from receiving packets.=C2=A0 The attacker can collect a seq= uence of traffic and replay at a later time, with different timing and in a= different location.=C2=A0 Not all replay mechanisms will defend against th= is attack int he same way.=C2=A0 Sequence number validation (which appears = to be allowed =C2=A0in 7183) may not be as effective as timestamps, dependi= ng upon the time skew allowed.=C2=A0 The document does discuss timestamps ,= but I think it should probably make the following clearer:

<= /div>
There are several places in sections 4 and 5 where the document s= ays something like "This kind of attack can be mitigated using integri= ty check mechanisms".=C2=A0 I think in most of these instances replay = protection is also important.=C2=A0 One solution would be to remove these i= nstances and just relay on section 6.2 which has a better description of th= e available protections. =C2=A0 Since it seems that the integrity check cou= ld be deployed with just sequence number instead of timestamps it might be = good to mention that it is important to include and verify timestamps for r= eplay protection.=C2=A0

Thanks,

Joe

--001a114ab9129b59ca0543dfcc8d-- From nobody Mon Dec 19 10:14:39 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C456B129592; Mon, 19 Dec 2016 10:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2TDIKSmTrDB; Mon, 19 Dec 2016 10:14:32 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 B3DAC12959C; Mon, 19 Dec 2016 10:14:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,374,1477954800"; d="scan'208";a="250740567" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.146]) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2016 19:14:29 +0100 From: Vincent Roca Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: <27F009E7-E8C2-4235-8288-DC8637FCF370@inria.fr> Date: Mon, 19 Dec 2016 19:14:28 +0100 To: IESG , secdir@ietf.org, draft-ietf-idr-large-community.all@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [secdir] Secdir review of draft-ietf-idr-large-community-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 18:14:34 -0000 Hello, I have reviewed this document as part of the security directorate=E2=80=99= 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. IMHO, the document is Ready. This document specifies an extension to BGP Communities. The initial RFC1997 being a bit old, it does not include any security = discussion section. Therefore it is important that the present document has a detailed = discussion on the topic, which is actually the case. The level of details seems = appropriate. Furthermore there is a dedicated "Error handling" section which is also = fine. Cheers, Vincent From nobody Mon Dec 19 10:29:03 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787271295A7; Mon, 19 Dec 2016 10:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10 X-Spam-Level: X-Spam-Status: No, score=-10 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnubzDw1Tage; Mon, 19 Dec 2016 10:28:57 -0800 (PST) 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 31E1D12959C; Mon, 19 Dec 2016 10:28:57 -0800 (PST) Received: from mbp-4.local ([IPv6:2601:1c0:cb00:5d1a:4444:8643:6836:dce8]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id uBJISuIs058902 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 19 Dec 2016 18:28:56 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:1c0:cb00:5d1a:4444:8643:6836:dce8] claimed to be mbp-4.local To: Vincent Roca , IESG , secdir@ietf.org, draft-ietf-idr-large-community.all@ietf.org References: <27F009E7-E8C2-4235-8288-DC8637FCF370@inria.fr> From: joel jaeggli Message-ID: <058a97b7-3588-948b-eb6f-da2745830a06@bogus.com> Date: Mon, 19 Dec 2016 10:28:55 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: <27F009E7-E8C2-4235-8288-DC8637FCF370@inria.fr> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V7stmoJiIdHW7BKxxQADdnuk2VaW9lBCl" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-idr-large-community-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 18:28:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V7stmoJiIdHW7BKxxQADdnuk2VaW9lBCl Content-Type: multipart/mixed; boundary="5GP5tsWAphB0ihcaSVOr2jTlfrv0qVFem"; protected-headers="v1" From: joel jaeggli To: Vincent Roca , IESG , secdir@ietf.org, draft-ietf-idr-large-community.all@ietf.org Message-ID: <058a97b7-3588-948b-eb6f-da2745830a06@bogus.com> Subject: Re: Secdir review of draft-ietf-idr-large-community-11 References: <27F009E7-E8C2-4235-8288-DC8637FCF370@inria.fr> In-Reply-To: <27F009E7-E8C2-4235-8288-DC8637FCF370@inria.fr> --5GP5tsWAphB0ihcaSVOr2jTlfrv0qVFem Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Thanks joel On 12/19/16 10:14 AM, Vincent Roca wrote: > Hello, > > 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. > > IMHO, the document is Ready. > > This document specifies an extension to BGP Communities. > The initial RFC1997 being a bit old, it does not include any security d= iscussion section. > Therefore it is important that the present document has a detailed disc= ussion on the > topic, which is actually the case. The level of details seems appropria= te. > Furthermore there is a dedicated "Error handling" section which is also= fine. > > Cheers, > > Vincent > > --5GP5tsWAphB0ihcaSVOr2jTlfrv0qVFem-- --V7stmoJiIdHW7BKxxQADdnuk2VaW9lBCl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlhYJugACgkQ8AA1q7Z/VrLtIwCfdtlzNFECZChRHidoBbr9C79C 6jUAn2IV3FRmHtV7ROhlQVS8+w17FZvq =m2c3 -----END PGP SIGNATURE----- --V7stmoJiIdHW7BKxxQADdnuk2VaW9lBCl-- From nobody Mon Dec 19 10:38:56 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273261295C9; Mon, 19 Dec 2016 10:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fuWEb2h89gw; Mon, 19 Dec 2016 10:38:53 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 E6E631295D2; Mon, 19 Dec 2016 10:38:52 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.7.237; From: "Susan Hares" To: "'Vincent Roca'" , "'IESG'" , , References: <27F009E7-E8C2-4235-8288-DC8637FCF370@inria.fr> In-Reply-To: <27F009E7-E8C2-4235-8288-DC8637FCF370@inria.fr> Date: Mon, 19 Dec 2016 13:35:38 -0500 Message-ID: <010c01d25a26$b265aa70$1730ff50$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG8NsPEOKwAyn6/aBNvL0cyzBQw6aE738Tg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-idr-large-community-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 18:38:54 -0000 Thank you for the review.=20 Sue Hares =20 (idr co-chair) -----Original Message----- From: Vincent Roca [mailto:vincent.roca@inria.fr]=20 Sent: Monday, December 19, 2016 1:14 PM To: IESG; secdir@ietf.org; draft-ietf-idr-large-community.all@ietf.org Cc: Vincent Roca Subject: Secdir review of draft-ietf-idr-large-community-11 Hello, 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. IMHO, the document is Ready. This document specifies an extension to BGP Communities. The initial RFC1997 being a bit old, it does not include any security = discussion section. Therefore it is important that the present document has a detailed = discussion on the topic, which is actually the case. The level of = details seems appropriate. Furthermore there is a dedicated "Error handling" section which is also = fine. Cheers, Vincent From nobody Mon Dec 19 10:43:42 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AB81295AA; Mon, 19 Dec 2016 10:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnAGcQUfRkFy; Mon, 19 Dec 2016 10:43:36 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51354129418; Mon, 19 Dec 2016 10:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1634; q=dns/txt; s=iport; t=1482173016; x=1483382616; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cQYlvQAVofY4EmdjdQq2xQ0Mik7tjIvOF30GZRure40=; b=Mu5Jf2zllpeYUBWSxLScI2Qls75vIWxTFzi9GeOr8rld4J2KbthHZexe hQj4Vo8ujXPgRW7dMIA2Bs2C27Xmhf29C/mwYwgyWwGWE1BP+XXqgeE6S uQQ7isbp8iRRKEmRtGiWsIeDqHE2wHiTs1WO38jNr2MoNviv6pU2Ou7DA U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CIAQCUKVhY/40NJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzcBAQEBAR+BYAcBjUeWWZUOggqGIgIagWg/FAECAQEBAQEBAWI?= =?us-ascii?q?ohGgBAQEEEhERUQQCAQgRBAEBAwIjAwICAjAUAQgIAgQBEggMDohJmloBjXaCK?= =?us-ascii?q?IsMAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELhSuEWYRXgm2CXQWVA4VtAYkfiAu?= =?us-ascii?q?QVo4ZhA4BHzeBJYYBcod9AYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.33,374,1477958400"; d="scan'208";a="183038269" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Dec 2016 18:43:35 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id uBJIhZq5013774 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Dec 2016 18:43:35 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 19 Dec 2016 12:43:34 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1210.000; Mon, 19 Dec 2016 12:43:34 -0600 From: "Jakob Heitz (jheitz)" To: Vincent Roca , IESG , "secdir@ietf.org" , "draft-ietf-idr-large-community.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-idr-large-community-11 Thread-Index: AQHSWiPFZXbyJGrfFk2KWO4vdz9ZZKEPmy1Q Date: Mon, 19 Dec 2016 18:43:34 +0000 Message-ID: References: <27F009E7-E8C2-4235-8288-DC8637FCF370@inria.fr> In-Reply-To: <27F009E7-E8C2-4235-8288-DC8637FCF370@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.147.22] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-idr-large-community-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 18:43:38 -0000 VGhhbmtzIFZpbmNlbnQsDQoNCkpha29iLg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogVmluY2VudCBSb2NhIFttYWlsdG86dmluY2VudC5yb2NhQGlucmlhLmZyXQ0K PiBTZW50OiBNb25kYXksIERlY2VtYmVyIDE5LCAyMDE2IDEwOjE0IEFNDQo+IFRvOiBJRVNHIDxp ZXNnQGlldGYub3JnPjsgc2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLWlkci1sYXJnZS1jb21t dW5pdHkuYWxsQGlldGYub3JnDQo+IENjOiBWaW5jZW50IFJvY2EgPHZpbmNlbnQucm9jYUBpbnJp YS5mcj4NCj4gU3ViamVjdDogU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWlkci1sYXJnZS1j b21tdW5pdHktMTENCj4gDQo+IEhlbGxvLA0KPiANCj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9j dW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGXigJlzIG9uZ29pbmcNCj4g ZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRo ZSBJRVNHLiBUaGVzZQ0KPiBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUg YmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYQ0KPiBkaXJlY3RvcnMuICBEb2N1bWVudCBlZGl0 b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QNCj4gbGlr ZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiANCj4gSU1ITywgdGhlIGRvY3VtZW50 IGlzIFJlYWR5Lg0KPiANCj4gVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gZXh0ZW5zaW9uIHRv IEJHUCBDb21tdW5pdGllcy4NCj4gVGhlIGluaXRpYWwgUkZDMTk5NyBiZWluZyBhIGJpdCBvbGQs IGl0IGRvZXMgbm90IGluY2x1ZGUgYW55IHNlY3VyaXR5IGRpc2N1c3Npb24gc2VjdGlvbi4NCj4g VGhlcmVmb3JlIGl0IGlzIGltcG9ydGFudCB0aGF0IHRoZSBwcmVzZW50IGRvY3VtZW50IGhhcyBh IGRldGFpbGVkIGRpc2N1c3Npb24gb24gdGhlDQo+IHRvcGljLCB3aGljaCBpcyBhY3R1YWxseSB0 aGUgY2FzZS4gVGhlIGxldmVsIG9mIGRldGFpbHMgc2VlbXMgYXBwcm9wcmlhdGUuDQo+IEZ1cnRo ZXJtb3JlIHRoZXJlIGlzIGEgZGVkaWNhdGVkICJFcnJvciBoYW5kbGluZyIgc2VjdGlvbiB3aGlj aCBpcyBhbHNvIGZpbmUuDQo+IA0KPiBDaGVlcnMsDQo+IA0KPiAgICBWaW5jZW50DQoNCg== From nobody Thu Dec 22 04:41:19 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FA3129570 for ; Thu, 22 Dec 2016 04:41:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Tero Kivinen" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148241047823.22480.14461357986048373083.idtracker@ietfa.amsl.com> Date: Thu, 22 Dec 2016 04:41:18 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 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, 22 Dec 2016 12:41:18 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-01-05 Reviewer LC end Draft Ólafur Guðmundsson 2016-12-30 draft-ietf-ospf-ttz-05 Matt Lepinski 2016-12-14 draft-ietf-avtext-avpf-ccm-layered-03 Sandra Murphy 2016-12-20 draft-ietf-6tisch-minimal-17 Eric Osterweil 2016-12-19 draft-ietf-i2rs-yang-network-topo-09 Rich Salz 2016-12-21 draft-ietf-sidr-bgpsec-ops-12 Yaron Sheffer 2016-12-19 draft-ietf-sidr-bgpsec-pki-profiles-18 For telechat 2017-01-19 Reviewer LC end Draft Derek Atkins 2017-01-06 draft-ietf-6man-rdnss-rfc6106bis-14 Shaun Cooley 2017-01-04 draft-ietf-rtgwg-rlfa-node-protection-08 Donald Eastlake 2017-01-04 draft-ietf-nvo3-use-case-15 Shawn Emery 2017-01-03 draft-ietf-trill-rfc6439bis-03 Daniel Franke 2017-01-02 draft-ietf-trill-directory-assist-mechanisms-10 Carl Wallace 2017-01-11 draft-ietf-bfcpbis-bfcp-websocket-13 David Waltermire 2017-01-10 draft-ietf-sidr-rpki-oob-setup-05 Brian Weis 2017-01-10 draft-ietf-sidr-adverse-actions-03 Paul Wouters 2017-01-06 draft-ietf-sidr-publication-09 Liang Xia 2017-01-06 draft-ietf-ecrit-car-crash-20 Dacheng Zhang 2017-01-06 draft-ietf-ecrit-ecall-21 For telechat 2017-02-02 Reviewer LC end Draft Hilarie Orman None draft-ietf-i2rs-yang-l3-topology-06 Last calls: Reviewer LC end Draft Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Phillip Hallam-Baker 2016-12-30 draft-ietf-ipsecme-rfc4307bis-15 Matthew Miller 2017-01-13 draft-harkins-owe-05 Melinda Shore 2017-01-09 draft-holmberg-dispatch-mcptt-rp-namespace-03 Robert Sparks 2017-01-18 draft-mohali-dispatch-cause-for-service-number-12 Hannes Tschofenig 2017-01-16 draft-murchison-webdav-prefer-11 Tina Tsou 2017-01-13 draft-ietf-payload-melpe-04 Sean Turner 2017-01-13 draft-ietf-insipid-logme-reqs-11 Tom Yu 2017-01-06 draft-ietf-kitten-krb-auth-indicator-04 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Hannes Tschofenig 2016-03-18 draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig 2016-03-18 draft-ietf-ntp-network-time-security-15 Hannes Tschofenig 2016-03-18 draft-ietf-ntp-using-nts-for-ntp-07 Brian Weis 2016-02-01 draft-ietf-cdni-uri-signing-10 Next in the reviewer rotation: Steve Hanna Dan Harkins Paul Hoffman Russ Housley Christian Huitema Christopher Inacio Leif Johansson Simon Josefsson Benjamin Kaduk Charlie Kaufman From nobody Thu Dec 22 06:46:48 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B392A128E18 for ; Thu, 22 Dec 2016 06:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x82OLmcN0q3q for ; Thu, 22 Dec 2016 06:46:39 -0800 (PST) Received: from nm38-vm7.bullet.mail.gq1.yahoo.com (nm38-vm7.bullet.mail.gq1.yahoo.com [98.136.217.78]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE12F129572 for ; Thu, 22 Dec 2016 06:46:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1482417999; bh=s+zMitbtbWUgBd8pRMBrYutTZE2cuMyKykj3MflE6Ks=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=UlvberPu32+L98OsW18xvAl19r7OrTzE+a5NKAHE21du43aWtf3AIa0uuvqM6mXdEOn41CYmgJUx0KRkAhjeTm8KEOm/NSCFrxItIZ4x9fQsiwOxJ8sgzEpguXqAGSmclTbRM4pKhZjRUghCpXHlaskDgkOgisw0h+2BBx6PP2Ji8ovUHnTkthspEIum09Ffno7uJVaOwEs8bPKxlZVFWph610PiPpboxxg1pvIMtfVi/r7wRFZRjVWG1tGZgtrhGP/zt8PjMQ0s4cqk+bfKRHCuFErODpnKVyQTIy5umQSkHamz2/r8tLxo5aSsFD/m1cQ/iw0rsV8jPwo9owl4Ag== Received: from [127.0.0.1] by nm38.bullet.mail.gq1.yahoo.com with NNFMP; 22 Dec 2016 14:46:39 -0000 Received: from [98.137.12.59] by nm38.bullet.mail.gq1.yahoo.com with NNFMP; 22 Dec 2016 14:43:44 -0000 Received: from [98.137.12.211] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 22 Dec 2016 14:43:44 -0000 Received: from [127.0.0.1] by omp1019.mail.gq1.yahoo.com with NNFMP; 22 Dec 2016 14:43:44 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 577569.70145.bm@omp1019.mail.gq1.yahoo.com X-YMail-OSG: eK82bHYVRDtgfAoCqOIpFuQf7CXNzbPmvwqKAF0E6WpCYH8GW8U- Received: from jws300040.mail.gq1.yahoo.com by sendmailws119.mail.gq1.yahoo.com; Thu, 22 Dec 2016 14:43:44 +0000; 1482417824.199 Date: Thu, 22 Dec 2016 14:43:14 +0000 (UTC) From: To: Tero Kivinen Message-ID: <1950709129.604084.1482417794841@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <1950709129.604084.1482417794841.ref@mail.yahoo.com> Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 : TimeBase X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: nalini.elkins@insidethestack.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 14:46:42 -0000 Tero, I am going to try to clean up the loose ends on this (at least as far as ou= r end!). Sorry for the delays in processing. This is what we have done as far as timebase / scaling for PDM. Summary:=20 1. Changed timebase 2. Eliminate negative scaling 3. Scaling still required 4. Layout changes 5. Changes for loss of precision=20 1. Changed timebase: We establish the Time Base value as 1 attosecond (ase= c). This allows for a common form and scaling of the time differential amon= g all IP stacks and hardware implementations. Note that we are trying to provide the ability to measure time deltas in a = DTN type environment where the delays may be great. So, we wanted to be ab= le to measure not just very small intervals but very large intervals such a= s days.=20 The first issue is the conversion from the native time base in the CPU hard= ware to some number of attoseconds. This might seem to be an astronomical n= umber, but the conversion is straightforward, and involves a multiplication= by an appropriate power of 10, and then a shift of a number of bits to cha= nge the units to asec.=20 Note these common relationships: 1 second =3D 10**18 asec =3D 1000**6 asec=20 1 millisecond =3D 10**-3 sec =3D 10**15 asec =3D 1000**5 asec=20 1 microsecond =3D 10**-6 sec =3D 10**12 asec =3D 1000**4 asec=20 1 nanosecond =3D 10**-9 sec =3D 10**9 asec =3D 1000**3 asec=20 1 picosecond =3D 10**-12 sec =3D 10**6 asec =3D 1000**2 asec=20 1 femtosecond =3D 10**-15 sec =3D 10**3 asec =3D 1000**1 asec=20 The conversion formula works like this: The time counter in a CPU is a binary whole number, representing a number o= f milliseconds (msec), microseconds (usec) or even picoseconds (psec). Repr= esenting one of these values as attoseconds (asec) means multiplying by the= value in the third column of this table. For example, if you have a time v= alue expressed in microseconds, since each microsecond is 10**12 asec, you = would multiply your time value by 10**12 to get the number of attoseconds. = The result is a binary value that will need to be shortened by a number of = bits so it will fit into the 16-bit PDM DELTA field. The exponent in the la= st column is useful here; the initial scaling factor is that exponent multi= plied by 10. This is the minimum number of low-order bits to be shifted-out= or discarded. The resulting value may still be too large to fit into 16 bi= ts, but can be normalized by shifting out more bits (dividing by 2) until t= he value fits into the 16-bit DELTA field. The number of extra bits shifted= out is then added to the scaling factor. The scaling factor, the total num= ber of low-order bits dropped, is then the SCALEDTL value. For example: say an application has these start and finish timer values (he= xadecimal values, in microseconds):=20 Finish: 27C849234 usec (02:57:58.997556)=20 -Start: 27C83F696 usec (02:57:58.957718)=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Difference 9B9E usec 00.039838 sec or 39838 usec=20 To convert this differential value to binary attoseconds, multiply the numb= er of microseconds by 10**12. Divide by 1024**4, or simply discard 40 bits = from the right. The result is 36232, or 8D88 in hex, with a scaling factor = or SCALEDTL value of 40.=20 For another example, presume the time differential is larger, say 32.311072= seconds, which is 32311072 usec. Each microseconds is 10**12 asec, so I mu= ltiply by 10**12, giving the hexadecimal value 1C067FCCAE8120000. Using the= initial scaling factor of 40, I would drop the last 10 characters (40 bits= ) from that string, giving 1C067FC. This will not fit into a DELTA field, a= s it is 25 bits long. Shifting the value to the right another 9 bits result= s in a DELTA value of E033, with now a scaling factor of 49. 2. Eliminate negative scaling: simplifies comparison between values=20 This form allows for simplified comparison between values. The time unit is= constant, reducing the computation required to manipulate these values. 3. Scaling is still required: Why do we still need scaling? Scaling is still required because the attosecond values can be very large, = and therefore will not fit into the DELTA fields. So, low order truncation= still needs to occur. 4. Layout=20 Current layout=20 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Option Type | Option Length |TB |ScaleDTLR | ScaleDTLS |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | PSN This Packet | PSN Last Received |=20 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Delta Time Last Received | Delta Time Last Sent |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 Scale Delta Time Last Received (SCALEDTLR)=20 7-bit signed integer. This is the scaling value for the Delta Time Last Re= ceived (DELTATLR) field. The possible values are from -128 to=20 +127. See Section 4 for further discussion on Timing Considerations and formatting of the scaling values.=20 Scale Delta Time Last Sent (SCALEDTLS)=20 7-bit signed integer. This is the scaling value for the Delta Time=20 Last Sent (DELTATLS) field. The possible values are from -128 to=20 +127.=20 New layout (Timebase eliminated) 0 1 2 3=20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Option Type | Option Length | ScaleDTLR | ScaleDTLS |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | PSN This Packet | PSN Last Received |=20 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | Delta Time Last Received | Delta Time Last Sent |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 Scale Delta Time Last Received (SCALEDTLR)=20 8-bit unsigned integer. This is the scaling value for the Delta Time=20 Last Received (DELTATLR) field. The possible values are from 0 to=20 255. See Section 4 for further discussion on Timing Considerations=20 and formatting of the scaling values.=20 Scale Delta Time Last Sent (SCALEDTLS)=20 8-bit unsigned integer. This is the scaling value for the Delta Time=20 Last Sent (DELTATLS) field. The possible values are from 0 to=20 255.=20 5. Loss of precision=20 When using and scaling binary numbers, the upper limit for the loss of=20 precision is 2**n-1, where n is the number of bits that have been dropped f= rom=20 the number. In this instance, n is the scaling factor, so while the scaling= =20 factors just discussed are very large, you must remember that we are talkin= g=20 about an infinitesimal amount of time. Since the "-1" in that formula refer= s=20 to a single attosecond, think of the formula as just 2**n when discussing v= alues larger than, say, picoseconds. To demonstrate the amount of precision lost, consider the second example ab= ove. The resulting DELTA value was E033, with a scaling factor of 49. Multiplyin= g the DELTA value by 2**49 and dividing by 10**12 gives me back the number of mic= roseconds this value represents, which is 32310512. Since the original value was 3231= 1072 usec, you can see that the amount of precision lost, on a 32+ second interval, wa= s just 560 usec. For this calculation, the scaling factor of 49 means that one could expect = a maximum loss of precision of 2**49 asec, which is a fraction smaller than 562.95 usec. As a further demonstration, consider this table of very long=20 time intervals, starting with some times on a real network:=20 PDM representation=20 DELTA Scaling=20 Time differential value factor=20 =3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D= =3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=20 1 sec =3D 10**18 asec DB06 44=20 1 min =3D 60*10**18 asec D20A 50=20 1 solar day =3D 86400 sec (3600*24) 925E 61=20 1 civil year =3D 31557600 sec D0DA 69=20 (3600*24*365.25)=20 With this in mind, if the response from a far-ranging spacecraft took a yea= r=20 to return to Earth, the loss of precision would be 2**69 asec, which is=20 just less than 9min and 50.3 seconds. For a time differential of 1 second,= =20 the maximum loss of precision is less than 17.6 microseconds. A time=20 differential of one picosecond, 10**6 asec, would be represented as the DEL= TA=20 value F424 with a scaling factor of 4, so the maximum precision loss would = be=20 15 asec.=20 =20 Thanks, Nalini Elkins Inside Products, Inc. www.insidethestack.com (831) 659-8360 On Tuesday, October 18, 2016 6:07 AM, Tero Kivinen wrote: nalini.elkins@insidethestack.com writes: > >The time base is so that one does not have to be committed to picosecond= s /=20 > >milliseconds, etc. Even in your example, I believe you used "unit" or= time=20 > >base. Our thinking was that we wanted future proof so as to be able to= =20 > >handle very small values and very large (as may be needed for DTN, for= =20 > >example). We can see if we can express years in picoseconds and see=20 > >what happens. Then, the unit would always be picoseconds=20 >=20 > The issue is with the hardware. When we were first researching the > "proper" or "best" time unit in which the PDM time differentials > should be measured, we found that different CPU hardware measure > time very differently. Some CPUs are still measuring time in > milliseconds and using multiple clocks to do it. Yep, but the problem is that if the implementation still need to be able to cope with other devices using different time bases, this does not help.=20 > Our plan was to have a CPU specify the time differential in its > native time units, to reduce its processing time when communicating > with another device that is at the same level. One could say that > the most logical solution is to use the time signature of the > slowest device, so that all the time-adjustment calculations are > performed on the device most capable of handling them quickly, and > similarly, requiring the slowest device to adjust to the timing used > by the fastest device would be forcing those calculations onto the > device least capable of handling them quickly. Further, why make two > devices that use the same clock unit to change to a different time > scale on both ends of the conversation? If both use microseconds, > why not let them specify their time differential in microseconds? The problem is that some implementations measure time in 0.01 seconds (10 ms), some implementations have timers which go up 60 times per second, then there are implementations which have free running counter running that full clock speed (or some fraction of clock speed or some other very fast value, but not necessarely ms, =C2=B5s, ns or ps). So even if you have 4 time bases, there are lots of implementations which need to convert their clock to something that is suitable for the wireformat. If we do not have time base, i.e. everything uses some common timebase then you always need to do it, but on the other hand it is simple, as there is no selection whether you should be using ms, =C2=B5s, ns or ps are your time base. Having the 2^scale factor to the numbers will take care of being able to represent any time value there, having two different ways of doing scaling (both 2^scale factor and the time base) will just complicate things.=20 > That's the reasoning that we had about the timebase. >=20 > Of course, we are open to discussion.=20 I think it would be simplier to just have one fixed timebase, and it might even be better to take the timebase so it is so small, that we do not need negative exponents for scale, like attoseconds. Attoseconds (10^-18) is so short that light can travel only 0.3 nm in one attosecond, so that should be enough for PDM (until we get new way of making transistors, and start measure latencies between transistors). If your clock is running milliseconds, you need to multiply the time in ms with 0.88818 ((1000/1024)^5) to get time in attoseconds with scale of 50. For microseconds the multiplier is 0.90949 with scale of 40, nanoseconds 0.93132 with scale of 30, picoseconds 0.95367 with scale of 20, and femtoseconds 0.97656 with scale of 10. --=20 kivinen@iki.fi From nobody Thu Dec 22 07:51:04 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E059C12941A; Thu, 22 Dec 2016 07:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sS10tb7oLclA; Thu, 22 Dec 2016 07:51:00 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0127.outbound.protection.outlook.com [23.103.200.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046F41295EF; Thu, 22 Dec 2016 07:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZM9rkMfJiHexbVMV5T7JFSXHr7UCoS53STo3jRK2rl8=; b=e+Vwj8UGnyme3KkpDdVzDWn1uIvSEuR2qHutgdY2qV0lZI3pCgJxlTsp0czGbpd/m5W2iy9cHP/rhHC/F8jnwYvJ9MGtyIp4KWwbXXgq+XWPp6L6+0GJAdhsKHKvVy+VFHHTJMrM0/RTVNygmkACGZSs/e9bb7TQlJ2LQLwdGwk= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0448.namprd09.prod.outlook.com (10.161.252.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Thu, 22 Dec 2016 15:50:55 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0789.018; Thu, 22 Dec 2016 15:50:55 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Russ Housley , "draft-ietf-sidr-bgpsec-protocol.all@ietf.org" Thread-Topic: SecDir Review of draft-ietf-sidr-bgpsec-protocol-20 Thread-Index: AQHSUW/sFNMfOkGS20CKc0VjvBxafaEUKNuP Date: Thu, 22 Dec 2016 15:50:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.220.81] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0448; 7:r9fBxZduxgZBG5S41IFnh33mL6gnTdvuoDsol5RVDFOsE1ErrZHUPs3o9P3Cy2QnYGPIH3UWVQhGTExB4H0Z236GdPZ7RzHVAptFcuRHTktGxlXKn6r1y6WqKKLwOhBeSbVkWDcW9QAgrLsnGAEsupXvh85VFs265A9TsorH5c8eoNGWk0YK+FDL35x7OjcFDsIS9v7u2Oh8qwwQXI860wgxuusGPyPscVjdW8oWGsRJpoX/T8bWuJXPje6mKlV6Hryr2OLkhSm3jRLoewpyvGfeZGcHWTT+jHmIoylgxTxEi1VZXKnRYPY9Xi14QK1J72UypeQQCmzKlMhqtL0zvahR4THzQ6n9zyLur5EQNBpyGW4TJ6yQipsIDwYHF443EimiAuUSexVoRbdNddnPbZQ9fGUrWfAcq3JeMOWx9kas80QC+kmJQf7+wH/Gkty4AKMudzuj27Ll5oA0WU8g0A== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39410400002)(39860400002)(39850400002)(78124002)(189002)(199003)(102836003)(86362001)(66066001)(101416001)(76576001)(2950100002)(68736007)(5660300001)(33656002)(8676002)(7696004)(6116002)(230783001)(122556002)(2501003)(81156014)(81166006)(54356999)(2906002)(50986999)(4326007)(9686002)(76176999)(2900100001)(5001770100001)(92566002)(8936002)(189998001)(345774005)(99286002)(106356001)(106116001)(38730400001)(105586002)(305945005)(229853002)(6506006)(74316002)(77096006)(6436002)(25786008)(97736004)(3280700002)(3660700001)(3846002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0448; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 2ddad053-dd32-4df5-5a72-08d42a82509e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0448; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:DM2PR09MB0448; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0448; x-forefront-prvs: 01644DCF4A received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2016 15:50:55.0310 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0448 Archived-At: Cc: IETF SecDir Subject: Re: [secdir] SecDir Review of draft-ietf-sidr-bgpsec-protocol-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 15:51:02 -0000 Hi Russ, Thank you for your comments. I am preparing a version 21 of the document to be submitted soon. I have updated the document already to include all your comments=20 except the following thee: (need your further guidance on these) #1 >In Section 3.2, the Signature Length within the Signature Segment does not count the length field itself. It seems that all of the other length values in this specification count the size of the length too. Consistency will avoid implementation errors. [Sriram] I agree. However, this change would require modifications with two= existing implementations. If you say it doesn't matter, just do it; let the implemen= tations catch up -- then sure I will have no problem. I'll make the change in the spec.=20 #2 >It seems a bit wasteful to repeat the whole capability for each direction. Wouldn't it be better to follow the example used in other capability definitions (such as RFC 7911) by using one of the unassigned bits? The Send/Receive pair of bits would have these semantics: [Sriram] I spoke with Oliver Borchert. He thought there was some merit to implementing it the way it currently is in the spec (he already has the implementation in Quagga BGPsec). This change would also require modifications with the two existing implementations (NIST's and Parson's).=20 Again, if you feel strongly, please let me know. #3 >I think an additional consideration is needed in Section 6.2. This protocol design assumes a signer will compute a message digest and then digitally sign that digest. If someone wants to use a digital signature that works differently, there may be a significant change to this protocol. [Sriram] Is this not already taken care of by using the same approach that = is described in Section 6.2? Section 6.2 says: "In the case that such a change to BGPsec were deemed desirable, it is expected that a subsequent version of BGPsec would be created and that this version of BGPsec would specify a new BGP path attribute, let's call it BGPsec_Path_Two, which is designed to accommodate the desired changes to BGPsec." [Sriram] BGPsec_Path_Two structure can be anything you want.=20 This is no way tied to computing a digest and signing it. It can be designed/structured specifically for the "signature that works di= fferently". No? =20 For the first two (#1 and #2), perhaps I can wait a bit and make the change= s=20 closer to the final publication of the RFC (in January). (I mean we perhaps need not rush at this time to make these two changes?) Regards, Sriram From nobody Thu Dec 22 08:31:19 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C581129A47 for ; Thu, 22 Dec 2016 08:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YigzAMl_pW_1 for ; Thu, 22 Dec 2016 08:31:16 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50A4E1296F8 for ; Thu, 22 Dec 2016 08:31:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 18E633002C5 for ; Thu, 22 Dec 2016 11:20:59 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JF67_lznuy81 for ; Thu, 22 Dec 2016 11:20:57 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 7C24630026D; Thu, 22 Dec 2016 11:20:57 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Thu, 22 Dec 2016 11:31:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <30C37BB9-9672-46CE-9442-636FFE9649E3@vigilsec.com> References: To: Sriram Kotikalapudi X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol.all@ietf.org" , IETF SecDir Subject: Re: [secdir] SecDir Review of draft-ietf-sidr-bgpsec-protocol-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 16:31:17 -0000 On Dec 22, 2016, at 10:50 AM, Sriram, Kotikalapudi (Fed) = wrote: > Hi Russ, >=20 > Thank you for your comments. > I am preparing a version 21 of the document to be submitted soon. > I have updated the document already to include all your comments=20 > except the following thee: > (need your further guidance on these) >=20 >=20 > #1 >> In Section 3.2, the Signature Length within the Signature Segment = does > not count the length field itself. It seems that all of the other > length values in this specification count the size of the length too. > Consistency will avoid implementation errors. >=20 > [Sriram] I agree. However, this change would require modifications = with two existing > implementations. If you say it doesn't matter, just do it; let the = implementations catch up -- > then sure I will have no problem. I'll make the change in the spec.=20 Better to point this out on the mail list and let the implementors have = a say. > #2 >> It seems a bit wasteful to repeat the whole capability for each > direction. Wouldn't it be better to follow the example used in > other capability definitions (such as RFC 7911) by using one of the > unassigned bits? The Send/Receive pair of bits would have these > semantics: >=20 > [Sriram] I spoke with Oliver Borchert. He thought there was some merit = to > implementing it the way it currently is in the spec > (he already has the implementation in Quagga BGPsec). > This change would also require modifications with the two existing > implementations (NIST's and Parson's).=20 > Again, if you feel strongly, please let me know. Again, please point this out on the mail list and let the implementors = have a say. > #3 >> I think an additional consideration is needed in Section 6.2. This > protocol design assumes a signer will compute a message digest and > then digitally sign that digest. If someone wants to use a digital > signature that works differently, there may be a significant change > to this protocol. >=20 > [Sriram] Is this not already taken care of by using the same approach = that is > described in Section 6.2? Section 6.2 says: >=20 >=20 > "In the case that such a change to BGPsec were deemed desirable, it is > expected that a subsequent version of BGPsec would be created and > that this version of BGPsec would specify a new BGP path attribute, > let's call it BGPsec_Path_Two, which is designed to accommodate the > desired changes to BGPsec.=94 When I read that paragraph, I did not think it was talking about the = hash and sign paradigm. Russ From nobody Thu Dec 22 11:07:46 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8340712947C; Thu, 22 Dec 2016 11:07:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148243366051.26035.14431528711060624773.idtracker@ietfa.amsl.com> Date: Thu, 22 Dec 2016 11:07:40 -0800 Archived-At: Cc: ietf@ietf.org, draft-mohali-dispatch-cause-for-service-number.all@ietf.org Subject: [secdir] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 19:07:40 -0000 Reviewer: Robert Sparks Review result: Ready 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. Document : draft-mohali-dispatch-cause-for-service-number-12 Summary: Ready for publication as an Informational RFC This document adds a value to use with the SIP "cause" URI parameter that means 'This URI is like it is because a service number translation service produced it'. Its key value is added when the URI appears in the sequence of URIs in the History-Info header field, letting a subsequent service, or recipient's user agent (particularly when the recipient is someone in a call center ) know more about who the caller was really trying to reach. This document doesn't change the security landscape for use of the cause URI parameter or the History-Info header mechanics. The only information it adds for consideration is that a number translation service was used. The History-Info mechanism (RFC7044) has significant security and privacy considerations. This document points strongly to that document, which points to the SIP Privacy mechanism (RFC3323). Again, adding this cause number does not add new considerations for the use of that mechanism. There has been a lot of discussion about whether this document should proceed as Informational, mostly rooted in the IANA registation policy for the registry containing the "cause" URI parameter. (This document asks to add itself as a reference to that existing registration). The shepherd's writeup does a good job of explaining why Informational is appropriate. From nobody Fri Dec 23 03:11:56 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E511297CA; Fri, 23 Dec 2016 03:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbAqs2qP4mDs; Fri, 23 Dec 2016 03:11:52 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6667B1296FF; Fri, 23 Dec 2016 03:11:52 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id uBNBBmP6004159 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 Dec 2016 13:11:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id uBNBBlZj001796; Fri, 23 Dec 2016 13:11:47 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22621.1651.693371.284600@fireball.acr.fi> Date: Fri, 23 Dec 2016 13:11:47 +0200 From: Tero Kivinen To: In-Reply-To: <1950709129.604084.1482417794841@mail.yahoo.com> References: <1950709129.604084.1482417794841.ref@mail.yahoo.com> <1950709129.604084.1482417794841@mail.yahoo.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Cc: "iesg@ietf.org" , "draft-ietf-ippm-6man-pdm-option.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 : TimeBase X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 11:11:54 -0000 nalini.elkins@insidethestack.com writes: > I am going to try to clean up the loose ends on this (at least as > far as our end!). Sorry for the delays in processing. > > This is what we have done as far as timebase / scaling for PDM. That looks good. -- kivinen@iki.fi From nobody Wed Dec 28 09:31:01 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B943B12962E; Wed, 28 Dec 2016 09:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SfVDq3N00Fi; Wed, 28 Dec 2016 09:30:56 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0112.outbound.protection.outlook.com [23.103.201.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC87129470; Wed, 28 Dec 2016 09:30:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ncw0eyAaXFdJoSFq9ZBnX1oSj5mEb4AOC2LK+t3HmYk=; b=PA76pEM329nOHx54NxlF1/eKRFelbKut0o4SpPxjxl6LMrta4uHnu8FR8qeyByb6kxf5HxzFKXoCS8Ag0jxbdgkJfXwHsBKhCCBiz9ntjCbWeotNikviZMZRq7BTqxSHk9Y8/kBXOfDxUH5yEjXJpdD7He36CNx1iEUQ8WejKPM= Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM2PR09MB0447.namprd09.prod.outlook.com (10.161.252.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Wed, 28 Dec 2016 17:30:54 +0000 Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0789.028; Wed, 28 Dec 2016 17:30:54 +0000 From: "Sriram, Kotikalapudi (Fed)" To: Russ Housley , "draft-ietf-sidr-bgpsec-protocol.all@ietf.org" Thread-Topic: SecDir Review of draft-ietf-sidr-bgpsec-protocol-20 Thread-Index: AQHSUW/sFNMfOkGS20CKc0VjvBxafaEdrPtg Date: Wed, 28 Dec 2016 17:30:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.122] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0447; 7:aDLBE0GAnC1vD3TFxzh9tTyM+gmcKIFSaA0mezGQjyQaDtyVeJ1c6R9noPQSoCHhFOM1IjUPl63fzBH4SMK2b2KbdGRI1QbZJ4UNfdHwFliYZCR73LfvQDAQosmb9E0OKkcPg6nsu84D2IWhvemjq0CF33l29/5FNnCAtrdwLEdiqDWaSLeW0MZlN90Dhy/DqGdp7g+wx75SLm7QbcZJMbYB4doSZt78AP5ISTCqgHDKqkva0q4qu9Hdqu3hfIvb17JKbKBQx+4eIZP3X6ExmoTgSyWTWXTjkbZ2WlQGQnKPrUmRZgLwfyFFd1STdt06Jvhwb2EHVDr4FbdHUmXbtHwH2BJ2jCrUIZ6vhvc0ppEHF1WDU/j5HUmJbyCKDhh8vuunMaNajxj7KPqMFYmFOcSOHfkAZleaZ8Qzp2NP2352cn2i5gluHVAaviIagKPTelngGu5NWZHQ2/dZUt37Xg== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39860400002)(39840400002)(39450400003)(39410400002)(189002)(377454003)(13464003)(199003)(377424004)(25786008)(230783001)(2950100002)(3660700001)(7696004)(81166006)(77096006)(345774005)(5660300001)(81156014)(6436002)(3280700002)(106356001)(105586002)(106116001)(8676002)(66066001)(99286002)(305945005)(76576001)(74316002)(6116002)(2906002)(4326007)(3846002)(2501003)(102836003)(6506006)(55016002)(9686002)(92566002)(54356999)(101416001)(5001770100001)(97736004)(4001150100001)(50986999)(76176999)(2900100001)(38730400001)(189998001)(122556002)(33656002)(86362001)(7736002)(229853002)(68736007)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0447; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 9d848f63-d58e-4bd0-8a7a-08d42f4746c1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM2PR09MB0447; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:DM2PR09MB0447; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0447; x-forefront-prvs: 0170DAF08C received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Dec 2016 17:30:53.9252 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0447 Archived-At: Cc: IETF SecDir Subject: Re: [secdir] SecDir Review of draft-ietf-sidr-bgpsec-protocol-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 17:30:58 -0000 Russ, Thanks once again for your detailed review and very helpful comments. The recently submitted version-21 of the draft incorporates changes to refl= ect all your comments except two minor comments that have to do with packet for= mat tweaks. (Please see Oliver's response on the SIDR list about the latter.) =20 Please see my specific responses inline below marked with [Sriram]. =20 Please let me know if there is anything that I have missed. Sriram -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: Thursday, December 08, 2016 11:26 AM To: draft-ietf-sidr-bgpsec-protocol.all@ietf.org Cc: IETF SecDir Subject: SecDir Review of draft-ietf-sidr-bgpsec-protocol-20 I reviewed this document as part of the Security Directorate's ongoing effo= rt to review all IETF documents being processed by the IESG. These comment= s were written primarily for the benefit of the Security Area Directors. D= ocument authors, document editors, and WG chairs should treat these comment= s just like any other IETF Last Call comments. Document: draft-ietf-sidr-bgpsec-protocol-20 Reviewer: Russ Housley Review Date: 2016-12-08 IETF LC End Date: 2016-12-16 IESG Telechat date: Unknown Summary: Almost Ready I also did a review for Gen-ART. This SecDir review is identical to that G= en-ART review. I was involved in the design of BGPsec, but I have not reviewed the documen= t for a long time. Question I do not see any guidance on the handling of private AS numbers. I'm not s= ure whether it belongs in the document or not. I am thinking about a BGP s= tub customer that employs a private AS. If I understand properly, that stu= b customer cannot publish a ROA for the private AS number and the prefixes = that it uses. So, the stub customer cannot become a BGPsec speaker. So, m= y question is about the BGPsec speaker that receives an announcement from t= he stub customer. Does that BGPsec speaker strip the private AS and sign a= n announcement? Will their ROA that cover the prefixes used by the stub cu= stomer? [Sriram] There are new paragraphs added in the ops and mgmt. section (S 7) = =20 to discuss proper handling of private ASNs that may be used for stub ASes=20 or inside confederations. Major Concerns Section 2.2 says: ... A BGP speaker MAY announce BGPsec capability only if it supports the BGP multiprotocol extension [RFC4760]. ... This needs to be worded as a MUST NOT statement. =20 The current wording does not align with the definition of MAY in RFC 2119. [Sriram]: Done I think an additional consideration is needed in Section 6.2. This protoco= l design assumes a signer will compute a message digest and then digitally = sign that digest. If someone wants to use a digital signature that works d= ifferently, there may be a significant change to this protocol. [Sriram]: Please refer to our earlier discussion in this thread on this top= ic.=20 I have left the section as is. It is very unusual for the IANA Considerations to contain a figure, and Fig= ure 10 really seems out of place. The version number can be put in an IANA= registry, but there really is no need until a second value is needed. The= re is no reason to put Dir in an IANA registry, there are only two values a= nd both are fully specified in this document. The unassigned bits must be = zero until a new version is specified. [Sriram] I have modified Figures 10 to make clear that the Dir values=20 are fully specified by the RFC-to-be. I have similarly added more clarity = in Figure 11 also. The IANA reviewer Sabrina Tanamal has used Figure 10 in her response. Seems like she found it useful. So I am keeping it in the document for now. In the IANA section (including Figs. 10 and 11), it is now clearly stated that the unassigned bits must be set to zero.=20 Minor Concerns I find the Abstract misses some important information. Also, the old wordi= ng suggests that the attribute contains a single digital signature. I suggest: This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of autonomous systems (ASes) through which a BGP update message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each autonomous system that propagates the update message. The digital signatures provide confidence that every AS on the path of ASes listed in the update message has explicitly authorized the advertisement of the route. [Sriram] Thanks for providing the additional wording. The document now has= =20 the modified version of the abstract that you've provided above.=20 Section 2.1 says: ... The BGP speaker sets this bit to 0 to indicate the capability to receive BGPsec update messages. The BGP speaker sets this bit to 1 to indicate the capability to send BGPsec update messages. It seems a bit wasteful to repeat the whole capability for each direction. = Wouldn't it be better to follow the example used in other capability defin= itions (such as RFC 7911) by using one of the unassigned bits? The Send/Re= ceive pair of bits would have these semantics: This field indicates whether the sender is (a) able to receive BGPsec update messages from its peer (value 1), (b) able to send BGPsec update messages to its peer (value 2), or (c) both (value 3) for the address family identified in the AFI. [Sriram]: I have followed your suggestion to put this out on the SIDR list = for comments.=20 Please see Oliver's response on the SIDR list. Let us see if anyone else co= mments. =20 For completeness, please add a paragraph to the end of Section 3.1 that des= cribes the 4-octet AS Number field. Please state how an old 16-bit AS numb= er is carried. [Sriram] Done. In Section 3.2, the Signature Length within the Signature Segment does not = count the length field itself. It seems that all of the other length value= s in this specification count the size of the length too. Consistency will avoid implementation errors. [Sriram] I have followed your suggestion to put this out on the SIDR list f= or Comments.=20 Please see Oliver's response on the SIDR list. Let us see if anyone else co= mments. Section 4.2 references the MP_REACH_NLRI attribute; please add a citation t= o the RFC that defines that attribute. [Sriram] Done. RFC7460 added as citation. Nits Section 2.1 says: The second and third octets contain the 16-bit Address Family Identifier (AFI) which indicates the address family for which the BGPsec speaker is advertising support for BGPsec. This document only specifies BGPsec for use with two address families, IPv4 and IPv6, AFI values 1 and 2 respectively. BGPsec for use with other address families may be specified in future documents. Please reference RFC 4760 for a place to learn about AFI. [Sriram] Done. In Section 4.1, the comma is in the wrong place, but when I tried to offer = a correction, I thought that a slight rewording would also improve the clar= ity: OLD: If a BGPsec router has received only a non-BGPsec update message (without the BGPsec_Path attribute), containing the AS_PATH attribute, from a peer for a given prefix then it MUST NOT ... NEW: If a BGPsec router has received only a non-BGPsec update message containing the AS_PATH attribute (instead of the BGPsec_Path attribute) from a peer for a given prefix, then it MUST NOT ... [Sriram] Done. Thank you for providing the better wording for this. Please reword the first paragraph of Section 4.2 to avoid the phrase "said = route advertisement". While it is not wrong, it does feel very awkward. T= his is not a patent claim. [Sriram] Done. Now the document avoids patent-like usage of "said".=20 The acronym "ASN" is not used until Section 4.4, and it is not expanded the= re. I suggest that all uses of ASN should be expanded to AS number. [Sriram] Done. From nobody Wed Dec 28 09:49:08 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72C6129639 for ; Wed, 28 Dec 2016 09:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bBDnW__sFHR for ; Wed, 28 Dec 2016 09:49:04 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7411D129635 for ; Wed, 28 Dec 2016 09:49:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 336FB30040A for ; Wed, 28 Dec 2016 12:38:47 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fWjkj0wS-30g for ; Wed, 28 Dec 2016 12:38:44 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 50790300260; Wed, 28 Dec 2016 12:38:44 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Wed, 28 Dec 2016 12:46:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sriram Kotikalapudi X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "draft-ietf-sidr-bgpsec-protocol.all@ietf.org" , IETF SecDir Subject: Re: [secdir] SecDir Review of draft-ietf-sidr-bgpsec-protocol-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 17:49:06 -0000 Sriram: Thanks for your very comprehensive response to my review. I think it is = ready to move forward, Russ On Dec 28, 2016, at 12:30 PM, Sriram, Kotikalapudi (Fed) = wrote: > Russ, >=20 > Thanks once again for your detailed review and very helpful comments. > The recently submitted version-21 of the draft incorporates changes to = reflect > all your comments except two minor comments that have to do with = packet format tweaks. > (Please see Oliver's response on the SIDR list about the latter.) =20 >=20 > Please see my specific responses inline below marked with [Sriram]. =20= > Please let me know if there is anything that I have missed. >=20 > Sriram >=20 >=20 > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com]=20 > Sent: Thursday, December 08, 2016 11:26 AM > To: draft-ietf-sidr-bgpsec-protocol.all@ietf.org > Cc: IETF SecDir > Subject: SecDir Review of draft-ietf-sidr-bgpsec-protocol-20 >=20 > I 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 authors, document editors, and WG chairs should = treat these comments just like any other IETF Last Call comments. >=20 > Document: draft-ietf-sidr-bgpsec-protocol-20 > Reviewer: Russ Housley > Review Date: 2016-12-08 > IETF LC End Date: 2016-12-16 > IESG Telechat date: Unknown >=20 > Summary: Almost Ready >=20 > I also did a review for Gen-ART. This SecDir review is identical to = that Gen-ART review. >=20 > I was involved in the design of BGPsec, but I have not reviewed the = document for a long time. >=20 >=20 > Question >=20 > I do not see any guidance on the handling of private AS numbers. I'm = not sure whether it belongs in the document or not. I am thinking about = a BGP stub customer that employs a private AS. If I understand = properly, that stub customer cannot publish a ROA for the private AS = number and the prefixes that it uses. So, the stub customer cannot = become a BGPsec speaker. So, my question is about the BGPsec speaker = that receives an announcement from the stub customer. Does that BGPsec = speaker strip the private AS and sign an announcement? Will their ROA = that cover the prefixes used by the stub customer? >=20 > [Sriram] There are new paragraphs added in the ops and mgmt. section = (S 7) =20 > to discuss proper handling of private ASNs that may be used for stub = ASes=20 > or inside confederations. >=20 >=20 > Major Concerns >=20 > Section 2.2 says: >=20 > ... A BGP speaker MAY > announce BGPsec capability only if it supports the BGP multiprotocol > extension [RFC4760]. ... >=20 > This needs to be worded as a MUST NOT statement. =20 > The current wording does not align with the definition of MAY in RFC = 2119. >=20 > [Sriram]: Done >=20 > I think an additional consideration is needed in Section 6.2. This = protocol design assumes a signer will compute a message digest and then = digitally sign that digest. If someone wants to use a digital signature = that works differently, there may be a significant change to this = protocol. >=20 > [Sriram]: Please refer to our earlier discussion in this thread on = this topic.=20 > I have left the section as is. >=20 > It is very unusual for the IANA Considerations to contain a figure, = and Figure 10 really seems out of place. The version number can be put = in an IANA registry, but there really is no need until a second value is = needed. There is no reason to put Dir in an IANA registry, there are = only two values and both are fully specified in this document. The = unassigned bits must be zero until a new version is specified. >=20 > [Sriram] I have modified Figures 10 to make clear that the Dir values=20= > are fully specified by the RFC-to-be. I have similarly added more = clarity in Figure 11 also. > The IANA reviewer Sabrina Tanamal has used Figure 10 in her response. > Seems like she found it useful. So I am keeping it in the document for = now. > In the IANA section (including Figs. 10 and 11), it is now clearly = stated > that the unassigned bits must be set to zero.=20 >=20 > Minor Concerns >=20 > I find the Abstract misses some important information. Also, the old = wording suggests that the attribute contains a single digital signature. > I suggest: >=20 > This document describes BGPsec, an extension to the Border Gateway > Protocol (BGP) that provides security for the path of autonomous > systems (ASes) through which a BGP update message passes. BGPsec is > implemented via an optional non-transitive BGP path attribute that > carries digital signatures produced by each autonomous system that > propagates the update message. The digital signatures provide > confidence that every AS on the path of ASes listed in the update > message has explicitly authorized the advertisement of the route. >=20 > [Sriram] Thanks for providing the additional wording. The document now = has=20 > the modified version of the abstract that you've provided above.=20 >=20 > Section 2.1 says: >=20 > ... The BGP speaker > sets this bit to 0 to indicate the capability to receive BGPsec > update messages. The BGP speaker sets this bit to 1 to indicate the > capability to send BGPsec update messages. >=20 > It seems a bit wasteful to repeat the whole capability for each = direction. Wouldn't it be better to follow the example used in other = capability definitions (such as RFC 7911) by using one of the unassigned = bits? The Send/Receive pair of bits would have these > semantics: >=20 > This field indicates whether the sender is (a) able to receive > BGPsec update messages from its peer (value 1), (b) able to send > BGPsec update messages to its peer (value 2), or (c) both (value 3) > for the address family identified in the AFI. >=20 > [Sriram]: I have followed your suggestion to put this out on the SIDR = list for comments.=20 > Please see Oliver's response on the SIDR list. Let us see if anyone = else comments. >=20 > For completeness, please add a paragraph to the end of Section 3.1 = that describes the 4-octet AS Number field. Please state how an old = 16-bit AS number is carried. >=20 > [Sriram] Done. >=20 > In Section 3.2, the Signature Length within the Signature Segment does = not count the length field itself. It seems that all of the other = length values in this specification count the size of the length too. > Consistency will avoid implementation errors. >=20 > [Sriram] I have followed your suggestion to put this out on the SIDR = list for Comments.=20 > Please see Oliver's response on the SIDR list. Let us see if anyone = else comments. >=20 > Section 4.2 references the MP_REACH_NLRI attribute; please add a = citation to the RFC that defines that attribute. >=20 >=20 > [Sriram] Done. RFC7460 added as citation. >=20 > Nits >=20 > Section 2.1 says: >=20 > The second and third octets contain the 16-bit Address Family > Identifier (AFI) which indicates the address family for which the > BGPsec speaker is advertising support for BGPsec. This document = only > specifies BGPsec for use with two address families, IPv4 and IPv6, > AFI values 1 and 2 respectively. BGPsec for use with other address > families may be specified in future documents. >=20 > Please reference RFC 4760 for a place to learn about AFI. >=20 > [Sriram] Done. >=20 > In Section 4.1, the comma is in the wrong place, but when I tried to = offer a correction, I thought that a slight rewording would also improve = the clarity: >=20 > OLD: >=20 > If a BGPsec router has received only a non-BGPsec update message > (without the BGPsec_Path attribute), containing the AS_PATH > attribute, from a peer for a given prefix then it MUST NOT ... >=20 > NEW: >=20 > If a BGPsec router has received only a non-BGPsec update message > containing the AS_PATH attribute (instead of the BGPsec_Path > attribute) from a peer for a given prefix, then it MUST NOT ... >=20 > [Sriram] Done. Thank you for providing the better wording for this. >=20 > Please reword the first paragraph of Section 4.2 to avoid the phrase = "said route advertisement". While it is not wrong, it does feel very = awkward. This is not a patent claim. >=20 > [Sriram] Done. Now the document avoids patent-like usage of "said".=20= >=20 > The acronym "ASN" is not used until Section 4.4, and it is not = expanded there. I suggest that all uses of ASN should be expanded to AS = number. >=20 > [Sriram] Done. >=20 From nobody Thu Dec 29 02:46:14 2016 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A560812940F for ; Thu, 29 Dec 2016 02:46:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Tero Kivinen" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148300837364.30194.10076575418455502211.idtracker@ietfa.amsl.com> Date: Thu, 29 Dec 2016 02:46:13 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 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, 29 Dec 2016 10:46:13 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-01-05 Reviewer LC end Draft Ólafur Guðmundsson 2017-01-03 draft-ietf-ospf-ttz-05 Matt Lepinski 2016-12-14 draft-ietf-avtext-avpf-ccm-layered-03 Eric Osterweil 2016-12-19 draft-ietf-i2rs-yang-network-topo-09 Rich Salz 2016-12-21 draft-ietf-sidr-bgpsec-ops-12 Yaron Sheffer 2016-12-19 draft-ietf-sidr-bgpsec-pki-profiles-18 For telechat 2017-01-19 Reviewer LC end Draft Derek Atkins 2017-01-06 draft-ietf-6man-rdnss-rfc6106bis-14 Shaun Cooley 2017-01-11 draft-ietf-rtgwg-rlfa-node-protection-09 Donald Eastlake 2017-01-11 draft-ietf-nvo3-use-case-15 Shawn Emery 2017-01-10 draft-ietf-trill-rfc6439bis-03 Daniel Franke 2017-01-09 draft-ietf-trill-directory-assist-mechanisms-10 Dan Harkins 2017-01-12 draft-ietf-clue-rtp-mapping-10 Paul Hoffman 2017-01-12 draft-ietf-bfcpbis-sdp-ws-uri-07 Carl Wallace 2017-01-11 draft-ietf-bfcpbis-bfcp-websocket-13 David Waltermire 2017-01-10 draft-ietf-sidr-rpki-oob-setup-05 Brian Weis 2017-01-10 draft-ietf-sidr-adverse-actions-03 Paul Wouters 2017-01-06 draft-ietf-sidr-publication-09 Liang Xia 2017-01-06 draft-ietf-ecrit-car-crash-20 Dacheng Zhang 2017-01-06 draft-ietf-ecrit-ecall-21 For telechat 2017-02-02 Reviewer LC end Draft Steve Hanna None draft-ietf-softwire-dslite-multicast-14 Christopher Inacio None draft-ietf-softwire-multicast-prefix-option-11 Hilarie Orman None draft-ietf-i2rs-yang-l3-topology-06 Last calls: Reviewer LC end Draft Alan DeKok 2016-04-30 draft-bradner-rfc3979bis-08 Phillip Hallam-Baker 2016-12-30 draft-ietf-ipsecme-rfc4307bis-15 Christian Huitema 2017-01-06 draft-ietf-kitten-krb-auth-indicator-04 Matthew Miller 2017-01-13 draft-harkins-owe-05 Sandra Murphy 2016-12-20 draft-ietf-6tisch-minimal-17 Melinda Shore 2017-01-09 draft-holmberg-dispatch-mcptt-rp-namespace-03 Hannes Tschofenig 2017-01-16 draft-murchison-webdav-prefer-12 Tina Tsou 2017-01-13 draft-ietf-payload-melpe-04 Sean Turner 2017-01-13 draft-ietf-insipid-logme-reqs-11 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Hannes Tschofenig 2016-03-18 draft-ietf-ntp-cms-for-nts-message-06 Hannes Tschofenig 2016-03-18 draft-ietf-ntp-network-time-security-15 Hannes Tschofenig 2016-03-18 draft-ietf-ntp-using-nts-for-ntp-07 Brian Weis 2016-02-01 draft-ietf-cdni-uri-signing-10 Next in the reviewer rotation: Leif Johansson Simon Josefsson Benjamin Kaduk Charlie Kaufman Scott Kelly Stephen Kent Tero Kivinen Warren Kumari Watson Ladd Ben Laurie From nobody Sat Dec 31 18:19:56 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5101294C5 for ; Sat, 31 Dec 2016 18:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPXjxyGnW_cf for ; Sat, 31 Dec 2016 18:19:53 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 0BFE312947C for ; Sat, 31 Dec 2016 18:19:53 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cNVkV-0000jQ-7x for secdir@ietf.org; Sun, 01 Jan 2017 03:19:52 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cNVkT-0005s3-1u for secdir@ietf.org; Sat, 31 Dec 2016 21:19:50 -0500 Received: (qmail 13791 invoked from network); 1 Jan 2017 02:19:45 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.73]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 1 Jan 2017 02:19:45 -0000 From: "Christian Huitema" To: "'IESG'" , "'secdir'" , Date: Sat, 31 Dec 2016 18:19:43 -0800 Message-ID: <005f01d263d5$84b14680$8e13d380$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdJjz9rthG/Lz73xRBWGGHxi2Ncdfw== Content-Language: en-us X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.13) X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49MJIIgmXWciG0xIgIHG/MnhTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXqvAY+igCPflcnB0OXWJWhURcOb18WfxGyg6Om6u4YYm/7kEmnXo3gOTwoX Y1vmgeM5hjoyEb9Oq0NWpyO3vrfYKtU04a0dsdHkKEFmS31kUD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBkye6uEH7Y2FUSOL4rzI+gxQRCdMNhge1Unb77YyuZq5cyXcOfFJuTWiAUcVUWhq2RBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/pxvnk7PJGygctl3LC86in/6DwZpjxPTx I2S/vwoydU3rc+Iv2rc9L0aEB794CHU7QkUmTDfMv/tVj9RPDK26f1ZS3ljmeFVRIgA8pd5GE2NV TgVI3tePcP+0TP9kyYEYWLqMT076wgjiEYaAeBXL0geYUOp7A73HI6oJg7w/VodqDS3jhFVyYvjB Ar8iUjNZzB9tfY+mOJVw0e2xMRa7D2P5RYOa/miinTReZ5OdasFBlor8ikxQTKPsYxS4ne8tcQkv 3rfK9nOh84B6FNp+WtpjXhV8g5C9ZVdQH0yPWSY= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Recommended-Action: accept Archived-At: Subject: [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2017 02:19:55 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a new type of Authorization Data for the Kerberos protocol. The new data type is used to convey authentication strength information to application services. It is intended to use when implementations support different type of authentication, for example password based, multi-factor, or public keys. The authentication strengths are identified by either an URI identifying a Level of Assurance (LoA) Profile registered with IANA (RFC 6711), or a site-defined string. These identifiers are wrapped in an AD-CAMMAC container defined in RFC 7751. The document is almost ready, by I wish a few issues were addressed before publication. My first issue is that the document describes an update to the Kerberos protocol specification, RFC 4120, but does not define the specific way in which RFC 4120 is updated. Could the draft be updated to include something like the section "6. Assigned Numbers" of RFC 7751? If I understand correctly, the changes are a new ad-type number 97, pointing to a CAMMAC container, in which the "elements" are encoded according to the syntax specified in Appendix A of the draft. Having that explained succinctly would help future readers. My second issue is with the use of site-defined strings. I understand that the site defined strings are defined by the administrator of a realm. What happens if these strings appear outside the original realm, for example in an environment connecting multiple realms? Don't we have a potential there for name collision? Should there not be some guidance to implementers? I note that the proposed short string syntax forbids use of the ":" character in site-defined strings. Did the WG look at the consequences of that choice? If site administrators cannot use the URI like syntax, what is the preferred way of defining unique strings and preventing collisions? What are application services supposed to do when they encounter URI or site-defined strings that they do not understand? The ASN.1 syntax defines the element as a "SEQUENCE OF UTF8String". The document mentions that "Each UTF8String value is a short string". How short exactly should these strings be? How many of them should an application expect in the "SEQUENCE OF" element? The syntax itself does not constrain the length or number of these strings. Are we not worried with potential interoperability issues? Could this be abused in some attacks? Should the security considerations mention that? -- Christian Huitema From nobody Sat Dec 31 18:39:31 2016 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47AF12955B for ; Sat, 31 Dec 2016 18:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TrV-BCnWJwJ for ; Sat, 31 Dec 2016 18:39:29 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 4B313129555 for ; Sat, 31 Dec 2016 18:39:29 -0800 (PST) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cNW3T-0002h9-Bz for secdir@ietf.org; Sun, 01 Jan 2017 03:39:28 +0100 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cNW3R-0003IH-By for secdir@ietf.org; Sat, 31 Dec 2016 21:39:26 -0500 Received: (qmail 31999 invoked from network); 1 Jan 2017 02:39:24 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.73]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 1 Jan 2017 02:39:24 -0000 From: "Christian Huitema" To: "'IESG'" , "'secdir'" , , , References: <005f01d263d5$84b14680$8e13d380$@huitema.net> In-Reply-To: <005f01d263d5$84b14680$8e13d380$@huitema.net> Date: Sat, 31 Dec 2016 18:39:21 -0800 Message-ID: <006f01d263d8$435dc430$ca194c90$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEaPs7iLwqOaTNknblhLQFEtN95CaKTMiaw Content-Language: en-us X-Originating-IP: 168.144.250.234 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.08) X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49FXKwZbSflcvTu2SSy6NnOlTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXqYq0msVkaLEgmxlAUfxVw4RcOb18WfxGyg6Om6u4YYm+3vXoyqU0cY7/gz Mk/VdBQ5hjoyEb9Oq0NWpyO3vrfYzS02aeiYw+GANPqwVsDMNz3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBcKaDTe3QRRhTm1Fh3Md1txQRCdMNhge1Unb77YyuZq7g0QgZeqquOR+3jgVIhh/+RBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/pxvnk7PJGygctl3LC86in/6DwZpjxPTx I2S/vwoydU2Z0wfN9VTx9JdR4F4pphrEJ0EukYkH0+QwgTkvGReJqS3AA1zi4L4OJ0M18xnuBW/6 592ULW4vfh/b1HrXegYtT+0ZYmWVDcilzOi/IsK0IJxMmrh0EB+IMLHqHSY3hiG6elFFgxvixKHD +ndZqoQq0JFb5sY5yvsuaKnQYvhP+274nM+117vLjWiTA8zC3e5qTjAEzQR26Rr0dPOgWImrJASn HPpo89VhQ79BRQQ5y0H9asyhHPHrk1fOl/Hbtww= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Recommended-Action: accept Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2017 02:39:31 -0000 Copying to Nathan Kinder and Nathaniel McCallum, since their mail server rejects messages relayed by the IETF server. -----Original Message----- From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Christian Huitema Sent: Saturday, December 31, 2016 6:20 PM To: 'IESG' ; 'secdir' ; draft-ietf-kitten-krb-auth-indicator.all@ietf.org Subject: [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a new type of Authorization Data for the Kerberos protocol. The new data type is used to convey authentication strength information to application services. It is intended to use when implementations support different type of authentication, for example password based, multi-factor, or public keys. The authentication strengths are identified by either an URI identifying a Level of Assurance (LoA) Profile registered with IANA (RFC 6711), or a site-defined string. These identifiers are wrapped in an AD-CAMMAC container defined in RFC 7751. The document is almost ready, by I wish a few issues were addressed before publication. My first issue is that the document describes an update to the Kerberos protocol specification, RFC 4120, but does not define the specific way in which RFC 4120 is updated. Could the draft be updated to include something like the section "6. Assigned Numbers" of RFC 7751? If I understand correctly, the changes are a new ad-type number 97, pointing to a CAMMAC container, in which the "elements" are encoded according to the syntax specified in Appendix A of the draft. Having that explained succinctly would help future readers. My second issue is with the use of site-defined strings. I understand that the site defined strings are defined by the administrator of a realm. What happens if these strings appear outside the original realm, for example in an environment connecting multiple realms? Don't we have a potential there for name collision? Should there not be some guidance to implementers? I note that the proposed short string syntax forbids use of the ":" character in site-defined strings. Did the WG look at the consequences of that choice? If site administrators cannot use the URI like syntax, what is the preferred way of defining unique strings and preventing collisions? What are application services supposed to do when they encounter URI or site-defined strings that they do not understand? The ASN.1 syntax defines the element as a "SEQUENCE OF UTF8String". The document mentions that "Each UTF8String value is a short string". How short exactly should these strings be? How many of them should an application expect in the "SEQUENCE OF" element? The syntax itself does not constrain the length or number of these strings. Are we not worried with potential interoperability issues? Could this be abused in some attacks? Should the security considerations mention that? -- Christian Huitema _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview