From nobody Mon Mar 3 09:42:44 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885FF1A0313; Mon, 3 Mar 2014 09:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVeNkU0BwdZM; Mon, 3 Mar 2014 09:42:38 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC9A1A0312; Mon, 3 Mar 2014 09:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3420; q=dns/txt; s=iport; t=1393868555; x=1395078155; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=2rMa2rs9I0jlISm9Sgfv9BucZxWrx/cxrdcIrMD2rhU=; b=KBNaLJPCBe7zqWDo4e5/uuunKp5PF/mDyXDB6ArJN9pB/K3XGcZ6hc8k 2W8yji9PIZlFdcCxvEW+q0fEwpjs4EXW0y2LUyNUsPpQj2ZXAfz/BOGdK x+BggH7NaCHM3tS6oXMCMfXwIKJsZe7EVRqObmCWLqhcStrMfgy0/ZtAt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAOG+FFOQ/khN/2dsb2JhbABagwbBZIEkFnSCJgEBBDhAEQsOExYPCQMCAQIBRQYBDAgBARCHZcw6F44LVYQ4AQOYPIZKi2GDLTw X-IronPort-AV: E=Sophos;i="4.97,578,1389744000"; d="scan'208";a="2219650" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-3.cisco.com with ESMTP; 03 Mar 2014 17:42:34 +0000 Received: from [10.61.192.27] ([10.61.192.27]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s23HgXK4011782; Mon, 3 Mar 2014 17:42:33 GMT Message-ID: <5314BF09.9020001@cisco.com> Date: Mon, 03 Mar 2014 17:42:33 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Yoav Nir , "" , " IESG" , "draft-ietf-eman-framework.all@tools.ietf.org" References: <523EEFE5-315C-4A49-B802-1F7C31B7ADD9@checkpoint.com> In-Reply-To: <523EEFE5-315C-4A49-B802-1F7C31B7ADD9@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/0pPybIz7HGHL9OdeZmfhf3Bm3Is Subject: Re: [secdir] SECDIR review of draft-ietf-eman-framework-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 17:42:40 -0000 Hi Yoav, Thanks for your review. Unfortunately, you have reviewed version 7 and we're now at version 15. However, some of your comments were still applicable. See in-line. > 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. > > Although I am reviewing this for SECDIR, I have to begin with some editorial remarks. I don't know what tool was used, but it's producing a very ill-formatted draft. It's true that the RFC editor staff will get it right, but it is apparent that this is a combination of several sources. See for example section 2 for a jarring mixture of line lengths. Or the broken-in-half artwork of Figure 1 at the bottom of page 14. When you do that, someone (that's the RFC editor) has to put your diagrams back together, an error-prone process that should be done by the authors. > > The middle of section 1 has a paragraph whose entire text is "Energy Management Documents Overview". Was this supposed to be the title to a subsection? > > The document also contains some parts that are supposed to be removed before publication, for example the URL to the issue tracker. Please add a label like "RFC EDITOR NOTE: REMOVE THE FOLLOWING PARAGRAPH" before this. They know to look for it, and we don't end up with things we didn't want in the draft. > > Speaking of issues, I followed that URL, and found that it is showing three open issues. Are these resolved? > > I confess to being totally ignorant of the subject matter, but reading through this I noticed something that surprised me. In section 3.1 there is this paragraph: > A simple device such as a light bulb can be switched on or off > only by switching its power supply. More complex devices may > have the ability to switch off themselves or to bring > themselves to states in which they consume very little power. > Is the "may" here appropriate? Don't these complex devices *require* that they switch themselves off rather than have their power switched off? changed "may" to "will" to all cases. > > Finally, the security considerations section. The most important recommendation there is to use SNMPv3, because it includes authentication and privacy, unlike earlier versions. I agree with the recommendation, but it should be noted that authentication was part of SNMPv1 as well, although different mechanisms (not based on community strings) were only added in SNMPv3. "Privacy" is a loaded term with multiple meanings. In SNMP privacy simply means confidentiality, and it's preferable to use that term rather than "privacy" which today is no longer used interchangeably with confidentiality. changed. Version 16, addressing your comments, will be posted shortly. Regards, Benoit > > The section does an OK job of enumerating the risks, but IMO downplays them. For example, "Unauthorized changes to the Energy Management Domain or business context of an Energy Object may result in misreporting or interruption of power." There's no "may" about it. If an attacker can modify the energy management domain, then they can at least shut down the network. > > Yoav > > > > > . > From nobody Mon Mar 3 11:07:52 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4851A00AD; Mon, 3 Mar 2014 11:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tET-mwG5LnJO; Mon, 3 Mar 2014 11:07:45 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 04CEB1A01E7; Mon, 3 Mar 2014 11:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=841; q=dns/txt; s=iport; t=1393873662; x=1395083262; h=date:from:to:subject:message-id:mime-version:content-id; bh=+o3CZ8J4eYy3A0S2b6l9BIaaJ8jHSoh9eB5fP8OsPXg=; b=Iw3MhZRsqCQDvJR/pkZ5Jk8wT1c2OjvSsu9iuiAGb94QIPKO8Aadi+Iy Wwpep1ECrK/kO8J5/l7G2rEFL6GYFZMiUabd8AhsHDjqUx5NtBIBWrthC gS+GWT/zYdj/ZqHPGc6L+2VmkpyGqtT3b2fok0ezFog7t1o5PWK4VRjzY 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAN7RFFOrRDoG/2dsb2JhbABagwbDCxZ0gmQCgX6ICsxDF5MYBIlLoRyDTg X-IronPort-AV: E=Sophos;i="4.97,579,1389744000"; d="scan'208";a="107472158" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 03 Mar 2014 19:07:42 +0000 Received: from sjc-xdm-112 (sjc-xdm-112.cisco.com [171.71.188.44]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s23J7fDq003054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Mar 2014 19:07:41 GMT Date: Mon, 3 Mar 2014 11:07:41 -0800 (PST) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dhc-dhcpv6-unknown-msg.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/heUHnAGn6tzrBYXUQ6bCpsJlt7A Subject: [secdir] SECDIR review of draft-ietf-dhc-dhcpv6-unknown-msg-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 19:07:46 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written 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 looks to be well thought out and almost complete. I would like to see a statement in the Security Considerations section that this specification adheres to the Security Considerations section of RFC 3315, and augments it by describing the disposition of unknown messages. Other than that, the only very minor nit that I have is that the second and third paragraphs of the Security Considerations section are a single thought and should be combined. Thanks, Chris From nobody Mon Mar 3 23:41:26 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7E31A03C3; Mon, 3 Mar 2014 23:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYWuKmO9qggs; Mon, 3 Mar 2014 23:41:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C38581A03AC; Mon, 3 Mar 2014 23:41:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEF08651; Tue, 04 Mar 2014 07:41:08 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Mar 2014 07:40:37 +0000 Received: from SZXEML452-HUB.china.huawei.com (10.82.67.195) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Mar 2014 07:41:03 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.77]) by szxeml452-hub.china.huawei.com ([10.82.67.195]) with mapi id 14.03.0158.001; Tue, 4 Mar 2014 15:40:51 +0800 From: Tina TSOU To: Linda Dunbar Thread-Topic: SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07 Thread-Index: AQHPKfsc65F4O1ntVkqzN1q05nHFcJrAX++QgAAGE6CADsvlkP//o8EA Date: Tue, 4 Mar 2014 07:40:51 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645CBE303@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645CBE303@dfweml701-chm.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FFA8BFED259D44838EA5124F65A403ABhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Ea-ea6VErvk3FmS5-5O6ASSY5bg Cc: "draft-dunbar-arms-arp-nd-scalling-practices.all@tools.ietf.org" , "Org Iesg@Ietf." , "Org Secdir@Ietf." Subject: Re: [secdir] SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 07:41:18 -0000 --_000_FFA8BFED259D44838EA5124F65A403ABhuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBMaW5kYSwNCg0KVGhlIGNoYW5nZXMgYXJlIE9LIHRvIG1lLg0KDQpJbiBhZGRpdGlvbiwg dGhlIHN1YmplY3QgZHJhZnQgcHJvdmlkZXMgYSBicmllZiBkZXNjcmlwdGlvbiBvZiBjb21tb24g ZGF0YSBjZW50ZXIgbmV0d29yayBkZXNpZ25zIGZvciBjb250ZXh0LCBleGFtaW5lcyB0aGUgQVJQ L05EIHNjYWxpbmcgaXNzdWVzIHRoYXQgYXJpc2UgaW4gdGhlc2UgZGVzaWducywgYW5kIGNvbmNs dWRlcyB0aGF0IHRoZSBrZXkgaXNzdWUgaXMgcHJvY2Vzc2luZyBsb2FkIG9uIHRoZSBMMi9MMyBi b3VuZGFyeSByb3V0ZXJzLiBJdCB0aGVuIHByb2NlZWRzIHRvIGRlc2NyaWJlIHNvbWUgcHJhY3Rp Y2VzIGZvciByZWR1Y2luZyB0aGF0IGxvYWQuIFRoZSBkZXNjcmlwdGlvbiBlbXBsb3lzIGEgbWl4 dHVyZSBvZiBiYXNlcyBmb3IgaXRzIG9yZ2FuaXphdGlvbjoNCg0KKGEpIG5ldHdvcmsgZGVzaWdu IGFwcHJvYWNoDQogLS0gbGF5ZXIgMyB0byBhY2Nlc3Mgc3dpdGNoZXMgb3IgVk1zIChzZWMuIDQp DQogLS0gbGF5ZXIgMiBtZWFzdXJlcyAoc2VjLiA1LjEpDQogLS0gc3RhdGljIEFSUC9ORCBlbnRy aWVzIG9uIHN3aXRjaGVzIChzZWMuIDUuMikNCiAtLSBBUlAvTkQgcHJveHlpbmcgKHNlYy4gNS4z KQ0KIC0tIG92ZXJsYXkgbW9kZWxzIChzZWMuIDYpDQoNCihiKSBpbmRpdmlkdWFsIGNhc2VzIChz ZWNzLiA1LjEuMSwgNS4xLjIsIDUuMS4zKQ0KDQooYykgSVB2NCBBUlAgdnMuIElQdjYgTkQgKGlu dGVyc3BlcnNlZCBpbiBhbGwgc2VjdGlvbnMgbWVudGlvbmVkIGFib3ZlIGV4Y2VwdCBzZWMuIDYu IEluIGFkZGl0aW9uLCBzZWMuIDUuNCBkaXNjdXNzZXMgbXVsdGljYXN0IGlzc3VlcyBhbmQgaXMg dGh1cyBzcGVjaWZpY2FsbHkgcmVsYXRlZCB0byBORC4pDQoNCkJlY2F1c2Ugb2YgdGhlIGRpZmZl cmVuY2VzIGJldHdlZW4gQVJQIGFuZCBORCBhbmQgcmVzdWx0aW5nIGFwcGxpY2FiaWxpdHkgb2Yg dGhlIGRpZmZlcmVudCBtZWFzdXJlcyBkZXNjcmliZWQgaW4gc2VjdGlvbnMgNC02LCB0aGUgcmV2 aWV3ZXIncyByZWNvbW1lbmRhdGlvbiB3b3VsZCBiZSB0byByZW9yZ2FuaXplIHRoZSB0ZXh0IGJ5 IHB1bGxpbmcgQVJQLXNwZWNpZmljIGFuZCBORC1zcGVjaWZpYyBkaXNjdXNzaW9ucyBpbnRvIHNl cGFyYXRlIHNlY3Rpb25zIG9mIHRoZWlyIG93biByZWZlcnJpbmcgYmFjayB0byB0aGUgcmVtYWlu aW5nIHRleHQuIEluIHRoaXMgd2F5IHNlYy4gNS40IGluIHBhcnRpY3VsYXIgd291bGQgZml0IG1v cmUgbmVhdGx5IGludG8gdGhlIGZyYW1ld29yay4gTW9yZSBpbXBvcnRhbnRseSwgaXQgd291bGQg YmVjb21lIGNsZWFyIHRoYXQgc2NhbGFiaWxpdHkgb2YgSVB2NiBORCBuZWVkcyBtb3JlIHdvcmsu DQoNCkl0IGlzIGludGVyZXN0aW5nIHRvIG5vdGUgdGhhdCBpbXByb3ZpbmcgdGhlIHNjYWxhYmls aXR5IG9mIE5EIGlzIGEgbWF0dGVyIHVuZGVyIGFjdGl2ZSBkaXNjdXNzaW9uIGluIDZtYW4gYW5k IHY2b3BzIGJ1dCBwYXJ0bHkgZnJvbSBhIGRpZmZlcmVudCBhbmdsZTogY29waW5nIHdpdGggYmF0 dGVyeS1saW1pdGVkIGRldmljZXMgdGhhdCBhcmUgbm90IGFsd2F5cyBhd2FrZS4gSW5mb3JtYXRp b25hbCByZWZlcmVuY2VzIHRvIHRoZSByZWxldmFudCBkcmFmdHMgKGRyYWZ0LWNoYWtyYWJhcnRp LW5vcmRtYXJrLTZtYW4tZWZmaWNpZW50LW5kLTA1LCBkcmFmdC15b3VydGNoZW5rby1jb2xpdHRp LW5kLXJlZHVjZS1tdWx0aWNhc3QtMDAsIGFuZCBkcmFmdC12eW5ja2UtNm1hbi1tY2FzdC1ub3Qt ZWZmaWNpZW50LTAxKSBtYXkgYmUgdXNlZnVsIHRvIGFkZC4NCg0KVGhlIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zIHNlY3Rpb24gaXMgY3VycmVudGx5IGp1c3QgYSAnbW90aGVyaG9vZCdzdGF0ZW1l bnQuIFNwZWNpZmljIHBvaW50cyBhcmUgcmFpc2VkIGluIHRoZSBib2R5IG9mIHRoZSB0ZXh0LCBz dWNoIGFzIHRoZSByZWxhdGlvbnNoaXAgb2YgdGhlIGJpZGlyZWN0aW9uYWwgbmF0dXJlIG9mIE5E IHRvIHRoZSBjb3JyZWN0IG9wZXJhdGlvbiBvZiBTZU5ELiBBbnkgc3VjaCBzcGVjaWZpYyBwb2lu dHMgc2hvdWxkIGJlIHJlZmxlY3RlZCBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2Vj dGlvbiB0b28uDQoNCk5pdHMNCj09PT0NCg0KLS0gU2VjdGlvbiA1LjEgc2VjdGlvbiBoZWFkZXI6 IHMvQVBSL0FSUC8NCg0KLS0gU2VjdGlvbiA3IGZpcnN0IGJ1bGxldCBsYXN0IHNlbnRlbmNlOg0K DQpPTEQNCg0KIiAuLi4gIHRvIGhhdmUgY29tcHJlaGVuc2l2ZSBzdHVkeSBpbiBtYWtpbmcgdGhv c2UgY2hhbmdlcy4iDQoNCk5FVw0KDQoiIC4uLiB0byBtYWtlIHRob3NlIGNoYW5nZXMgb25seSBh ZnRlciBjb21wcmVoZW5zaXZlIHN0dWR5LiINCg0KLS0gU2VjdGlvbiA3IHNlY29uZCBidWxsZXQ6 IHMvQ3JlYXRlIGFuL0NyZWF0ZS8NCg0KLS0gUmVmZXJlbmNlcyBuZWVkIHVwZGF0aW5nIHRvIG1v c3QgcmVjZW50IHZlcnNpb25zLg0KDQoNClRoYW5rIHlvdSwNClRpbmENCg0KDQpGcm9tOiBMaW5k YSBEdW5iYXINClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjEsIDIwMTQgNTozMiBQTQ0KVG86IFRp bmEgVFNPVTsgJ3NlY2RpckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPic7ICdpZXNn QGlldGYub3JnPG1haWx0bzppZXNnQGlldGYub3JnPic7ICdkcmFmdC1kdW5iYXItYXJtZC1hcnAt bmQtc2NhbGluZy1wcmFjdGljZXNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWR1bmJhci1h cm1kLWFycC1uZC1zY2FsaW5nLXByYWN0aWNlc0B0b29scy5pZXRmLm9yZz4nDQpTdWJqZWN0OiBS RTogU0VDRElSIGVhcmx5IHJldmlldyBvZiBkcmFmdC1kdW5iYXItYXJtZC1hcnAtbmQtc2NhbGlu Zy1wcmFjdGljZXMtMDcNCg0KVGluYSwNCg0KUGxlYXNlIHNlZSB0aGUgYXR0YWNoZWQgMDggdmVy c2lvbiBmb3IgdGhlIGNoYW5nZXMgdG8gYWRkcmVzcyB5b3VyIGNvbW1lbnRzLiBQbGVhc2UgbGV0 IG1lIGtub3cgaWYgdGhleSBhcmUgT0suDQoNClRoYW5rcywgTGluZGENCg0KRnJvbTogTGluZGEg RHVuYmFyDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDIxLCAyMDE0IDU6MjcgUE0NClRvOiBUaW5h IFRTT1U7IHNlY2RpckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPjsgaWVzZ0BpZXRm Lm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz47IGRyYWZ0LWR1bmJhci1hcm1kLWFycC1uZC1zY2Fs aW5nLXByYWN0aWNlc0B0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtZHVuYmFyLWFybWQtYXJw LW5kLXNjYWxpbmctcHJhY3RpY2VzQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogUkU6IFNFQ0RJ UiBlYXJseSByZXZpZXcgb2YgZHJhZnQtZHVuYmFyLWFybWQtYXJwLW5kLXNjYWxpbmctcHJhY3Rp Y2VzLTA3DQoNClRpbmEsDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSByZXZpZXcuDQoN ClJlcGxpZXMgYXJlIGluc2VydGVkIGJlbG93DQoNCkZyb206IFRpbmEgVFNPVSBbbWFpbHRvOlRp bmEuVHNvdS5ab3V0aW5nQGh1YXdlaS5jb21dDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDE0LCAy MDE0IDk6MDggUE0NClRvOiBzZWNkaXJAaWV0Zi5vcmc8bWFpbHRvOnNlY2RpckBpZXRmLm9yZz47 IGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+OyBkcmFmdC1kdW5iYXItYXJtZC1h cnAtbmQtc2NhbGluZy1wcmFjdGljZXNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWR1bmJh ci1hcm1kLWFycC1uZC1zY2FsaW5nLXByYWN0aWNlc0B0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6 IFNFQ0RJUiBlYXJseSByZXZpZXcgb2YgZHJhZnQtZHVuYmFyLWFybWQtYXJwLW5kLXNjYWxpbmct cHJhY3RpY2VzLTA3DQoNCkRlYXIgIGFsbCwNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50 IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8g Zm9yIGVhcmx5IHJldmlldyBvZiBXRyBkcmFmdHMuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0 ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3Rv cnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCB3b3JraW5nIGdyb3VwIGNoYWlycyBzaG91bGQgdHJl YXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBjb21tZW50cy4NCg0KU2VjdGlv biAxOg0KUGxlYXNlIGV4cGFuZCBUb1IgdXBvbiBmaXJzdCBvY2N1cnJlbmNlLg0KW0xpbmRhXSBU b1IgaXMgYWxyZWFkeSBkZWZpbmVkIGluIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uLiBJcyBpdCBz dGlsbCBuZWNlc3NhcnkgdG8gZXhwYW5kPw0KDQpTZWN0aW9uIDIsIHBhZ2UgMy80Og0KQ291bGQg eW91IHBsZWFzZSBjbGFyaWZ5IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gIm5vZGUiIGFuZCAiZW5k IHN0YXRpb24iPyBBcmUgdGhleSBzeW5vbnltcz8NCltMaW5kYV0gTm9kZSBjYW4gYmUgc3dpdGNo ZXMvcm91dGVycy4g4oCcZW5kIHN0YXRpb27igJ0gZG9lc27igJl0IHJvdXRlIG9yIGZvcndhcmQg dHJhZmZpYy4gUGFja2V0cyBhcmUgdGVybWluYXRlZCBieSDigJxlbmQgc3RhdGlvbuKAnS4NCg0K DQoNClNlY3Rpb24gNS4xLjE6DQoNClNob3VsZG4ndCBpdCBiZSBwb3NzaWJsZSB0byBhdm9pZCBO RCBsb2FkIGJ5IHByb3BlciBzZXR0aW5nIG9mIHRoZSBSZWFjaGFibGVUaW1lIHZhcmlhYmxlPyAt LSBUaGlzIHdvdWxkbid0IHJlcXVpcmUgYW55IHByb3RvY29sIGNoYW5nZXMuDQoNCltMaW5kYV0g RG8geW91IG1lYW4gY2hhbmdpbmcgdGhlIHNldHRpbmcgb24gR3Vlc3RPUz8gVGhlIGlzc3VlIGlz IHRoYXQgbWFueSBHdWVzdCBPU3MgYXJlIG91dCBvZiBuZXR3b3Jr4oCZcyBjb250cm9sLiBJZiBO ZXR3b3JrIGNhbiBjb250cm9sIEd1ZXN0IE9T4oCZcyBiZWhhdmlvciwgbWFueSB0aGluZ3MgY2Fu IGJlIGVhc2llci4NCg0KDQpTZWN0aW9uIDUuMS4xOg0KDQpTbm9vcGluZyBBUlAgcGFja2V0cyBw cm9iYWJseSBtZWFucyBpbmNyZWFzZWQgbG9hZCAoYSBkaXNhZHZhbnRhZ2UgeW91IGRpZG4ndCBt ZW50aW9uKS4NCltMaW5kYV0geWVzLCBpdCBpbmNyZWFzZSB0aGUgbG9hZCwgYnV0IGluIGEgY29u dHJvbGxlZCB3YXkuIFNvIHRoZSByb3V0ZXJzIGNhbiBwcm9jZXNzIHRoZW0gd2l0aGluIGl0cyBj YXBhY2l0eS4gU28sIGl0IGlzIG5vdCByZWFsbHkgZGlzYWR2YW50YWdlLg0KDQpTZWN0aW9uIDUu MS4xOg0KDQpXaGVuIGFkZHJlc3MgcmVzb2x1dGlvbiBpcyBuZWVkZWQgdG8gZGVsaXZlciBhIHBh Y2tldCwgc29tZSByb3V0ZXJzIGp1c3QgZHJvcCB0aGUgcGFja2V0IHdoZW4gdGhleSBlbmdhZ2Ug aW4gQVJQIChzZWUgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjI3NCNzZWN0aW9uLTQu Mi4zKS4gVGhlIHNhbWUgaXMgdHJ1ZSBmb3INCklQdjYgTkQuDQoNCltMaW5kYV0gY29ycmVjdC4g VGhlIGJlaGF2aW9yIGlzIGRlc2NyaWJlZCBpbiB0aGUgc2Vjb25kIHBhcmFncmFwaCBvZiBTZWN0 aW9uIDUuMS4yOg0KU29sdXRpb246IFRvIHByb3RlY3QgYSByb3V0ZXIgZnJvbSBiZWluZyBvdmVy YnVyZGVuZWQgYnkgcmVzb2x2aW5nIHRhcmdldCBNQUMgYWRkcmVzc2VzLCBvbmUgc29sdXRpb24g aXMgZm9yIHRoZSByb3V0ZXIgdG8gbGltaXQgdGhlIHJhdGUgb2YgcmVzb2x2aW5nIHRhcmdldCBN QUMgYWRkcmVzc2VzIGZvciBpbmJvdW5kIHRyYWZmaWMgd2hvc2UgdGFyZ2V0IGlzIG5vdCBpbiB0 aGUgcm91dGVy4oCZcyBBUlAvTkQgY2FjaGUuIFdoZW4gdGhlIHJhdGUgaXMgZXhjZWVkZWQsIHRo ZSBpbmNvbWluZyB0cmFmZmljIHdob3NlIHRhcmdldCBpcyBub3QgaW4gdGhlIEFSUC9ORCBjYWNo ZSBpcyBkcm9wcGVkLg0KDQoNClNlY3Rpb24gODoNCg0KV2hpbGUgdGhpcyBkb2N1bWVudCBkb2Vz IG5vdCBpbnRyb2R1Y2UgbmV3IGlzc3VlcyBpdHNlbGYsIGl0IHNob3VsZCBhdCBsZWFzdCBtZW50 aW9uIGhvdyB0aGUgc2FtZSBBUlAvTkQgaXNzdWVzIG1heSBiZSBpbnRlbnRpb25hbGx5IHRyaWdn ZXJlZCBieSBhbiBhdHRhY2tlci4gRm9yIGV4YW1wbGUsIHlvdSBtYXkgcmVmZXJlbmNlIFJGQyA2 NTgzDQoNCltMaW5kYV0gU3VyZS4gV2lsbCBhZGQgaW4gdGhlIG5ldyB2ZXJzaW9uLg0KDQoqIE5p dHMNCg0KU2VjdGlvbiA0LCBwYWdlIDQ6DQo+IFRoZXJlIGFyZSBubyBhZGRyZXNzDQo+ICAgIHJl c29sdXRpb24gaXNzdWUgaW4gdGhpcyBkZXNpZ24uDQoNClJlcGxhY2UgImlzc3VlIiB3aXRoICJp c3N1ZXMiDQpbTGluZGFdIEluIHRoZSBsYXRlc3QgZHJhZnQgKCAwNyB2ZXJzaW9uOiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItYXJtZC1hcnAtbmQtc2NhbGlu Zy1wcmFjdGljZXMvKSwgaXQgaXMgYWxyZWFkeSBjaGFuZ2VkOg0KDQpUaGVyZSBpcyBubyBhZGRy ZXNzIHJlc29sdXRpb24gaXNzdWUgaW4gdGhpcyBkZXNpZ24uDQoNCg0KDQpTZWN0aW9uIDUuMS4x LCBwYWdlIDU6DQoNCiJJcHY2IiAtPiAiSVB2NiINCg0KW0xpbmRhIF0gSW4gdGhlIGxhdGVzdCBk cmFmdCAoMDcgdmVyc2lvbiksIGl0IGlzIGFscmVhZHkgY2hhbmdlZC4NCg0KDQpTZWN0aW9uIDUu MS4yOg0KDQpQbGVhc2UgZXhwYW5kIFVOQSAocG9zc2libHkgaW4gdGhlIHRlcm1pbm9sb2d5IHNl Y3Rpb24pIC0tIHlvdSBwcm9iYWJseSBtZWFuICJVbnNvbGljaXRlZC4uIiwgYnV0IHRoaXMgc2hv dWxkIGJlIGV4cGxpY2l0Lg0KW0xpbmRhXSBpbiB0aGUgbGF0ZXN0IGRyYWZ0ICgwNyB2ZXJzaW9u KSwgVU5BIGlzIGFscmVhZHkgbGlzdGVkIHVuZGVyIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uLg0K DQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgcmV2aWV3IGFuZCBjb21tZW50cy4NCg0KTGlu ZGENCg0KVGhhbmsgeW91LA0KVGluYQ0KDQpGcm9tOiBzZWNkaXIgW21haWx0bzpzZWNkaXItYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hdHRoZXcgTGVwaW5za2kNClNlbnQ6IEZyaWRh eSwgRmVicnVhcnkgMTQsIDIwMTQgMjo1MiBBTQ0KVG86IHNlY2RpckBpZXRmLm9yZzxtYWlsdG86 c2VjZGlyQGlldGYub3JnPjsgaWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz47IGRy YWZ0LWhvdXNsZXktcGtpeC1vaWRzLmFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaG91 c2xleS1wa2l4LW9pZHMuYWxsQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogW3NlY2Rpcl0gU0VD RElSIHJldmlldyBvZiBkcmFmdC1ob3VzbGV5LXBraXgtb2lkcw0KDQpJIGhhdmUgcmV2aWV3ZWQg dGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29p bmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5 IHRoZSBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhl IGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9y cyBhbmQgd29ya2luZyBncm91cCBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1 c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpUaGlzIGRvY3VtZW50IHJl dHVybnMgY29udHJvbCBvZiB0aGUgUEtJWCBvYmplY3QgaWRlbnRpZmllciBhcmMgdG8gSUFOQS4g VGhhdCBpcywgaXQgZXN0YWJsaXNoZXMgYSBuZXcgSUFOQSByZWdpc3RyeSBmb3IgT0lEcyBpbiB0 aGUgUEtJWCBhcmMgYW5kIHBvcHVsYXRlcyB0aGF0IHJlZ2lzdHJ5IHdpdGggdGhlIGV4aXN0aW5n IE9JRCBhc3NpZ25tZW50cy4gRmluYWxseSwgdGhlIGRvY3VtZW50IGVzdGFibGlzaGVzIGV4cGVy dCByZXZpZXcgYXMgdGhlIGNyaXRlcmlhIGZvciBmdXR1cmUgYWRkaXRpb25zIHRvIHRoZSByZWdp c3RyeSBhbmQgaW5jbHVkZXMgZ3VpZGFuY2UgdGhhdCBmb3IgcmV2aWV3Lg0KDQpBZnRlciByZXZp ZXdpbmcgdGhlIGRvY3VtZW50LCBJIGFncmVlIHdpdGggdGhlIGF1dGhvciB0aGF0IHRoaXMgZG9j dW1lbnQgaW50cm9kdWNlcyBubyBuZXcgc2VjdXJpdHkgY29uY2VybnMuDQoNCkkgZm91bmQgbm8g aXNzdWVzIGluIHRoZSBkb2N1bWVudCBhbmQgSSBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJs aWNhdGlvbi4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpOaXRzDQoNClRo ZSBhdXRob3Igc2hvdWxkIGNvbnNpZGVyIGluY2x1ZGluZyBhbiBleHBhbnNpb24gb2YgdGhlIGFj cm9ueW0gU01JLCB3aGljaCBpcyB1c2VkIGZyZXF1ZW50bHkgaW4gdGhlIGRvY3VtZW50LiAoSSBi ZWxpZXZlIGluIHRoaXMgY29udGV4dCBTTUkgPSBTdHJ1Y3R1cmUgb2YgTWFuYWdlbWVudCBJbmZv cm1hdGlvbikNCg0KSW4gU2VjdGlvbiAzOg0Kcy9iZSByZWxhdGVkIHRvIFguNTA5IGNlcnRpZmlj YXRlL2JlIHJlbGF0ZWQgdG8gWC41MDkgY2VydGlmaWNhdGVzLw0KDQpJbiBTZWN0aW9uIDMuMToN CnMvdG8gcG9pbnRzIHRvIHRoaXMgZG9jdW1lbnQvdG8gcG9pbnQgdG8gdGhpcyBkb2N1bWVudC8N Cg0KDQoNCjxkcmFmdC1kdW5iYXItYXJtZC1hcnAtbmQtc2NhbGluZy1wcmFjdGljZXMtMDguZG9j eD4NCg== --_000_FFA8BFED259D44838EA5124F65A403ABhuaweicom_ Content-Type: text/html; charset="utf-8" Content-ID: <2C09CB00D79B254E8EA872F577BA5AC2@huawei.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2IHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxM3B0OyI+RGVhciBMaW5kYSw8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSIt d2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsiPlRoZSBjaGFuZ2VzIGFyZSBPSyB0byBt ZS48L2Rpdj4NCjxkaXYgc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsiPjxi cj4NCjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBh dXRvOyI+SW4gYWRkaXRpb24sIHQ8L3NwYW4+PHNwYW4gc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsi PmhlIHN1YmplY3QgZHJhZnQgcHJvdmlkZXMgYSBicmllZiBkZXNjcmlwdGlvbiBvZiBjb21tb24g ZGF0YSBjZW50ZXIgbmV0d29yayBkZXNpZ25zIGZvciBjb250ZXh0LA0KIGV4YW1pbmVzIHRoZSBB UlAvTkQgc2NhbGluZyBpc3N1ZXMgdGhhdCBhcmlzZSBpbiB0aGVzZSBkZXNpZ25zLCBhbmQgY29u Y2x1ZGVzIHRoYXQgdGhlIGtleSBpc3N1ZSBpcyBwcm9jZXNzaW5nIGxvYWQgb24gdGhlIEwyL0wz IGJvdW5kYXJ5IHJvdXRlcnMuIEl0IHRoZW4gcHJvY2VlZHMgdG8gZGVzY3JpYmUgc29tZSBwcmFj dGljZXMgZm9yIHJlZHVjaW5nIHRoYXQgbG9hZC4gVGhlIGRlc2NyaXB0aW9uIGVtcGxveXMgYSBt aXh0dXJlIG9mIGJhc2VzDQogZm9yIGl0cyBvcmdhbml6YXRpb246PGJyPg0KPGJyPg0KKGEpIG5l dHdvcmsgZGVzaWduIGFwcHJvYWNoPGJyPg0KJm5ic3A7LS0gbGF5ZXIgMyB0byBhY2Nlc3Mgc3dp dGNoZXMgb3IgVk1zIChzZWMuIDQpPGJyPg0KJm5ic3A7LS0gbGF5ZXIgMiBtZWFzdXJlcyAoc2Vj LiA1LjEpPGJyPg0KJm5ic3A7LS0gc3RhdGljIEFSUC9ORCBlbnRyaWVzIG9uIHN3aXRjaGVzIChz ZWMuIDUuMik8YnI+DQombmJzcDstLSBBUlAvTkQgcHJveHlpbmcgKHNlYy4gNS4zKTxicj4NCiZu YnNwOy0tIG92ZXJsYXkgbW9kZWxzIChzZWMuIDYpPGJyPg0KPGJyPg0KKGIpIGluZGl2aWR1YWwg Y2FzZXMgKHNlY3MuIDUuMS4xLCA1LjEuMiwgNS4xLjMpPGJyPg0KPGJyPg0KKGMpIElQdjQgQVJQ IHZzLiBJUHY2IE5EIChpbnRlcnNwZXJzZWQgaW4gYWxsIHNlY3Rpb25zIG1lbnRpb25lZCBhYm92 ZSBleGNlcHQgc2VjLiA2LiBJbiBhZGRpdGlvbiwgc2VjLiA1LjQgZGlzY3Vzc2VzIG11bHRpY2Fz dCBpc3N1ZXMgYW5kIGlzIHRodXMgc3BlY2lmaWNhbGx5IHJlbGF0ZWQgdG8gTkQuKTxicj4NCjxi cj4NCkJlY2F1c2Ugb2YgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gQVJQIGFuZCBORCBhbmQgcmVz dWx0aW5nIGFwcGxpY2FiaWxpdHkgb2YgdGhlIGRpZmZlcmVudCBtZWFzdXJlcyBkZXNjcmliZWQg aW4gc2VjdGlvbnMgNC02LCB0aGUgcmV2aWV3ZXIncyByZWNvbW1lbmRhdGlvbiB3b3VsZCBiZSB0 byByZW9yZ2FuaXplIHRoZSB0ZXh0IGJ5IHB1bGxpbmcgQVJQLXNwZWNpZmljIGFuZCBORC1zcGVj aWZpYyBkaXNjdXNzaW9ucyBpbnRvIHNlcGFyYXRlIHNlY3Rpb25zDQogb2YgdGhlaXIgb3duIHJl ZmVycmluZyBiYWNrIHRvIHRoZSByZW1haW5pbmcgdGV4dC4gSW4gdGhpcyB3YXkgc2VjLiA1LjQg aW4gcGFydGljdWxhciB3b3VsZCBmaXQgbW9yZSBuZWF0bHkgaW50byB0aGUgZnJhbWV3b3JrLiBN b3JlIGltcG9ydGFudGx5LCBpdCB3b3VsZCBiZWNvbWUgY2xlYXIgdGhhdCBzY2FsYWJpbGl0eSBv ZiBJUHY2IE5EIG5lZWRzIG1vcmUgd29yay48YnI+DQo8YnI+DQpJdCBpcyBpbnRlcmVzdGluZyB0 byBub3RlIHRoYXQgaW1wcm92aW5nIHRoZSBzY2FsYWJpbGl0eSBvZiBORCBpcyBhIG1hdHRlciB1 bmRlciBhY3RpdmUgZGlzY3Vzc2lvbiBpbiA2bWFuIGFuZCB2Nm9wcyBidXQgcGFydGx5IGZyb20g YSBkaWZmZXJlbnQgYW5nbGU6IGNvcGluZyB3aXRoIGJhdHRlcnktbGltaXRlZCBkZXZpY2VzIHRo YXQgYXJlIG5vdCBhbHdheXMgYXdha2UuIEluZm9ybWF0aW9uYWwgcmVmZXJlbmNlcyB0byB0aGUg cmVsZXZhbnQgZHJhZnRzDQogKGRyYWZ0LWNoYWtyYWJhcnRpLW5vcmRtYXJrLTZtYW4tZWZmaWNp ZW50LW5kLTA1LCBkcmFmdC15b3VydGNoZW5rby1jb2xpdHRpLW5kLXJlZHVjZS1tdWx0aWNhc3Qt MDAsIGFuZCBkcmFmdC12eW5ja2UtNm1hbi1tY2FzdC1ub3QtZWZmaWNpZW50LTAxKSBtYXkgYmUg dXNlZnVsIHRvIGFkZC48YnI+DQo8YnI+DQpUaGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2Vj dGlvbiBpcyBjdXJyZW50bHkganVzdCBhICdtb3RoZXJob29kJ3N0YXRlbWVudC4gU3BlY2lmaWMg cG9pbnRzIGFyZSByYWlzZWQgaW4gdGhlIGJvZHkgb2YgdGhlIHRleHQsIHN1Y2ggYXMgdGhlIHJl bGF0aW9uc2hpcCBvZiB0aGUgYmlkaXJlY3Rpb25hbCBuYXR1cmUgb2YgTkQgdG8gdGhlIGNvcnJl Y3Qgb3BlcmF0aW9uIG9mIFNlTkQuIEFueSBzdWNoIHNwZWNpZmljIHBvaW50cyBzaG91bGQgYmUN CiByZWZsZWN0ZWQgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24gdG9vLjxi cj4NCjxicj4NCk5pdHM8YnI+DQo9PT09PGJyPg0KPGJyPg0KLS0gU2VjdGlvbiA1LjEgc2VjdGlv biBoZWFkZXI6IHMvQVBSL0FSUC88YnI+DQo8YnI+DQotLSBTZWN0aW9uIDcgZmlyc3QgYnVsbGV0 IGxhc3Qgc2VudGVuY2U6PGJyPg0KPGJyPg0KT0xEPGJyPg0KPGJyPg0KJnF1b3Q7IC4uLiAmbmJz cDt0byBoYXZlIGNvbXByZWhlbnNpdmUgc3R1ZHkgaW4gbWFraW5nIHRob3NlIGNoYW5nZXMuJnF1 b3Q7PGJyPg0KPGJyPg0KTkVXPGJyPg0KPGJyPg0KJnF1b3Q7IC4uLiB0byBtYWtlIHRob3NlIGNo YW5nZXMgb25seSBhZnRlciBjb21wcmVoZW5zaXZlIHN0dWR5LiZxdW90Ozxicj4NCjxicj4NCi0t IFNlY3Rpb24gNyBzZWNvbmQgYnVsbGV0OiBzL0NyZWF0ZSBhbi9DcmVhdGUvPGJyPg0KPGJyPg0K LS0gUmVmZXJlbmNlcyBuZWVkIHVwZGF0aW5nIHRvIG1vc3QgcmVjZW50IHZlcnNpb25zLjxicj4N Cjwvc3Bhbj4NCjxkaXYgc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsiPjxi cj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyI+ PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 Ij5UaGFuayB5b3UsPC9kaXY+DQo8ZGl2IHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87Ij5UaW5hPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzsiPjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5 bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsiPg0KPGRpdj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBMaW5kYSBEdW5iYXINCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEZl YnJ1YXJ5IDIxLCAyMDE0IDU6MzIgUE08YnI+DQo8Yj5Ubzo8L2I+IFRpbmEgVFNPVTsgJzxhIGhy ZWY9Im1haWx0bzpzZWNkaXJAaWV0Zi5vcmciPnNlY2RpckBpZXRmLm9yZzwvYT4nOyAnPGEgaHJl Zj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+JzsgJzxhIGhyZWY9Im1h aWx0bzpkcmFmdC1kdW5iYXItYXJtZC1hcnAtbmQtc2NhbGluZy1wcmFjdGljZXNAdG9vbHMuaWV0 Zi5vcmciPmRyYWZ0LWR1bmJhci1hcm1kLWFycC1uZC1zY2FsaW5nLXByYWN0aWNlc0B0b29scy5p ZXRmLm9yZzwvYT4nPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBTRUNESVIgZWFybHkgcmV2aWV3 IG9mIGRyYWZ0LWR1bmJhci1hcm1kLWFycC1uZC1zY2FsaW5nLXByYWN0aWNlcy0wNzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaW5hLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QbGVhc2Ugc2VlIHRo ZSBhdHRhY2hlZCAwOCB2ZXJzaW9uIGZvciB0aGUgY2hhbmdlcyB0byBhZGRyZXNzIHlvdXIgY29t bWVudHMuIFBsZWFzZSBsZXQgbWUga25vdyBpZiB0aGV5IGFyZSBPSy4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhh bmtzLCBMaW5kYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExpbmRhIER1bmJhcg0KPGJyPg0KPGI+U2Vu dDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMjEsIDIwMTQgNToyNyBQTTxicj4NCjxiPlRvOjwvYj4g VGluYSBUU09VOyA8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5v cmc8L2E+OyA8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+DQppZXNnQGlldGYub3JnPC9h PjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWR1bmJhci1hcm1kLWFycC1uZC1zY2FsaW5nLXByYWN0 aWNlc0B0b29scy5pZXRmLm9yZyI+DQpkcmFmdC1kdW5iYXItYXJtZC1hcnAtbmQtc2NhbGluZy1w cmFjdGljZXNAdG9vbHMuaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBTRUNE SVIgZWFybHkgcmV2aWV3IG9mIGRyYWZ0LWR1bmJhci1hcm1kLWFycC1uZC1zY2FsaW5nLXByYWN0 aWNlcy0wNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaW5hLA0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgcmV2aWV3Lg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZXBsaWVz IGFyZSBpbnNlcnRlZCBiZWxvdzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRpbmEgVFNPVSBbPGEgaHJl Zj0ibWFpbHRvOlRpbmEuVHNvdS5ab3V0aW5nQGh1YXdlaS5jb20iPm1haWx0bzpUaW5hLlRzb3Uu Wm91dGluZ0BodWF3ZWkuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEZlYnJ1 YXJ5IDE0LCAyMDE0IDk6MDggUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpzZWNk aXJAaWV0Zi5vcmciPnNlY2RpckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppZXNnQGll dGYub3JnIj4NCmllc2dAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtZHVuYmFy LWFybWQtYXJwLW5kLXNjYWxpbmctcHJhY3RpY2VzQHRvb2xzLmlldGYub3JnIj4NCmRyYWZ0LWR1 bmJhci1hcm1kLWFycC1uZC1zY2FsaW5nLXByYWN0aWNlc0B0b29scy5pZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gU0VDRElSIGVhcmx5IHJldmlldyBvZiBkcmFmdC1kdW5iYXItYXJt ZC1hcnAtbmQtc2NhbGluZy1wcmFjdGljZXMtMDc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVhciZuYnNwOyBhbGwsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgaGF2ZSBy ZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRl J3Mgb25nb2luZyBlZmZvcnQgdG8gZm9yIGVhcmx5IHJldmlldyBvZiBXRyBkcmFmdHMuJm5ic3A7 IFRoZXNlIGNvbW1lbnRzDQogd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQg b2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiZuYnNwOyBEb2N1bWVudCBlZGl0b3JzIGFu ZCB3b3JraW5nIGdyb3VwIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBs aWtlIGFueSBvdGhlciBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gMTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIGV4cGFuZCBU b1IgdXBvbiBmaXJzdCBvY2N1cnJlbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojNzAzMEEwIj5bTGluZGFdIFRvUiBpcyBhbHJlYWR5IGRlZmluZWQg aW4gdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24uIElzIGl0IHN0aWxsIG5lY2Vzc2FyeSB0byBleHBh bmQ/ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+U2VjdGlvbiAyLCBwYWdlIDMvNDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q291bGQgeW91IHBsZWFzZSBj bGFyaWZ5IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gJnF1b3Q7bm9kZSZxdW90OyBhbmQgJnF1b3Q7 ZW5kIHN0YXRpb24mcXVvdDs/IEFyZSB0aGV5IHN5bm9ueW1zPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNzAzMEEwIj5bTGluZGFdIE5vZGUgY2FuIGJl IHN3aXRjaGVzL3JvdXRlcnMuIOKAnGVuZCBzdGF0aW9u4oCdIGRvZXNu4oCZdCByb3V0ZSBvciBm b3J3YXJkIHRyYWZmaWMuIFBhY2tldHMgYXJlIHRlcm1pbmF0ZWQgYnkg4oCcZW5kIHN0YXRpb27i gJ0uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VjdGlvbiA1LjEuMTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNob3VsZG4n dCBpdCBiZSBwb3NzaWJsZSB0byBhdm9pZCBORCBsb2FkIGJ5IHByb3BlciBzZXR0aW5nIG9mIHRo ZSBSZWFjaGFibGVUaW1lIHZhcmlhYmxlPyAtLSBUaGlzIHdvdWxkbid0IHJlcXVpcmUgYW55IHBy b3RvY29sDQogY2hhbmdlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiM3MDMwQTAiPltMaW5kYV0gRG8geW91IG1lYW4gY2hhbmdpbmcgdGhl IHNldHRpbmcgb24gR3Vlc3RPUz8gVGhlIGlzc3VlIGlzIHRoYXQgbWFueSBHdWVzdCBPU3MgYXJl IG91dCBvZiBuZXR3b3Jr4oCZcyBjb250cm9sLiBJZiBOZXR3b3JrIGNhbg0KIGNvbnRyb2wgR3Vl c3QgT1PigJlzIGJlaGF2aW9yLCBtYW55IHRoaW5ncyBjYW4gYmUgZWFzaWVyLiA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxp Z246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5TZWN0aW9uIDUuMS4xOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U25vb3BpbmcgQVJQIHBhY2tldHMgcHJvYmFibHkg bWVhbnMgaW5jcmVhc2VkIGxvYWQgKGEgZGlzYWR2YW50YWdlIHlvdSBkaWRuJ3QgbWVudGlvbiku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQt YWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3MDMwQTAi PltMaW5kYV0geWVzLCBpdCBpbmNyZWFzZSB0aGUgbG9hZCwgYnV0IGluIGEgY29udHJvbGxlZCB3 YXkuIFNvIHRoZSByb3V0ZXJzIGNhbiBwcm9jZXNzIHRoZW0gd2l0aGluIGl0cyBjYXBhY2l0eS4g U28sIGl0IGlzIG5vdCByZWFsbHkNCiBkaXNhZHZhbnRhZ2UuIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VjdGlvbiA1LjEu MTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPldoZW4gYWRkcmVzcyByZXNvbHV0aW9uIGlzIG5lZWRlZCB0byBkZWxpdmVyIGEg cGFja2V0LCBzb21lIHJvdXRlcnMganVzdCBkcm9wIHRoZSBwYWNrZXQgd2hlbiB0aGV5IGVuZ2Fn ZSBpbiBBUlAgKHNlZQ0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjI3 NCNzZWN0aW9uLTQuMi4zIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2Mjc0I3NlY3Rp b24tNC4yLjM8L2E+KS4gVGhlIHNhbWUgaXMgdHJ1ZSBmb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SVB2NiBORC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246 anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3MDMwQTAiPltMaW5k YV0gY29ycmVjdC4gVGhlIGJlaGF2aW9yIGlzIGRlc2NyaWJlZCBpbiB0aGUgc2Vjb25kIHBhcmFn cmFwaCBvZiBTZWN0aW9uIDUuMS4yOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0byI+U29sdXRpb246IFRvIHBy b3RlY3QgYSByb3V0ZXIgZnJvbSBiZWluZyBvdmVyYnVyZGVuZWQgYnkgcmVzb2x2aW5nIHRhcmdl dCBNQUMgYWRkcmVzc2VzLCBvbmUgc29sdXRpb24gaXMgZm9yIHRoZSByb3V0ZXIgdG8gbGltaXQg dGhlIHJhdGUgb2YgcmVzb2x2aW5nIHRhcmdldCBNQUMgYWRkcmVzc2VzIGZvciBpbmJvdW5kIHRy YWZmaWMgd2hvc2UgdGFyZ2V0DQogaXMgbm90IGluIHRoZSByb3V0ZXLigJlzIEFSUC9ORCBjYWNo ZS4gV2hlbiB0aGUgcmF0ZSBpcyBleGNlZWRlZCwgdGhlIGluY29taW5nIHRyYWZmaWMgd2hvc2Ug dGFyZ2V0IGlzIG5vdCBpbiB0aGUgQVJQL05EIGNhY2hlIGlzIGRyb3BwZWQuDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxp Z246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNl Y3Rpb24gODo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPldoaWxlIHRoaXMgZG9jdW1lbnQgZG9lcyBub3QgaW50cm9kdWNlIG5l dyBpc3N1ZXMgaXRzZWxmLCBpdCBzaG91bGQgYXQgbGVhc3QgbWVudGlvbiBob3cgdGhlIHNhbWUg QVJQL05EIGlzc3VlcyBtYXkgYmUgaW50ZW50aW9uYWxseQ0KIHRyaWdnZXJlZCBieSBhbiBhdHRh Y2tlci4gRm9yIGV4YW1wbGUsIHlvdSBtYXkgcmVmZXJlbmNlIFJGQyA2NTgzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlm eSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWdu Omp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bTGlu ZGFdIFN1cmUuIFdpbGwgYWRkIGluIHRoZSBuZXcgdmVyc2lvbi4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+KiBOaXRzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxp Z246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5TZWN0aW9uIDQsIHBhZ2UgNDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0OyBUaGVyZSBhcmUgbm8gYWRkcmVzczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1 c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHJlc29sdXRpb24gaXNzdWUgaW4gdGhpcyBkZXNpZ24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFs aWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5S ZXBsYWNlICZxdW90O2lzc3VlJnF1b3Q7IHdpdGggJnF1b3Q7aXNzdWVzJnF1b3Q7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3MDMwQTAiPltMaW5kYV0g SW4gdGhlIGxhdGVzdCBkcmFmdCAoIDA3IHZlcnNpb246DQo8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItYXJtZC1hcnAtbmQtc2NhbGluZy1wcmFj dGljZXMvIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWR1bmJhci1h cm1kLWFycC1uZC1zY2FsaW5nLXByYWN0aWNlcy88L2E+KSwgaXQgaXMgYWxyZWFkeSBjaGFuZ2Vk OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0 LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlcmUgaXMgbm8gYWRkcmVzcyByZXNvbHV0aW9uIGlzc3Vl IGluIHRoaXMgZGVzaWduLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VjdGlvbiA1LjEuMSwgcGFnZSA1Ojxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFs aWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+JnF1b3Q7SXB2NiZxdW90OyAtJmd0OyAmcXVvdDtJUHY2JnF1b3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlm eSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWdu Omp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNzAzMEEwIj5bTGlu ZGEgXSBJbiB0aGUgbGF0ZXN0IGRyYWZ0ICgwNyB2ZXJzaW9uKSwgaXQgaXMgYWxyZWFkeSBjaGFu Z2VkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VjdGlvbiA1LjEuMjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBleHBhbmQg VU5BIChwb3NzaWJseSBpbiB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbikgLS0geW91IHByb2JhYmx5 IG1lYW4gJnF1b3Q7VW5zb2xpY2l0ZWQuLiZxdW90OywgYnV0IHRoaXMgc2hvdWxkIGJlIGV4cGxp Y2l0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNzAz MEEwIj5bTGluZGFdIGluIHRoZSBsYXRlc3QgZHJhZnQgKDA3IHZlcnNpb24pLCBVTkEgaXMgYWxy ZWFkeSBsaXN0ZWQgdW5kZXIgdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24uDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246 anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3MDMwQTAiPlRoYW5r IHlvdSB2ZXJ5IG11Y2ggZm9yIHRoZSByZXZpZXcgYW5kIGNvbW1lbnRzLg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlm eSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3MDMwQTAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWdu Omp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNzAzMEEwIj5MaW5k YQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGFuayB5b3UsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRpbmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCBVbmljb2RlIE1TJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNlY2RpciBb PGEgaHJlZj0ibWFpbHRvOnNlY2Rpci1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2VjZGlyLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NYXR0aGV3IExlcGluc2tp PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMTQsIDIwMTQgMjo1MiBBTTxicj4N CjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+c2VjZGlyQGlldGYu b3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPg0KaWVzZ0BpZXRmLm9yZzwv YT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1ob3VzbGV5LXBraXgtb2lkcy5hbGxAdG9vbHMuaWV0 Zi5vcmciPmRyYWZ0LWhvdXNsZXktcGtpeC1vaWRzLmFsbEB0b29scy5pZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW3NlY2Rpcl0gU0VDRElSIHJldmlldyBvZiBkcmFmdC1ob3VzbGV5 LXBraXgtb2lkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBh cyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJl dmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAmbmJz cDtUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5DQogZm9yIHRoZSBiZW5lZml0 IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gJm5ic3A7RG9jdW1lbnQgZWRpdG9ycyBh bmQgd29ya2luZyBncm91cCBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3Qg bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGlzIGRvY3VtZW50IHJl dHVybnMgY29udHJvbCBvZiB0aGUgUEtJWCBvYmplY3QgaWRlbnRpZmllciBhcmMgdG8gSUFOQS4g VGhhdCBpcywgaXQgZXN0YWJsaXNoZXMgYSBuZXcgSUFOQSByZWdpc3RyeSBmb3IgT0lEcyBpbiB0 aGUgUEtJWCBhcmMgYW5kIHBvcHVsYXRlcyB0aGF0IHJlZ2lzdHJ5IHdpdGggdGhlIGV4aXN0aW5n IE9JRA0KIGFzc2lnbm1lbnRzLiBGaW5hbGx5LCB0aGUgZG9jdW1lbnQgZXN0YWJsaXNoZXMgZXhw ZXJ0IHJldmlldyBhcyB0aGUmbmJzcDtjcml0ZXJpYSZuYnNwO2ZvciZuYnNwO2Z1dHVyZSBhZGRp dGlvbnMgdG8gdGhlIHJlZ2lzdHJ5IGFuZCBpbmNsdWRlcyZuYnNwO2d1aWRhbmNlJm5ic3A7dGhh dCBmb3IgcmV2aWV3Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFmdGVyIHJldmlld2luZyB0aGUgZG9jdW1lbnQs IEkgYWdyZWUgd2l0aCB0aGUgYXV0aG9yIHRoYXQgdGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIG5v IG5ldyBzZWN1cml0eSBjb25jZXJucy4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGZvdW5kIG5vIGlz c3VlcyBpbiB0aGUgZG9jdW1lbnQgYW5kIEkgYmVsaWV2ZSBpdCBpcyByZWFkeSBmb3IgcHVibGlj YXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPk5pdHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgYXV0aG9yIHNob3VsZCBjb25zaWRlciBp bmNsdWRpbmcgYW4gZXhwYW5zaW9uIG9mIHRoZSZuYnNwO2Fjcm9ueW0mbmJzcDtTTUksIHdoaWNo IGlzIHVzZWQgZnJlcXVlbnRseSBpbiB0aGUgZG9jdW1lbnQuIChJIGJlbGlldmUgaW4gdGhpcyBj b250ZXh0IFNNSSA9IFN0cnVjdHVyZSBvZiBNYW5hZ2VtZW50IEluZm9ybWF0aW9uKTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkluIFNlY3Rpb24gMzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+cy88L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5iZSByZWxhdGVkIHRvIFguNTA5IGNlcnRpZmljYXRlL2JlIHJlbGF0ZWQgdG8g WC41MDkgY2VydGlmaWNhdGVzLzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkluIFNlY3Rpb24gMy4xOiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5zLzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnRvIHBvaW50cyB0 byB0aGlzIGRvY3VtZW50L3RvIHBvaW50IHRvIHRoaXMgZG9jdW1lbnQvPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOyI+DQo8ZGl2PiZsdDtkcmFmdC1kdW5iYXItYXJtZC1hcnAtbmQtc2NhbGluZy1w cmFjdGljZXMtMDguZG9jeCZndDs8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcmlhbCBVbmljb2RlIE1TIjsNCglwYW5vc2UtMToyIDEx IDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBBcmlhbCBVbmljb2RlIE1TIjsNCglwYW5v c2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJpYWwgVW5pY29kZSBNUyIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FFA8BFED259D44838EA5124F65A403ABhuaweicom_-- From nobody Tue Mar 4 04:24:21 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76A41A004B for ; Tue, 4 Mar 2014 04:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjunPqyopi87 for ; Tue, 4 Mar 2014 04:24:17 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id D003A1A0055 for ; Tue, 4 Mar 2014 04:24:16 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s24COBTd015545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 4 Mar 2014 14:24:11 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s24COBAv014535; Tue, 4 Mar 2014 14:24:11 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21269.50667.638391.555895@fireball.kivinen.iki.fi> Date: Tue, 4 Mar 2014 14:24:11 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Zv947_04ZGdiilcoOc2-Ut0d7Yc Subject: [secdir] Link to the Security Area Review Tool. X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 12:24:18 -0000 The Secdir Area Review tool can be found at: https://art.tools.ietf.org/tools/art/secdir/index.cgi/t=5467/welcome One thing you can do there, is to mark yourself for being unavaible for some time, i.e. if you are month or so on vacation you can mark yourself of being away until specific time. Unless you are next in rotation there is not really point of marking yourself away if you are away only week or two. Btw, we currently go around the list of reviewers every 5-6 weeks. -- kivinen@iki.fi From nobody Tue Mar 4 04:37:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157C61A0055 for ; Tue, 4 Mar 2014 04:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmu0_3P56lxC for ; Tue, 4 Mar 2014 04:37:50 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id D153C1A0103 for ; Tue, 4 Mar 2014 04:37:49 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s24CbjCq022278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 4 Mar 2014 14:37:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s24Cbj3F026975; Tue, 4 Mar 2014 14:37:45 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21269.51481.954107.59740@fireball.kivinen.iki.fi> Date: Tue, 4 Mar 2014 14:37:45 +0200 From: Tero Kivinen To: secdir@ietf.org In-Reply-To: <21269.50667.638391.555895@fireball.kivinen.iki.fi> References: <21269.50667.638391.555895@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Jm84KG3E-mnnIHQTl0CV7E8tOUU Subject: [secdir] Link to the Security Area Review Tool. X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 12:37:53 -0000 Tero Kivinen writes: > The Secdir Area Review tool can be found at: > > https://art.tools.ietf.org/tools/art/secdir/index.cgi/t=5467/welcome Forgot one important thing. The authentication email address and password are normal tools.ietf.org accounts. I.e if you do not have account already in there get one from https://tools.ietf.org/newlogin site. The only thing is that the email address of the account and the email address stored in the database must match, so if you cannot log in with your tools.ietf.org account then the review database most likely have some old address for you. In that case send me email and I will fix the email address in the database. -- kivinen@iki.fi From nobody Tue Mar 4 04:54:24 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AC81A0041 for ; Tue, 4 Mar 2014 04:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uib6clyzUnuc for ; Tue, 4 Mar 2014 04:54:21 -0800 (PST) Received: from buckwheat.cc.columbia.edu (buckwheat.cc.columbia.edu [128.59.72.251]) by ietfa.amsl.com (Postfix) with ESMTP id D571D1A002A for ; Tue, 4 Mar 2014 04:54:20 -0800 (PST) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by buckwheat.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id s24Cq2Iw031758 for ; Tue, 4 Mar 2014 07:54:17 -0500 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id 70C366C for ; Tue, 4 Mar 2014 07:54:17 -0500 (EST) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by hazelnut (Postfix) with ESMTP id 5C80D6C for ; Tue, 4 Mar 2014 07:54:17 -0500 (EST) Received: from dhcp-bb3d.meeting.ietf.org (dhcp-bb3d.meeting.ietf.org [31.133.187.61]) (user=smb2132 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id s24CsFR9014536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 4 Mar 2014 07:54:16 -0500 (EST) From: "Steven M. Bellovin" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6992E9CF-C0E0-4532-A116-4D434903B4EB@cs.columbia.edu> Date: Tue, 4 Mar 2014 12:53:54 +0000 To: secdir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/zhwpCiBw2RYBosDv7mgPuDcNSJk Subject: [secdir] reference X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 12:54:22 -0000 @inproceedings{CL01, Author =3D {J. Camenisch and A. Lysyanskaya}, Booktitle =3D {Proc. of Eurocrypt '01, LNCS 2045}, Pages =3D {93-118}, Publisher =3D {Springer-Verlag}, Title =3D {An Efficient System for Non-transferable Anonymous = Credentials with Optional Anonymity Revocation}, Year =3D 2001} There's a lot more in that vein in the crypto literature. --Steve Bellovin, https://www.cs.columbia.edu/~smb From nobody Tue Mar 4 06:49:22 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC76F1A0251 for ; Tue, 4 Mar 2014 06:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG_cYYECfkwH for ; Tue, 4 Mar 2014 06:49:15 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCA31A01DA for ; Tue, 4 Mar 2014 06:49:15 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id if11so4393089vcb.36 for ; Tue, 04 Mar 2014 06:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wym0W2nypR2Uqn6ygs7eCLtDmtxcKyYrl6QB5u95YfQ=; b=MWETZ66Zf3N1VT5XYxrjNPrZ3iYwLgdXkwxk0dbXb0W7xAvPltZt6UcUcxK4kc/CuB 2gjhNIDBRlX9Vbtqgfm3KFbePemz4P7OmCWj3ah7KIhfzjl0W8Q0GselUP6uu9MVVNXb Jf5kMMpduHPmzlagMmrTN5dGLPYUKElhBcF7melXVzrYwOga59dk8NNd5WEs8gA/7fxS tzLxyyBWhgWfV1QeZ8qkMtdYIF6aRwjol10t/LVQbsVONBJRvPWAB6FWxfKA+bdkkI38 OqGfsXHqVxwnmi2YC2bQ0FSOGDMwmXah6EXEyAR4NjR7jo9ep5Bwef75aU64oxQByJDl 5Y1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Wym0W2nypR2Uqn6ygs7eCLtDmtxcKyYrl6QB5u95YfQ=; b=ENYvmUEn3IBDwtJpfzLTf+u1hC/7E4efTSAQfaR36D/UU0U3QKAF6GNy25zNOWhRih HqG6qhvPMwUjgFPlt0iC3Z3qfiEmuVnldmIp+3cSPXdy+2bQy2/ccxypTZSkmrQQIU+K +3vUXh+8j+cyg8epxjq/3GHjVyO7ZscMmQEuuYdUsjxhspW0fJ+aDHsQom7tLh2jz92o QPgiTLn1M/6JonQXDFTTy35UL6l5IPKvrGEf76AsUx8RBPg56/5riFnMAIpbOu7BLRew KLrYkdNcP5pUPaHKvtE7UN+q81a1/l1Vg4bmfDRHqPxGfzqw+gjVJqi5eQkfAFBeVRCN srUw== X-Gm-Message-State: ALoCoQk6lv1vY8zRxac1LnwO5ecZZI0oH7NdEQ0JyZ/WcftIanYV2fUcXNT9u0BGdHMeRAq6IbYm/DQhS97A0FyF+BtGfvr9j5bKvwjluG3kHspuH61GFyRimmZEYm6Tm+p8VjzNXXma/3diQP4LHFxxUdriA7kuQTzj8xAfI7a56PWXvEkP5AG1DeTzp3kev9zlHH/KLQ/z MIME-Version: 1.0 X-Received: by 10.58.100.100 with SMTP id ex4mr22357veb.2.1393944551615; Tue, 04 Mar 2014 06:49:11 -0800 (PST) Received: by 10.52.230.105 with HTTP; Tue, 4 Mar 2014 06:49:11 -0800 (PST) In-Reply-To: <6992E9CF-C0E0-4532-A116-4D434903B4EB@cs.columbia.edu> References: <6992E9CF-C0E0-4532-A116-4D434903B4EB@cs.columbia.edu> Date: Tue, 4 Mar 2014 14:49:11 +0000 Message-ID: From: Ben Laurie To: "Steven M. Bellovin" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/VALCqLRs_S40ADb3YU-bT4q3Kl8 Cc: "secdir@ietf.org" Subject: Re: [secdir] reference X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:49:18 -0000 On 4 March 2014 12:53, Steven M. Bellovin wrote: > @inproceedings{CL01, > Author = {J. Camenisch and A. Lysyanskaya}, > Booktitle = {Proc. of Eurocrypt '01, LNCS 2045}, > Pages = {93-118}, > Publisher = {Springer-Verlag}, > Title = {An Efficient System for Non-transferable Anonymous Credentials with Optional Anonymity Revocation}, > Year = 2001} > > There's a lot more in that vein in the crypto literature. There's also selective disclosure, which is at least theoretically useful :-) @inproceedings{DBLP:conf/spw/BangerterCL04, author = {Endre Bangerter and Jan Camenisch and Anna Lysyanskaya}, title = {A Cryptographic Framework for the Controlled Release of Certified Data}, booktitle = {Security Protocols Workshop}, year = {2004}, pages = {20-42}, ee = {http://dx.doi.org/10.1007/11861386_4}, crossref = {DBLP:conf/spw/2004}, bibsource = {DBLP, http://dblp.uni-trier.de} } From nobody Tue Mar 4 06:58:19 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DE01A0125 for ; Tue, 4 Mar 2014 06:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiusZmVc6Pqr for ; Tue, 4 Mar 2014 06:58:14 -0800 (PST) Received: from buckwheat.cc.columbia.edu (buckwheat.cc.columbia.edu [128.59.72.251]) by ietfa.amsl.com (Postfix) with ESMTP id C88941A00B9 for ; Tue, 4 Mar 2014 06:58:13 -0800 (PST) Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by buckwheat.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id s24EuR9i013513; Tue, 4 Mar 2014 09:58:10 -0500 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id EC8746C; Tue, 4 Mar 2014 09:58:09 -0500 (EST) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by hazelnut (Postfix) with ESMTP id E1C1D6C; Tue, 4 Mar 2014 09:58:09 -0500 (EST) Received: from [31.93.251.160] ([31.93.251.160]) (user=smb2132 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id s24Ew6pg016337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Mar 2014 09:58:08 -0500 (EST) User-Agent: K-9 Mail for Android In-Reply-To: References: <6992E9CF-C0E0-4532-A116-4D434903B4EB@cs.columbia.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: smb@cs.columbia.edu Date: Tue, 04 Mar 2014 14:58:00 +0000 To: Ben Laurie Message-ID: X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/SpLO7pdOklEi5Gu4qIb2PmLdJOc Cc: "secdir@ietf.org" Subject: Re: [secdir] reference X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:58:16 -0000 On March 4, 2014 2:49:11 PM GMT+00:00, Ben Laurie wrote: >On 4 March 2014 12:53, Steven M. Bellovin wrote: >> @inproceedings{CL01, >> Author = {J. Camenisch and A. Lysyanskaya}, >> Booktitle = {Proc. of Eurocrypt '01, LNCS 2045}, >> Pages = {93-118}, >> Publisher = {Springer-Verlag}, >> Title = {An Efficient System for Non-transferable Anonymous >Credentials with Optional Anonymity Revocation}, >> Year = 2001} >> >> There's a lot more in that vein in the crypto literature. > >There's also selective disclosure, which is at least theoretically >useful :-) > >@inproceedings{DBLP:conf/spw/BangerterCL04, > author = {Endre Bangerter and > Jan Camenisch and > Anna Lysyanskaya}, > title = {A Cryptographic Framework for the Controlled Release of > Certified Data}, > booktitle = {Security Protocols Workshop}, > year = {2004}, > pages = {20-42}, > ee = {http://dx.doi.org/10.1007/11861386_4}, > crossref = {DBLP:conf/spw/2004}, > bibsource = {DBLP, http://dblp.uni-trier.de} >} As I said, a lot more. A talk on some of these mechanisms might be a useful thing to schedule for Toronto. -- --Steve Bellovin, sending from a toy. From nobody Tue Mar 4 08:11:20 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D8C1A020F for ; Tue, 4 Mar 2014 08:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLxka7JX8JuP for ; Tue, 4 Mar 2014 08:11:10 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 813831A01B0 for ; Tue, 4 Mar 2014 08:10:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 681FDBE33; Tue, 4 Mar 2014 16:10:22 +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 6kNjOKEBOr8u; Tue, 4 Mar 2014 16:10:21 +0000 (GMT) Received: from [31.133.162.177] (dhcp-a2b1.meeting.ietf.org [31.133.162.177]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E8424BE2F; Tue, 4 Mar 2014 16:10:20 +0000 (GMT) Message-ID: <5315FAEC.8040807@cs.tcd.ie> Date: Tue, 04 Mar 2014 16:10:20 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: smb@cs.columbia.edu, Ben Laurie References: <6992E9CF-C0E0-4532-A116-4D434903B4EB@cs.columbia.edu> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/RylvgVBWAzOsgB3uUpr5JySeSXY Cc: "secdir@ietf.org" Subject: Re: [secdir] reference X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 16:11:19 -0000 On 03/04/2014 02:58 PM, smb@cs.columbia.edu wrote: > A talk on some of these mechanisms might be a useful thing to schedule for Toronto. Sounds good. Was that the sound of you volunteering? :-) S > From nobody Tue Mar 4 08:16:52 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C401A020F for ; Tue, 4 Mar 2014 08:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlArIBzJqK2p for ; Tue, 4 Mar 2014 08:16:49 -0800 (PST) Received: from eloi.cs.columbia.edu (eloi.cs.columbia.edu [128.59.21.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAB21A01DA for ; Tue, 4 Mar 2014 08:16:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eloi.cs.columbia.edu (Postfix) with ESMTP id 99F00795F09; Tue, 4 Mar 2014 11:16:45 -0500 (EST) X-Virus-Scanned: amavisd-new at eloi.cs.columbia.edu Received: from eloi.cs.columbia.edu ([127.0.0.1]) by localhost (eloi.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJcGleqldDlP; Tue, 4 Mar 2014 11:16:44 -0500 (EST) Received: from [10.9.0.182] (fireball.cs.columbia.edu [128.59.13.10]) by eloi.cs.columbia.edu (Postfix) with ESMTPSA id 9127C795EFB; Tue, 4 Mar 2014 11:16:43 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Steven M. Bellovin" In-Reply-To: <5315FAEC.8040807@cs.tcd.ie> Date: Tue, 4 Mar 2014 16:16:40 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6992E9CF-C0E0-4532-A116-4D434903B4EB@cs.columbia.edu> <5315FAEC.8040807@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/LKyLvSP9RFWl2x9rNFR2BoVEe4o Cc: "secdir@ietf.org" Subject: Re: [secdir] reference X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 16:16:51 -0000 On Mar 4, 2014, at 4:10 PM, Stephen Farrell = wrote: >=20 >=20 > On 03/04/2014 02:58 PM, smb@cs.columbia.edu wrote: >> A talk on some of these mechanisms might be a useful thing to = schedule for Toronto.=20 >=20 > Sounds good. Was that the sound of you volunteering? :-) No, because I don't know if I'll be there. Even if I were, it might pay = to ask the CFRG chairs to find a sucker^h^h^h^h^h^hvolunteer, since I = don't know that I know all of the lovely tricks that they've come up = with. --Steve Bellovin, https://www.cs.columbia.edu/~smb From nobody Wed Mar 5 08:07:04 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584F61A0391; Wed, 5 Mar 2014 01:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.793 X-Spam-Level: * X-Spam-Status: No, score=1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RCVD_IN_BRBL_LASTEXT=1.449, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IH4nYrApIE-b; Wed, 5 Mar 2014 01:28:34 -0800 (PST) Received: from mail.csnet1.cs.tsinghua.edu.cn (unknown [211.151.89.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4089F1A0392; Wed, 5 Mar 2014 01:28:24 -0800 (PST) Received: from dhcp-a315.meeting.ietf.org (dhcp-a315.meeting.ietf.org [31.133.163.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.csnet1.cs.tsinghua.edu.cn (Tsinghua University (Postfix)) with ESMTPSA id C73C114983BB; Wed, 5 Mar 2014 17:03:53 +0800 (CST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-31--907336436 From: Qi Sun In-Reply-To: <3605A730-DFCA-4A9B-9A30-7FAE4A938CBA@gmail.com> Date: Wed, 5 Mar 2014 09:28:11 +0000 Message-Id: <0072CD75-BCD2-4759-A28E-92481E6D50D8@csnet1.cs.tsinghua.edu.cn> References: <3605A730-DFCA-4A9B-9A30-7FAE4A938CBA@gmail.com> To: Chris Lonvick X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Sz35PPOILvIixE4w7meIjvTtunE X-Mailman-Approved-At: Wed, 05 Mar 2014 08:06:57 -0800 Cc: draft-ietf-dhc-dhcpv6-unknown-msg.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-dhc-dhcpv6-unknown-msg-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 09:28:38 -0000 --Apple-Mail-31--907336436 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Chris, Many thanks for your comments!=20 About the Security Considerations section, how about we add the = following clarification: OLD: 6. Security Considerations As the relay agent will forward all unknown types of DHCPv6 messages, a malicious attacker can interfere with the relaying function by constructing fake DHCPv6 messages with arbitrary type code. The same problem may happen in current DHCPv4 and DHCPv6 practice where the attacker constructs the fake DHCP message with a known type code. ... NEW: 6. Security Considerations This document creates no new security issues that are not already present in RFC3315. By explicitly documenting the correct handling of unknown messages, this document, if implemented, reduces any security exposure that might result from incorrect handling of unknown messages. The following issues are issues that could already be present with section 23 of [RFC3315], but we discuss them in detail here as guidance for implementors. As the relay agent will forward all unknown types of DHCPv6 messages, a malicious attacker can interfere with the relaying function by constructing fake DHCPv6 messages with arbitrary type code. The same problem may happen in current DHCPv4 and DHCPv6 practice where the attacker constructs the fake DHCP message with a known type code. ... Would that be OK?=20 Best Regards, Qi //Sorry if you received duplicate mails. On 2014-3-3, at =E4=B8=8B=E5=8D=887:07, Chris Lonvick wrote: > 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 > This document looks to be well thought out and almost complete. I = would like to see a statement in the Security Considerations section = that this specification adheres to the Security Considerations section = of RFC 3315, and augments it by describing the disposition of unknown = messages. >=20 > Other than that, the only very minor nit that I have is that the = second and third paragraphs of the Security Considerations section are a = single thought and should be combined. >=20 > Thanks, > Chris >=20 --Apple-Mail-31--907336436 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Dear Chris,

Many thanks for = your comments! 

About the Security Considerations section, = how about we add the following clarification:

OLD:
6. =  Security Considerations

  As the relay agent will forward all = unknown types of DHCPv6 messages,
  a malicious attacker can = interfere with the relaying function by
  constructing fake = DHCPv6 messages with arbitrary type code.  The same
  = problem may happen in current DHCPv4 and DHCPv6 practice where = the
  attacker constructs the fake DHCP message with a known = type code.
  ...

NEW:
6.  Security = Considerations

  This document creates no new = security issues that are not already
  present in RFC3315. =  By explicitly documenting the correct handling
  of = unknown messages, this document, if implemented, reduces any
  = security exposure that might result from incorrect handling of
  = unknown messages.  The following issues are issues that could = already
  be present with section 23 of [RFC3315], but we = discuss them in
  detail here as guidance for = implementors.

  As the relay agent will forward all = unknown types of DHCPv6 messages,
  a malicious attacker can = interfere with the relaying function by
  constructing fake = DHCPv6 messages with arbitrary type code.  The same
  = problem may happen in current DHCPv4 and DHCPv6 practice where = the
  attacker constructs the fake DHCP message with a known = type code.
  ...

Would that be OK? 

Best = Regards,
Qi
//Sorry if you received duplicate = mails.



On 2014-3-3, at = =E4=B8=8B=E5=8D=887:07, Chris Lonvick wrote:


Hi,

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

This document looks to be well thought out and almost = complete.  I would like to see a statement in the Security = Considerations section that this specification adheres to the Security = Considerations section of RFC 3315, and augments it by describing the = disposition of unknown messages.

Other than that, the only very = minor nit that I have is that the second and third paragraphs of the = Security Considerations section are a single thought and should be = combined.

Thanks,
Chris


= --Apple-Mail-31--907336436-- From nobody Wed Mar 5 11:55:02 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C587C1A0224; Wed, 5 Mar 2014 11:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNHkl7HtG5Yz; Wed, 5 Mar 2014 11:54:58 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 192771A021C; Wed, 5 Mar 2014 11:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3027; q=dns/txt; s=iport; t=1394049294; x=1395258894; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=gPUe08TkaeEDGVzc+MpIppqOKxPZidgYgTuuF8uV1n0=; b=cnScUrYQ6fI10IKU+B005DKR7e0r+3tsq/KJ4sUVelM55YfVXJ4Tl2zM 5DvBVX/BQ1tUqKg5s9vFphnDXcGMzn4NHlpHO84bHlD3lHES297Y8SuAF MZt97Dbs4Rl0F3ITnjpWC5Z6IPjyb5XanJX0DKE42Suxza7bEZaBNf1oR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAOJ/F1OrRDoJ/2dsb2JhbABaDoJ4hBa+CYEaFnSCJQEBAQMBI1YQCQIYKgICVwaIBAeSI5wXoCcXjlEHgm+BSQSJS6Edgm5g X-IronPort-AV: E=Sophos;i="4.97,594,1389744000"; d="scan'208";a="104419680" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 05 Mar 2014 19:54:54 +0000 Received: from sjc-xdm-112 (sjc-xdm-112.cisco.com [171.71.188.44]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s25Jssvr029952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Mar 2014 19:54:54 GMT Date: Wed, 5 Mar 2014 11:54:54 -0800 (PST) From: Chris Lonvick To: Qi Sun In-Reply-To: <0072CD75-BCD2-4759-A28E-92481E6D50D8@csnet1.cs.tsinghua.edu.cn> Message-ID: References: <3605A730-DFCA-4A9B-9A30-7FAE4A938CBA@gmail.com> <0072CD75-BCD2-4759-A28E-92481E6D50D8@csnet1.cs.tsinghua.edu.cn> User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1202400444-2086425228-1394049294=:17205" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/EPINhoAzMzAQpaR_Mf8QST1_tjY Cc: draft-ietf-dhc-dhcpv6-unknown-msg.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-dhc-dhcpv6-unknown-msg-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 19:55:01 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1202400444-2086425228-1394049294=:17205 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hi Qi, That sounds reasonable. Best regards, Chris On Wed, 5 Mar 2014, Qi Sun wrote: > > > Dear Chris, > > Many thanks for your comments!  > > About the Security Considerations section, how about we add the following clarification: > > OLD: > 6.  Security Considerations > >   As the relay agent will forward all unknown types of DHCPv6 messages, >   a malicious attacker can interfere with the relaying function by >   constructing fake DHCPv6 messages with arbitrary type code.  The same >   problem may happen in current DHCPv4 and DHCPv6 practice where the >   attacker constructs the fake DHCP message with a known type code. >   ... > > NEW: > 6.  Security Considerations > >   This document creates no new security issues that are not already >   present in RFC3315.  By explicitly documenting the correct handling >   of unknown messages, this document, if implemented, reduces any >   security exposure that might result from incorrect handling of >   unknown messages.  The following issues are issues that could already >   be present with section 23 of [RFC3315], but we discuss them in >   detail here as guidance for implementors. > >   As the relay agent will forward all unknown types of DHCPv6 messages, >   a malicious attacker can interfere with the relaying function by >   constructing fake DHCPv6 messages with arbitrary type code.  The same >   problem may happen in current DHCPv4 and DHCPv6 practice where the >   attacker constructs the fake DHCP message with a known type code. >   ... > > Would that be OK?  > > Best Regards, > Qi > //Sorry if you received duplicate mails. > > > > On 2014-3-3, at 下åˆ7:07, Chris Lonvick wrote: > > > Hi, > > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments > were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last > call comments. > > This document looks to be well thought out and almost complete.  I would like to see a statement in the Security Considerations section that this > specification adheres to the Security Considerations section of RFC 3315, and augments it by describing the disposition of unknown messages. > > Other than that, the only very minor nit that I have is that the second and third paragraphs of the Security Considerations section are a single thought and > should be combined. > > Thanks, > Chris > > > > --1202400444-2086425228-1394049294=:17205-- From nobody Mon Mar 10 14:31:05 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46301A04B0; Mon, 10 Mar 2014 14:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tX60tG1BaYrL; Mon, 10 Mar 2014 14:31:01 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD701A0146; Mon, 10 Mar 2014 14:31:00 -0700 (PDT) X-AuditID: 12074424-f79e26d000000c70-6b-531e2f0fd78f Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id FE.84.03184.F0F2E135; Mon, 10 Mar 2014 17:30:55 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s2ALUnI7008478; Mon, 10 Mar 2014 17:30:54 -0400 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s2ALUlvm002403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Mar 2014 17:30:48 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id s2ALUkq0025170; Mon, 10 Mar 2014 17:30:46 -0400 (EDT) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mpls-special-purpose-labels-05.all@tools.ietf.org From: Tom Yu Date: Mon, 10 Mar 2014 17:30:46 -0400 Message-ID: Lines: 31 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUixCmqrcuvLxdssGi+qMW6yzNZLWb8mchs 8WHhQxYHZo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK+P80eNMBTu5K44u2MDYwDifs4uR k0NCwETi1Jx9jBC2mMSFe+vZuhi5OIQEZjNJrJr5iRXC2cgo0TR5DwtIlZDAOSaJh136EIku oET/c7B2EYFMifNHjrKD2MICzhIPt5wHauDgYBOQlji6uAwkzCKgKtF58BEziM0rYCHRu30V mM0jwClxqGclI0RcUOLkzCdgu5gFtCRu/HvJNIGRbxaS1CwkqQWMTKsYZVNyq3RzEzNzilOT dYuTE/PyUot0zfVyM0v0UlNKNzGCQo3dRWUHY/MhpUOMAhyMSjy8B9/KBAuxJpYVV+YeYpTk YFIS5c3TkQsW4kvKT6nMSCzOiC8qzUktPsQowcGsJMK7Thwox5uSWFmVWpQPk5LmYFES5+07 KxEsJJCeWJKanZpakFoEk5Xh4FCS4F2pDdQoWJSanlqRlplTgpBm4uAEGc4DNHyOLsjw4oLE 3OLMdIj8KUZFKXHeBSAXCYAkMkrz4HphqeAVozjQK8K8K0HaeYBpBK77FdBgJqDBzcelQAaX JCKkpBoYJe/LvJcLS2ZOCC5fkHnT+d8phufS35+57e5fFGqw8LHy+2nCK82Tn9+cbi3IpXjV LHBHKVPH9ETDxWohtQ9neh8X4bwct+On8buHbq+/zMwwSbzCcrOSXaueszrPg5kphGuV/tyL sTcvMD4J1k9S5C3Xm/6nWf7HdjfNMmGdfVwKFsyTDhxTYinOSDTUYi4qTgQAfoHmEuACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Q2ckBP21GYgPsh-vTDmq_rAwZ3k Subject: [secdir] secdir review of draft-ietf-mpls-special-purpose-labels-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 21:31:02 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: ready with nits I believe the Security Considerations section of this document is reasonable. Query: I'm not very familiar with MPLS; is the handling of the Entropy Label Indicator the only situation where a Label Switching Router would need to inspect (as opposed to hash for load balancing) labels below the top of the label stack? I was confused by the explanation of why Label 7 (ELI) has meaning as both an ordinary Special Label and an Extended Special Purpose Label until I read RFC 6790. Perhaps explain that looking for the ELI is typically the only reason why a LSR would inspect the middle of the label stack? Re answer 6 of Section 3: If an ingress LSR pushes ESPLs onto the label stack, any downstream LSRs that do not understand ESPLs could erroneously use the ESPLs as load balancing inputs. Would it be a good idea to recommend that ingress LSRs avoid pushing ESPLs onto the label stack if their policy cannot tolerate variations in downstream load balancing caused by inappropriate use of the ESPLs as load balancing inputs by downstream LSRs that don't understand ESPLs? From nobody Mon Mar 10 14:34:42 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E8F1A04E9; Mon, 10 Mar 2014 14:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-78hI4tPBTd; Mon, 10 Mar 2014 14:34:40 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id B96D91A0146; Mon, 10 Mar 2014 14:34:39 -0700 (PDT) X-AuditID: 1209190c-f794a6d000000c27-55-531e2fe909c5 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 08.AA.03111.9EF2E135; Mon, 10 Mar 2014 17:34:33 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s2ALYWsk008989; Mon, 10 Mar 2014 17:34:33 -0400 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s2ALYVoJ004566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Mar 2014 17:34:32 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id s2ALYVN0025196; Mon, 10 Mar 2014 17:34:31 -0400 (EDT) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mpls-special-purpose-labels.all@tools.ietf.org From: Tom Yu Date: Mon, 10 Mar 2014 17:34:31 -0400 Message-ID: Lines: 34 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixCmqrftSXy7Y4PhvLYsTX2eyWcz4M5HZ 4sPChywOzB5Llvxk8vhy+TNbAFMUl01Kak5mWWqRvl0CV8b751fYCrp5Kg5O/srSwHiPs4uR g0NCwETi5jL5LkZOIFNM4sK99WxdjFwcQgKzmSS6fl5gBkkICWxklHhwXhEicY5J4uTafnYI p4tRYtf9f2wgVSICaRJzDl9jB7GFBXwkHi46xw6ygU1AWuLo4jKQMIuAqsSjLc9ZQWxeAQuJ BT13wVp5BDglevu6mSHighInZz5hAbGZBbQkbvx7yTSBkW8WktQsJKkFjEyrGGVTcqt0cxMz c4pTk3WLkxPz8lKLdA31cjNL9FJTSjcxggNNkmcH45uDSocYBTgYlXh4D7yVCRZiTSwrrsw9 xCjJwaQkypunIxcsxJeUn1KZkVicEV9UmpNafIhRgoNZSYR3nThQjjclsbIqtSgfJiXNwaIk ztt3ViJYSCA9sSQ1OzW1ILUIJivDwaEkwasPjCghwaLU9NSKtMycEoQ0EwcnyHAeoOHmIDW8 xQWJucWZ6RD5U4yKUuK8CnpACQGQREZpHlwvLBG8YhQHekWYVwCknQeYROC6XwENZgIa3Hxc CmRwSSJCSqqBUZpFZXZRc+jkuPUlGfYvFyTdbD0beeC8hmzlQstlFrMtw571GjtOb8yXfTYj s8359L73NnlcExVvHmk1O61+oKxXOvbTm2Zd6VdzfDN+bsyQZnAr0fcXW/9mg/GcqhXSuTYb KmXPqrrcfbrtWuzEdH0eZWHvAJXwOUlm8rdmTEq+tKdI6/sdJZbijERDLeai4kQA0BSblt8C AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/5DgLi6qXahDiwP9IYJ5bw43YakM Subject: [secdir] secdir review of draft-ietf-mpls-special-purpose-labels-05 (resend) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 21:34:41 -0000 [Sorry for the resend; I got the tools address for the draft wrong at first.] 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 believe the Security Considerations section of this document is reasonable. Query: I'm not very familiar with MPLS; is the handling of the Entropy Label Indicator the only situation where a Label Switching Router would need to inspect (as opposed to hash for load balancing) labels below the top of the label stack? I was confused by the explanation of why Label 7 (ELI) has meaning as both an ordinary Special Label and an Extended Special Purpose Label until I read RFC 6790. Perhaps explain that looking for the ELI is typically the only reason why a LSR would inspect the middle of the label stack? Re answer 6 of Section 3: If an ingress LSR pushes ESPLs onto the label stack, any downstream LSRs that do not understand ESPLs could erroneously use the ESPLs as load balancing inputs. Would it be a good idea to recommend that ingress LSRs avoid pushing ESPLs onto the label stack if their policy cannot tolerate variations in downstream load balancing caused by inappropriate use of the ESPLs as load balancing inputs by downstream LSRs that don't understand ESPLs? From nobody Tue Mar 11 00:52:42 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566CE1A0139 for ; Tue, 11 Mar 2014 00:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuR0CJZa5gDl for ; Tue, 11 Mar 2014 00:52:39 -0700 (PDT) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id BEC751A0381 for ; Tue, 11 Mar 2014 00:52:36 -0700 (PDT) Received: by mail-ve0-f178.google.com with SMTP id jw12so8082990veb.37 for ; Tue, 11 Mar 2014 00:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=I3eNdwH73PZkePkVIU3Vk0pB155NU32wUZaitGTMQhw=; b=GmhAmTHGyvnqEWfSTiM6nCIMTqpBNd23E9kykUh6kdeLGbw3rkmm9muyCcYYkoWU2Y 8XF2yKB35OhgI/nbq59rPFXPXeCXeC2ji4QAiB7/xSGY32aKSmXzjpf5aVXlTKJnFVX3 OlKiFJ+JCdnrlIyDvE1R5zpfxk949/csJ77zchMcA44TVs2WNFstbaTHjuCMtBpAiC17 xlvLlg98LGxCzfrZguYZO+8nQXd8DJN0l3SyDPdF4nBtSGYv9mmZ3ELqvWUq0sVGRG0Y AWRDUC28UsovutdwVTi9juOjteoW8kphwnGL3Q8tIToNGHA5RZbRzD2S3UTUpEEbzpoz 1cjA== MIME-Version: 1.0 X-Received: by 10.52.69.146 with SMTP id e18mr25526742vdu.15.1394524349768; Tue, 11 Mar 2014 00:52:29 -0700 (PDT) Received: by 10.52.173.204 with HTTP; Tue, 11 Mar 2014 00:52:29 -0700 (PDT) Date: Tue, 11 Mar 2014 00:52:29 -0700 Message-ID: From: Julien Laganier To: "secdir@ietf.org" , draft-fairhurst-ipdvb-ule-iana.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/4qi2vHS4UCjcoe6NPR7QMsWtxEU Subject: [secdir] secdir review of draft-fairhurst-ipdvb-ule-iana-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 07:52:40 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This document clarifies that the applicability of the IANA registry for ULE's (Unidirectional Lightweight Encapsulation) Next Header Type [RFC4326] extends to ETSI's DVB (Digital Video Broadcasting) Generic Stream Encapsulation (GSE) Protocol. As such this document appears to have no security conditions. From nobody Thu Mar 13 02:52:20 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD2A1A099B for ; Thu, 13 Mar 2014 02:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4eftM8z0td4 for ; Thu, 13 Mar 2014 02:52:16 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id B014E1A09A8 for ; Thu, 13 Mar 2014 02:52:14 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s2D9q5Hk027535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 13 Mar 2014 11:52:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s2D9q559016310; Thu, 13 Mar 2014 11:52:05 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21281.32709.464078.446082@fireball.kivinen.iki.fi> Date: Thu, 13 Mar 2014 11:52:05 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/pOp263dl1ajVJucGv82Ip0P3ihM Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 09:52:19 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Shawn Emery is next in the rotation. For telechat 2014-03-27 Reviewer LC end Draft Shaun Cooley T 2014-03-17 draft-ietf-appsawg-rrvs-header-field-07 Alan DeKok T 2014-03-17 draft-ietf-appsawg-xml-mediatypes-09 Steve Hanna TR2013-10-16 draft-ietf-manet-smf-mib-10 Scott Kelly TR2013-05-29 draft-ietf-cuss-sip-uui-14 Catherine Meadows TR2014-02-17 draft-ietf-dmm-requirements-15 Adam Montville T 2014-02-19 draft-ietf-storm-rdmap-ext-09 Yoav Nir TR2014-02-24 draft-ietf-eman-framework-16 Radia Perlman T 2014-02-24 draft-ietf-multimob-pmipv6-source-08 Zach Shelby T 2013-08-30 draft-kaplan-insipid-session-id-04 Ondrej Sury T 2014-02-27 draft-ietf-ippm-testplan-rfc2680-04 Brian Weis T 2014-02-28 draft-ietf-ecrit-trustworthy-location-08 Tom Yu TR2014-01-17 draft-ietf-abfab-arch-12 For telechat 2014-04-03 Derek Atkins T 2014-03-12 draft-ietf-ipsecme-ikev2-fragmentation-05 Sandy Murphy T 2014-03-05 draft-melnikov-smime-msa-to-mda-04 For telechat 2014-04-10 Rob Austein T 2014-03-24 draft-ietf-cdni-framework-10 Last calls and special requests: Donald Eastlake 2014-03-24 draft-ietf-netext-pmip6-qos-11 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-11 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-08 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Vincent Roca 2014-02-25 draft-ietf-sidr-policy-qualifiers-01 Carl Wallace 2014-03-14 draft-drage-sipping-rfc3455bis-13 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 Dacheng Zhang 2014-03-14 draft-vanelburg-dispatch-private-network-ind-05 -- kivinen@iki.fi From nobody Fri Mar 14 03:32:55 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2257C1A00EF; Fri, 14 Mar 2014 03:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdVCnul1EN9h; Fri, 14 Mar 2014 03:32:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2D81A0100; Fri, 14 Mar 2014 03:32:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEO38095; Fri, 14 Mar 2014 10:32:37 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Mar 2014 10:31:29 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Mar 2014 10:32:12 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.209]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Fri, 14 Mar 2014 18:32:08 +0800 From: "Zhangdacheng (Dacheng)" To: "secdir@ietf.org" Thread-Topic: secdir review of draft-vanelburg-dispatch-private-network-ind-05 Thread-Index: Ac8/cKSE3IBqqIfsSWK0qV6GmzJeoQ== Date: Fri, 14 Mar 2014 10:32:07 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: multipart/alternative; boundary="_000_C72CBD9FE3CA604887B1B3F1D145D05E7BC3D75Bnkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/lSr20ej1d2wEgpvlA1dhn_iiXfk Cc: "iesg@ietf.org" , "draft-vanelburg-dispatch-private-network-ind.all@tools.ietf.org" Subject: [secdir] secdir review of draft-vanelburg-dispatch-private-network-ind-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 10:32:50 -0000 --_000_C72CBD9FE3CA604887B1B3F1D145D05E7BC3D75Bnkgeml507mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to for early review of WG drafts. These comments were written prim= arily for the benefit of the security area directors. Document editors and= working group chairs should treat these comments just like any other comme= nts. This document specifies a SIP P-Private-Network-Indication P-header which i= s able to contain a domain name to identify the organization that certain p= rivate network traffics belong to and enable network nodes to process diffe= rent traffics with different sets of rules. There are some comments in the security considerations. A: "The private network indication defined in this document MUST only be us= ed in an environment where elements are trusted and where attackers do not = have access to the protocol messages between those elements." This sentence is not very accurate. In the examples discussed in the docume= nt, the private traffics could be transported over public networks, where t= hey can be "accessed" by attackers. In addition, there is no definition of = "trust" or "trusted notes". I guess you are using the terms specified in RF= C3324. If so, please mention it in section 3. When using the terms in RFC33= 24, I think this sentence could be changed to "The private network indicati= on defined in this document MUST only be used in an environment where eleme= nts are trusted and there are secure connections between those elements." O= r even simpler, "The private network indication defined in this document MU= ST only be used in the traffics transported between the elements which are = mutually trusted." B: "Traffic protection between network elements can be achieved by using IP= sec and sometimes by physical protection of the network." Because we intend to provide confidentiality protection for the contents of= this header field, IPsec AH may not be suitable here. So, maybe we can cha= nge this sentence to "Traffic protection between network elements can be ac= hieved by using the security protocols such as IPsec ESP [RFC2406] or somet= imes by physical protection of the network." C: "A private network indication received from an untrusted node MUST NOT b= e used and the information MUST be removed from a request or response befor= e it is forwarded to entities in the trust domain." There is a concern about this sentence. If a device receives a message with= a invalid indication, should the device forwards it or just discards it? D: "There is a security risk if a private network indication is allowed to= propagate out of the trust domain where it was generated. In that case sen= sitive information would be revealed by such a breach." It would be good to clarify what kind information is sensitive and what kin= d of risk will be caused by disclosing such information. The domain name of= an organization is public, right? I know the leak of the domain name is un= desired. But I suggest making some discussions here. E: "There is no automatic mechanism to learn the support for this specifica= tion." Maybe we can change this sentence to "However, how to learn such knowledge = is out of scope." Cheers Dacheng --_000_C72CBD9FE3CA604887B1B3F1D145D05E7BC3D75Bnkgeml507mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I have reviewed this document as part of the sec= urity directorate's ongoing effort to for early review of WG drafts.  = These comments were written primarily for the benefit of the security area directors.  Document editors and working= group chairs should treat these comments just like any other comments.

 

This document specifies a SIP P-Private-Network-= Indication P-header which is able to contain a domain name to identify the = organization that certain private network traffics belong to and enable network nodes to process different traffics = with different sets of rules.

 

There are some comments in the security consider= ations.

 

A: “The private network indication defined= in this document MUST only be used in an environment where elements are tr= usted and where attackers do not have access to the protocol messages between those elements.”<= /p>

  

This sentence is not very accurate. In the examp= les discussed in the document, the private traffics could be transported ov= er public networks, where they can be “accessed” by attackers. In addition, there is no definition of “trust” or “trusted notes”. I guess you are using the terms specified in RFC3324. If= so, please mention it in section 3. When using the terms in RFC3324, I think this sentence could be changed to ”The pri= vate network indication defined in this document MUST only be used in an en= vironment where elements are trusted and there are secure connections betwe= en those elements.” Or even simpler, “The private network indication defined in this document MUST only be used in t= he traffics transported between the elements which are mutually trusted.= 221;

 

B: “Traffic protection between network ele= ments can be achieved by using IPsec and sometimes by physical protection o= f the network.” 

 

Because we intend to provide confidentiality pro= tection for the contents of this header field, IPsec AH may not be suitable= here. So, maybe we can change this sentence to “Traffic protection between network elements can be achieved by using = the security protocols such as IPsec ESP [RFC2406] or sometimes by physical= protection of the network.”

 

C: “A private network indication received = from an untrusted node MUST NOT be used and the information MUST be removed= from a request or response before it is forwarded to entities in the trust domain.”

 

There is a concern about this sentence. If a dev= ice receives a message with a invalid indication, should the device forward= s it or just discards it?

 

D:  “There is a security risk if a pr= ivate network indication is allowed to propagate out of the trust domain wh= ere it was generated. In that case sensitive information would be revealed by such a breach.”

 

It would be good to clarify what kind informatio= n is sensitive and what kind of risk will be caused by disclosing such info= rmation. The domain name of an organization is public, right? I know the leak of the domain name is undesired. But I s= uggest making some discussions here.

 

E: “There is no automatic mechanism to lea= rn the support for this specification.”

 

Maybe we can change this sentence to “Howe= ver, how to learn such knowledge is out of scope.”<= /p>

 

Cheers

 

Dacheng

--_000_C72CBD9FE3CA604887B1B3F1D145D05E7BC3D75Bnkgeml507mbschi_-- From nobody Mon Mar 17 00:04:03 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD471A0030; Mon, 17 Mar 2014 00:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01SHn0n3lKmG; Mon, 17 Mar 2014 00:03:57 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id F1C6C1A03A8; Mon, 17 Mar 2014 00:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1499; q=dns/txt; s=iport; t=1395039829; x=1396249429; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=cqlVAIhjToJHIh+uxC0hW3F/VeYaYCfQ2LkY56EpxfM=; b=Uy6VVXvJb8BB8Bx49pviuihsCaD7d77pRSMCNE3wqyIRvKnWkvpXni+u Zw/n46W0zzmZP8w8F3Hmvvcitdy0MRZahpiNs/Hxlns+dl4lbkUepjuFU U+iSKmfnWMUvMWwDxKDPQLtLGudwAFW8mnsfLuSF+xUmD0zCP2hkXeyXj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAMSdJlOtJV2a/2dsb2JhbABZgwaBEsIHgRgWdIInAQR5EgEqC0smAQQBDQ2HcdIyF44VAgEBHjERgxqBFAEDiRqhW4MtgXI5 X-IronPort-AV: E=Sophos;i="4.97,668,1389744000"; d="scan'208";a="307709908" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 17 Mar 2014 07:03:49 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2H73m18005344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Mar 2014 07:03:49 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.205]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Mon, 17 Mar 2014 02:03:48 -0500 From: "Shaun Cooley (shcooley)" To: "secdir@ietf.org" , "iesg@ietf.org" Thread-Topic: secdir review of draft-ietf-appsawg-rrvs-header-field Thread-Index: Ac9BrCh2zAg7BhNeSsS1/SZjUWgivA== Date: Mon, 17 Mar 2014 07:03:48 +0000 Message-ID: <187A7B1DA239514F9146FC78B19AADE30B6CAE6A@xmb-aln-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.219.109] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Of6Nykj-nkdnR-YGgHpAJ3hjd1M Cc: "draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org" Subject: [secdir] secdir review of draft-ietf-appsawg-rrvs-header-field X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 07:04:00 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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. This document defines an extension for SMTP called RRVS, along with a new M= AIL header field called Require-Recipient-Valid-Since, that allows senders = to indicate to receivers the last date when the sender confirmed the owners= hip of the target mailbox with the intended recipient, with a goal of preve= nting sensitive mail from being delivered to the wrong party if the ownersh= ip of a mailbox has changed. The document is easy to understand and covers several information disclosur= e issues that might arise from abuse of the RRVS extension or matching head= er. I consider this document to be ready for publication with two small ni= ts: - The suggested abuse countermeasures described in 14.1 should be reworded= to indicate that operators SHOULD (or are RECOMMENDED to) implement counte= rmeasures against RRVS probing. - The suggested use restrictions described in 14.2 should be reworded to i= ndicate that operators SHOULD (or are RECOMMENDED to) accept any RRVS datet= ime as valid for accounts that have only had a single owner, even if the RR= VS datetime predates the creation of the target account. -Shaun From nobody Mon Mar 17 18:20:32 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CA31A045D for ; Mon, 17 Mar 2014 18:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URKuDCsMvn5O for ; Mon, 17 Mar 2014 18:20:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9D70B1A0473 for ; Mon, 17 Mar 2014 18:20:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCE04190; Tue, 18 Mar 2014 01:20:17 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Mar 2014 01:19:59 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Mar 2014 01:20:00 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.209]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 18 Mar 2014 09:19:56 +0800 From: "Zhangdacheng (Dacheng)" To: "secdir@ietf.org" Thread-Topic: secdir review of draft-vanelburg-dispatch-private-network-ind-05 Thread-Index: Ac8/cKSE3IBqqIfsSWK0qV6GmzJeoQC1326Q Date: Tue, 18 Mar 2014 01:19:56 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: multipart/alternative; boundary="_000_C72CBD9FE3CA604887B1B3F1D145D05E7BC3DFEBnkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/LNMtn6Z0zVPh2l9-3Bb9k_gUJhs Subject: [secdir] FW: secdir review of draft-vanelburg-dispatch-private-network-ind-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 01:20:31 -0000 --_000_C72CBD9FE3CA604887B1B3F1D145D05E7BC3DFEBnkgeml507mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Zhangdacheng (Dacheng) Sent: Friday, March 14, 2014 6:32 PM To: secdir@ietf.org Cc: iesg@ietf.org; 'draft-vanelburg-dispatch-private-network-ind.all@tools.= ietf.org' Subject: secdir review of draft-vanelburg-dispatch-private-network-ind-05 I have reviewed this document as part of the security directorate's ongoing= effort to for early review of WG drafts. These comments were written prim= arily for the benefit of the security area directors. Document editors and= working group chairs should treat these comments just like any other comme= nts. This document specifies a SIP P-Private-Network-Indication P-header which i= s able to contain a domain name to identify the organization that certain p= rivate network traffics belong to and enable network nodes to process diffe= rent traffics with different sets of rules. There are some comments in the security considerations. A: "The private network indication defined in this document MUST only be us= ed in an environment where elements are trusted and where attackers do not = have access to the protocol messages between those elements." This sentence is not very accurate. In the examples discussed in the docume= nt, the private traffics could be transported over public networks, where t= hey can be "accessed" by attackers. In addition, there is no definition of = "trust" or "trusted notes". I guess you are using the terms specified in RF= C3324. If so, please mention it in section 3. When using the terms in RFC33= 24, I think this sentence could be changed to "The private network indicati= on defined in this document MUST only be used in an environment where eleme= nts are trusted and there are secure connections between those elements." O= r even simpler, "The private network indication defined in this document MU= ST only be used in the traffics transported between the elements which are = mutually trusted." B: "Traffic protection between network elements can be achieved by using IP= sec and sometimes by physical protection of the network." Because we intend to provide confidentiality protection for the contents of= this header field, IPsec AH may not be suitable here. So, maybe we can cha= nge this sentence to "Traffic protection between network elements can be ac= hieved by using the security protocols such as IPsec ESP [RFC2406] or somet= imes by physical protection of the network." C: "A private network indication received from an untrusted node MUST NOT b= e used and the information MUST be removed from a request or response befor= e it is forwarded to entities in the trust domain." There is a concern about this sentence. If a device receives a message with= a invalid indication, should the device forwards it or just discards it? D: "There is a security risk if a private network indication is allowed to= propagate out of the trust domain where it was generated. In that case sen= sitive information would be revealed by such a breach." It would be good to clarify what kind information is sensitive and what kin= d of risk will be caused by disclosing such information. The domain name of= an organization is public, right? I know the leak of the domain name is un= desired. But I suggest making some discussions here. E: "There is no automatic mechanism to learn the support for this specifica= tion." Maybe we can change this sentence to "However, how to learn such knowledge = is out of scope." Cheers Dacheng --_000_C72CBD9FE3CA604887B1B3F1D145D05E7BC3DFEBnkgeml507mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 = ;

 = ;

From: Z= hangdacheng (Dacheng)
Sent: Friday, March 14, 2014 6:32 PM
To: secdir@ietf.org
Cc: iesg@ietf.org; 'draft-vanelburg-dispatch-private-network-ind.all= @tools.ietf.org'
Subject: secdir review of draft-vanelburg-dispatch-private-network-i= nd-05

 

 

I = have reviewed this document as part of the security directorate's ongoing e= ffort to for early review of WG drafts.  These comments were written p= rimarily for the benefit of the security area directors.  Document editors and working group chairs should treat th= ese comments just like any other comments.

 

Th= is document specifies a SIP P-Private-Network-Indication P-header which is = able to contain a domain name to identify the organization that certain pri= vate network traffics belong to and enable network nodes to process different traffics with different sets of rules.<= o:p>

 

Th= ere are some comments in the security considerations.

 

A:= “The private network indication defined in this document MUST only b= e used in an environment where elements are trusted and where attackers do = not have access to the protocol messages between those elements.”

&n= bsp; 

Th= is sentence is not very accurate. In the examples discussed in the document= , the private traffics could be transported over public networks, where the= y can be “accessed” by attackers. In addition, there is no definition of “trust” or “trusted notes”. I guess you are using the terms specified in RFC3324. If= so, please mention it in section 3. When using the terms in RFC3324, I think this sentence could be changed to ”The pri= vate network indication defined in this document MUST only be used in an en= vironment where elements are trusted and there are secure connections betwe= en those elements.” Or even simpler, “The private network indication defined in this document MUST only be used in t= he traffics transported between the elements which are mutually trusted.= 221;

 

B:= “Traffic protection between network elements can be achieved by usin= g IPsec and sometimes by physical protection of the network.” 

 

Be= cause we intend to provide confidentiality protection for the contents of t= his header field, IPsec AH may not be suitable here. So, maybe we can chang= e this sentence to “Traffic protection between network elements can be achieved by using the = security protocols such as IPsec ESP [RFC2406] or sometimes by physical pro= tection of the network.”

 

C:= “A private network indication received from an untrusted node MUST N= OT be used and the information MUST be removed from a request or response b= efore it is forwarded to entities in the trust domain.”

 

Th= ere is a concern about this sentence. If a device receives a message with a= invalid indication, should the device forwards it or just discards it?

 

D:=  “There is a security risk if a private network indication is a= llowed to propagate out of the trust domain where it was generated. In that= case sensitive information would be revealed by such a breach.”

 

It= would be good to clarify what kind information is sensitive and what kind = of risk will be caused by disclosing such information. The domain name of a= n organization is public, right? I know the leak of the domain name is undesired. But I suggest making some discus= sions here.

 

E:= “There is no automatic mechanism to learn the support for this speci= fication.”

 

Ma= ybe we can change this sentence to “However, how to learn such knowle= dge is out of scope.”

 

Ch= eers

 

Da= cheng

--_000_C72CBD9FE3CA604887B1B3F1D145D05E7BC3DFEBnkgeml507mbschi_-- From nobody Mon Mar 17 21:18:07 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA1B1A03FC; Mon, 17 Mar 2014 21:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-RjoElpeoly; Mon, 17 Mar 2014 21:18:00 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4F51A0364; Mon, 17 Mar 2014 21:18:00 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id mc6so4366674lab.13 for ; Mon, 17 Mar 2014 21:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iTnPGD51TnsxEVIKIBA7WdYzVtnbDSdtCZkXiKH0MF4=; b=CtwVJ+JM6Sb/hzpwTMddKEbNXWWFv4kcgraXa1b6jcoyTsXBuXxGd3fqeC0MviucND XmNwYSeJfw67zwsmVCDy3up9XPnzDGxQfs8SNFbTaUGi3V8e8pexgu8lEUsOR8ClQBcl OWmeDkAxgX7GaBOVYnm8NZq28lvpziU/DmCpnKyR3Y7GzRL0BSFcy+pyoikfMdQ9s75b hV16PaODKYusFjuS5ZtkORHY1+U0tpGqiAnN2OaAQlgugE9pjuZ2MSl5BRo/jVPgVKSm BAgwHovA9IPfsfuo4Jn5HcNKdO7Og+2VIY35tGPKYPs/NVcdy6gPd7u1PtQl6X754hnc y0ig== MIME-Version: 1.0 X-Received: by 10.112.164.5 with SMTP id ym5mr80204lbb.48.1395116271389; Mon, 17 Mar 2014 21:17:51 -0700 (PDT) Received: by 10.112.199.2 with HTTP; Mon, 17 Mar 2014 21:17:51 -0700 (PDT) Date: Mon, 17 Mar 2014 21:17:51 -0700 Message-ID: From: Radia Perlman To: "secdir@ietf.org" , The IESG , draft-ietf-multimob-pmipv6-source.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c26818c6d1a304f4d9d112 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Flb-Zgha9y54Oj4AtK2dBxwd0vA Subject: [secdir] Secdir review of draft-ietf-multimob-pmipv6-source X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 04:18:02 -0000 --001a11c26818c6d1a304f4d9d112 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 17, 2013 at 7:11 PM, Radia Perlman wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document combines mobile IPv6 with multicast. It's unnecessarily difficult to read. There should be a section upfront expanding all the acronyms, at the very least. For instance, MLD, PMIPv6, PIM, MAG, HNP. Some of these (like MAG) are expanded in the text the first time they are used, but most are not, and people aren't necessarily going to remember it because of seeing it once, and there's no downside to having a section in the introduction called "acronyms". It also wouldn't hurt to explain "proxy mobile IPv6 domains" (not just expand the acronym PMIPv6). I admit I don't completely understand this document, because I didn't want to have to read all the other documents that this thing assumes you understand, but I think I get the general idea. I think the security considerations section covers most of the downsides, but it doesn't talk about how multicast in general can amplify DOS packets. And with mobility, there are two problems with having a proxy sending the multicast (unless it's tunneled, which would be OK). If packets with an IP source address can come from a different location, then loops won't be detected (the security considerations section mentions that), but also, it's harder for the infrastructure to filter out packets from forged IP addresses. Radia --001a11c26818c6d1a304f4d9d112 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Dec 17, 2013 at 7:11 PM, Radia Perlman &l= t;radiaperlman@= gmail.com> wrote:
I have reviewed this document as part of the security directorate's=20
ongoing effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the=20
security area directors.  Document editors and WG chairs should treat=20
these comments just like any other last call comments.
This document combines mobile IPv6 with multicast. =A0It's unn= ecessarily difficult to read. =A0There should be a section upfront expandin= g all the acronyms, at the very least. =A0For instance, MLD, PMIPv6, PIM, M= AG, HNP. =A0Some of these (like MAG) are expanded in the text the first tim= e they are used, but most are not, and people aren't necessarily going = to remember it because of seeing it once, and there's no downside to ha= ving a section in the introduction called "acronyms".

It also wouldn't hurt to explain "proxy mobile= IPv6 domains" =A0(not just expand the acronym PMIPv6).

=
I admit I don't completely understand this document, because= I didn't want to have to read all the other documents that this thing = assumes you understand, but I think I get the general idea.

I think the security considerations section covers most= of the downsides, but it doesn't talk about how multicast in general c= an amplify DOS packets. =A0And with mobility, there are two problems with h= aving a proxy sending the multicast (unless it's tunneled, which would = be OK). =A0If packets with an IP source address can come from a different l= ocation, then loops won't be detected (the security considerations sect= ion mentions that), but also, it's harder for the infrastructure to fil= ter out packets from forged IP addresses.

Radia


--001a11c26818c6d1a304f4d9d112-- From nobody Tue Mar 18 04:16:16 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273261A03C9; Tue, 18 Mar 2014 04:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.783 X-Spam-Level: X-Spam-Status: No, score=-99.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ODWqw9oNI7n; Tue, 18 Mar 2014 04:16:08 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8660D1A06A8; Tue, 18 Mar 2014 04:16:08 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2IBFxHe030545; Tue, 18 Mar 2014 11:15:59 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2IBFqJw030437 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2014 11:15:57 GMT From: "Adrian Farrel" To: "'Tom Yu'" References: In-Reply-To: Date: Tue, 18 Mar 2014 11:15:52 -0000 Message-ID: <013c01cf429b$70b72a90$52257fb0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHqkxBwphpOBtuABjYo2lKAwgzvvZqwDANA Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20572.005 X-TM-AS-Result: No--9.101-10.0-31-10 X-imss-scan-details: No--9.101-10.0-31-10 X-TMASE-MatchedRID: +f/wAVSGjuhxtRSiTWsxtfHkpkyUphL9MhomkrNJ+uzNQVzhfYY5so9/ 6wlLhvp4L81jVSVU6+iCbJKOlWLydZ+/3E8wlr+Dde4BwMgBa9OrzMdPEAIrFjAVXG2j6Yswakc q2RAHKcok/TQmrPGEgNZwCHB4c2lu1OGXhAFLw8vCz1ymGcrCUYEcpMn6x9cZi2g8XzxCDfvg9L It2OdOa5KrGRECKhSO8JwrmyXfpoNCl9DEsHnSbbMjW/sniEQKpw/gqzLticlIjvA1/YS+0bliD 6D5Idq7YaIwvoCNtbMo6ikEEzC7Af+JqEYbBLbNSDkh6bW+bccsleOknNBI05soi2XrUn/JyeMt MD9QOgCk8oKXKhRLPI2j49Ftap9EOwBXM346/+w+2PP2xW2k7pcpEZ0AmOH27WhLu0LiBHZJG8u y1zCyHwqZuffWhtd5 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/qaqKIeXKKlTSJu7EWyt5LMTbymY Cc: iesg@ietf.org, draft-ietf-mpls-special-purpose-labels.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-mpls-special-purpose-labels-05 (resend) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 11:16:10 -0000 Hi Tom, > Summary: ready with nits > > I believe the Security Considerations section of this document is > reasonable. > > Query: I'm not very familiar with MPLS; is the handling of the Entropy > Label Indicator the only situation where a Label Switching Router > would need to inspect (as opposed to hash for load balancing) labels > below the top of the label stack? Welcome to the wonderful world of MPLS, and thanks for your review. RFC 6790 Section 4.3 says In any case, reserved labels MUST NOT be used as keys for the load-balancing function. but it is recognised that some implementations might currently be hashing the label stack without inspection. So, the technically correct answer is that every reserved label (aka special purpose label) is such a case, and (since no-one knows what labels will show up in the stack) it means that all labels used for hashing must be inspected. > I was confused by the explanation of why Label 7 (ELI) has meaning as > both an ordinary Special Label and an Extended Special Purpose Label > until I read RFC 6790. Perhaps explain that looking for the ELI is > typically the only reason why a LSR would inspect the middle of the > label stack? Well, this is being changed (somewhat in the face of mutterings from two of the authors) so that 7 is reserved in the extended range. Hence, no need to explain or discuss :-) > Re answer 6 of Section 3: > > If an ingress LSR pushes ESPLs onto the label stack, any downstream > LSRs that do not understand ESPLs could erroneously use the ESPLs as > load balancing inputs. Would it be a good idea to recommend that > ingress LSRs avoid pushing ESPLs onto the label stack if their policy > cannot tolerate variations in downstream load balancing caused by > inappropriate use of the ESPLs as load balancing inputs by downstream > LSRs that don't understand ESPLs? You are right about that. The LSR would spot the XL and know that it was a special purpose label and so would not use it. But it would not know that the XL meant that the next label was also a special purpose label and so would include that label in the hash. And, indeed, this is what the answer to Question 6 observes. And the answer also notes that reordering may occur in these situations (perhaps we thought it obvious that if you don't want reordering to occur you had better avoid this situation?). I think that also in our minds is that this whole piece of work is considerably future-sighted. we don't anticipate the first extended special purpose label being assigned for a number of years, so this document enables hardware to be built and deployed that will be proof against the introduction of ESPLs when they roll up. Thanks, Adrian From nobody Tue Mar 18 12:00:53 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06411A06E8; Tue, 18 Mar 2014 12:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8x582PCoMRa; Tue, 18 Mar 2014 12:00:45 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 09DCD1A07EC; Tue, 18 Mar 2014 12:00:38 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id r10so7511881pdi.30 for ; Tue, 18 Mar 2014 12:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bR45UXVM2jNZex83wrEVQUdPvXNaPTDj2qBHmb5nvt4=; b=nqYoD2+aW3PuYI1tz6mPpUU+a1dkkvnoOd3KnXozK/FigBvA/Tj52RAZ4/ctltoFDz /vc3kUf3qCGL9DyS9wxGu8vRhimL+2D99YyhuYEGAkvU9C+FMfPvP/xwqzowLVslCs2h dB8Br29ssY6Ctd6AwW3j4E1wsagF4OkjOQyNFWzbeG9S1Y8dTUfEPUHEGagmCnhHHFLt KBp1Vdzc4XYeHIEPJIWkfRmQKrIUpw0q1PBJtY6eqLBClhVuEsK2cS5yIgYyEFSDaMko Iquyvrzt7vuCMGZnz8m6PJyHyt7MJ1HX22QMd9l0hlMste5Ngc7lHz9Tvl5mmxetFPhc k6cA== MIME-Version: 1.0 X-Received: by 10.66.144.200 with SMTP id so8mr35402591pab.15.1395169230692; Tue, 18 Mar 2014 12:00:30 -0700 (PDT) Received: by 10.66.220.102 with HTTP; Tue, 18 Mar 2014 12:00:30 -0700 (PDT) In-Reply-To: <187A7B1DA239514F9146FC78B19AADE30B6CAE6A@xmb-aln-x10.cisco.com> References: <187A7B1DA239514F9146FC78B19AADE30B6CAE6A@xmb-aln-x10.cisco.com> Date: Tue, 18 Mar 2014 12:00:30 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Shaun Cooley (shcooley)" Content-Type: multipart/alternative; boundary=047d7b6d928465a77c04f4e62625 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/_icI-ILCk1H9xIFrG582vNvf7JY Cc: "draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-appsawg-rrvs-header-field X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 19:00:49 -0000 --047d7b6d928465a77c04f4e62625 Content-Type: text/plain; charset=ISO-8859-1 Barry, what's your take on these? I'm still under the impression that Security Considerations shouldn't include normative language, but the opinions on this seem to vary from one person and one week to the next. Otherwise, they appear reasonable to me. -MSK On Mon, Mar 17, 2014 at 12:03 AM, Shaun Cooley (shcooley) < shcooley@cisco.com> wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > This document defines an extension for SMTP called RRVS, along with a new > MAIL header field called Require-Recipient-Valid-Since, that allows senders > to indicate to receivers the last date when the sender confirmed the > ownership of the target mailbox with the intended recipient, with a goal of > preventing sensitive mail from being delivered to the wrong party if the > ownership of a mailbox has changed. > > The document is easy to understand and covers several information > disclosure issues that might arise from abuse of the RRVS extension or > matching header. I consider this document to be ready for publication with > two small nits: > > - The suggested abuse countermeasures described in 14.1 should be > reworded to indicate that operators SHOULD (or are RECOMMENDED to) > implement countermeasures against RRVS probing. > > - The suggested use restrictions described in 14.2 should be reworded to > indicate that operators SHOULD (or are RECOMMENDED to) accept any RRVS > datetime as valid for accounts that have only had a single owner, even if > the RRVS datetime predates the creation of the target account. > > -Shaun > --047d7b6d928465a77c04f4e62625 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Barry, what's your take on these? I'm still u= nder the impression that Security Considerations shouldn't include norm= ative language, but the opinions on this seem to vary from one person and o= ne week to the next.

Otherwise, they appear reasonable to me.

-MSK


On Mon, Mar 17, = 2014 at 12:03 AM, Shaun Cooley (shcooley) <shcooley@cisco.com> wrote:
I have reviewed this document as part of the= security directorate's ongoing effort to review all IETF documents bei= ng processed by the IESG. =A0These comments were written primarily for the = benefit of the security area directors. =A0Document editors and WG chairs s= hould treat these comments just like any other last call comments.

This document defines an extension for SMTP called RRVS, along with a new M= AIL header field called Require-Recipient-Valid-Since, that allows senders = to indicate to receivers the last date when the sender confirmed the owners= hip of the target mailbox with the intended recipient, with a goal of preve= nting sensitive mail from being delivered to the wrong party if the ownersh= ip of a mailbox has changed.

The document is easy to understand and covers several information disclosur= e issues that might arise from abuse of the RRVS extension or matching head= er. =A0I consider this document to be ready for publication with two small = nits:

=A0- The suggested abuse countermeasures described in 14.1 should be reword= ed to indicate that operators SHOULD (or are RECOMMENDED to) implement coun= termeasures against RRVS probing.

=A0- The suggested use restrictions described in 14.2 should be reworded to= indicate that operators SHOULD (or are RECOMMENDED to) accept any RRVS dat= etime as valid for accounts that have only had a single owner, even if the = RRVS datetime predates the creation of the target account.

-Shaun

--047d7b6d928465a77c04f4e62625-- From nobody Tue Mar 18 23:12:23 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C339B1A0545 for ; Tue, 18 Mar 2014 23:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6Pyx3kjjYOX for ; Tue, 18 Mar 2014 23:11:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DBDF51A0505 for ; Tue, 18 Mar 2014 23:11:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCF19597; Wed, 19 Mar 2014 06:11:38 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Mar 2014 06:11:25 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Mar 2014 06:11:36 +0000 Received: from NKGEML507-MBS.china.huawei.com ([169.254.6.209]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 19 Mar 2014 14:11:29 +0800 From: "Zhangdacheng (Dacheng)" To: Shida Schubert Thread-Topic: secdir review of draft-vanelburg-dispatch-private-network-ind-05 Thread-Index: Ac8/cKSE3IBqqIfsSWK0qV6GmzJeoQDCTf/wAB7RpQAAERnJwA== Date: Wed, 19 Mar 2014 06:11:28 +0000 Message-ID: References: <398D4FFF-FB13-4686-B7CB-F621912BF5BB@ntt-at.com> In-Reply-To: <398D4FFF-FB13-4686-B7CB-F621912BF5BB@ntt-at.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.139] Content-Type: multipart/alternative; boundary="_000_C72CBD9FE3CA604887B1B3F1D145D05E7BC3EC91nkgeml507mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/wrrPcVipqp5XwEf9mVXXZOhwhK0 Cc: "secdir@ietf.org" , "draft-vanelburg-dispatch-private-network-ind.all@tools.ietf.org" Subject: Re: [secdir] secdir review of draft-vanelburg-dispatch-private-network-ind-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 06:12:07 -0000 --_000_C72CBD9FE3CA604887B1B3F1D145D05E7BC3EC91nkgeml507mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, very happy that you like the comments. About comment D. Your descripti= on about the sensitive information is good. So, could you please in to the = document when updating it? ^_^ Cheers Dacheng From: Shida Schubert [mailto:shida@ntt-at.com] Sent: Wednesday, March 19, 2014 1:58 PM To: Zhangdacheng (Dacheng) Cc: draft-vanelburg-dispatch-private-network-ind.all@tools.ietf.org Subject: Re: secdir review of draft-vanelburg-dispatch-private-network-ind-= 05 Dear Dacheng; From: Zhangdacheng (Dacheng) Sent: Friday, March 14, 2014 6:32 PM To: secdir@ietf.org Cc: iesg@ietf.org; 'draft-vanelburg-dispatch-private-= network-ind.all@tools.ietf.org' Subject: secdir review of draft-vanelburg-dispatch-private-network-ind-05 I have reviewed this document as part of the security directorate's ongoing= effort to for early review of WG drafts. These comments were written prim= arily for the benefit of the security area directors. Document editors and= working group chairs should treat these comments just like any other comme= nts. This document specifies a SIP P-Private-Network-Indication P-header which i= s able to contain a domain name to identify the organization that certain p= rivate network traffics belong to and enable network nodes to process diffe= rent traffics with different sets of rules. There are some comments in the security considerations. A: "The private network indication defined in this document MUST only be us= ed in an environment where elements are trusted and where attackers do not = have access to the protocol messages between those elements." This sentence is not very accurate. In the examples discussed in the docume= nt, the private traffics could be transported over public networks, where t= hey can be"accessed" by attackers. In addition, there is no definition of "= trust" or "trusted notes". I guess you are using the terms specified in RFC= 3324. If so, please mention it in section 3. When using the terms in RFC332= 4, I think this sentence could be changed to "The private network indicatio= n defined in this document MUST only be used in an environment where elemen= ts are trusted and there are secure connections between those elements." Or= even simpler, "The private network indication defined in this document MUS= T only be used in the traffics transported between the elements which are m= utually trusted." Many thanks for suggestion, I will reflect the changes when updating the dr= aft. B: "Traffic protection between network elements can be achieved by using IP= sec and sometimes by physical protection of the network." Because we intend to provide confidentiality protection for the contents of= this header field, IPsec AH may not be suitable here. So, maybe we can cha= nge this sentence to "Traffic protection between network elements can be ac= hieved by using the security protocols such as IPsec ESP [RFC2406] or somet= imes by physical protection of the network." Again, sounds great. Thanks for the suggestion. C: "A private network indication received from an untrusted node MUST NOT b= e used and the information MUST be removed from a request or response befor= e it is forwarded to entities in the trust domain." There is a concern about this sentence. If a device receives a message with= a invalid indication, should the device forwards it or just discards it? As you sated the concern is valid, why should you receive the header from a= n untrusted node. It is very likely an attempt to compromise the public or = private network. We could change it to: "A private network indication received from an untrusted node MUST NOT be u= sed and the information MUST be removed from a request or response before i= t is forwarded to entities in the trust domain. Additionally local policies= may be in place that ensure that all requests entering the trust domain fo= r private network indication from untrusted nodes with a private network in= dication will be discarded." D: "There is a security risk if a private network indication is allowed to= propagate out of the trust domain where it was generated. In that case sen= sitive information would be revealed by such a breach." It would be good to clarify what kind information is sensitive and what kin= d of risk will be caused by disclosing such information. The domain name of= an organization is public, right? I know the leak of the domain name is un= desired. But I suggest making some discussions here. The indication may reveal information about the identity of the caller, i,e= , the organisation that he belongs to. That is sensitive information. It al= so reveals to the outside world that there is a set of rules that this call= is subject to that is different then the rules that apply to public traffi= c. That is sensitive information too. E: "There is no automatic mechanism to learn the support for this specifica= tion." Maybe we can change this sentence to "However, how to learn such knowledge = is out of scope." Great! we will :-) Many Thanks! Shida Cheers Dacheng --_000_C72CBD9FE3CA604887B1B3F1D145D05E7BC3EC91nkgeml507mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, very h= appy that you like the comments. About comment D.  Your description ab= out the sensitive information is good. So, could you please in to the document when updating it? ^_^

 = ;

Cheers

 = ;

Dacheng

 = ;

From: Shida Schubert [mailto:shida@ntt-at.com]
Sent: Wednesday, March 19, 2014 1:58 PM
To: Zhangdacheng (Dacheng)
Cc: draft-vanelburg-dispatch-private-network-ind.all@tools.ietf.org<= br> Subject: Re: secdir review of draft-vanelburg-dispatch-private-netwo= rk-ind-05

 

 

Dear Dacheng; <= /span>

 

 

 

From: Zhangdacheng (Dacheng) 
Sent: Friday, Marc= h 14, 2014 6:32 PM
To: secdir@ietf.org
Cc: iesg@ietf.org; '= draft-vanelburg-dispatch-private-netwo= rk-ind.all@tools.ietf.org'
Subject: secdir re= view of draft-vanelburg-dispatch-private-network-ind-05

 

 

I have reviewed this docume= nt as part of the security directorate's ongoing effort to for early review= of WG drafts.  These comments were written primarily for the benefit = of the security area directors.  Document editors and working group chairs should treat these comments just like any= other comments.

 

This document specifies a S= IP P-Private-Network-Indication P-header which is able to contain a domain = name to identify the organization that certain private network traffics bel= ong to and enable network nodes to process different traffics with different sets of rules.

 

There are some comments in = the security considerations.

 

A: “The private netwo= rk indication defined in this document MUST only be used in an environment = where elements are trusted and where attackers do not have access to the pr= otocol messages between those elements.”

  

This sentence is not very a= ccurate. In the examples discussed in the document, the private traffics co= uld be transported over public networks, where they can be“accessed” by attackers. In addition, there is no definition of “tru= st”=  or “trusted notes”. I guess you are using= the terms specified in RFC3324. If so, please mention it in section 3. Whe= n using the terms in RFC3324, I think this sentence could be changed to ”The private network indication defined in this = document MUST only be used in an environment where elements are trusted and= there are secure connections between those elements.” Or even simple= r, “The private network indication defined in this document MUST only be used in the traffics transported between the el= ements which are mutually trusted.”

 

Many thanks for suggestion, I w= ill reflect the changes when updating the draft. 



 

B: “Traffic protectio= n between network elements can be achieved by using IPsec and sometimes by = physical protection of the network.” 

 

Because we intend to provid= e confidentiality protection for the contents of this header field, IPsec A= H may not be suitable here. So, maybe we can change this sentence to “Traffic protection between network elements can be achieved by using the security = protocols such as IPsec ESP [RFC2406] or sometimes by physical protection o= f the network.”

 

Again, sounds great. Thanks for= the suggestion. 



 

C: “A private network= indication received from an untrusted node MUST NOT be used and the inform= ation MUST be removed from a request or response before it is forwarded to = entities in the trust domain.”

 

There is a concern about th= is sentence. If a device receives a message with a invalid indication, shou= ld the device forwards it or just discards it?

 

As you sated the concern is val= id, why should you receive the header from an untrusted node. It is very li= kely an attempt to compromise the public or private network.

 

We could change it to:
“A private network indication received from an untrusted node MUST NO= T be used and the information MUST be removed from a request or response be= fore it is forwarded to entities in the trust domain. Additionally = local policies may be in place that ensure that all requests entering the trust domain for private network indication= from untrusted nodes with a private network indication will be discarded.<= /i>”



 

D:  “There is a = security risk if a private network indication is allowed to propagate out o= f the trust domain where it was generated. In that case sensitive informati= on would be revealed by such a breach.”

 

It would be good to clarify= what kind information is sensitive and what kind of risk will be caused by= disclosing such information. The domain name of an organization is public,= right? I know the leak of the domain name is undesired. But I suggest making some discussions here.<= /span>

 

 

The indication may reveal infor= mation about the identity of the caller, i,e, the organisation that he belo= ngs to. That is sensitive information. It also reveals to the outside world= that there is a set of rules that this call is subject to that is different then the rules that apply to public t= raffic. That is sensitive information too.

 



E: “There is no autom= atic mechanism to learn the support for this specification.”

 

Maybe we can change this se= ntence to “However, how to learn such knowledge is out of scope.̶= 1;

 

 Great! we will :-)

 

 Many Thanks! 

 

 Shida



 

Cheers

 

Dacheng

 

--_000_C72CBD9FE3CA604887B1B3F1D145D05E7BC3EC91nkgeml507mbschi_-- From nobody Wed Mar 19 05:51:46 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E481A04A6 for ; Tue, 18 Mar 2014 23:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGfo0CvnO-mW for ; Tue, 18 Mar 2014 23:17:01 -0700 (PDT) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) by ietfa.amsl.com (Postfix) with ESMTP id CD0371A0505 for ; Tue, 18 Mar 2014 23:17:00 -0700 (PDT) Received: from [50.184.77.69] (port=61319 helo=[192.168.1.24]) by gator4135.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1WQ9o1-0004aU-0N; Wed, 19 Mar 2014 01:16:49 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_6E2E00DA-1034-4D33-8640-D70772D957E1" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Shida Schubert In-Reply-To: Date: Tue, 18 Mar 2014 23:16:42 -0700 Message-Id: <76FEA635-5720-4947-9123-AF3F224BCBC1@ntt-at.com> References: <398D4FFF-FB13-4686-B7CB-F621912BF5BB@ntt-at.com> To: "Zhangdacheng (Dacheng)" X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 50.184.77.69 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.24]) [50.184.77.69]:61319 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ANuREEsZFEh9bjB2sYME8znLkcQ X-Mailman-Approved-At: Wed, 19 Mar 2014 05:51:45 -0700 Cc: "secdir@ietf.org" , "draft-vanelburg-dispatch-private-network-ind.all@tools.ietf.org" Subject: Re: [secdir] secdir review of draft-vanelburg-dispatch-private-network-ind-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 06:17:06 -0000 --Apple-Mail=_6E2E00DA-1034-4D33-8640-D70772D957E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Decheng; I am glad the description is acceptable.. I will make the change and = submit the=20 doc over the next few days.=20 Thanks again for reviewing and providing constructive/valuable = feedback!=20 =20 Shida On Mar 18, 2014, at 11:11 PM, Zhangdacheng (Dacheng) = wrote: > Hi, very happy that you like the comments. About comment D. Your = description about the sensitive information is good. So, could you = please in to the document when updating it? ^_^ > =20 > Cheers > =20 > Dacheng > =20 > From: Shida Schubert [mailto:shida@ntt-at.com]=20 > Sent: Wednesday, March 19, 2014 1:58 PM > To: Zhangdacheng (Dacheng) > Cc: draft-vanelburg-dispatch-private-network-ind.all@tools.ietf.org > Subject: Re: secdir review of = draft-vanelburg-dispatch-private-network-ind-05 > =20 > =20 > Dear Dacheng;=20 > =20 > =20 > =20 > From: Zhangdacheng (Dacheng)=20 > Sent: Friday, March 14, 2014 6:32 PM > To: secdir@ietf.org > Cc: iesg@ietf.org; = 'draft-vanelburg-dispatch-private-network-ind.all@tools.ietf.org' > Subject: secdir review of = draft-vanelburg-dispatch-private-network-ind-05 > =20 > =20 > I have reviewed this document as part of the security directorate's = ongoing effort to for early review of WG drafts. These comments were = written primarily for the benefit of the security area directors. = Document editors and working group chairs should treat these comments = just like any other comments. > =20 > This document specifies a SIP P-Private-Network-Indication P-header = which is able to contain a domain name to identify the organization that = certain private network traffics belong to and enable network nodes to = process different traffics with different sets of rules. > =20 > There are some comments in the security considerations. > =20 > A: =93The private network indication defined in this document MUST = only be used in an environment where elements are trusted and where = attackers do not have access to the protocol messages between those = elements.=94 > =20 > This sentence is not very accurate. In the examples discussed in the = document, the private traffics could be transported over public = networks, where they can be=93accessed=94 by attackers. In addition, = there is no definition of =93trust=94 or =93trusted notes=94. I guess = you are using the terms specified in RFC3324. If so, please mention it = in section 3. When using the terms in RFC3324, I think this sentence = could be changed to =94The private network indication defined in this = document MUST only be used in an environment where elements are trusted = and there are secure connections between those elements.=94 Or even = simpler, =93The private network indication defined in this document MUST = only be used in the traffics transported between the elements which are = mutually trusted.=94 > =20 > Many thanks for suggestion, I will reflect the changes when updating = the draft.=20 >=20 >=20 > =20 > B: =93Traffic protection between network elements can be achieved by = using IPsec and sometimes by physical protection of the network.=94=20 > =20 > Because we intend to provide confidentiality protection for the = contents of this header field, IPsec AH may not be suitable here. So, = maybe we can change this sentence to =93Traffic protection between = network elements can be achieved by using the security protocols such as = IPsec ESP [RFC2406] or sometimes by physical protection of the network.=94= > =20 > Again, sounds great. Thanks for the suggestion.=20 >=20 >=20 > =20 > C: =93A private network indication received from an untrusted node = MUST NOT be used and the information MUST be removed from a request or = response before it is forwarded to entities in the trust domain.=94 > =20 > There is a concern about this sentence. If a device receives a message = with a invalid indication, should the device forwards it or just = discards it? > =20 > As you sated the concern is valid, why should you receive the header = from an untrusted node. It is very likely an attempt to compromise the = public or private network. > =20 > We could change it to: > =93A private network indication received from an untrusted node MUST = NOT be used and the information MUST be removed from a request or = response before it is forwarded to entities in the trust domain. = Additionally local policies may be in place that ensure that all = requests entering the trust domain for private network indication from = untrusted nodes with a private network indication will be discarded.=94 >=20 >=20 > =20 > D: =93There is a security risk if a private network indication is = allowed to propagate out of the trust domain where it was generated. In = that case sensitive information would be revealed by such a breach.=94 > =20 > It would be good to clarify what kind information is sensitive and = what kind of risk will be caused by disclosing such information. The = domain name of an organization is public, right? I know the leak of the = domain name is undesired. But I suggest making some discussions here. > =20 > =20 > The indication may reveal information about the identity of the = caller, i,e, the organisation that he belongs to. That is sensitive = information. It also reveals to the outside world that there is a set of = rules that this call is subject to that is different then the rules that = apply to public traffic. That is sensitive information too. > =20 >=20 >=20 > E: =93There is no automatic mechanism to learn the support for this = specification.=94 > =20 > Maybe we can change this sentence to =93However, how to learn such = knowledge is out of scope.=94 > =20 > Great! we will :-) > =20 > Many Thanks!=20 > =20 > Shida >=20 >=20 > =20 > Cheers > =20 > Dacheng --Apple-Mail=_6E2E00DA-1034-4D33-8640-D70772D957E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Dear = Decheng;

 I am glad the description is = acceptable.. I will make the change and submit the 
doc = over the next few days. 

 Thanks = again for reviewing and providing constructive/valuable = feedback! 
 
 Shida


On Mar 18, 2014, at 11:11 PM, Zhangdacheng (Dacheng) = <zhangdacheng@huawei.com> = wrote:

Hi, very happy that you like the = comments. About comment D.  Your description about the sensitive = information is good. So, could you please in to the document when = updating it? ^_^
 
Cheers
 
Dacheng
 
From: Shida Schubert [mailto:shida@ntt-at.com] 
Sent: Wednesday, March 19, 2014 = 1:58 PM
To: Zhangdacheng = (Dacheng)
Cc: draft-vanelburg-dispatch-private-network-ind.all@tools.ietf.or= g
Subject: Re: secdir review of = draft-vanelburg-dispatch-private-network-ind-05
 
 
Dear = Dacheng; 
 
 
 
From: Zhangdacheng (Dacheng) 
Sent: Friday, March 14, 2014 6:32 = PM
To: secdir@ietf.org
Cc: iesg@ietf.org; 'draft-vanelburg-dispatch-private-network-ind.all@tools.ietf.org'
Subject: secdir review of = draft-vanelburg-dispatch-private-network-ind-05
 
 
I have reviewed this = document as part of the security directorate's ongoing effort to for = early review of WG drafts.  These comments were written primarily = for the benefit of the security area directors.  Document editors = and working group chairs should treat these comments just like any other = comments.
 
This document specifies a SIP = P-Private-Network-Indication P-header which is able to contain a domain = name to identify the organization that certain private network traffics = belong to and enable network nodes to process different traffics with = different sets of rules.
 
There are some comments in = the security considerations.
 
A: =93The private network = indication defined in this document MUST only be used in an environment = where elements are trusted and where attackers do not have access to the = protocol messages between those elements.=94
  
This sentence is not very accurate. In the = examples discussed in the document, the private traffics could be = transported over public networks, where they can be=93accessed=94 by attackers. In addition, there is no definition of =93trust=94 or =93trusted notes=94. I guess you are using the = terms specified in RFC3324. If so, please mention it in section 3. When = using the terms in RFC3324, I think this sentence could be changed to = =94The private network indication defined in this document MUST only be = used in an environment where elements are trusted and there are secure = connections between those elements.=94 Or even simpler, =93The private = network indication defined in this document MUST only be used in the = traffics transported between the elements which are mutually = trusted.=94
 
Many thanks for suggestion, I = will reflect the changes when updating the = draft. 


 
B: =93Traffic protection between network = elements can be achieved by using IPsec and sometimes by physical = protection of the network.=94 
 
Because we intend to provide = confidentiality protection for the contents of this header field, IPsec = AH may not be suitable here. So, maybe we can change this sentence = to =93Traffic protection between = network elements can be achieved by using the security protocols such as = IPsec ESP [RFC2406] or sometimes by physical protection of the = network.=94
 
Again, sounds great. Thanks for = the suggestion. 


 
C: =93A private network indication received = from an untrusted node MUST NOT be used and the information MUST be = removed from a request or response before it is forwarded to entities in = the trust domain.=94
 
There is a concern about = this sentence. If a device receives a message with a invalid indication, = should the device forwards it or just discards = it?
 
As you sated the concern is = valid, why should you receive the header from an untrusted node. It is = very likely an attempt to compromise the public or private = network.
 
We could change it to:
=93A private = network indication received from an untrusted node MUST NOT be used and = the information MUST be removed from a request or response before it is = forwarded to entities in the trust domain. Additionally local = policies may be in place that ensure that all requests entering the = trust domain for private network indication from untrusted nodes with a = private network indication will be = discarded.=94


 
D:  =93There is a security risk if a = private network indication is allowed to propagate out of the trust = domain where it was generated. In that case sensitive information would = be revealed by such a breach.=94
 
It would be good to clarify what kind = information is sensitive and what kind of risk will be caused by = disclosing such information. The domain name of an organization is = public, right? I know the leak of the domain name is undesired. But I = suggest making some discussions here.
 
 
The indication may reveal information about = the identity of the caller, i,e, the organisation that he belongs to. = That is sensitive information. It also reveals to the outside world that = there is a set of rules that this call is subject to that is different = then the rules that apply to public traffic. That is sensitive = information too.
 


E: =93There is no automatic = mechanism to learn the support for this = specification.=94
 
Maybe we can change this = sentence to =93However, how to learn such knowledge is out of = scope.=94
 
 Great! we will = :-)
 
 Many = Thanks! 
 
 Shida


 
Cheers
 
Dacheng

= --Apple-Mail=_6E2E00DA-1034-4D33-8640-D70772D957E1-- From nobody Wed Mar 19 19:10:30 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C171A043A for ; Wed, 19 Mar 2014 19:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0T2dES6kM-0 for ; Wed, 19 Mar 2014 19:10:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id E1C971A033D for ; Wed, 19 Mar 2014 19:10:21 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s2K2AAiN000678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 20 Mar 2014 04:10:10 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s2K2AASm012128; Thu, 20 Mar 2014 04:10:10 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21290.19970.388690.352606@fireball.kivinen.iki.fi> Date: Thu, 20 Mar 2014 04:10:10 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/AxR2xmyKmku8TlUv7ycXgBu3qn0 Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 02:10:27 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Dan Harkins is next in the rotation. For telechat 2014-03-27 Reviewer LC end Draft Alan DeKok T 2014-03-17 draft-ietf-appsawg-xml-mediatypes-09 Donald Eastlake T 2014-03-24 draft-ietf-netext-pmip6-qos-11 Steve Hanna TR2013-10-16 draft-ietf-manet-smf-mib-10 Scott Kelly TR2013-05-29 draft-ietf-cuss-sip-uui-14 Catherine Meadows TR2014-02-17 draft-ietf-dmm-requirements-15 Adam Montville T 2014-02-19 draft-ietf-storm-rdmap-ext-09 Yoav Nir TR2014-02-24 draft-ietf-eman-framework-16 Zach Shelby T 2013-08-30 draft-kaplan-insipid-session-id-04 Ondrej Sury T 2014-02-27 draft-ietf-ippm-testplan-rfc2680-04 Brian Weis T 2014-02-28 draft-ietf-ecrit-trustworthy-location-09 Tom Yu TR2014-01-17 draft-ietf-abfab-arch-12 For telechat 2014-04-03 Derek Atkins T 2014-03-12 draft-ietf-ipsecme-ikev2-fragmentation-06 Sandy Murphy T 2014-03-05 draft-melnikov-smime-msa-to-mda-04 For telechat 2014-04-10 Rob Austein T 2014-03-24 draft-ietf-cdni-framework-10 Last calls and special requests: Shawn Emery E 2014-03-27 draft-ietf-tcpm-fastopen-08 Dorothy Gellert 2014-04-01 draft-ietf-pcp-dhcp-09 Tobias Gondrom 2014-03-27 draft-ietf-pwe3-p2mp-pw-requirements-07 Phillip Hallam-Baker 2014-04-01 draft-ietf-trill-esadi-06 Steve Hanna 2014-03-28 draft-ietf-xrblock-rtcp-xr-loss-conceal-10 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-11 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-08 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Vincent Roca 2014-02-25 draft-ietf-sidr-policy-qualifiers-01 Carl Wallace 2014-03-14 draft-drage-sipping-rfc3455bis-13 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Wed Mar 19 23:32:09 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8691A04AA; Wed, 19 Mar 2014 23:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 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=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRg_J7tTS_IF; Wed, 19 Mar 2014 23:32:05 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC2A1A04A7; Wed, 19 Mar 2014 23:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13235; q=dns/txt; s=iport; t=1395297117; x=1396506717; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=91rF7iTzbe3SnqEytKXvl7hjaookA4DfAtQmp/hzHXo=; b=OQFymO5i1/tTBPivx+uvu/P5oiBUA/4dgTl7MPVCyZRPVeTt205e6F/3 asvLSslduPOa3UmFBGqyboluHk0X+2wUs4BFm9JKaktL6t8Y/RDyH+8vL farikCnGvmm+CnRW0/c+8dxjldaudq8iXNjoiIzfjcc1PPk76n5pmgRxQ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4FALSKKlOtJV2c/2dsb2JhbABagkJEO1fCToEbFnSCJQEBAQQtTBACAQgRBAEBCwsSByERFAkIAQEEDgUIh10DEch3DYclF4xNgUUCAQEeMQYBCoMagRQEhV6QfI5VhUiDLYFyOQ X-IronPort-AV: E=Sophos; i="4.97,692,1389744000"; d="scan'208,217"; a="28901678" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 20 Mar 2014 06:31:56 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2K6VulI032601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 06:31:56 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 20 Mar 2014 01:31:55 -0500 From: "Shaun Cooley (shcooley)" To: "Murray S. Kucherawy" Thread-Topic: secdir review of draft-ietf-appsawg-rrvs-header-field Thread-Index: Ac9BrCh2zAg7BhNeSsS1/SZjUWgivABWhUsAAD8+2bA= Date: Thu, 20 Mar 2014 06:31:55 +0000 Message-ID: <187A7B1DA239514F9146FC78B19AADE30B6CC737@xmb-aln-x10.cisco.com> References: <187A7B1DA239514F9146FC78B19AADE30B6CAE6A@xmb-aln-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.187.28] Content-Type: multipart/alternative; boundary="_000_187A7B1DA239514F9146FC78B19AADE30B6CC737xmbalnx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/HW05EbltMVhW5xyPHsEhZoNAcRA Cc: "draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-appsawg-rrvs-header-field X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 06:32:08 -0000 --_000_187A7B1DA239514F9146FC78B19AADE30B6CC737xmbalnx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable While RFC 3552 (=93Guidelines for Writing RFC Text on Security Consideratio= ns=94) does not specify whether or not Security Considerations should inclu= de normative language, both of the examples in section 6 (SMTP and VRRP) in= clude normative language: - 6.1.1.2 =96 two uses of SHOULD NOT - 6.1.1.3 =96 two uses of SHOULD - 6.1.1.7 =96 two uses of SHOULD - 6.2.1.1 =96 one use of SHOULD - 6.2.1.2 =96 one use of RECOMMENDED - 6.2.1.3 =96 two uses of RECOMMENDED I don=92t see why we wouldn=92t want to include normative language in the S= ecurity Considerations =96 especially SHOULD. The definition from BCP14/RF= C2119 of =93there may exist valid reasons in particular circumstances to ig= nore a particular item, but the full implications must be understood and ca= refully weighed before choosing a different course=94 seems like exactly wh= at the Security Considerations are getting at: =93the authors thought about= this, and suggest you do X, unless you have a specific reason and fully un= derstand the implications of not following the authors=92 suggestion=94. EKR =96 care to weigh in? MSK =96 Seeing that you are more or less in agreement with adding the norma= tive language, I=92ll split this discussion to a new thread if this goes mo= re than two (or so) replies on this thread. -Shaun From: Murray S. Kucherawy [mailto:superuser@gmail.com] Sent: Tuesday, March 18, 2014 12:01 PM To: Shaun Cooley (shcooley) Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-appsawg-rrvs-header-field.al= l@tools.ietf.org Subject: Re: secdir review of draft-ietf-appsawg-rrvs-header-field Barry, what's your take on these? I'm still under the impression that Secur= ity Considerations shouldn't include normative language, but the opinions o= n this seem to vary from one person and one week to the next. Otherwise, they appear reasonable to me. -MSK On Mon, Mar 17, 2014 at 12:03 AM, Shaun Cooley (shcooley) > wrote: I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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. This document defines an extension for SMTP called RRVS, along with a new M= AIL header field called Require-Recipient-Valid-Since, that allows senders = to indicate to receivers the last date when the sender confirmed the owners= hip of the target mailbox with the intended recipient, with a goal of preve= nting sensitive mail from being delivered to the wrong party if the ownersh= ip of a mailbox has changed. The document is easy to understand and covers several information disclosur= e issues that might arise from abuse of the RRVS extension or matching head= er. I consider this document to be ready for publication with two small ni= ts: - The suggested abuse countermeasures described in 14.1 should be reworded= to indicate that operators SHOULD (or are RECOMMENDED to) implement counte= rmeasures against RRVS probing. - The suggested use restrictions described in 14.2 should be reworded to i= ndicate that operators SHOULD (or are RECOMMENDED to) accept any RRVS datet= ime as valid for accounts that have only had a single owner, even if the RR= VS datetime predates the creation of the target account. -Shaun --_000_187A7B1DA239514F9146FC78B19AADE30B6CC737xmbalnx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

While RFC 3552 (=93Guidelines for Writing RFC Text on Security Considera= tions=94) does not specify whether or not Security Considerations should include normative language, both of the examples in section 6 (SMTP= and VRRP) include normative language:

 <= /p>

- 6.1.1.2 =96 two uses of= SHOULD NOT

- 6.1.1.3 =96 two uses of= SHOULD

- 6.1.1.7 =96 two uses of= SHOULD

- 6.2.1.1 =96 one use of = SHOULD

- 6.2.1.2 =96 one use of = RECOMMENDED

- 6.2.1.3 =96 two uses of= RECOMMENDED

 <= /p>

I don=92t see why we woul= dn=92t want to include normative language in the Security Considerations = =96 especially SHOULD.  The definition from BCP14/RFC2119 of =93the= re may exist valid reasons in particular circumstances to ignore a particular= item, but the full implications must be understood and carefully weighed b= efore choosing a different course=94 seems like exactly what the Securi= ty Considerations are getting at: =93the authors thought about this, and suggest you do X, unless you have a= specific reason and fully understand the implications of not following the= authors=92 suggestion=94.

 <= /p>

EKR =96 care to weigh in?=

 <= /p>

MSK =96 Seeing that you a= re more or less in agreement with adding the normative language, I=92ll spl= it this discussion to a new thread if this goes more than  two (or so) replies on this thread.

 <= /p>

-Shaun<= /p>

 <= /p>

From: Murray= S. Kucherawy [mailto:superuser@gmail.com]
Sent: Tuesday, March 18, 2014 12:01 PM
To: Shaun Cooley (shcooley)
Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-appsawg-rrvs-header-f= ield.all@tools.ietf.org
Subject: Re: secdir review of draft-ietf-appsawg-rrvs-header-field

 

Barry, what's your ta= ke on these? I'm still under the impression that Security Considerations sh= ouldn't include normative language, but the opinions on this seem to vary f= rom one person and one week to the next.

Otherwise, they appear reasonable to me.

-MSK

 

On Mon, Mar 17, 2014 at 12:03 AM, Shaun Cooley (shco= oley) <shcooley@= cisco.com> wrote:

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

This document defines an extension for SMTP called RRVS, along with a new M= AIL header field called Require-Recipient-Valid-Since, that allows senders = to indicate to receivers the last date when the sender confirmed the owners= hip of the target mailbox with the intended recipient, with a goal of preventing sensitive mail from being de= livered to the wrong party if the ownership of a mailbox has changed.

The document is easy to understand and covers several information disclosur= e issues that might arise from abuse of the RRVS extension or matching head= er.  I consider this document to be ready for publication with two sma= ll nits:

 - The suggested abuse countermeasures described in 14.1 should be rew= orded to indicate that operators SHOULD (or are RECOMMENDED to) implement c= ountermeasures against RRVS probing.

 - The suggested use restrictions described in 14.2 should be reworded= to indicate that operators SHOULD (or are RECOMMENDED to) accept any RRVS = datetime as valid for accounts that have only had a single owner, even if t= he RRVS datetime predates the creation of the target account.

-Shaun

 

--_000_187A7B1DA239514F9146FC78B19AADE30B6CC737xmbalnx10ciscoc_-- From nobody Thu Mar 20 01:36:59 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E671A07C9; Thu, 20 Mar 2014 01:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eb_Hmw4jXeFq; Thu, 20 Mar 2014 01:36:52 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DE2D81A0654; Thu, 20 Mar 2014 01:36:51 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so603074pdi.5 for ; Thu, 20 Mar 2014 01:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WIu74Gm2jsspMJsJGvqkManN7Mb9aeLdnQR2nnzJmfE=; b=wBih1gp+lg+yVJ0udBnKc4XWdRqJa3OIG1vXHOE5ayTUCoBLI9hjWJJlIcF1loy/fq oBuGK3fvMLLy0/Yvw86tR50aW2KM9+AWjAqZb9TkkaT68MsTxHG7lYn7kqtDH3Avz570 IbbdZcVkUJROkuPuQtaRwY0a91updPelPpF9M/JiqOMgZFvO3rU+nvhiz7jzS7e5e2oM tSuvh+bViAzPw7N8NvHAnzGy9+1UzPVQp9HZaXVvEfTy4o3xK4IaEQ7tBDhq5jB8kch+ f6nqaLRGKvPoxPanout+fpgrpYuLiXxgpR1Ex4/0Cegzuo6cuhYmxPyn611cZseyTP/w andw== MIME-Version: 1.0 X-Received: by 10.68.196.202 with SMTP id io10mr23196420pbc.149.1395304603096; Thu, 20 Mar 2014 01:36:43 -0700 (PDT) Received: by 10.66.220.102 with HTTP; Thu, 20 Mar 2014 01:36:42 -0700 (PDT) In-Reply-To: <187A7B1DA239514F9146FC78B19AADE30B6CC737@xmb-aln-x10.cisco.com> References: <187A7B1DA239514F9146FC78B19AADE30B6CAE6A@xmb-aln-x10.cisco.com> <187A7B1DA239514F9146FC78B19AADE30B6CC737@xmb-aln-x10.cisco.com> Date: Thu, 20 Mar 2014 01:36:42 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Shaun Cooley (shcooley)" Content-Type: multipart/alternative; boundary=e89a8fb208a6389b4204f505ab6a Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/n0Z_tdZnEXaIMcV0fbel0VD2uJ8 Cc: "draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-appsawg-rrvs-header-field X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 08:36:54 -0000 --e89a8fb208a6389b4204f505ab6a Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 19, 2014 at 11:31 PM, Shaun Cooley (shcooley) < shcooley@cisco.com> wrote: > While RFC 3552 ("Guidelines for Writing RFC Text on Security > Considerations") does not specify whether or not Security Considerations > should include normative language, both of the examples in section 6 (SMTP > and VRRP) include normative language: > > > > - 6.1.1.2 - two uses of SHOULD NOT > > - 6.1.1.3 - two uses of SHOULD > > - 6.1.1.7 - two uses of SHOULD > > - 6.2.1.1 - one use of SHOULD > > - 6.2.1.2 - one use of RECOMMENDED > > - 6.2.1.3 - two uses of RECOMMENDED > > > > I don't see why we wouldn't want to include normative language in the > Security Considerations - especially SHOULD. The definition from > BCP14/RFC2119 of "*there may exist valid reasons in particular > circumstances to ignore a particular item, but the full implications must > be understood and carefully weighed before choosing a different course*" > seems like exactly what the Security Considerations are getting at: "the > authors thought about this, and suggest you do X, unless you have a > specific reason and fully understand the implications of not following the > authors' suggestion". > > > I can't recall the exact reason why it's been said that RFC2119 language ought not be used in Security Considerations (or similar) prose, or which document's development cycle brought it up, but my general recollection is that those words were intended to convey aspects of interoperability having to do with protocol elements, and not otherwise. It would appear this opinion has formed since RFC3552 was published, since obviously there's a conflict between them. But like I said, it does seem to vary depending on who and when one is asking. Could also be the person(s) who told me this are actually plain wrong. I'm happy to take direction from the sponsoring AD on this one. -MSK --e89a8fb208a6389b4204f505ab6a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 19, 2014 at 11:31 PM, Shaun Cooley (shcooley) = <shcooley@cisco.com> wrote:
<= div class=3D"gmail_quote">

While RFC 3552 (“Guidelines for Writing RFC Text = on Security Considerations”) does not specify whether or not Security= Considerations should include normative language, both of the examples in section 6 (SMTP= and VRRP) include normative language:

 

- 6.1.1.2 – two use= s of SHOULD NOT

- 6.1.1.3 – two use= s of SHOULD

- 6.1.1.7 – two use= s of SHOULD

- 6.2.1.1 – one use= of SHOULD

- 6.2.1.2 – one use= of RECOMMENDED

- 6.2.1.3 – two use= s of RECOMMENDED

 

I don’t see why we = wouldn’t want to include normative language in the Security Considera= tions – especially SHOULD.  The definition from BCP14/RFC2119 of= “there may exist valid reasons in particular circumstances to ignore a particular= item, but the full implications must be understood and carefully weighed b= efore choosing a different course” seems like exactly what the Se= curity Considerations are getting at: “the authors thought about this, and suggest you do X, unless you ha= ve a specific reason and fully understand the implications of not following= the authors’ suggestion”.



I can't recall the exact reason why = it's been said that RFC2119 language ought not be used in Security Cons= iderations (or similar) prose, or which document's development cycle br= ought it up, but my general recollection is that those words were intended = to convey aspects of interoperability having to do with protocol elements, = and not otherwise.  It would appear this opinion has formed since RFC3= 552 was published, since obviously there's a conflict between them.&nbs= p; But like I said, it does seem to vary depending on who and when one is a= sking.  Could also be the person(s) who told me this are actually plai= n wrong. 

I'm happy to take direction from the sponsoring AD on this one.
=
-MSK

--e89a8fb208a6389b4204f505ab6a-- From nobody Thu Mar 20 03:59:12 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0681A06C3; Thu, 20 Mar 2014 03:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ppqZnebJVhT; Thu, 20 Mar 2014 03:59:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 992EF1A08B5; Thu, 20 Mar 2014 03:59:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6EA8EBE51; Thu, 20 Mar 2014 10:58:55 +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 Ag9Sk4quK3lc; Thu, 20 Mar 2014 10:58:54 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.46.29.72]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 18BA1BE4D; Thu, 20 Mar 2014 10:58:54 +0000 (GMT) Message-ID: <532AC9ED.80108@cs.tcd.ie> Date: Thu, 20 Mar 2014 10:58:53 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , "Shaun Cooley (shcooley)" References: <187A7B1DA239514F9146FC78B19AADE30B6CAE6A@xmb-aln-x10.cisco.com> <187A7B1DA239514F9146FC78B19AADE30B6CC737@xmb-aln-x10.cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/xUM4CyGD_1PNJDd-ts7jER29xJs Cc: "draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-appsawg-rrvs-header-field X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 10:59:08 -0000 On 03/20/2014 08:36 AM, Murray S. Kucherawy wrote: > I can't recall the exact reason why it's been said that RFC2119 language > ought not be used in Security Considerations (or similar) prose, or which > document's development cycle brought it up, but my general recollection is > that those words were intended to convey aspects of interoperability having > to do with protocol elements, and not otherwise. It would appear this > opinion has formed since RFC3552 was published, since obviously there's a > conflict between them. But like I said, it does seem to vary depending on > who and when one is asking. Could also be the person(s) who told me this > are actually plain wrong. > > I'm happy to take direction from the sponsoring AD on this one. I'm sure you'll get that. FWIW, from my POV there should be no magical interactions between RFC section headings and RFC 2119. You should do what makes sense and is more clear for the reader. That can and often does include using e.g. a 2119 MUST in the security considerations section. In other words, I figure the folklore you describe above ought be ignored and/or corrected. I do not believe that's written down anywhere in an RFC or IESG statement, if you find it is, please let me know and I'll try get it fixed. S. From nobody Thu Mar 20 04:05:10 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C701A08C5; Thu, 20 Mar 2014 04:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKTj--dECAZE; Thu, 20 Mar 2014 04:05:04 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFFF1A08BE; Thu, 20 Mar 2014 04:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1395313492; d=isode.com; s=selector; i=@isode.com; bh=bEGSu7rqBuC56EU6AUm1Q2Qej2NXXZ4Cq+9DJnQlPiY=; 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=xJz9DXdY8ALrBGBs4PxE2/TAOgXFbPAxkARvlKp7q8Isn8ZkCA/tPUbHUShUVc7Jz+qog3 3RCnGm29m9FA1MXf04em6UpP9aMveXdRlGRHHetWkrPBQrmmANXcFCFEDd+ekKpnBDT2tK 47AW41VKWHCcGtZzYorrDsoBqMlxZhM=; Received: from [192.168.0.7] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 20 Mar 2014 11:04:52 +0000 Message-ID: <532ACB96.1090806@isode.com> Date: Thu, 20 Mar 2014 11:05:58 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 To: Stephen Farrell , "Murray S. Kucherawy" , "Shaun Cooley (shcooley)" References: <187A7B1DA239514F9146FC78B19AADE30B6CAE6A@xmb-aln-x10.cisco.com> <187A7B1DA239514F9146FC78B19AADE30B6CC737@xmb-aln-x10.cisco.com> <532AC9ED.80108@cs.tcd.ie> In-Reply-To: <532AC9ED.80108@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/PALqVTXuNun0g8kyEh7_OGXPh0o Cc: "draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-appsawg-rrvs-header-field X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 11:05:08 -0000 On 20/03/2014 10:58, Stephen Farrell wrote: > On 03/20/2014 08:36 AM, Murray S. Kucherawy wrote: >> I can't recall the exact reason why it's been said that RFC2119 language >> ought not be used in Security Considerations (or similar) prose, or which >> document's development cycle brought it up, but my general recollection is >> that those words were intended to convey aspects of interoperability having >> to do with protocol elements, and not otherwise. It would appear this >> opinion has formed since RFC3552 was published, since obviously there's a >> conflict between them. But like I said, it does seem to vary depending on >> who and when one is asking. Could also be the person(s) who told me this >> are actually plain wrong. >> >> I'm happy to take direction from the sponsoring AD on this one. > I'm sure you'll get that. > > FWIW, from my POV there should be no magical interactions between > RFC section headings and RFC 2119. You should do what makes sense > and is more clear for the reader. That can and often does include > using e.g. a 2119 MUST in the security considerations section. > > In other words, I figure the folklore you describe above ought be > ignored and/or corrected. Agreed. > I do not believe that's written down > anywhere in an RFC or IESG statement, I don't think so either. I think the main argument against RFC 2119 language in Security Considerations sections is that people are not going to read them while implementing specs (and they might only read them later when considering security aspects). But I think this is nonsense. > if you find it is, please let me know and I'll try get it fixed. From nobody Thu Mar 20 07:53:10 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B0E1A0747; Thu, 20 Mar 2014 07:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me52zLE-eN-H; Thu, 20 Mar 2014 07:53:02 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id D03A71A046A; Thu, 20 Mar 2014 07:53:01 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so2890084qgd.9 for ; Thu, 20 Mar 2014 07:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AxOLkFsZ0EKrDr7y6OCj6d4HoFQCRaWylemD2pldIbI=; b=HVHk3pDasI31dt5Ozc8HvhBUKGn2byMdxjagWy841HRmd02SDCMNSqcGNKkgbASid2 osRMvCNzvBELFy/L2iKUzXihvxJMPmtoWXnDhlpaReBfMAH0a89e6oCk+4EFOvfLGAhV Bdt0lKWVA3pQBZd7uKlLIQlwSSGMQVaUKltcySDGQgb0JUv/6rxgAMe2kain6E/j+/Ui MlPoQHTJzcaRlT4I+p5+A26Exalbzgg2XHYAYwWfGShcVbWY/hNSg15C+eUk9TiZ9rqE 02uiRTCq3Va8T9b/nsGa8rkfue+nSCoknEr5p6qqLT0owXRYOZLqOlXkaXn/CWc6rsFb wN4w== MIME-Version: 1.0 X-Received: by 10.140.84.39 with SMTP id k36mr2217576qgd.51.1395327172554; Thu, 20 Mar 2014 07:52:52 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.42.136 with HTTP; Thu, 20 Mar 2014 07:52:52 -0700 (PDT) In-Reply-To: References: <187A7B1DA239514F9146FC78B19AADE30B6CAE6A@xmb-aln-x10.cisco.com> <187A7B1DA239514F9146FC78B19AADE30B6CC737@xmb-aln-x10.cisco.com> Date: Thu, 20 Mar 2014 10:52:52 -0400 X-Google-Sender-Auth: AiX5y1zFo-_nefIoIFI237IYv10 Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/nPVdnfFB6X_ojWwpSeM3FK10-xA Cc: "draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-appsawg-rrvs-header-field X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 14:53:04 -0000 >> While RFC 3552 ("Guidelines for Writing RFC Text on Security >> Considerations") does not specify whether or not Security Considerations >> should include normative language, both of the examples in section 6 (SMTP >> and VRRP) include normative language: First, let's please separate "2119 key words" from "normative language", and be sure we don't fall under the mistaken impression that language isn't normative unless it's in all caps. If a Security considerations section says, "Farble attack is possible if you don't wiffle, so it's essential that servers wiffle," that's a normative requirement for servers to wiffle, whether or not the magic word "please" "MUST" is used. Now... > I can't recall the exact reason why it's been said that RFC2119 language > ought not be used in Security Considerations (or similar) prose, or which > document's development cycle brought it up, but my general recollection is > that those words were intended to convey aspects of interoperability having > to do with protocol elements, and not otherwise. That's the silliest thing I've ever heard.[1] May I disabuse y'all of that idea forthwith? Yes? Good. Thank you. The document tells us how to implement the protocol. The whole document does, from the tippy-top of the Introduction head to the soles of the References feet. Normative stuff can appear anywhere, and if it makes sense to put some in the Security Considerations section, then that's where we should put it. Now, I *would* have an issue with the organization of the document if protocol elements were defined only in the Security Considerations, and there might be times when security aspects should be normatively specified where the protocol elements were defined, and only highlighted in the Security Considerations, or whatnot. But that's a question of organization of a particular document. This document is well organized, and I have no issues with that. So if you (for whatever value of "you", which here seems like Shaun, with Murray in basic agreement) think that the normative language in the Security Considerations is not sufficiently clear or strong, and would benefit from some 2119 key words, make it so. Do it with care and thought, but don't have any silly ideas that 2119 key words don't belong in security considerations sections. They belong where they are needed, and not where they aren't. > I'm happy to take direction from the sponsoring AD on this one. So let it be written; so let it be done. Barry [1] Actually, not really: I've heard some pretty damnfool things in my life, some far sillier than any of us can imagine. But a little hyperbole never hurt an argument. From nobody Thu Mar 20 10:39:56 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB3A1A0912; Thu, 20 Mar 2014 10:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiFRAfaL9cRL; Thu, 20 Mar 2014 10:39:48 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8D81A0743; Thu, 20 Mar 2014 10:39:48 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id w10so1234475pde.10 for ; Thu, 20 Mar 2014 10:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v24+VobgA3OnnBqz9SPgW5aOfNY1/7Ldu/lVFm4xBc4=; b=Nx0whxOkDsSLsNTtoP7nezDIgH8c+COU3myIUpcLsxcbqj7efVjjqvl4aVUrectv+o TKv6UaF3gz7PWNdcDrEnJYT58bmUQyUQuUJhG1HRpw2poUqfT8dnVI6eH2heb9oBfcsa zzEdvNAxx1pnqTJYhBdMHup3FudZRczP7WttdDuRwKw1B2fp8WkmLXQWMG8E/6e6Ardq ueUHET1uWw5t9WOUfVq1Bs1RJWCBuk4skwPA56Io1DtXC4KgKWLArc+gKf0qpsaDGHuG BFNvVXiOxQPElnRqrk3hv+6NUT55kL4QDSEdvzZ9Wyh35Ljpx3hauPVBZgqUmlNmeaaa 5gFQ== MIME-Version: 1.0 X-Received: by 10.68.196.202 with SMTP id io10mr26439093pbc.149.1395337179225; Thu, 20 Mar 2014 10:39:39 -0700 (PDT) Received: by 10.66.220.102 with HTTP; Thu, 20 Mar 2014 10:39:39 -0700 (PDT) In-Reply-To: References: <187A7B1DA239514F9146FC78B19AADE30B6CAE6A@xmb-aln-x10.cisco.com> <187A7B1DA239514F9146FC78B19AADE30B6CC737@xmb-aln-x10.cisco.com> Date: Thu, 20 Mar 2014 10:39:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=e89a8fb208a6e8e34c04f50d40dc Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/-633fETygopC338MqqwglITHnts Cc: "draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-appsawg-rrvs-header-field X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 17:39:50 -0000 --e89a8fb208a6e8e34c04f50d40dc Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 20, 2014 at 7:52 AM, Barry Leiba wrote: > > > I can't recall the exact reason why it's been said that RFC2119 language > > ought not be used in Security Considerations (or similar) prose, or which > > document's development cycle brought it up, but my general recollection > is > > that those words were intended to convey aspects of interoperability > having > > to do with protocol elements, and not otherwise. > > That's the silliest thing I've ever heard.[1] > > May I disabuse y'all of that idea forthwith? Yes? Good. Thank you. > [...] > Given that Shaun's original comment identified these as nits: "What mighty contests arise from trivial things." I've made his changes in the next version, which I'll post after the telechat unless you want them sooner. The only other pending change is a language tweak in IANA Considerations that came up during their review of that section. -MSK --e89a8fb208a6e8e34c04f50d40dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 20, 2014 at 7:52 AM, Barry Leiba <barry= leiba@computer.org> wrote:

> I can't recall the exact reason why it's been said that RFC211= 9 language
> ought not be used in Security Considerations (or similar) prose, or wh= ich
> document's development cycle brought it up, but my general recolle= ction is
> that those words were intended to convey aspects of interoperability h= aving
> to do with protocol elements, and not otherwise.

That's the silliest thing I've ever heard.[1]

May I disabuse y'all of that idea forthwith? =A0Yes? =A0Good. =A0Thank = you.
[...]

Given that Shaun's original c= omment identified these as nits: "What mighty contests arise from triv= ial things."

I've made his changes in the next version, whi= ch I'll post after the telechat unless you want them sooner.=A0 The onl= y other pending change is a language tweak in IANA Considerations that came= up during their review of that section.

-MSK
--e89a8fb208a6e8e34c04f50d40dc-- From nobody Thu Mar 20 12:23:22 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DDE1A0410; Thu, 20 Mar 2014 12:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPyNdmW3Nat3; Thu, 20 Mar 2014 12:23:19 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9899C1A034F; Thu, 20 Mar 2014 12:23:19 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id m5so1382375qaj.39 for ; Thu, 20 Mar 2014 12:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ly0t2Vk8qPp5nAvbF8nHE1Us6tzllmiA5mtbafgW4dM=; b=dZtFQea43bNjR5LGThTv14f8cztXIGtYAuRsIDXhIs6idorcMajgm8G7z5bcki2e3s f8HBlmAekYByiC7bevS4T+3fMbTYOTcGalTBjDkgqqu123b9tNCD7cleUAya/2kiSCOZ LQxD+Whl+poTrtgDeM72YwAv3MqFPe9cofGD8QzTqaTKWZVtQrlN5YKYk9juSixW2egr wLKSjo1rCM9pXaDygq7cJ74L4TTyYTD//Gv+uZOXPDN+0AZ72Hfp1hfaV2kNmq4kVOdM Q78N8C/YkoEspHsl2EM06jBUub1va3My0JlJiM0AnyliCS/8m3/MLA4hV3Xpc9Wkzd/a Ruww== MIME-Version: 1.0 X-Received: by 10.224.157.7 with SMTP id z7mr52974695qaw.37.1395343390400; Thu, 20 Mar 2014 12:23:10 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.42.136 with HTTP; Thu, 20 Mar 2014 12:23:10 -0700 (PDT) In-Reply-To: References: <187A7B1DA239514F9146FC78B19AADE30B6CAE6A@xmb-aln-x10.cisco.com> <187A7B1DA239514F9146FC78B19AADE30B6CC737@xmb-aln-x10.cisco.com> Date: Thu, 20 Mar 2014 15:23:10 -0400 X-Google-Sender-Auth: gZL6kGrYJV5yAvA4R0sfBtBjohk Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=089e0160a3d01fe75304f50eb359 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/m-6QXVyJFe3rZURsXFNqdevFuos Cc: "draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-appsawg-rrvs-header-field X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 19:23:21 -0000 --089e0160a3d01fe75304f50eb359 Content-Type: text/plain; charset=ISO-8859-1 Go aheand and post now, so the IESG is reviewing the very latest version. T'anks. b On Thursday, March 20, 2014, Murray S. Kucherawy wrote: > On Thu, Mar 20, 2014 at 7:52 AM, Barry Leiba > > wrote: > >> >> > I can't recall the exact reason why it's been said that RFC2119 language >> > ought not be used in Security Considerations (or similar) prose, or >> which >> > document's development cycle brought it up, but my general recollection >> is >> > that those words were intended to convey aspects of interoperability >> having >> > to do with protocol elements, and not otherwise. >> >> That's the silliest thing I've ever heard.[1] >> >> May I disabuse y'all of that idea forthwith? Yes? Good. Thank you. >> > [...] >> > > Given that Shaun's original comment identified these as nits: "What mighty > contests arise from trivial things." > > I've made his changes in the next version, which I'll post after the > telechat unless you want them sooner. The only other pending change is a > language tweak in IANA Considerations that came up during their review of > that section. > > -MSK > --089e0160a3d01fe75304f50eb359 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Go aheand and post now, so the IESG is reviewing the very latest version. = =A0T'anks.

b

On Thursday, March 20, 2014, Mur= ray S. Kucherawy <superuser@gmail= .com> wrote:
On Thu, Mar 20, 2014 at 7:5= 2 AM, Barry Leiba <barrylei= ba@computer.org> wrote:

> I can't recall the exact reason why it's been said that RFC211= 9 language
> ought not be used in Security Considerations (or similar) prose, or wh= ich
> document's development cycle brought it up, but my general recolle= ction is
> that those words were intended to convey aspects of interoperability h= aving
> to do with protocol elements, and not otherwise.

That's the silliest thing I've ever heard.[1]

May I disabuse y'all of that idea forthwith? =A0Yes? =A0Good. =A0Thank = you.
[...]

Given that Shaun's original c= omment identified these as nits: "What mighty contests arise from triv= ial things."

I've made his changes in the next version, whi= ch I'll post after the telechat unless you want them sooner.=A0 The onl= y other pending change is a language tweak in IANA Considerations that came= up during their review of that section.

-MSK
--089e0160a3d01fe75304f50eb359-- From nobody Thu Mar 20 12:29:10 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DEC1A077C; Thu, 20 Mar 2014 12:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkDVU7r4SF5l; Thu, 20 Mar 2014 12:29:08 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3FA1A0894; Thu, 20 Mar 2014 12:29:08 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id kp14so1385077pab.33 for ; Thu, 20 Mar 2014 12:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z//zhonvrP1dwciXgfV12JvGDh0TWYnDjDmOkPJFeNg=; b=ZTG+aJYK8EK7rrKkqsSwHKime7AXqDPze/7R5vsGyetuKMlxJn47Bs2so/m11wKc9W XmpykkrOYpGr5o12O2Z9CoCwDXFVVdIv4KjU7MPMdZGCwUS6swshjLL+FXZkqEVxIJJa EVoiAUyydcblKt3QR8UPbhevrGm75nnSPHeTuKmTSPS84J5M14ixnpuGsc/rW3Qa77Gy tIoWyuOyGUQ4FZHA4qSs79xM2fbS7Yi15fxHTEd4l5ELx7ORuiiZOUdx7My3eAuVHIYA 4wLDTgEcCkBiaAWL+TiolOjukrmS6BwaHDVTTAGmqssqzaJyYO5C7ExcKAUPwUifN9VU rZIg== MIME-Version: 1.0 X-Received: by 10.66.118.71 with SMTP id kk7mr48545115pab.14.1395343739598; Thu, 20 Mar 2014 12:28:59 -0700 (PDT) Received: by 10.66.220.102 with HTTP; Thu, 20 Mar 2014 12:28:59 -0700 (PDT) In-Reply-To: References: <187A7B1DA239514F9146FC78B19AADE30B6CAE6A@xmb-aln-x10.cisco.com> <187A7B1DA239514F9146FC78B19AADE30B6CC737@xmb-aln-x10.cisco.com> Date: Thu, 20 Mar 2014 12:28:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=e89a8ffbad05f03caa04f50ec7f6 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/6hKHZy5igdlE5t-LKwSD2UWDyKk Cc: "draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-appsawg-rrvs-header-field X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 19:29:10 -0000 --e89a8ffbad05f03caa04f50ec7f6 Content-Type: text/plain; charset=ISO-8859-1 Done. On Thu, Mar 20, 2014 at 12:23 PM, Barry Leiba wrote: > Go aheand and post now, so the IESG is reviewing the very latest version. > T'anks. > > b > > > On Thursday, March 20, 2014, Murray S. Kucherawy > wrote: > >> On Thu, Mar 20, 2014 at 7:52 AM, Barry Leiba wrote: >> >>> >>> > I can't recall the exact reason why it's been said that RFC2119 >>> language >>> > ought not be used in Security Considerations (or similar) prose, or >>> which >>> > document's development cycle brought it up, but my general >>> recollection is >>> > that those words were intended to convey aspects of interoperability >>> having >>> > to do with protocol elements, and not otherwise. >>> >>> That's the silliest thing I've ever heard.[1] >>> >>> May I disabuse y'all of that idea forthwith? Yes? Good. Thank you. >>> >> [...] >>> >> >> Given that Shaun's original comment identified these as nits: "What >> mighty contests arise from trivial things." >> >> I've made his changes in the next version, which I'll post after the >> telechat unless you want them sooner. The only other pending change is a >> language tweak in IANA Considerations that came up during their review of >> that section. >> >> -MSK >> > --e89a8ffbad05f03caa04f50ec7f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Done.


On Thu, Mar 20, 2014 at 12:23 PM, Barry Leiba <b= arryleiba@computer.org> wrote:
Go aheand and post now, so the IESG is revie= wing the very latest version. =A0T'anks.

b


On Thursday, March 20, 2014,= Murray S. Kucherawy <superuser@gmail.com> wrote:
On Thu, Mar 20, 2014 at 7:5= 2 AM, Barry Leiba <barryleiba@computer.org><= /span> wrote:

> I can't recall the exact reason why it's been said that RFC211= 9 language
> ought not be used in Security Considerations (or similar) prose, or wh= ich
> document's development cycle brought it up, but my general recolle= ction is
> that those words were intended to convey aspects of interoperability h= aving
> to do with protocol elements, and not otherwise.

That's the silliest thing I've ever heard.[1]

May I disabuse y'all of that idea forthwith? =A0Yes? =A0Good. =A0Thank = you.
[...]

Given that Shaun's original c= omment identified these as nits: "What mighty contests arise from triv= ial things."

I've made his changes in the next version, whi= ch I'll post after the telechat unless you want them sooner.=A0 The onl= y other pending change is a language tweak in IANA Considerations that came= up during their review of that section.

-MSK

--e89a8ffbad05f03caa04f50ec7f6-- From nobody Thu Mar 20 15:58:20 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215971A0930; Thu, 20 Mar 2014 15:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-8TEYA98XwL; Thu, 20 Mar 2014 15:58:14 -0700 (PDT) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 84CFA1A0920; Thu, 20 Mar 2014 15:58:13 -0700 (PDT) Received: by mail-bk0-f45.google.com with SMTP id na10so119171bkb.32 for ; Thu, 20 Mar 2014 15:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=jeaOCeUwzKJjTSdvFrsVYMZa2IhKbr05893N5xV7PRw=; b=0Y58dcJ4v2wyzVTmL+VlsXrEcDqVAbtwt4KNtXPHPzAIhRFWdx6vgFTVJmN0DgtKOC O0IjLsLY9pyk2R6KsXleImoyUP1bOhO39Ci3fw2QmFMhlFLzOAb4r9OJ62/0yCY+Pkto G6MDVM6NXtTEUOSn+cwg/wNDjaDzs6va64ByqMRYc2D1QnDHCEMbGudSMa37MrL0OsH6 erWTK6eusOH/QxyYlRltWKQJw574f8+RDZB/OT0S7JeRsagXAqqEwFIkviCFt1Pjb4NE HsZvNDAEoK/V3kYtO9cS2uc3+OwpK22FP9kfTy+N4CRArbhCw8AiJ3j8Hrt3FBg8Tcge +pfg== X-Received: by 10.204.81.14 with SMTP id v14mr24662970bkk.3.1395356283871; Thu, 20 Mar 2014 15:58:03 -0700 (PDT) Received: from [192.168.2.104] (p5DC1549E.dip0.t-ipconnect.de. [93.193.84.158]) by mx.google.com with ESMTPSA id c15sm3417762bky.13.2014.03.20.15.58.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Mar 2014 15:58:03 -0700 (PDT) Message-ID: <532B727A.9060500@gmail.com> Date: Thu, 20 Mar 2014 23:58:02 +0100 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0 MIME-Version: 1.0 To: "Klaas Wierenga (kwiereng)" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-jcardcal-jcal.all@tools.ietf.org" References: <894C08E3-0017-4830-9C8F-930CCEB5B2E2@cisco.com> In-Reply-To: <894C08E3-0017-4830-9C8F-930CCEB5B2E2@cisco.com> Content-Type: multipart/alternative; boundary="------------000000020609080709090205" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/p7cPdKY4ElMQ9OH5ulMmXvww6q0 Subject: Re: [secdir] secdir review of draft-ietf-jcardcal-jcal-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 22:58:16 -0000 This is a multi-part message in MIME format. --------------000000020609080709090205 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Klaas, thank you for your corrections. Here is my feedback: > - Paragraph 3 (converting from iCal to jCal): > > The text looks very much like production rules, why not give ABNF? (Ah wait, now that I have read the full document I see that that appears in Appendix B, I think you should at least point to Appendix B here) The ABNF is considered informative, I was told for jCard that not too much weight should be put into it. Nevertheless, I am happy to mention it if you like. How is this for the introduction to section 3? OLD This section describes how iCalendar data is converted to jCal using a simple mapping between the iCalendar data model and JSON elements. NEW This section describes how iCalendar data is converted to jCal using a simple mapping between the iCalendar data model and JSON elements. Aside from the formal description in this section, an informative ABNF is specified in Appendix B. END > - Paragraph 3.4 and onwards > > It is unclear to me when you write for example "Each individual iCalendar property is represented in jCal by …" whether you really mean to write: "Each individual iCalendar property MUST be represented in jCal by…." > I assume you want to be normative in specifying the format? Thanks, I've changed it (almost) as you suggested. OLD Each individual iCalendar property is represented in jCal by an array with three fixed elements, followed by one or more additional elements, depending on if the property is a multi-value property as described in Section 3.1.2 of [RFC5545]. NEW In jCal, each individual iCalendar property MUST be represented by an array with three fixed elements, followed by one or more additional elements, depending on if the property is a multi-value property as described in Section 3.1.2 of [RFC5545]. END > - Paragraph 9.2 should RFC4627 not be a normative rather than informative reference? Yes, indeed. I've changed this and also updated references to rfc7159. While doing this I noticed that we referenced a regex that was in rfc4627 but no longer in rfc7159. I've made some changes: OLD With this in mind, a parser for JSON data should be used for jCal that is aware of the security implications. For example, the use of JavaScript's eval() function is only allowed using the regular expression in Section 6 of [RFC4627]. A native parser with full awareness of the JSON format should be preferred. NEW With this in mind, a parser for JSON data should be used for jCal that is aware of the security implications. For example, the use of JavaScript's eval() function is considered an unacceptable security risk, as described in [RFC7159], Section 12. A native parser with full awareness of the JSON format should be preferred. END Regards, Philipp --------------000000020609080709090205 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Klaas,

thank you for your corrections. Here is my feedback:
- Paragraph 3 (converting from iCal to jCal):

The  text looks very much like production rules, why not give ABNF? (Ah wait, now that I have read the full document I see that that appears in Appendix B, I think you should at least point to Appendix B here)
The ABNF is considered informative, I was told for jCard that not too much weight should be put into it. Nevertheless, I am happy to mention it if you like. How is this for the introduction to section 3?

OLD
   This section describes how iCalendar data is converted to jCal using
   a simple mapping between the iCalendar data model and JSON elements.
NEW
   This section describes how iCalendar data is converted to jCal using
   a simple mapping between the iCalendar data model and JSON elements.
   Aside from the formal description in this section, an informative ABNF is
   specified in Appendix B.
END

- Paragraph 3.4 and onwards

It is unclear to me when you write for example "Each individual iCalendar property is represented in jCal by …" whether you really mean to write: "Each individual iCalendar property MUST be represented in jCal by…." 
I assume you want to be normative in specifying the format?

Thanks, I've changed it (almost) as you suggested.

OLD
   Each individual iCalendar property is represented in jCal by an array
   with three fixed elements, followed by one or more additional
   elements, depending on if the property is a multi-value property as
   described in Section 3.1.2 of [RFC5545].
NEW
   In jCal, each individual iCalendar property MUST be represented by an
   array with three fixed elements, followed by one or more additional
   elements, depending on if the property is a multi-value property as
   described in Section 3.1.2 of [RFC5545].
END

- Paragraph 9.2 should RFC4627 not be a normative rather than informative reference?
Yes, indeed. I've changed this and also updated references to rfc7159. While doing this I noticed that we referenced a regex that was in rfc4627 but no longer in rfc7159. I've made some changes:

OLD
   With this in mind, a parser for JSON data should be used for jCal
   that is aware of the security implications.  For example, the use of
   JavaScript's eval() function is only allowed using the regular
   expression in Section 6 of [RFC4627].  A native parser with full
   awareness of the JSON format should be preferred.
NEW
   With this in mind, a parser for JSON data should be used for jCal that
   is aware of the security implications. For example, the use of
   JavaScript's eval() function is considered an unacceptable security
   risk, as described in [RFC7159], Section 12. A native parser with full
   awareness of the JSON format should be preferred.
END

Regards,
Philipp
--------------000000020609080709090205-- From nobody Fri Mar 21 00:40:07 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1451A069E; Fri, 21 Mar 2014 00:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RosjJzfnTdA; Fri, 21 Mar 2014 00:39:56 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3AF1A067E; Fri, 21 Mar 2014 00:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3180; q=dns/txt; s=iport; t=1395387587; x=1396597187; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VkvL3YQexO5aVfR77wQ9C1BSIrEzzgb7bkX8US+B9tE=; b=XXDTjG1Wm925XQ7vmBd6TgOmGQUHHsd/ITEKDe97M5Bj2t9poAdJQ0qR 5kbkwk4RLzBIVLarIcb2OvnFQ6jDCGHU+roxgwkGxJEwk22hELkR0sIuC uaG2L5JvlYTCzZi6tpCq8Wm/hsUqP1q0vnEzDVghQ4Gj6oNTuDdudAWbs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAHfrK1OtJV2Z/2dsb2JhbABZgwbDYoESFnSCJQEBAQMBeQULAgEIGC4hESUCBA4Fh2UDCQjIOQ2HGReMTYFlMweDJIEUBJZcgW2MaIVJgy0 X-IronPort-AV: E=Sophos;i="4.97,702,1389744000"; d="scan'208";a="311899959" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 21 Mar 2014 07:39:47 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2L7dlK6006584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 07:39:47 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.194]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 02:39:46 -0500 From: "Klaas Wierenga (kwiereng)" To: Philipp Kewisch Thread-Topic: secdir review of draft-ietf-jcardcal-jcal-09 Thread-Index: AQHPMjcJwgX+osJyDEaPL10iZVgG5ZrrDxQAgAA99DU= Date: Fri, 21 Mar 2014 07:39:46 +0000 Message-ID: References: <894C08E3-0017-4830-9C8F-930CCEB5B2E2@cisco.com>, <532B727A.9060500@gmail.com> In-Reply-To: <532B727A.9060500@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Qib1F8LC-vZaUo7h3anVBH7XKAA Cc: "draft-ietf-jcardcal-jcal.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-jcardcal-jcal-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 07:39:58 -0000 Hi Philipp, Looks good to me! Klaas Sent from my iPhone > On 20 mrt. 2014, at 23:58, "Philipp Kewisch" wrote: >=20 > Hi Klaas, >=20 > thank you for your corrections. Here is my feedback: >> - Paragraph 3 (converting from iCal to jCal): >>=20 >> The text looks very much like production rules, why not give ABNF? (Ah = wait, now that I have read the full document I see that that appears in App= endix B, I think you should at least point to Appendix B here) > The ABNF is considered informative, I was told for jCard that not too muc= h weight should be put into it. Nevertheless, I am happy to mention it if y= ou like. How is this for the introduction to section 3? >=20 > OLD > This section describes how iCalendar data is converted to jCal using > a simple mapping between the iCalendar data model and JSON elements. > NEW > This section describes how iCalendar data is converted to jCal using > a simple mapping between the iCalendar data model and JSON elements. > Aside from the formal description in this section, an informative ABNF= is > specified in Appendix B. > END >=20 >> - Paragraph 3.4 and onwards >>=20 >> It is unclear to me when you write for example "Each individual iCalenda= r property is represented in jCal by =85" whether you really mean to write:= "Each individual iCalendar property MUST be represented in jCal by=85."=20 >> I assume you want to be normative in specifying the format? >=20 > Thanks, I've changed it (almost) as you suggested. >=20 > OLD > Each individual iCalendar property is represented in jCal by an array > with three fixed elements, followed by one or more additional > elements, depending on if the property is a multi-value property as > described in Section 3.1.2 of [RFC5545]. > NEW > In jCal, each individual iCalendar property MUST be represented by an > array with three fixed elements, followed by one or more additional > elements, depending on if the property is a multi-value property as > described in Section 3.1.2 of [RFC5545]. > END >=20 >> - Paragraph 9.2 should RFC4627 not be a normative rather than informativ= e reference? > Yes, indeed. I've changed this and also updated references to rfc7159. Wh= ile doing this I noticed that we referenced a regex that was in rfc4627 but= no longer in rfc7159. I've made some changes: >=20 > OLD > With this in mind, a parser for JSON data should be used for jCal > that is aware of the security implications. For example, the use of > JavaScript's eval() function is only allowed using the regular > expression in Section 6 of [RFC4627]. A native parser with full > awareness of the JSON format should be preferred. > NEW > With this in mind, a parser for JSON data should be used for jCal that > is aware of the security implications. For example, the use of > JavaScript's eval() function is considered an unacceptable security > risk, as described in [RFC7159], Section 12. A native parser with full= =20 > awareness of the JSON format should be preferred. > END >=20 > Regards, > Philipp From nobody Mon Mar 24 17:28:00 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377141A0012; Mon, 24 Mar 2014 17:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHZLR5q2IbWB; Mon, 24 Mar 2014 17:27:54 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEFF1A000F; Mon, 24 Mar 2014 17:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2849; q=dns/txt; s=iport; t=1395707274; x=1396916874; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=AbFXxX2D0R/Xb0g2FIWq5c02NmQMgaSBB1aWbZYYPlA=; b=Ejs9zvSdVIWGASmaXSkpms9mX5R7F3EM8oAupgtfYiYmkRGbSqayFXcO 9QQ+u5Ge2NdkGa4vUx77N4G2ItbkmZnDDWn8FL68JJHeF6/o3r5HfvScc 9LbUknFJBt/j9N4RxL4lZbNoLIYUObB4sCVxL74O14GLe/jn5kRJdD9fu A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFANvMMFOrRDoI/2dsb2JhbABQCYMGqwGZB4EjFnSCZj8tfRQBLYddzy0Xjh9bgyuBFASJUo54hkyLZYNNHQ X-IronPort-AV: E=Sophos;i="4.97,723,1389744000"; d="scan'208";a="108933493" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 25 Mar 2014 00:27:53 +0000 Received: from [10.154.161.202] ([10.154.161.202]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2P0RrmD006732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Mar 2014 00:27:53 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Mar 2014 17:27:53 -0700 Message-Id: <20EA5EFD-036D-4924-A206-849FE0B5B0BE@cisco.com> To: "secdir@ietf.org" , The IESG Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/FgWQN5TN-bYZsrafKthOGhhGvYI Cc: draft-ietf-ecrit-trustworthy-location.all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-ecrit-trustworthy-location-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 00:27:56 -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 identifies a number of threats and attacks when location = data associated with an IP-based emergency services emergency service = call. Three types of adversaries are identified, however only threats = from malicious end host adversaries are addressed in this document. That = is, adversaries which are themselves malicious, with or without the the = awareness of the owner. Two types of threats from malicious hosts are = discussed: location spoofing, where an adversary provides false location = information in an emergency call; and identity spoofing, where a false = network access identity or caller identity is claimed. The document is useful and generally ready to publish. But I have the = following suggestions that would improve reader comprehension. Section 3 describes three "Solutions", which are perhaps better termed = "Techniques to Mitigate Threats". I say this because each "Solution" = lists caveats in the use of each technique, and there seems to be extant = threats in each case. This is not a criticism of the proposed solutions, = but rather a recognition that the document clearly states in each case = that there are factors not in control of the LIS and/or Location = Recipient that can reduce the trustworthiness of the location and/or = identity information. So they are more properly mitigations, not = solutions. With the above comment in mind, the Abstract seems to overclaim a bit = when it says "This document describes how to convey location in a manner = that is inherently secure and reliable." It might be better to say = something like "This document describes techniques that improve the = reliability and security of location information conveyed in a IP-based = emergency services emergency service call." Section 5 "Security Considerations" contains a lot of good additional = information on the consequences to attacks on emergency services, but = for a document limiting itself to threats from hosts attacking the = system I'm not sure why it discusses denial of service attacks to the = infrastructure and attacks on the mapping architecture. This section = could be clearer if this discussion was either removed or its relevance = made clearer. The definition for "Target" in Section 1.1 is a particularly important = definition for this document but the definition is not actually present. = It would benefit from a brief explanation of the term rather than just a = pointer to RFC 3693! Brian= From nobody Tue Mar 25 06:12:16 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873381A011D for ; Tue, 25 Mar 2014 06:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPkhObEB-oca for ; Tue, 25 Mar 2014 06:12:09 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id EC8901A0110 for ; Tue, 25 Mar 2014 06:12:08 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id l6so502367oag.25 for ; Tue, 25 Mar 2014 06:12:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=pRtRfFXDm0Wv8ynmGLtqOvSi6XdmjmBw/VsHsj4xtV0=; b=EdCy8qw42HbOj0eUkE7Wk7H4iYHP8dz+6mSJbTSLWl4dX/1KeI9WMGwcLBXotkvVpi N+C7PKbXMLlw2yRpjcS52LTcltrZXvfT7XxvIOi75DY5YDC8bzz87A4mFbVjhzqWvE66 wa5679c0cTvVkld/9x8IwTI8oZhUzpQxX2vN1LLrg2g/PHPM8kFr0sMWwFAlh0tinitq /RtO5hN6liTL7vTtV5WCPCfnc1lbK6UNm21ipfLtY05mGSpMUo/6zq1ShGGTCnGbKh/X vk8Y9+qo3RR40PBf4G2qCjPBec4f9xqXMp1l4vl/pD6RExvfzHSNT/teWZAWXPLegpvH f9wg== X-Gm-Message-State: ALoCoQl9Dhvx4IE+TS3FJE3RMHJZiCv4OgT6p0nEFLeo+tdBpG47YkJ9kOXaA4y4bSqBuBZC/VMC X-Received: by 10.182.33.35 with SMTP id o3mr58028558obi.15.1395753127617; Tue, 25 Mar 2014 06:12:07 -0700 (PDT) Received: from ?IPv6:2602:306:3406:4f00:b9ff:6038:d65a:97ce? ([2602:306:3406:4f00:b9ff:6038:d65a:97ce]) by mx.google.com with ESMTPSA id m7sm30262700obo.7.2014.03.25.06.12.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Mar 2014 06:12:06 -0700 (PDT) From: Adam Montville Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 25 Mar 2014 08:12:04 -0500 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-storm-rdmap-ext.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vpxXGXbD94g0YT6Myh3WyBTpGNo Subject: [secdir] secdir review of draft-ietf-storm-rdmap-ext-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 13:12:10 -0000 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This draft is ready. =20 One non-blocking suggestion comes to mind. It would be to add = subsection references in draft-ietf-storm-rdmap-ext Section 9 (Security = Considerations) to RFC5040 and RFC5042. Such references might better = describe how use of ULP Buffer addresses for the Remote Peer buffer = addressing by Atomic Operations satisfies the security model described = in RFC5042. Regards, Adam= From nobody Tue Mar 25 13:13:36 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A11A1A00CA; Tue, 25 Mar 2014 05:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.012 X-Spam-Level: X-Spam-Status: No, score=-5.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3ujPT_mvFzr; Tue, 25 Mar 2014 05:31:46 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4701A00BE; Tue, 25 Mar 2014 05:31:45 -0700 (PDT) x-m-msg: CPCHECK Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s2PCVdfI003495; Tue, 25 Mar 2014 14:31:39 +0200 Received: from IL-EX10.ad.checkpoint.com ([169.254.2.26]) by DAG-EX10.ad.checkpoint.com ([169.254.3.228]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 14:31:40 +0200 From: Yoav Nir To: "" , " IESG" , "draft-ietf-eman-framework.all@tools.ietf.org" Thread-Topic: SECDIR review of draft-ietf-eman-framework-16 Thread-Index: Ac9IDP3a75Lz8KTcRSikp8TKfFQCWQ== Date: Tue, 25 Mar 2014 12:31:38 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277213AFB6E5E@IL-EX10.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.62] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/R4UuYG6pcmb_75H-50S2H0_ByiU X-Mailman-Approved-At: Tue, 25 Mar 2014 08:13:08 -0700 Subject: Re: [secdir] SECDIR review of draft-ietf-eman-framework-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 12:31:47 -0000 Hi I have now reviewed version -16. The formatting problems are still present= . I think the security considerations does an OK job of enumerating the risks= . It could use some stronger language, but the information is there. Yoav=20 From nobody Tue Mar 25 14:17:41 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12351A0236; Tue, 25 Mar 2014 14:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 FZnVlRxbt4vx; Tue, 25 Mar 2014 14:17:26 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 10D7A1A0231; Tue, 25 Mar 2014 14:17:25 -0700 (PDT) Received: from mail5-am1-R.bigfish.com (10.3.201.237) by AM1EHSOBE026.bigfish.com (10.3.207.148) with Microsoft SMTP Server id 14.1.225.22; Tue, 25 Mar 2014 21:17:24 +0000 Received: from mail5-am1 (localhost [127.0.0.1]) by mail5-am1-R.bigfish.com (Postfix) with ESMTP id 4B834140111; Tue, 25 Mar 2014 21:17:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I542I1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzdchz1de098h1033IL8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh9a9j1155h) Received-SPF: pass (mail5-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=shanna@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(13464003)(199002)(189002)(51704005)(377454003)(81342001)(74876001)(56816005)(69226001)(74316001)(92566001)(74366001)(90146001)(20776003)(63696002)(97186001)(97336001)(79102001)(2201001)(77982001)(59766001)(49866001)(81686001)(81816001)(80976001)(47976001)(4396001)(50986001)(47736001)(33646001)(83322001)(46102001)(54316002)(19580395003)(56776001)(76482001)(98676001)(93136001)(19580405001)(53806001)(51856001)(2656002)(87936001)(76176001)(86362001)(47446002)(74502001)(74662001)(94946001)(66066001)(31966008)(95416001)(93516002)(54356001)(81542001)(85852003)(80022001)(87266001)(85306002)(74706001)(83072002)(94316002)(95666003)(65816001)(76576001)(76786001)(76796001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB740; H:BLUPR05MB737.namprd05.prod.outlook.com; FPR:FEBCC4DE.D12570A.73D35DB7.44D1D1A1.20290; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail5-am1 (localhost.localdomain [127.0.0.1]) by mail5-am1 (MessageSwitch) id 1395782242696912_5231; Tue, 25 Mar 2014 21:17:22 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.243]) by mail5-am1.bigfish.com (Postfix) with ESMTP id A40EE3E0116; Tue, 25 Mar 2014 21:17:22 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Mar 2014 21:17:22 +0000 Received: from BLUPR05MB740.namprd05.prod.outlook.com (10.141.208.28) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.423.0; Tue, 25 Mar 2014 21:17:22 +0000 Received: from BLUPR05MB737.namprd05.prod.outlook.com (10.141.208.17) by BLUPR05MB740.namprd05.prod.outlook.com (10.141.208.28) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 25 Mar 2014 21:17:20 +0000 Received: from BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) by BLUPR05MB737.namprd05.prod.outlook.com ([10.141.208.17]) with mapi id 15.00.0898.005; Tue, 25 Mar 2014 21:17:20 +0000 From: Stephen Hanna To: The IESG , "secdir@ietf.org" , "draft-ietf-manet-smf-mib.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-manet-smf-mib-11 Thread-Index: Ac7LmPjydxpNTDH1RCq+bXu7cbCCRR81Jwcg Date: Tue, 25 Mar 2014 21:17:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.11] x-forefront-prvs: 01613DFDC8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/KadlfUkBy0mnrpkzI0AByTfuy4Q Subject: [secdir] secdir review of draft-ietf-manet-smf-mib-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 21:17:34 -0000 I have reviewed the latest version of 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. Neither of my comments below seems to have been addressed. In addition, I did notice a few more typos that have been added to the Security Considerations section: * "destine" should be "destined" * "does specifies" should be "does specify" * "but these cases will vary dependent" should be "these cases will vary depending" Other than these typos, the document looks fine from a security perspective. In fact, I'm happy to see more and better commentary in the Security Considerations section. Thanks, Steve > -----Original Message----- > From: Stephen Hanna > Sent: Thursday, October 17, 2013 8:29 PM > To: The IESG; secdir@ietf.org; 'draft-ietf-manet-smf- > mib.all@tools.ietf.org' > Subject: secdir review of draft-ietf-manet-smf-mib-08 >=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 > While I am not an expert in SNMP, SMF, or MANET, I found this > document to be well-written and easy to understand. More relevant > to this review, the security of the protocol is adequate and > the Security Considerations section is exemplary. >=20 > I did notice two typos: >=20 > * In the Security Considerations section, the commentary on > smfConfiguredOpMode includes the words "this writable > configuration objects define". This should end in "object > define", I think. >=20 > * In the Security Considerations section, the commentary on > smfNhdpRssaMesgTLVIncluded includes the words "the the". > Of course, that should be just "the". >=20 > With these corrections, I think the document is ready to publish. >=20 > Thanks, >=20 > Steve From nobody Tue Mar 25 15:21:30 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4DD1A0242; Tue, 25 Mar 2014 15:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgdgC7Ida9dz; Tue, 25 Mar 2014 15:21:21 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA4A1A0168; Tue, 25 Mar 2014 15:21:20 -0700 (PDT) X-AuditID: 1209190e-f79ee6d000000c40-7f-5332015f297e Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id EC.A7.03136.F5102335; Tue, 25 Mar 2014 18:21:19 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s2PMLHm9021716; Tue, 25 Mar 2014 18:21:18 -0400 Received: from cathode-dark-space.mit.edu (cathode-dark-space.mit.edu [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s2PMLE8E002246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Mar 2014 18:21:15 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id s2PMLDEC017657; Tue, 25 Mar 2014 18:21:13 -0400 (EDT) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-abfab-arch.all@tools.ietf.org From: Tom Yu Date: Tue, 25 Mar 2014 18:21:13 -0400 Message-ID: Lines: 22 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUixCmqrBvPaBRscHEJl8XaNadYLGb8mchs 8WHhQxYHZo8lS34yeXy5/JktgCmKyyYlNSezLLVI3y6BK+P34YKCoxwVj95fZG1g/M7WxcjJ ISFgInFo0TZmCFtM4sK99UBxLg4hgdlMEtc6PzFBOBsZJVqWH2OEcM4xSUw+uxEq08Uo0f9g I1i/iICPxMZJc5lAbGEBU4nnz6YDxTk42ASkJY4uLgMJswioSrx6d4cdxOYVsJB4ueEYWDmP AKdE7+GprBBxQYmTM5+wgNjMAloSN/69ZJrAyDcLSWoWktQCRqZVjLIpuVW6uYmZOcWpybrF yYl5ealFusZ6uZkleqkppZsYwaEmybeD8etBpUOMAhyMSjy8EyYYBguxJpYVV+YeYpTkYFIS 5f33ByjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhPfDPaAcb0piZVVqUT5MSpqDRUmcV55DO1hI ID2xJDU7NbUgtQgmK8PBoSTBu5TBKFhIsCg1PbUiLTOnBCHNxMEJMpwHaDgLSA1vcUFibnFm OkT+FKOilDivKUhCACSRUZoH1wtLBa8YxYFeEebtBaniAaYRuO5XQIOZgAaHN+mBDC5JREhJ NTAuT08p0BabvWy7aG9DSWHGY/7VgpwJlie/7r4UdlLw9sLPC1NSuE8/W3Q0VHfyhAb9/1+r 3P2kJ+x40CXfcvOD+kHHxV3bbP53vdWxfXtdqu5ZkqtAaLt+T5eizcJq48aPxdsmCG2dtmnG RaWDD1IlU/dGfBFVa3tZFPPO5q+D/K7Qr517msuVWIozEg21mIuKEwFTYjEt4AIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/7VVJrBgSv2isNJRYi1CyovTnMko Subject: [secdir] secdir re-review of draft-ietf-abfab-arch-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 22:21:23 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: ready with nits The Security Considerations (section 5) no longer has the placeholder text from the -10 version. The text describing the detailed security properties of the various communication channels appears to be gone, possibly replaced by summaries in section 4. Other items listed in the "to be addressed" paragraph from -10 appear to have been covered by new text. I'm not sure whether the removed text describing the security properties of the communication channels was completely redundant with text in section 4, but some of it seems close, so the current state might be good enough. What is the authors' belief about that? There appears to be a author's query labeled [CREF1]; has that question been resolved? From nobody Tue Mar 25 21:15:51 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13221A00A9; Tue, 25 Mar 2014 21:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izqils48BIt8; Tue, 25 Mar 2014 21:15:47 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9195E1A0083; Tue, 25 Mar 2014 21:15:47 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id i7so1841844oag.33 for ; Tue, 25 Mar 2014 21:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=WKE4EzcF9FpcOqGO089ejH5reLiXEQfQhp5yT9zTy9U=; b=i52DP0Lx3ytr+a/RCmLWCwvqgKeO1bPRKWKNiKxFzcOWTAeMEyd/Aj9w4RMuz90K4l zLaOXJQABAeZpwy5GCCa8CQCWtZFtJ0ZlE869uLViithmscc5w8y3pIThjyu0lM+R+1P TB990Ma9wACIxgvasPtd63Qal06sfrxekQotxGOTaXUq8kuvBf3AzgUpdcNRAFW5TsL7 q7zZG6RBB9P7bAuP+GZV8h6P+12AYCA50B4764Dwxdsg+zQnNieepL563cc2hOmpIevT XdVc2TVleR9afRkgxAjuTWFlKmxpTvI0qeeU4qhzKYqhOjHGV1InKymL8yDCjPlsg/1D JvvQ== X-Received: by 10.182.220.7 with SMTP id ps7mr35536983obc.23.1395807346210; Tue, 25 Mar 2014 21:15:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.23.138 with HTTP; Tue, 25 Mar 2014 21:15:26 -0700 (PDT) From: Donald Eastlake Date: Wed, 26 Mar 2014 00:15:26 -0400 Message-ID: To: "iesg@ietf.org" , draft-ietf-netext-pmip6-qos@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/QVHv0xTvTL_4mCobXMZmpOxgoOk Cc: "secdir@ietf.org" Subject: [secdir] SECDIR review of draft-ietf-netext-pmip6-qos-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 04:15:49 -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. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies Quality of Service options for Proxy Mobile IPv6 along with appropriate new status codes and other protocol considerations. These options are carried in Proxy Binding Update messages to which a Proxy Binding Acknowledgement is sent in response. The Security Considerations section refers to earlier RFCs (5213 and 7077). There earlier RFCs do appear to provide adequate security for the messages involved. And, on thinking about it, I tend to agree with the assertion that "The quality of service option when included in these signaling messages does not require additional security considerations." If it were me, I would add a few words about how, if the Proxy Binding Update/Acknowledgement protocol is not secured, you can do worse things than change the quality of service. However, while the Security Considerations section feels quite minimal, it does appear to be adequate. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Wed Mar 26 00:27:59 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69E41A02A8; Wed, 26 Mar 2014 00:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl8yVsgNB3eH; Wed, 26 Mar 2014 00:27:56 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1C14A1A008A; Wed, 26 Mar 2014 00:27:55 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id hr13so1181997lab.17 for ; Wed, 26 Mar 2014 00:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Wehb/WqxFq0NZt0b7nQ8alTWc1KMs12dWEHIKEwGhuE=; b=qAz7YkxYUeAruYFcMhrwm2bwQQPREexB3oHOJpkyDwqazsRlXaCEurwxQdIQdoAya2 mHcNJDt7GwhdqMHcf+3UMIlGzIEg9Ygu8c1F4CFJkJCJhC3Lnn+2L/KtDFi7c0yUL+Bc EROq1O+K/CABQXEXLJ2tskgko+/kgmElGhyhwVfAGa4WN3M6iTUQDg2LDUGEz6nPd7oG 3MlaomfX1W4A+z28dw+Nc8+9p+LyN0tgWnLCsc8cynptR8ouy+U3xxj7Z5I4p2lH3SBF QEP1nhcgAWxOJQ0mC57TnC5IIJSBy4sMjblvHIeaEyHtCLX26jXgRgPA0K9SkBgbuAhd HiaQ== X-Received: by 10.152.172.103 with SMTP id bb7mr160666lac.49.1395818874203; Wed, 26 Mar 2014 00:27:54 -0700 (PDT) Received: from [188.117.15.107] ([188.117.15.107]) by mx.google.com with ESMTPSA id jm3sm4864238lbc.29.2014.03.26.00.27.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Mar 2014 00:27:51 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Wed, 26 Mar 2014 09:27:49 +0200 Content-Transfer-Encoding: 7bit Message-Id: <1B841F73-3460-436D-AF64-19ED3901771D@gmail.com> References: To: Donald Eastlake X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ZbaRyZS8r_DuJ3QIEKtIsUK27_o Cc: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-netext-pmip6-qos@tools.ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-netext-pmip6-qos-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 07:27:58 -0000 Donald, Thanks for the review. I agree what you say but I think an extra warning is not necessary. If an operator deliberately turns off the signaling security, he would probably do so regardless of any warning. - Jouni On Mar 26, 2014, at 6:15 AM, Donald Eastlake wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. Document editors and WG chairs should treat these comments just > like any other last call comments. > > This draft specifies Quality of Service options for Proxy Mobile IPv6 > along with appropriate new status codes and other protocol > considerations. These options are carried in Proxy Binding Update > messages to which a Proxy Binding Acknowledgement is sent in response. > > The Security Considerations section refers to earlier RFCs (5213 and > 7077). There earlier RFCs do appear to provide adequate security for > the messages involved. And, on thinking about it, I tend to agree with > the assertion that "The quality of service option when included in > these signaling messages does not require additional security > considerations." If it were me, I would add a few words about how, if > the Proxy Binding Update/Acknowledgement protocol is not secured, you > can do worse things than change the quality of service. However, while > the Security Considerations section feels quite minimal, it does > appear to be adequate. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com From nobody Wed Mar 26 08:37:44 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFB11A0306; Wed, 26 Mar 2014 08:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rya9RdthCRbZ; Wed, 26 Mar 2014 08:37:35 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 21A8F1A016A; Wed, 26 Mar 2014 08:37:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 74E6E224014F; Wed, 26 Mar 2014 16:37:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyNn+lunxR6d; Wed, 26 Mar 2014 16:37:33 +0100 (CET) Received: from Thor.local (bas1-ottawa11-1176224686.dsl.bell.ca [70.27.195.174]) by power.freeradius.org (Postfix) with ESMTPSA id 772F32240082; Wed, 26 Mar 2014 16:37:32 +0100 (CET) Message-ID: <5332F43B.7040404@deployingradius.com> Date: Wed, 26 Mar 2014 11:37:31 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "secdir@ietf.org" , IESG IESG , draft-ietf-appsawg-xml-mediatypes.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/NyrfvTNriY-dhO6hRITShY7BZMA Subject: [secdir] Secdir review of draft-ietf-appsawg-xml-mediatypes X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:37: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. Section 2.2: UTF-32 has four potential serializations, of which only two (UTF-32BE and UTF-32LE) are given names in in [UNICODE]. Support for the various serializations varies widely, and security concerns about their use have been raised. - It would be good to have a reference for the security concerns, or perhaps a little more discussion. Section 3 Other MIME agents will not be XML-aware, and thus cannot know anything about the XML encoding declaration. Not only do they lack one of the three sources of information about encoding, they are also less likely to be aware of or responsive to this spec. - it may be useful to discuss how an XML-unware MIME agent will handle the XML documents. e.g. do they usually pass the document through unaltered? Do they mangle the document, changing it's meaning? Are there recommendations for what they should do? Some MIME agents, such as proxies and transcoders, both consume and produce MIME entities. - it may be use to have recommendations for what MIME agents should do (or not) when they want to proxy XML messages, without examining them. Section 10 Security considerations will vary by domain of use. For example, XML medical records will have much more stringent privacy and security considerations than XML library metadata. Similarly, use of XML as a parameter marshalling syntax necessitates a case by case security review. - it would be good to make recommendations here. e.g. standards for XML medical records SHOULD have limitations on which external XML libraries can be used. A few paragraphs earlier, this section has the following text: Thus, the security of any XML document is vitally dependent on all of the documents recursively referenced by that document. - the only way to ensure security of XML records is to control which documents they reference. This doesn't matter much for some situations, where the possible attacks are minor. It can matter enormously for more critical situations, like medical records. XML may also have some of the same security concerns as plain text. Like plain text, XML can contain escape sequences that, when displayed, have the potential to change the display processor environment in ways that adversely affect subsequent operations. Possible effects include, but are not limited to, locking the keyboard, changing display parameters so subsequent displayed text is unreadable, or even changing display parameters to deliberately obscure or distort subsequent displayed material so that its meaning is lost or altered. Display processors SHOULD either filter such material from displayed text or else make sure to reset all important settings after a given display operation is complete. - I would suggest changing the SHOULD to a MUST. The display processor MUST by default filter such material, or be sure to reset all settings. The filter MAY be administratively controlled. i.e. the user can turn it off. As such, the ability to program keys SHOULD be blocked either by filtering or by disabling the ability to program keys entirely. - the same comment as above applies here However, even non- recursive expansions may cause problems with the finite computing resources of computers, if they are performed many times. For example, consider the case where XML-entity A consists of 100 copies of XML-entity B, which in turn consists of 100 copies of XML-entity C, and so on. - it would be good to make specific recommendations here. e.g. XML processors SHOULD administratively limit the number of XML entities they will process from one document. This limitation SHOULD be configurable. Where possible, the XML processors may also prompt the end user when this limit is reached, to see if they should continue processing the document. From nobody Wed Mar 26 15:39:15 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE4D1A03D9; Wed, 26 Mar 2014 14:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnrWvUIy5HHQ; Wed, 26 Mar 2014 14:07:09 -0700 (PDT) Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id BC94E1A03D1; Wed, 26 Mar 2014 14:07:08 -0700 (PDT) Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 26 Mar 2014 22:07:06 +0100 Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 6FDE310679D7; Wed, 26 Mar 2014 22:07:06 +0100 (CET) Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21793-09; Wed, 26 Mar 2014 22:07:05 +0100 (CET) Received: from [141.22.28.186] (unknown [141.22.28.186]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 2A2BC10679CF; Wed, 26 Mar 2014 22:07:04 +0100 (CET) Message-ID: <53334175.8080807@informatik.haw-hamburg.de> Date: Wed, 26 Mar 2014 22:07:01 +0100 From: "Thomas C. Schmidt" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Radia Perlman , "secdir@ietf.org" , The IESG , draft-ietf-multimob-pmipv6-source.all@tools.ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/dqAebyg0IRwXWGcHkWYkPdyBQls X-Mailman-Approved-At: Wed, 26 Mar 2014 15:39:13 -0700 Subject: Re: [secdir] Secdir review of draft-ietf-multimob-pmipv6-source X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 21:07:12 -0000 Dear Radia, thanks for your review and please apologize our late reply. Please see answers inline. On 18.03.2014 05:17, Radia Perlman wrote: > > > > On Tue, Dec 17, 2013 at 7:11 PM, Radia Perlman > wrote: > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document combines mobile IPv6 with multicast. It's unnecessarily > difficult to read. There should be a section upfront expanding all the > acronyms, at the very least. For instance, MLD, PMIPv6, PIM, MAG, HNP. > Some of these (like MAG) are expanded in the text the first time they > are used, but most are not, and people aren't necessarily going to > remember it because of seeing it once, and there's no downside to having > a section in the introduction called "acronyms". > I'm sorry that reading was troublesome. We have taken up your suggestion to add the list of acronyms. However, this draft builds on two rather large subject areas, Multicast and Mobility Management. Retelling only the core ideas of the protocols involved in this work would extend the document to a rather unpleasant volume ... > It also wouldn't hurt to explain "proxy mobile IPv6 domains" (not just > expand the acronym PMIPv6). > Proxy Mobile IPv6 Domain = region of PMIPv6 deployment ... this is a very common term in our area. Considering the target audience of this document ( i.e., people who deploy or implement PMIPv6), I would rather not burden the document with corresponding explanations. > I admit I don't completely understand this document, because I didn't > want to have to read all the other documents that this thing assumes you > understand, but I think I get the general idea. > > I think the security considerations section covers most of the > downsides, but it doesn't talk about how multicast in general can > amplify DOS packets. And with mobility, there are two problems with > having a proxy sending the multicast (unless it's tunneled, which would > be OK). If packets with an IP source address can come from a different > location, then loops won't be detected (the security considerations > section mentions that), but also, it's harder for the infrastructure to > filter out packets from forged IP addresses. > The issue you raise (changing source IP addresses) is present at the early MIPv4 protocol. In contrast, mobile senders in PMIPv6 tunnel their packets to a mobility anchor, the LMA, and thus never need to change their source address. Consequently, there is no additional threat introduced from topologically invalid or unstable IP addresses. Ingress or egress filtering can be applied with PMIPv6 just as in the fixed Internet. Changes to the document as described above will be part of the next submission. Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 ° From nobody Thu Mar 27 04:23:05 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3BE1A064D for ; Thu, 27 Mar 2014 04:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2YfVW2K7BKP for ; Thu, 27 Mar 2014 04:23:00 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9321A064B for ; Thu, 27 Mar 2014 04:22:59 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s2RBMt9K012973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 27 Mar 2014 13:22:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s2RBMtVU001018; Thu, 27 Mar 2014 13:22:55 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21300.2575.72550.808757@fireball.kivinen.iki.fi> Date: Thu, 27 Mar 2014 13:22:55 +0200 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/C_OEskS303wmxKKffvcgTNHU8po Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 11:23:04 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Leif Johansson is next in the rotation. For telechat 2014-03-27 Reviewer LC end Draft Scott Kelly TR2013-05-29 draft-ietf-cuss-sip-uui-14 Catherine Meadows TR2014-02-17 draft-ietf-dmm-requirements-15 Zach Shelby T 2013-08-30 draft-kaplan-insipid-session-id-04 Ondrej Sury T 2014-02-27 draft-ietf-ippm-testplan-rfc2680-04 For telechat 2014-04-03 Derek Atkins T 2014-03-12 draft-ietf-ipsecme-ikev2-fragmentation-06 Sandy Murphy T 2014-03-05 draft-melnikov-smime-msa-to-mda-04 For telechat 2014-04-10 Rob Austein T 2014-03-24 draft-ietf-cdni-framework-10 Last calls and special requests: Shawn Emery E 2014-03-27 draft-ietf-tcpm-fastopen-08 Dorothy Gellert 2014-04-01 draft-ietf-pcp-dhcp-09 Tobias Gondrom 2014-03-27 draft-ietf-pwe3-p2mp-pw-requirements-07 Phillip Hallam-Baker 2014-04-01 draft-ietf-trill-esadi-06 Steve Hanna 2014-03-28 draft-ietf-xrblock-rtcp-xr-loss-conceal-10 Dan Harkins 2014-04-08 draft-ietf-idr-aigp-16 David Harrington 2014-04-03 draft-ietf-idr-last-as-reservation-04 Sam Hartman 2014-04-08 draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Paul Hoffman 2014-04-07 draft-ietf-mpls-lsp-ping-ttl-tlv-07 Jeffrey Hutzelman E 2013-11-21 draft-ietf-drinks-spp-protocol-over-soap-05 Jeffrey Hutzelman 2014-04-09 draft-ietf-mpls-psc-updates-03 Chris Inacio 2014-04-07 draft-ietf-opsec-lla-only-07 Julien Laganier E 2013-11-21 draft-ietf-websec-key-pinning-11 Russ Mundy 2014-03-24 draft-mahalingam-dutt-dcops-vxlan-08 Sandy Murphy 2013-12-17 draft-ietf-netmod-iana-timezones-03 Vincent Roca 2014-02-25 draft-ietf-sidr-policy-qualifiers-01 Carl Wallace 2014-03-14 draft-drage-sipping-rfc3455bis-13 Brian Weis E 2014-01-16 draft-ietf-radext-dynamic-discovery-11 -- kivinen@iki.fi From nobody Thu Mar 27 07:34:22 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BEB1A071A for ; Thu, 27 Mar 2014 07:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evPsAoIXoKFm for ; Thu, 27 Mar 2014 07:34:20 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id E686C1A06C1 for ; Thu, 27 Mar 2014 07:34:19 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA11.westchester.pa.mail.comcast.net with comcast id icDn1n0011YDfWL5BeaHMP; Thu, 27 Mar 2014 14:34:17 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta20.westchester.pa.mail.comcast.net with comcast id ieaH1n00R2yZEBF3geaH4c; Thu, 27 Mar 2014 14:34:17 +0000 From: "ietfdbh" To: , , Date: Thu, 27 Mar 2014 10:34:02 -0400 Message-ID: <018e01cf49c9$99a2a120$cce7e360$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac9JxVzucOfxmxC2RyKubfXNixV2gA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1395930857; bh=l4VzVqXh/2WeB0Apmgcet79533vSXivRMxd8fphAEVQ=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=s769DnLayzF1Z2+IL9QCF86XVTYumlcYepFa51APssVORXcRFGLwAJfrWEvbygqh5 j5fJbzJ21yaD+ygCHPxkyOixAzFtu5KHtB4vz6FHtOu+4nHYrbSLUvmb2OEdnal3cA 1yQpv2TJ7Mjto97qUiJtH5G3gxFbTbjYt6IAb6bmmMB9EhW7gwKmyWVOw63CsF+L6i JBMKDXig9JFyhQVkWAVZe3v6heOr1mxUk3rdI0bCSs3YBNe2VmxmPhHstBCuZZEVfc 6tpehpFYYS+rjYp36FfV0XtmQGz11jM5AfVTt9MfPLSMawFtghkw8N7mCE/1wkDXSH spAFWNXGXKR7Q== Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/TnmzcjCFKWj6nWhuzRCwLbDU_oA Subject: [secdir] secdir review of draft-ietf-idr-last-as-reservation-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 14:34: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 reserves the highest-valued 32-bit AS number for an unknown future use. >From a security standpoint, since it says don't use it, and doesn't say what it will be used for in the future, it creates no new security issues. When a special use is standardized for this AS number, then associated security risk presumably will be documented. The document tells operators not to use this reserved value, but tells implementers they should not consider its use to be a protocol error. This is equivalent to having a reserved bit in a message format, but this relates to an IANA registration so needs separate documentation. I'm a bit surprised the document has an intended status of Informational, but is being requested in the shepherd writeup to be published as PS or BCP. Reviewers might assume this only requires the level of review associated with an Informational doc rather than PS or BCP. The document is well-written and ready to advance. David Harrington ietfdbh@comcast.net +1-603-828-1401 From nobody Thu Mar 27 14:48:40 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71AC1A06F6; Thu, 27 Mar 2014 14:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIbg1J87pdec; Thu, 27 Mar 2014 14:48:31 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [132.250.118.211]) by ietfa.amsl.com (Postfix) with ESMTP id DA9FB1A03DA; Thu, 27 Mar 2014 14:48:30 -0700 (PDT) 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 s2RLmRF9018702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 27 Mar 2014 17:48:28 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_444A3BA6-0CCC-44A0-A744-4D52479BCF3E" Date: Thu, 27 Mar 2014 17:48:27 -0400 Message-Id: <05273ED7-A4DE-4A14-8754-BC228FC036F6@nrl.navy.mil> To: secdir@ietf.org, iesg@ietf.org, draft-ietf-dmm-requirements.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/C7F2H-ed54Xv2xWGoDVUnmI8_mo Subject: [secdir] review of draft-ietf-dmm-requirements-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 21:48:38 -0000 --Apple-Mail=_444A3BA6-0CCC-44A0-A744-4D52479BCF3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The authors have not only implemented the changes I suggested but have improved on my suggestions, so I have no further recommendations. Sorry, Anthony, that I missed your email. I need to set up some sort of = alert system to notify me of replies to my reviews. Cathy 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=_444A3BA6-0CCC-44A0-A744-4D52479BCF3E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The authors have not only implemented the changes I suggested but have
improved on my suggestions, so I have no further recommendations.


Sorry, Anthony, that I missed your email.  I need to set up some sort of alert system to
notify me of replies to my reviews.

Cathy

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=_444A3BA6-0CCC-44A0-A744-4D52479BCF3E-- From nobody Fri Mar 28 11:35:00 2014 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 639D01A0979; Fri, 28 Mar 2014 11:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1396031551; bh=elKZaep/DOLU42rccRcNFbrcN6vrhzG6Ygm1IKcCjwY=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=b/EGzEJk9uL6SWeQiYrhONDc0R9kss0nT9/m6pMec4aH0r7XJoe1H8TyBIgyIFvAv HCFkcKsfReXcVhFkLCxLW/+nDXK+gPEd+VJ+E5s9s8Bjolb6hzFgfoWtp+vMQXe0Ju 4HGHqQAv30BsSwz7Ln7HznHKg9GjAaodRwwY1cHU= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845A51A0959; Fri, 28 Mar 2014 11:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk1KE8_Hswlp; Fri, 28 Mar 2014 11:32:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E12DC1A0961; Fri, 28 Mar 2014 11:32:25 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140328183225.28807.36480.idtracker@ietfa.amsl.com> Date: Fri, 28 Mar 2014 11:32:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/new-work/Iae-RpUof8rQnlYIm_D6PVnrtAE X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.15 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vgjOJpEYVJeMH47efoFhY159bGA X-Mailman-Approved-At: Fri, 28 Mar 2014 11:34:57 -0700 Subject: [secdir] [new-work] WG Review: DiffServ Applied to RTP Transports (dart) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:32:31 -0000 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-04-07. DiffServ Applied to RTP Transports (dart) ------------------------------------------------ Current Status: Proposed WG Chairs: Ben Campbell Technical advisors: Martin Stiemerling Assigned Area Director: Richard Barnes Mailing list Address: dart@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dart Archive: http://www.ietf.org/mail-archive/web/dart/ Charter: DART - DiffServ Applied to Real-time Transports Differentiated Services (DiffServ) and DiffServ code points (DSCP) can be used in some situations to provide quality of service (QoS). Packets with different markings can be reordered, which can cause poor interaction with a transport protocol that is sensitive to reordering. When RTP streams or other real-time media (sub-)flows are used with different DSCP values with the same transport 5-tuple, there may be transport protocol interactions. There are also environments where the DSCP markings are removed or remarked. This WG will write a document that explains the limitations that exist with DiffServ when used with RTP in general as well in the specific RTCWeb cases. The WG will coordinate with relevant WGs, including TSVWG, AVTCORE, MMUSIC, CLUE, RTCWEB, and RMCAT. Milestones: Aug 2014 - Send Informational draft to IESG on DiffServ usage consideration Milestones: _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Sun Mar 30 13:45:03 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BB41A08D5 for ; Sun, 30 Mar 2014 13:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEw2PiX2Qrte for ; Sun, 30 Mar 2014 13:45:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AE2711A07D7 for ; Sun, 30 Mar 2014 13:45:00 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2UKitbQ010514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 30 Mar 2014 13:44:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6FF53033-2513-4672-8EE1-52483DE6F114@vpnc.org> Date: Sun, 30 Mar 2014 13:44:54 -0700 To: secdir Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Heq67q87cPrImJGxFDWhSGswcC0 Subject: [secdir] Secdir review of draft-ietf-mpls-lsp-ping-ttl-tlv X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 20:45:02 -0000 This draft describes adding a TTL to MPLS LSP pings. There are no = significant security considerations to this protocol addition. The = Security Considerations section talks about the possibility of a DoS = based on this new attribute, but also acknowledges that the the same DoS = was already possible. So: no security concerns at all. --Paul Hoffman= From nobody Sun Mar 30 15:31:03 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945451A07DF; Sun, 30 Mar 2014 15:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSBB-AR_7uwj; Sun, 30 Mar 2014 15:30:58 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0381A0344; Sun, 30 Mar 2014 15:30:58 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2UMUnI0007780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 30 Mar 2014 22:30:52 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2UMUmeu003920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Mar 2014 22:30:49 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2UMUmBJ003917; Sun, 30 Mar 2014 22:30:48 GMT Received: from [10.159.126.144] (/10.159.126.144) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 30 Mar 2014 15:30:48 -0700 Message-ID: <53389B18.9060305@oracle.com> Date: Sun, 30 Mar 2014 16:30:48 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140222 Thunderbird/17.0.6 MIME-Version: 1.0 To: secdir@ietf.org References: <52DEB7D6.6050308@oracle.com> In-Reply-To: <52DEB7D6.6050308@oracle.com> Content-Type: multipart/alternative; boundary="------------030306010200060501040800" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/9o3I_Y2UcjY-4xUK544KpY4Eiyc Cc: iesg@ietf.org, draft-ietf-tcpm-fastopen.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-tcpm-fastopen-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 22:31:00 -0000 This is a multi-part message in MIME format. --------------030306010200060501040800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This experimental draft describes a way for TCP to include data in the SYN and SYN-ACK exchanges when establishing an initial connection. As you've probably already guessed there are number security ramifications with this feature. One is that the server applications receive the SYN packet before the three-way handshake is complete. This opens up various DoS attacks that would otherwise be thwarted by TCP filtering, receive queues, etc. The proposed solution against such attacks involves a server derived MAC that the client requests during a TCP connection establishment. The client subsequently uses this MAC in subsequent three-way handshakes with the server. The security considerations section does exist and reiterates the DoS attacks that this protocol opens. To help prevent DoS attacks the server keeps track of pending requests and compares this against PendingFastOpenRequests in order to limit resources taken by an attacker. If the limit is exceeded then the protocol reverts to regular TCP, which has the traditional techniques to thwart SYN floods. The section goes on to state that another possible attack would be to trick a number of servers to send a large response to an unsuspecting host. It prescribes that the server could not respond with data until the handshake completes. I believe the various risks associated with this protocol are outlined in the draft and provides sufficient techniques for mitigating against such attacks. General comments: None. Editorial comments: s/cause firewall/causing firewall/ s/case it may/cases it may/ Shawn. -- --------------030306010200060501040800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments just like any other last call comments.

This experimental draft describes a way for TCP to include data in the SYN and SYN-ACK
exchanges when establishing an initial connection.  As you've probably already guessed
there are number security ramifications with this feature.  One is that the server
applications receive the SYN packet before the three-way handshake is complete.
This opens up various DoS attacks that would otherwise be thwarted by TCP filtering,
receive queues, etc.

The proposed solution against such attacks involves a server derived MAC that the client
requests during a TCP connection establishment.  The client subsequently uses this MAC in
subsequent three-way handshakes with the server.  

The security considerations section does exist and reiterates the DoS attacks that this
protocol opens.  To help prevent DoS attacks the server keeps track of pending requests
and compares this against PendingFastOpenRequests in order to limit resources taken by
an attacker.  If the limit is exceeded then the protocol reverts to regular TCP, which
has the traditional techniques to thwart SYN floods.  The section goes on to state that another
possible attack would be to trick a number of servers to send a large response to an unsuspecting
host.  It prescribes that the server could not respond with data until the handshake completes.
I believe the various risks associated with this protocol are outlined in the draft and provides
sufficient techniques for mitigating against such attacks.

General comments:

None.

Editorial comments:

s/cause firewall/causing firewall/
s/case it may/cases it may/

Shawn.
--
--------------030306010200060501040800-- From nobody Mon Mar 31 03:22:03 2014 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79ABE1A096E for ; Sun, 30 Mar 2014 23:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0ccyg72Tq0a for ; Sun, 30 Mar 2014 23:49:10 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6F91A0444 for ; Sun, 30 Mar 2014 23:49:09 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s2V6n2Ic006178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 31 Mar 2014 01:49:06 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s2V6n1l9030910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Mar 2014 08:49:02 +0200 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.224]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 31 Mar 2014 08:49:01 +0200 From: "Scharf, Michael (Michael)" To: Shawn M Emery , "secdir@ietf.org" Thread-Topic: Review of draft-ietf-tcpm-fastopen-08 Thread-Index: AQHPTGgGVJ4kIXErBE2cItqpXr9aeJr6wCKo Date: Mon, 31 Mar 2014 06:49:00 +0000 Message-ID: <655C07320163294895BBADA28372AF5D26343D@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <52DEB7D6.6050308@oracle.com>,<53389B18.9060305@oracle.com> In-Reply-To: <53389B18.9060305@oracle.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.132.188.47] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D26343DFR712WXCHMBA15zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/hwRz45DZfUJWTRmOH2jrpKAwDKg X-Mailman-Approved-At: Mon, 31 Mar 2014 03:22:01 -0700 Cc: "draft-ietf-tcpm-fastopen.all@tools.ietf.org" Subject: Re: [secdir] Review of draft-ietf-tcpm-fastopen-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 06:49:12 -0000 --_000_655C07320163294895BBADA28372AF5D26343DFR712WXCHMBA15zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Shawn, Many thanks for your early SECDIR review! I'll then move the document forward to the AD/IESG. Best regards Michael ________________________________ Von: Shawn M Emery [shawn.emery@oracle.com] Gesendet: Montag, 31. M=E4rz 2014 00:30 An: secdir@ietf.org Cc: draft-ietf-tcpm-fastopen.all@tools.ietf.org; iesg@ietf.org Betreff: Review of draft-ietf-tcpm-fastopen-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. This experimental draft describes a way for TCP to include data in the SYN = and SYN-ACK exchanges when establishing an initial connection. As you've probably alre= ady guessed there are number security ramifications with this feature. One is that the= server applications receive the SYN packet before the three-way handshake is compl= ete. This opens up various DoS attacks that would otherwise be thwarted by TCP f= iltering, receive queues, etc. The proposed solution against such attacks involves a server derived MAC th= at the client requests during a TCP connection establishment. The client subsequently us= es this MAC in subsequent three-way handshakes with the server. The security considerations section does exist and reiterates the DoS attac= ks that this protocol opens. To help prevent DoS attacks the server keeps track of pend= ing requests and compares this against PendingFastOpenRequests in order to limit resourc= es taken by an attacker. If the limit is exceeded then the protocol reverts to regular= TCP, which has the traditional techniques to thwart SYN floods. The section goes on t= o state that another possible attack would be to trick a number of servers to send a large respo= nse to an unsuspecting host. It prescribes that the server could not respond with data until the = handshake completes. I believe the various risks associated with this protocol are outlined in t= he draft and provides sufficient techniques for mitigating against such attacks. General comments: None. Editorial comments: s/cause firewall/causing firewall/ s/case it may/cases it may/ Shawn. -- --_000_655C07320163294895BBADA28372AF5D26343DFR712WXCHMBA15zeu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Shawn,

Many thanks for your early SECDIR review!

I'll then move the document forward to the AD/IESG.

Best regards

Michael


Von: Shawn M Emery [shawn.emery@oracle.co= m]
Gesendet: Montag, 31. M=E4rz 2014 00:30
An: secdir@ietf.org
Cc: draft-ietf-tcpm-fastopen.all@tools.ietf.org; iesg@ietf.org
Betreff: Review of draft-ietf-tcpm-fastopen-08


I have reviewed this document as part of the security directorate's=0A=
ongoing effort to review all IETF documents being processed by the IESG.=0A=
These comments were written primarily for the benefit of the security=0A=
area directors. Document editors and WG chairs should treat these=0A=
comments just like any other last call comments.=0A=
=0A=
This experimental draft describes a way for TCP to include data in the SYN =
and SYN-ACK=0A=
exchanges when establishing an initial connection.  As you've probably alre=
ady guessed=0A=
there are number security ramifications with this feature.  One is that the=
 server=0A=
applications receive the SYN packet before the three-way handshake is compl=
ete.=0A=
This opens up various DoS attacks that would otherwise be thwarted by TCP f=
iltering,=0A=
receive queues, etc.=0A=
=0A=
The proposed solution against such attacks involves a server derived MAC th=
at the client=0A=
requests during a TCP connection establishment.  The client subsequently us=
es this MAC in=0A=
subsequent three-way handshakes with the server.  =0A=
=0A=
The security considerations section does exist and reiterates the DoS attac=
ks that this=0A=
protocol opens.  To help prevent DoS attacks the server keeps track of pend=
ing requests=0A=
and compares this against PendingFastOpenRequests in order to limit resourc=
es taken by=0A=
an attacker.  If the limit is exceeded then the protocol reverts to regular=
 TCP, which=0A=
has the traditional techniques to thwart SYN floods.  The section goes on t=
o state that another=0A=
possible attack would be to trick a number of servers to send a large respo=
nse to an unsuspecting=0A=
host.  It prescribes that the server could not respond with data until the =
handshake completes.=0A=
I believe the various risks associated with this protocol are outlined in t=
he draft and provides=0A=
sufficient techniques for mitigating against such attacks.=0A=
=0A=
General comments:=0A=
=0A=
None.=0A=
=0A=
Editorial comments:=0A=
=0A=
s/cause firewall/causing firewall/=0A=
s/case it may/cases it may/=0A=
=0A=
Shawn.=0A=
--=0A=
--_000_655C07320163294895BBADA28372AF5D26343DFR712WXCHMBA15zeu_--