From lionel.morand@orange.com Wed Feb 27 10:58:21 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB2121F8475; Wed, 27 Feb 2013 10:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uzf7elcObj2q; Wed, 27 Feb 2013 10:58:21 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 821B221F8484; Wed, 27 Feb 2013 10:58:17 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9ABB322C98A; Wed, 27 Feb 2013 19:58:13 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 78DE9238048; Wed, 27 Feb 2013 19:58:13 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 27 Feb 2013 19:58:13 +0100 From: To: "Moriarty, Kathleen" Thread-Topic: New Version Notification - draft-ietf-dime-rfc4005bis-12.txt Thread-Index: AQHN6Y/jxTTym83mXk6wAvdtF+e3F5g3RoIAgFcb0OA= Date: Wed, 27 Feb 2013 18:58:11 +0000 Message-ID: <28616_1361991493_512E5745_28616_3052_1_6B7134B31289DC4FAF731D844122B36E13D014@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20130103085355.3332.87241.idtracker@ietfa.amsl.com> <50E55018.70108@gmail.com> In-Reply-To: <50E55018.70108@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.27.154817 X-Mailman-Approved-At: Fri, 01 Mar 2013 08:54:26 -0800 Cc: "bclaise@cisco.com" , Jouni Korhonen , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] New Version Notification - draft-ietf-dime-rfc4005bis-12.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:58:21 -0000 SGkgS2F0aGxlZW4sDQoNCkFmdGVyIHlvdXIgaW5pdGlhbCByZXZpZXcsIHRoZSBkaXNjdXNzaW9u IHdhcyBzdG9wcGVkIGFmdGVyIEdsZW4ncyBhbnN3ZXIuIFNvIHdlIGRvbid0IGtub3cgaWYgaXQg b2sgZm9yIHlvdSBvciBub3QuIEJhc2VkIG9uIHRoZSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQs IGRvIHlvdSBtYWludGFpbiB5b3VyIGlzc3VlcyBvciBjb3VsZCB3ZSBjbG9zZSB0aGVtPyBXZSBu ZWVkIHRvIG1vdmUgb24gd2l0aCB0aGlzIGRyYWZ0Lg0KDQpSZWdhcmRzLA0KDQpMaW9uZWwNCiAN Cg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBHbGVuIFpvcm4gW21haWx0bzpn bGVuem9ybkBnbWFpbC5jb21dIA0KRW52b3nDqcKgOiBqZXVkaSAzIGphbnZpZXIgMjAxMyAxMDoz Mg0Kw4DCoDogYmNsYWlzZUBjaXNjby5jb20NCkNjwqA6IFBldGVyIFNhaW50LUFuZHJlOyBkaW1l LWNoYWlyc0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1kaW1lLXJmYzQwMDViaXNAdG9vbHMu aWV0Zi5vcmc7IGdsZW56b3JuQGdtYWlsLmNvbTsgQmxhY2ssIERhdmlkDQpPYmpldMKgOiBSZTog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIC0gZHJhZnQtaWV0Zi1kaW1lLXJmYzQwMDViaXMtMTIu dHh0DQoNCkkgYmVsaWV2ZSB0aGF0IHRoaXMgcmV2IHJlc29sdmVzIGFsbCBvdXRzdGFuZGluZyBp c3N1ZXMuDQoNCk9uIDAxLzAzLzIwMTMgMDM6NTMgUE0sIGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyB3cm90ZToNCj4gQSBuZXcgdmVyc2lvbiAoLTEyKSBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIGRy YWZ0LWlldGYtZGltZS1yZmM0MDA1YmlzOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLWRpbWUtcmZjNDAwNWJpcy0xMi50eHQNCj4NCj4NCj4gVGhlIElF VEYgZGF0YXRyYWNrZXIgcGFnZSBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaW1lLXJmYzQwMDViaXMvDQo+ DQo+IERpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRpbWUtcmZjNDAwNWJpcy0xMg0KPg0KPiBJRVRGIFNlY3Jl dGFyaWF0Lg0KPg0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRl dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJv bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCkZyYW5jZSBUZWxlY29tIC0g T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4K VGhhbmsgeW91LgoK From stephen.farrell@cs.tcd.ie Mon Mar 4 09:27:00 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0372A21F8D1A for ; Mon, 4 Mar 2013 09:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9eZMIq4yb5s for ; Mon, 4 Mar 2013 09:26:56 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 145BB21F8D14 for ; Mon, 4 Mar 2013 09:26:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 89CECBE70 for ; Mon, 4 Mar 2013 17:26:32 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TCHrkne+I4g for ; Mon, 4 Mar 2013 17:26:32 +0000 (GMT) Received: from [IPv6:2001:770:10:203:4179:befb:7c4a:b956] (unknown [IPv6:2001:770:10:203:4179:befb:7c4a:b956]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 32A80BE6F for ; Mon, 4 Mar 2013 17:26:32 +0000 (GMT) Message-ID: <5134D949.4090206@cs.tcd.ie> Date: Mon, 04 Mar 2013 17:26:33 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "secdir@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] ADs and directorates X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 17:27:00 -0000 Hi, I'm sure some of you are following the discussion on the IETF discuss list about the transport area and the difficulty in finding an AD for that. (Thread starts at [1]). Some people are asking things like "could directorates help reduce the time commitment of ADs" and of course secdir are the poster-child good directorate (thanks again!) so Sean and I would like to get your opinions about that, as it might relate to secdir, at the lunch next week. (Or via mail if you won't be there.) Just as an example, some people are suggesting that directorates might take on more of the AD role, so for secdir, do you think that's crazy, worth-a-look, a really good idea, or something else? We're not proposing to actually do anything right now, but it'd be good if Sean and I knew what you folks think about such suggestions as they relate to the security area. Your more general thoughts would of course also be useful, but are probably better sent to the IETF discussion list. Thanks, S. [1] http://www.ietf.org/mail-archive/web/ietf/current/msg77418.html From turners@ieca.com Mon Mar 4 14:03:24 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8A821F870C for ; Mon, 4 Mar 2013 14:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pT7M3Yc3R1N9 for ; Mon, 4 Mar 2013 14:03:23 -0800 (PST) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.93.179.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5175F21F86D4 for ; Mon, 4 Mar 2013 14:03:23 -0800 (PST) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 77DF86C18FE4D; Mon, 4 Mar 2013 16:03:20 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 67F776C18FE1C for ; Mon, 4 Mar 2013 16:03:20 -0600 (CST) Received: from [108.45.16.214] (port=57667 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UCdTe-0001pj-Mi for secdir@ietf.org; Mon, 04 Mar 2013 16:03:22 -0600 Message-ID: <51351A2A.8080907@ieca.com> Date: Mon, 04 Mar 2013 17:03:22 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.16.214]:57667 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [secdir] really early review of draft-huang-netmod-acl X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 22:03:24 -0000 The nedmod WG hasn't yet adopted this draft, but in case anybody is in need of some reading material on their trip to Orlando please feel free to review (https://datatracker.ietf.org/doc/draft-huang-netmod-acl/), which a YANG model that allows to configure ACLs. spt From leifj@sunet.se Mon Mar 4 17:07:36 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D761F0D0F for ; Mon, 4 Mar 2013 17:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3B6fS5vle0Bn for ; Mon, 4 Mar 2013 17:07:36 -0800 (PST) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by ietfa.amsl.com (Postfix) with ESMTP id BC80311E80AE for ; Mon, 4 Mar 2013 17:07:35 -0800 (PST) Received: from [192.168.1.149] ([150.100.253.2]) (authenticated bits=0) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r2517JZA029626 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 5 Mar 2013 01:07:29 GMT Message-ID: <51354547.2070800@sunet.se> Date: Tue, 05 Mar 2013 02:07:19 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: secdir@ietf.org References: <5134D949.4090206@cs.tcd.ie> In-Reply-To: <5134D949.4090206@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] ADs and directorates X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 01:07:36 -0000 On 03/04/2013 06:26 PM, Stephen Farrell wrote: > Hi, > > I'm sure some of you are following the discussion on > the IETF discuss list about the transport area and > the difficulty in finding an AD for that. (Thread > starts at [1]). > > Some people are asking things like "could directorates > help reduce the time commitment of ADs" and of course > secdir are the poster-child good directorate (thanks > again!) so Sean and I would like to get your opinions > about that, as it might relate to secdir, at the lunch > next week. (Or via mail if you won't be there.) > > Just as an example, some people are suggesting that > directorates might take on more of the AD role, so > for secdir, do you think that's crazy, worth-a-look, > a really good idea, or something else? That actually sounds a bit crazy to me. The AD role is mainly a leadership role which makes it really had to split 20 odd ways :-) I would imagine that synchronizing between 2-3 ADs pose enough of a challenge as it is. > > We're not proposing to actually do anything right > now, but it'd be good if Sean and I knew what you > folks think about such suggestions as they relate > to the security area. > > Your more general thoughts would of course also be > useful, but are probably better sent to the IETF > discussion list. > > Thanks, > S. > > [1] http://www.ietf.org/mail-archive/web/ietf/current/msg77418.html > From kent@bbn.com Wed Mar 6 07:40:11 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04D521F86FF for ; Wed, 6 Mar 2013 07:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovcRyvXLgaP6 for ; Wed, 6 Mar 2013 07:40:10 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 634E721F89BF for ; Wed, 6 Mar 2013 07:40:10 -0800 (PST) Received: from dhcp89-089-230.bbn.com ([128.89.89.230]:51357) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UDGRm-000K43-NJ; Wed, 06 Mar 2013 10:40:02 -0500 Message-ID: <51376352.5050802@bbn.com> Date: Wed, 06 Mar 2013 10:40:02 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: secdir , chris.dearlove@baesystems.com, T.Clausen@computer.org, philippe.jacquet@alcatel-lucent.com, macker@itd.nrl.navy.mil, sratliff@cisco.com, Stewart Bryant , Adrian Farrel Content-Type: multipart/alternative; boundary="------------000303060604020406000009" Subject: [secdir] SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 15:40:12 -0000 This is a multi-part message in MIME format. --------------000303060604020406000009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors and WG chairs should treat these comments just like any other last call comments. This document is targeted as an Informational RFC. It describes itself as "... an historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2." The Security Considerations section says simply "This document does not specify any security considerations." It's been a very long time (many years) since I've encountered that phrase in a candidate RFC. A rationale document itself probably does not entail security considerations, but the omission of any security discussion suggests that security did not play a role in the deign of this routing protocol. Is that true? If so, who thinks this is a good thing? I looked at the I-D that defines OLSRv2. It contains a two-page Security Considerations section. From my perspective, this document ought to provide background info (rationale) for the security suggestions contained that document. --------------000303060604020406000009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02

 

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

 

This document is targeted as an Informational RFC. It describes itself as “… an historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2.”

 

The Security Considerations section says simply “This document does not specify any security considerations.” It’s been a very long time (many years) since I’ve encountered that phrase in a candidate RFC. A rationale document itself probably does not entail security considerations, but the omission of any security discussion suggests that security did not play a role in the deign of this routing protocol. Is that true? If so, who thinks this is a good thing?

 

I looked at the I-D that defines OLSRv2. It contains a two-page Security Considerations section. From my perspective, this document ought to provide background info (rationale) for the security suggestions contained that document.

--------------000303060604020406000009-- From kathleen.moriarty@emc.com Wed Mar 6 07:50:32 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C819121F8A55 for ; Wed, 6 Mar 2013 07:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekXuhaMPXqOC for ; Wed, 6 Mar 2013 07:50:32 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2978621F8AAC for ; Wed, 6 Mar 2013 07:50:31 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r26FoUBQ016634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Mar 2013 10:50:31 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 6 Mar 2013 10:50:16 -0500 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r26FoF97022298; Wed, 6 Mar 2013 10:50:15 -0500 Received: from mx15a.corp.emc.com ([169.254.1.118]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Wed, 6 Mar 2013 10:50:14 -0500 From: "Moriarty, Kathleen" To: Leif Johansson , "secdir@ietf.org" Date: Wed, 6 Mar 2013 10:50:13 -0500 Thread-Topic: [secdir] ADs and directorates Thread-Index: Ac4ZPd3CTwXl1K6ST/mOQ2gY5rPlYwBQ+WSg Message-ID: References: <5134D949.4090206@cs.tcd.ie> <51354547.2070800@sunet.se> In-Reply-To: <51354547.2070800@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [secdir] ADs and directorates X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 15:50:32 -0000 I've been talking about this with a colleague who is active in transport. = Rather than not have a second AD, I really don't see why they don't use a d= irectorate to fill the gaps in knowledge from the selected candidate (they = went through at least 5-6 already). They are already talking about trainin= g on congestion control to prepare more future candidates, so a stop-gap so= lution seems very reasonable to me. It will be a lot of work for one AD to= run TSV and then without a directorate... in addition to a day job (at lea= st part time). My .02 -Kathleen -----Original Message----- From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf Of= Leif Johansson Sent: Monday, March 04, 2013 8:07 PM To: secdir@ietf.org Subject: Re: [secdir] ADs and directorates On 03/04/2013 06:26 PM, Stephen Farrell wrote: > Hi, > > I'm sure some of you are following the discussion on > the IETF discuss list about the transport area and > the difficulty in finding an AD for that. (Thread > starts at [1]). > > Some people are asking things like "could directorates > help reduce the time commitment of ADs" and of course > secdir are the poster-child good directorate (thanks > again!) so Sean and I would like to get your opinions > about that, as it might relate to secdir, at the lunch > next week. (Or via mail if you won't be there.) > > Just as an example, some people are suggesting that > directorates might take on more of the AD role, so > for secdir, do you think that's crazy, worth-a-look, > a really good idea, or something else? That actually sounds a bit crazy to me. The AD role is mainly a leadership role which makes it really had to split 20 odd ways :-) I would imagine that synchronizing between 2-3 ADs pose enough of a challenge as it is. > > We're not proposing to actually do anything right > now, but it'd be good if Sean and I knew what you > folks think about such suggestions as they relate > to the security area. > > Your more general thoughts would of course also be > useful, but are probably better sent to the IETF > discussion list. > > Thanks, > S. > > [1] http://www.ietf.org/mail-archive/web/ietf/current/msg77418.html > _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From kent@bbn.com Wed Mar 6 09:02:42 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA8321F8C93 for ; Wed, 6 Mar 2013 09:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJvVG1OSUo07 for ; Wed, 6 Mar 2013 09:02:38 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAE821F8C96 for ; Wed, 6 Mar 2013 09:02:38 -0800 (PST) Received: from dhcp89-089-230.bbn.com ([128.89.89.230]:51634) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UDHjd-000MEO-KJ; Wed, 06 Mar 2013 12:02:33 -0500 Message-ID: <513776A9.2040906@bbn.com> Date: Wed, 06 Mar 2013 12:02:33 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <51376352.5050802@bbn.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080708070005050206070908" Cc: "T.Clausen@computer.org" , secdir , "philippe.jacquet@alcatel-lucent.com" , "sratliff@cisco.com" , Adrian Farrel , "macker@itd.nrl.navy.mil" , Stewart Bryant Subject: Re: [secdir] SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:02:42 -0000 This is a multi-part message in MIME format. --------------080708070005050206070908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Christopher, Sorry for my mischaracterization of the scope of this doc. So, you are saying that there are no security considerations relevant to the choice of metrics? Steve On 3/6/13 11:37 AM, Dearlove, Christopher (UK) wrote: > > Please note that this is not a rationale of OLSRv2. > > This is a rationale of how metrics were added to OLSRv2, a small > subset of the complete OLSRv2 functionality. > > There were of course security considerations in the design of OLSRv2, > but this is not that document. > > -- > > Christopher Dearlove > > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > > chris.dearlove@baesystems.com | > http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace > Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > *From:*Stephen Kent [mailto:kent@bbn.com] > *Sent:* 06 March 2013 15:40 > *To:* secdir; Dearlove, Christopher (UK); T.Clausen@computer.org; > philippe.jacquet@alcatel-lucent.com; macker@itd.nrl.navy.mil; > sratliff@cisco.com; Stewart Bryant; Adrian Farrel > *Subject:* SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 > > **** WARNING **** > > /This message originates from outside our organisation, either from an > external partner or the internet.// > /Keep this in mind if you answer this message./ > /Please see this process > > on how to deal with suspicious emails.// > > SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 > > I reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > This document is targeted as an Informational RFC. It describes itself > as "... an historic record of the rationale for, and design > considerations behind, how link metrics were included in OLSRv2." > > The Security Considerations section says simply "This document does > not specify any security considerations." It's been a very long time > (many years) since I've encountered that phrase in a candidate RFC. A > rationale document itself probably does not entail security > considerations, but the omission of any security discussion suggests > that security did not play a role in the deign of this routing > protocol. Is that true? If so, who thinks this is a good thing? > > I looked at the I-D that defines OLSRv2. It contains a two-page > Security Considerations section. From my perspective, this document > ought to provide background info (rationale) for the security > suggestions contained that document. > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > --------------080708070005050206070908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Christopher,

Sorry for my mischaracterization of the scope of this doc.

So, you are saying that there are no security considerations relevant to the choice of metrics?

Steve

On 3/6/13 11:37 AM, Dearlove, Christopher (UK) wrote:

Please note that this is not a rationale of OLSRv2.

 

This is a rationale of how metrics were added to OLSRv2, a small subset of the complete OLSRv2 functionality.

 

There were of course security considerations in the design of OLSRv2, but this is not that document.

 

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: 06 March 2013 15:40
To: secdir; Dearlove, Christopher (UK); T.Clausen@computer.org; philippe.jacquet@alcatel-lucent.com; macker@itd.nrl.navy.mil; sratliff@cisco.com; Stewart Bryant; Adrian Farrel
Subject: SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02

 

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

 

This document is targeted as an Informational RFC. It describes itself as “… an historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2.”

 

The Security Considerations section says simply “This document does not specify any security considerations.” It’s been a very long time (many years) since I’ve encountered that phrase in a candidate RFC. A rationale document itself probably does not entail security considerations, but the omission of any security discussion suggests that security did not play a role in the deign of this routing protocol. Is that true? If so, who thinks this is a good thing?

 

I looked at the I-D that defines OLSRv2. It contains a two-page Security Considerations section. From my perspective, this document ought to provide background info (rationale) for the security suggestions contained that document.


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************


--------------080708070005050206070908-- From new-work-bounces@ietf.org Tue Mar 5 10:37:08 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CBB11E8101; Tue, 5 Mar 2013 10:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1362508628; bh=utu1c3LlXJL0TOh6gmrqYiKV5Ev7f4oJAAaA5QQlelQ=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=JrdMe9mZoTFh5bhWh//kzhbK4hmcHFGIm4wgMR1t4e4Hahu31VHf6YdhA/EgfDMrD vdYjjU+Qv3UATrpFOX+3SE59YKoyvLGVuG11gjmRfj3tMB3vnjrS51bMwcYJXt7gBI K/1NXABThsimB9W2zhA/7FXJ1a2ADivI6Sf2WE1I= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C362011E8101; Tue, 5 Mar 2013 10:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRe5+xFwIUAs; Tue, 5 Mar 2013 10:37:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 277E211E80AD; Tue, 5 Mar 2013 10:37:07 -0800 (PST) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.41 Message-ID: <20130305183707.8732.55346.idtracker@ietfa.amsl.com> Date: Tue, 05 Mar 2013 10:37:07 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 06 Mar 2013 10:24:20 -0800 Subject: [secdir] [new-work] WG Review: Hypertext Transmission Protocol Authentication (httpauth) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 18:37:09 -0000 A new IETF working group has been proposed in the Security 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 2013-03-12. Hypertext Transmission Protocol Authentication (httpauth) ------------------------------------------------ Current Status: Proposed Working Group Chairs: TBD Assigned Area Director: Sean Turner Mailing list Address: http-auth@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/http-auth Archive: http://www.ietf.org/mail-archive/web/http-auth/ Charter of Working Group: Authentication of users to servers over HTTP has always been a weak point in web services. The current HTTP authentication mechanisms, basic and digest, pass the credentials in the clear or employ weak algorithms and are considered to be insecure today. Authentication through non-standard web forms is much more commonly used, but also pass the credentials in the clear. There is a need for improved mechanisms that can replace or augment HTTP authentication without the need to rely on transport layer security. Only HTTP authentication is in scope for this WG; form-based or "web" authentication is out of scope. The httpauth WG will be a short-lived working group that will document a small number of HTTP user authentication schemes that might offer security benefits, and that could, following experimentation, be widely adopted as standards-track schemes for HTTP user authentication. Each of these RFCs will be Informational or Experimental, and should include a description of when use of its mechanism is appropriate, via a use-case or other distinguishing characteristics. Standards track solutions for HTTP Authentication schemes are out of scope, as none of the proposals are expected to be sufficiently widely deployed to warrant that status before the WG closes. All schemes to be developed in the httpauth WG must be usable with the existing HTTP authentication framework, or with evolutions of that framework as developed in the httpbis WG. That is, the evolution of the HTTP authentication framework is to be done in the httpbis WG and not in the httpauth WG. The httpauth WG will work closely with the httpbis WG to ensure that the outcomes from the httpauth WG do not conflict with work done elsewhere. The drafts currently under consideration as WG items include: - draft-williams-http-rest-auth - draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension - draft-farrell-httpbis-hoba - draft-montenegro-httpbis-multilegged-auth - draft-melnikov-httpbis-scram-auth The WG will produce two standards track documents that will obsolete the basic and digest schemes defined in RFC 2617 taking into account errata on that specification. For the digest scheme, the new specification will incorporate "more modern" algorithm agility and internationalization support, which requires input from internationalization experts. draft-ahrens-httpbis-digest-auth-update documents one possible approach that the WG could adopt and modify as it sees fit. For the basic scheme, no technical changes are envisaged other than to handle internationalization of usernames and passwords. The goal is to improve the scheme's documentation and to obsolete RFC 2617, which has some significant flaws that have emerged through 13 years of experience. The WG is not required to merge all proposals into one. The goal is not to produce "perfect" mechanisms, but to review and improve proposals and to quickly produce stable specifications for the purpose of obtaining implementation and deployment experience. The working group will then close, and any further culling or refinement of the experimental mechanisms will be done in another context. It is expected that the market/community will select which if any of the RFCs developed might be worth progressing on the standards-track at a later date, in a different WG. Adoption of additional work items is not expected and will require a re-charter. The following are explicitly out of scope: - changes to TLS - changes to HTTP, except for those made in the httpbis WG - definition of authentication mechanisms that do not work with the HTTP authentication framework - authentication schemes that distinguish between devices and humans - authentication schemes that cannot be sensibly used for and by humans - "web" authentication that is not HTTP authentication Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From Chris.Dearlove@baesystems.com Wed Mar 6 08:37:33 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32E921F8CCA for ; Wed, 6 Mar 2013 08:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuTo3J17TUJk for ; Wed, 6 Mar 2013 08:37:31 -0800 (PST) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9708521F8CD0 for ; Wed, 6 Mar 2013 08:37:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,795,1355097600"; d="scan'208,217";a="317375250" Received: from unknown (HELO baemasmds010.greenlnk.net) ([141.245.68.247]) by baemasmds003ir.sharelnk.net with ESMTP; 06 Mar 2013 16:37:29 +0000 Received: from baemasmds017.greenlnk.net ([10.15.207.104]) by baemasmds010.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id r26GbTPR003034 for ; Wed, 6 Mar 2013 16:37:29 GMT X-IronPort-AV: E=Sophos;i="4.84,795,1355097600"; d="scan'208,217";a="9870558" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 06 Mar 2013 16:37:29 +0000 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.173]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.02.0328.009; Wed, 6 Mar 2013 16:37:29 +0000 From: "Dearlove, Christopher (UK)" To: Stephen Kent , secdir , "T.Clausen@computer.org" , "philippe.jacquet@alcatel-lucent.com" , "macker@itd.nrl.navy.mil" , "sratliff@cisco.com" , Stewart Bryant , Adrian Farrel Thread-Topic: SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 Thread-Index: AQHOGoDygRfcmtRVNE2Ns5BnbZoekZiY3Bhw Date: Wed, 6 Mar 2013 16:37:28 +0000 Message-ID: References: <51376352.5050802@bbn.com> In-Reply-To: <51376352.5050802@bbn.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D2502C92BGLKXM0002VGREEN_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 06 Mar 2013 10:24:20 -0800 Subject: Re: [secdir] SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 16:37:33 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D2502C92BGLKXM0002VGREEN_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please note that this is not a rationale of OLSRv2. This is a rationale of how metrics were added to OLSRv2, a small subset of the complete OLSRv2 functionality. There were of course security considerations in the design of OLSRv2, but this is not that document. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Stephen Kent [mailto:kent@bbn.com] Sent: 06 March 2013 15:40 To: secdir; Dearlove, Christopher (UK); T.Clausen@computer.org; philippe.jacquet@alcatel-lucent.com; macker@itd.nrl.navy.mil; sratliff@cisco.com; Stewart Bryant; Adrian Farrel Subject: SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Keep this in mind if you answer this message. Please see this process on how to deal with suspicious emails. SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is targeted as an Informational RFC. It describes itself as "... an historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2." The Security Considerations section says simply "This document does not specify any security considerations." It's been a very long time (many years) since I've encountered that phrase in a candidate RFC. A rationale document itself probably does not entail security considerations, but the omission of any security discussion suggests that security did not play a role in the deign of this routing protocol. Is that true? If so, who thinks this is a good thing? I looked at the I-D that defines OLSRv2. It contains a two-page Security Considerations section. From my perspective, this document ought to provide background info (rationale) for the security suggestions contained that document. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D2502C92BGLKXM0002VGREEN_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Please note that this is not a rationale of OLSRv2.

 

This is a rationale of how metrics were added to OLSRv2, a small subset of the complete OLSRv2 functionality.

 

There were of course security considerations in the design of OLSRv2, but this is not that document.

 

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: 06 March 2013 15:40
To: secdir; Dearlove, Christopher (UK); T.Clausen@computer.org; philippe.jacquet@alcatel-lucent.com; macker@itd.nrl.navy.mil; sratliff@cisco.com; Stewart Bryant; Adrian Farrel
Subject: SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02

 

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

 

This document is targeted as an Informational RFC. It describes itself as “… an historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2.”

 

The Security Considerations section says simply “This document does not specify any security considerations.” It’s been a very long time (many years) since I’ve encountered that phrase in a candidate RFC. A rationale document itself probably does not entail security considerations, but the omission of any security discussion suggests that security did not play a role in the deign of this routing protocol. Is that true? If so, who thinks this is a good thing?

 

I looked at the I-D that defines OLSRv2. It contains a two-page Security Considerations section. From my perspective, this document ought to provide background info (rationale) for the security suggestions contained that document.


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D2502C92BGLKXM0002VGREEN_-- From sratliff@cisco.com Wed Mar 6 09:14:59 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDD921F85B2 for ; Wed, 6 Mar 2013 09:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eW7sdMGd9eNq for ; Wed, 6 Mar 2013 09:14:54 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCB721F867D for ; Wed, 6 Mar 2013 09:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19660; q=dns/txt; s=iport; t=1362590089; x=1363799689; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2jnr6WI38Km55sCqtw72KIWzTcQ/tiA/upmXrkqOKr4=; b=ao+JDie56VXubpUVjGOSsZhWohO/4KoncsxCbcIfBctJUC7GAEX7buFx jbqZw7W6WgNqIaSn7o8y2OkdpStLAEmj3oM6epAxOLDNZotjbw/S/jmWQ tiYwCNcJWaSnPJXalYVERRIz+FwUOMuAp6g3cRm/ZrQ5WUYRHA//UY49w k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAJ94N1GtJXG+/2dsb2JhbABEhBS4DogkgVoWc4IqAQEBAgJVHAgQAgEIEQQBAQsdBzIUCQgCBA4FCIgLDL0JjUsKDngmBgUGAQYDglZhA5dpj1KDCIFpCRce X-IronPort-AV: E=Sophos;i="4.84,795,1355097600"; d="scan'208,217";a="184467477" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 06 Mar 2013 17:14:49 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r26HEmhS006019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Mar 2013 17:14:48 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 11:14:48 -0600 From: "Stan Ratliff (sratliff)" To: "Dearlove, Christopher (UK)" Thread-Topic: SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 Thread-Index: AQHOGoDnF/PDunHJJE6/fPb3L+81eJiZQVoAgAAKboA= Date: Wed, 6 Mar 2013 17:14:47 +0000 Message-ID: <2ED1D3801ACAAB459FDB4EAC9EAD090C1004184D@xmb-aln-x03.cisco.com> References: <51376352.5050802@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.54.124] Content-Type: multipart/alternative; boundary="_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1004184Dxmbalnx03ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 06 Mar 2013 10:24:20 -0800 Cc: "T.Clausen@computer.org" , secdir , "philippe.jacquet@alcatel-lucent.com" , Adrian Farrel , "macker@itd.nrl.navy.mil" , "Stewart Bryant \(stbryant\)" Subject: Re: [secdir] SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:14:59 -0000 --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1004184Dxmbalnx03ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable FWIW, I agree with Chris - including security concerns for OLSRv2 would be = a scope change for the document. The authors were trying to answer the ques= tion "Why did you put metrics into OLSRv2, and why did you include them in = this specific fashion?" Given that scope, I don't believe there are securit= y issues, and the note in the document is adequate. Just my 2 cents. Regards, Stan On Mar 6, 2013, at 11:37 AM, Dearlove, Christopher (UK) wrote: Please note that this is not a rationale of OLSRv2. This is a rationale of how metrics were added to OLSRv2, a small subset of = the complete OLSRv2 functionality. There were of course security considerations in the design of OLSRv2, but t= his is not that document. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http:= //www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 From: Stephen Kent [mailto:kent@bbn.com] Sent: 06 March 2013 15:40 To: secdir; Dearlove, Christopher (UK); T.Clausen@computer.org; philippe.jacquet@alcatel-lucent.com; macker@itd.nrl.navy.mil; sratliff@cisco.com; Stewart Bryant; Adri= an Farrel Subject: SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Keep this in mind if you answer this message. Please see this process on how to= deal with suspicious emails. SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 I reviewed this document as part of the security directorate's ongoing effo= rt to review all IETF documents being processed by the IESG. These comment= s were written primarily for the benefit of the security area directors. D= ocument editors and WG chairs should treat these comments just like any oth= er last call comments. This document is targeted as an Informational RFC. It describes itself as = =93=85 an historic record of the rationale for, and design considerations b= ehind, how link metrics were included in OLSRv2.=94 The Security Considerations section says simply =93This document does not s= pecify any security considerations.=94 It=92s been a very long time (many y= ears) since I=92ve encountered that phrase in a candidate RFC. A rationale = document itself probably does not entail security considerations, but the o= mission of any security discussion suggests that security did not play a ro= le in the deign of this routing protocol. Is that true? If so, who thinks t= his is a good thing? I looked at the I-D that defines OLSRv2. It contains a two-page Security Co= nsiderations section. From my perspective, this document ought to provide b= ackground info (rationale) for the security suggestions contained that docu= ment. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1004184Dxmbalnx03ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <421711076101344B87996F3511534DED@cisco.com> Content-Transfer-Encoding: quoted-printable FWIW, I agree with Chris - including security concerns for OLSRv2 would be = a scope change for the document. The authors were trying to answer the ques= tion "Why did you put metrics into OLSRv2, and why did you include the= m in this specific fashion?" Given that scope, I don't believe there are security issues, and the note in the docu= ment is adequate. 

Just my 2 cents. 

Regards,
Stan

On Mar 6, 2013, at 11:37 AM, Dearlove, Christopher (UK) wrote:

Please note that this is not a rationale of OLSRv2.<= /o:p>
 
This is a rationale of how metrics were added to OLSRv2, = a small subset of the complete OLSRv2 functionality.
 
There were of course security considerations in the desig= n of OLSRv2, but this is not that document.
 
--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove@baesystems.com<= span class=3D"Apple-converted-space"> | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, = Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687
 
From: Stephen Kent [mailto:kent@bbn.com] 
Sent: 06 March 201= 3 15:40
To: secdir; Dearlo= ve, Christopher (UK); T.Clausen@computer.org; philippe.jacquet@alcatel= -lucent.com; macker@itd.nrl.navy.mil; sratliff@cisco.com; Stewart Bryant; Adrian Farrel
Subject: SECDIR re= view of draft-ietf-manet-olsrv2-metrics-rationale-02
 
 
*** WARNING ***

This message originates from outside our organisation= , either from an external partner or the internet.
Keep this in mind if y= ou answer this message.
Please see this process on how to de= al with suspicious emails.

SECDIR review of dr= aft-ietf-manet-olsrv2-metrics-rationale-02
 <= /o:p>
I reviewed this doc= ument as part of the security directorate's ongoing effort to review all IE= TF 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 co= mments just like any other last call comments.
 
This document is targeted as an Informati= onal RFC. It describes itself as =93=85 an historic record of the rationale= for, and design considerations behind, how link metrics were included in O= LSRv2.=94
 
The Security Considerations section says = simply =93This document does not specify any security considerations.=94 It= =92s been a very long time (many years) since I=92ve encountered that phras= e in a candidate RFC. A rationale document itself probably does not entail security considerations, but the omission = of any security discussion suggests that security did not play a role in th= e deign of this routing protocol. Is that true? If so, who thinks this is a= good thing?
 
I looked at the I-D that defines OLSRv2. = It contains a two-page Security Considerations section. From my perspective= , this document ought to provide background info (rationale) for the securi= ty suggestions contained that document.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************


--_000_2ED1D3801ACAAB459FDB4EAC9EAD090C1004184Dxmbalnx03ciscoc_-- From adrian@olddog.co.uk Wed Mar 6 10:31:07 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196EC21F86F5 for ; Wed, 6 Mar 2013 10:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHKEhTVqfASP for ; Wed, 6 Mar 2013 10:31:04 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id B8D1921F85B1 for ; Wed, 6 Mar 2013 10:31:00 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r26ITpPl020497; Wed, 6 Mar 2013 18:29:52 GMT Received: from 950129200 (089144192096.atnat0001.highway.a1.net [89.144.192.96]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r26ITmhG020467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Mar 2013 18:29:50 GMT From: "Adrian Farrel" To: "'Stephen Kent'" , "'secdir'" , , , , , , "'Stewart Bryant'" References: <51376352.5050802@bbn.com> In-Reply-To: <51376352.5050802@bbn.com> Date: Wed, 6 Mar 2013 18:29:52 -0000 Message-ID: <022f01ce1a98$991192e0$cb34b8a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0230_01CE1A98.991C8F60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNG5uRV1AP4Bq9s3GOfb4X8RM35mZWnYFJw Content-Language: en-gb Subject: Re: [secdir] SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 06 Mar 2013 18:31:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0230_01CE1A98.991C8F60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Stephen, Thanks for this. I wanted to note that this is the rationale for adding metrics to OLSRv2, not the whole deign rationale for OLSRv2, so there is a big gap between "consideration of security did not play any part in the design of this protocol" and "this document does not specify any design considerations". However, I think your point is valid. During my AD review I asked the authors: > Were there any security considerations that cropped up while designing > metric support in OSLRv2? If so, here would be the place to mention > them. The authors had no updates they wanted to make to this document and that led me to conclude: > Security issues arising from the inclusion of metrics in OLSRv2 did > not get any specific discussion. Since OLSRv2 has its own security > considerations to cover the whole protocol, there is nothing further > to say in this document. ...a statement which I put to the WG and which they did not refute. So that leads us to wonder: should the addition of a metric to a routing protocol have been the subject of a discussion about the impact on security. And if it wasn't, should this document record that it wasn't (and if so, why it wasn't)? I think that would probably lead to a very short paragraph being inserted in Section 8 saying "We knew that OSLRv2 already had adequate security so we did not consider adding metrics in anyway changed the threats or mitigation expressed in the base specification." Would that have addressed the issue for you? Cheers, Adrian From: Stephen Kent [mailto:kent@bbn.com] Sent: 06 March 2013 15:40 To: secdir; chris.dearlove@baesystems.com; T.Clausen@computer.org; philippe.jacquet@alcatel-lucent.com; macker@itd.nrl.navy.mil; sratliff@cisco.com; Stewart Bryant; Adrian Farrel Subject: SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 SECDIR review of draft-ietf-manet-olsrv2-metrics-rationale-02 I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is targeted as an Informational RFC. It describes itself as ". an historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2." The Security Considerations section says simply "This document does not specify any security considerations." It's been a very long time (many years) since I've encountered that phrase in a candidate RFC. A rationale document itself probably does not entail security considerations, but the omission of any security discussion suggests that security did not play a role in the deign of this routing protocol. Is that true? If so, who thinks this is a good thing? I looked at the I-D that defines OLSRv2. It contains a two-page Security Considerations section. From my perspective, this document ought to provide background info (rationale) for the security suggestions contained that document. ------=_NextPart_000_0230_01CE1A98.991C8F60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stephen,

 

Thanks for this. I wanted to note that this is the = rationale for adding metrics to OLSRv2, not the whole deign rationale = for OLSRv2, so there is a big gap between "consideration of = security did not play any part in the design of this protocol" and = "this document does not specify any design = considerations".

 

However, I think your point is = valid.

 

During my AD review I asked the = authors:

 

> Were there any security considerations that = cropped up while designing

> metric support in OSLRv2? If so, here would = be the place to mention

> them.

 

The authors had no updates they wanted to make to = this document and that led me to conclude:

 

> Security issues arising from the inclusion of = metrics in OLSRv2 did

> not get any specific discussion. Since OLSRv2 = has its own security

> considerations to cover the whole protocol, = there is nothing further

> to say in this = document.

 

...a statement which I put to the WG and which = they did not refute.

 

So that leads us to wonder: should the addition of = a metric to a routing protocol have been the subject of a discussion = about the impact on security. And if it wasn't, should this document = record that it wasn't (and if so, why it = wasn't)?

 

I think that would probably lead to a very short = paragraph being inserted in Section 8 saying "We knew that OSLRv2 = already had adequate security so we did not consider adding metrics in = anyway changed the threats or mitigation expressed in the base = specification."

 

Would that have addressed the issue for = you?

 

Cheers,

Adrian

 

From: = Stephen Kent [mailto:kent@bbn.com]
Sent: 06 March 2013 = 15:40
To: secdir; chris.dearlove@baesystems.com; = T.Clausen@computer.org; philippe.jacquet@alcatel-lucent.com; = macker@itd.nrl.navy.mil; sratliff@cisco.com; Stewart Bryant; Adrian = Farrel
Subject: SECDIR review of = draft-ietf-manet-olsrv2-metrics-rationale-02

<= /div>

 

SECDIR review = of draft-ietf-manet-olsrv2-metrics-rationale-02

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

This document is targeted as an Informational = RFC. It describes itself as “… an historic record of the = rationale for, and design considerations behind, how link metrics were = included in OLSRv2.”

 

The Security = Considerations section says simply “This document does not specify = any security considerations.” It’s been a very long time = (many years) since I’ve encountered that phrase in a candidate = RFC. A rationale document itself probably does not entail security = considerations, but the omission of any security discussion suggests = that security did not play a role in the deign of this routing protocol. = Is that true? If so, who thinks this is a good = thing?

 

I looked at the = I-D that defines OLSRv2. It contains a two-page Security Considerations = section. From my perspective, this document ought to provide background = info (rationale) for the security suggestions contained that = document.

------=_NextPart_000_0230_01CE1A98.991C8F60-- From kivinen@iki.fi Thu Mar 7 02:20:42 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3133B21F8481; Thu, 7 Mar 2013 02:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYHB6rIMM65m; Thu, 7 Mar 2013 02:20:41 -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 3ED8421F8480; Thu, 7 Mar 2013 02:20:40 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r27AKbN3023839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Mar 2013 12:20:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r27AKav0002544; Thu, 7 Mar 2013 12:20:36 +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: <20792.27124.120072.820303@fireball.kivinen.iki.fi> Date: Thu, 7 Mar 2013 12:20:36 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tsvwg-byte-pkt-congest.all@tools.ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 6 min Subject: [secdir] Secdir review of draft-ietf-tsvwg-byte-pkt-congest-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 10:20:42 -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 modifies the existing recommendation how small packets should be treated in the RED AQM algorithm. This document deprecates the deliberate preferential treatment of small packets in AQM algorithms. The new recommendation is that packet size is taken in to consideration when measuring congestion, but not to taken consideration when signaling that congestion by dropping packets. The security considerations section gives good explination how the new recommendation is better for security. I have no comments to the draft. -- kivinen@iki.fi From kivinen@iki.fi Thu Mar 7 03:09:30 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C4121F8D5B for ; Thu, 7 Mar 2013 03:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.374 X-Spam-Level: X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNne0L54+h1v for ; Thu, 7 Mar 2013 03:09:30 -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 A4E3721F8CD0 for ; Thu, 7 Mar 2013 03:09:28 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r27B9Ok0022561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Mar 2013 13:09:24 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r27B9NNJ001691; Thu, 7 Mar 2013 13:09:23 +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: <20792.30051.40497.739551@fireball.kivinen.iki.fi> Date: Thu, 7 Mar 2013 13:09:23 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2013 11:09:31 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Alexey Melnikov is next in the rotation. For telechat 2013-03-28 Reviewer LC end Draft Stephen Kent TR2013-01-21 draft-ietf-roll-security-threats-01 Glen Zorn T 2013-02-11 draft-ietf-mpls-tp-use-cases-and-design-07 Last calls and special requests: Rob Austein 2013-03-06 draft-arkko-iesg-crossarea-03 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-06 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Scott Kelly 2013-03-08 draft-ietf-intarea-nat-reveal-analysis-05 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-09 Warren Kumari 2013-03-26 draft-merkle-ikev2-ke-brainpool-03 Julien Laganier 2013-03-18 draft-ietf-appsawg-webfinger-10 Ben Laurie 2013-03-29 draft-ietf-ospf-ipv4-embedded-ipv6-routing-07 Matt Lepinski 2013-03-15 draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10 Chris Lonvick 2013-03-15 draft-ietf-xrblock-rtcp-xr-burst-gap-loss-08 Catherine Meadows 2013-03-15 draft-ietf-xrblock-rtcp-xr-decodability-09 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Eric Rescorla 2013-01-24 draft-ietf-ospf-ospfv3-iid-registry-update-02 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-04 Nico Williams - draft-ietf-httpbis-p5-range-22 -- kivinen@iki.fi From new-work-bounces@ietf.org Thu Mar 7 09:19:13 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581AA21F89CB; Thu, 7 Mar 2013 09:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1362676753; bh=0+9G1Z351jQdmPkjSC/urJY9sl0i99Hi5MJFGj3leA0=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=oaVUPixnak2BcWMcOfVYy7Hc7afQB8juAiq33bmfEL13EclXBHMsswzESoOII13f5 5C2T335WyEX24kIYrspfE44JhOG+HmQ+NIea8uGotUglYjys2M8HkaTziO9cFQN839 3oMqgwrpNk6Odc3qX1NYGKlPYgcaaIo/OdYdehxU= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A0321F89CB for ; Thu, 7 Mar 2013 09:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO3xBmgTPXsS for ; Thu, 7 Mar 2013 09:19:11 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 4B99921F89C7 for ; Thu, 7 Mar 2013 09:19:08 -0800 (PST) Received: from c-98-207-40-171.hsd1.ca.comcast.net ([98.207.40.171] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1UDeTC-0005s0-7E for new-work@ietf.org; Thu, 07 Mar 2013 12:19:06 -0500 To: new-work@ietf.org Date: Thu, 07 Mar 2013 18:19:05 +0100 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/12.14 (MacIntel) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Thu, 07 Mar 2013 09:21:51 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web Performance Working Group (until 2013-04-04) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 17:19:13 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Rich Web Client Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web Performance Working Group: http://www.w3.org/2013/01/webperf.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2013-04-04 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Philippe Le Hegaret, Interaction Domain Lead . Thank you, Coralie Mercier, W3C Communications [0] http://www.w3.org/2006/rwc/Activity.html [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +33643220001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From secdir-bounces@mit.edu Thu Mar 7 16:03:38 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0510021F86BC for ; Thu, 7 Mar 2013 16:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0bH5BaQxFcM for ; Thu, 7 Mar 2013 16:03:37 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by ietfa.amsl.com (Postfix) with ESMTP id 61C3421F869E for ; Thu, 7 Mar 2013 16:03:37 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id r2803aSg029829 for ; Thu, 7 Mar 2013 19:03:36 -0500 Received: from mailhub-dmz-3.mit.edu (MAILHUB-DMZ-3.MIT.EDU [18.9.21.42]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id r2803Y97029826 for ; Thu, 7 Mar 2013 19:03:34 -0500 Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by mailhub-dmz-3.mit.edu (8.13.8/8.9.2) with ESMTP id r28031NL015496 for ; Thu, 7 Mar 2013 19:03:34 -0500 X-AuditID: 1209190c-b7f046d00000094c-54-51392ad6fcc2 Authentication-Results: symauth.service.identifier Received: from smtp112.iad.emailsrvr.com (smtp112.iad.emailsrvr.com [207.97.245.112]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id E5.78.02380.6DA29315; Thu, 7 Mar 2013 19:03:34 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp51.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id B360A20A00; Thu, 7 Mar 2013 19:03:33 -0500 (EST) X-Virus-Scanned: OK Received: from legacy13.wa-web.iad1a (legacy13.wa-web.iad1a.rsapps.net [192.168.4.99]) by smtp51.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 96084209E9; Thu, 7 Mar 2013 19:03:33 -0500 (EST) Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by legacy13.wa-web.iad1a (Postfix) with ESMTP id 84C4737040D; Thu, 7 Mar 2013 19:03:33 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Thu, 7 Mar 2013 16:03:33 -0800 (PST) Date: Thu, 7 Mar 2013 16:03:33 -0800 (PST) From: "Scott G. Kelly" To: draft-ietf-intarea-nat-reveal-analysis.all@tools.ietf.org, "iesg@ietf.org" , "secdir" MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1362701013.542210453@apps.rackspace.com> X-Mailer: webmail7.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEKsWRWlGSWpSXmKPExsVyPvFrge41LctAg1O7+Szanu1mc2D0aDpz lDmAMYrLJiU1J7MstUjfLoEr40/DLaaC05wVh+8eZ2lg/MHexcjJISFgItH/9DQjiM0oYCSx +9wrVoi4mMSFe+vZuhi5OIQE7jFKXJ8wCcrZxCixZ+UfFogqYYnHfUdZIRJnGCW2tZwFGyUk sJpR4tbDJIjEckaJGa2HmEESLAJaEt1bF4IVCQs4S2z7MxMsziagL3Ho8Uw2EFtEoFZixukF YPfxCghKnJz5BGgbOwezgJrEDV2QKLOAtsSyha/BOjkFhCQ6rnbCXT1h3S9mCJtX4sz+T8wQ U0wlfh4+yAgRF5G42vOefQKj6CwkC2bBLZiFZMECRuZVjLIpuVW6uYmZOcWpybrFyYl5ealF uoZ6uZkleqkppZsYgZEgxCnJs4PxzUGlQ4wCHIxKPLwVmywChVgTy4orcw8xSnIwKYnyTlGw DBTiS8pPqcxILM6ILyrNSS0+xCjBwawkwvtbBijHm5JYWZValA+TkuZgURLnvZxy019IID2x JDU7NbUgtQgmy8TBfohRhoNDSYI3FRj7QoJFqempFWmZOSXIajhBBBfIGh6gNUkghbzFBYm5 xZnpEEWnGHU5Zt199IJRiCUvPy9VSpw3AKRIAKQoozQPbhgsqV1ilJUS5mVkYGAQ4gG6BhgI qPKvGMWBASDMGw4yhSczrwRu0yugI5iAjvALtgA5oiQRISXVwDhD48p3tbnfOpVntuVrvb0s t2zCOQflY4Kfdk5xm7eml3cr51RuhYutE74HTTJYnNnh1pTpXKJnNkPkvOJRM2eR/f1S6RWr 3eWurr1TmVXrJhMxT+yG4Tn9S2fEV6tnGNeWFD17cutB+3+PtVeuTdr995Dl+p33m1qvbV1y YsfJxJJ19nuWRi9QYinOSDTUYi4qTgQAMvalTmUDAAA= X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id r2803Y97029826 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: [secdir] secdir review of draft-ietf-intarea-nat-reveal-analysis-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 00:03:38 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The intended status is Informational. From the abstract, the document describes a collection of solutions to reveal a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. The document looks at several options for adding an identifier to packets that facilitates source disambiguation by endpoints. The document includes a section on privacy considerations, and the security considerations section points out that servers should not rely on HOST_ID for trust decisions, and that admins should be aware of the potential for unwanted information leakage. It also says that HOST_ID specification documents should elaborate further on threats specific to the particular solution. I think this pretty well covers it, and I have no concerns with this document. --Scott _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Thu Mar 7 22:21:01 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C4321F86B6 for ; Thu, 7 Mar 2013 22:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.079 X-Spam-Level: X-Spam-Status: No, score=-104.079 tagged_above=-999 required=5 tests=[AWL=2.520, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZe2YQ1Gygcr for ; Thu, 7 Mar 2013 22:21:00 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by ietfa.amsl.com (Postfix) with ESMTP id B997421F86A1 for ; Thu, 7 Mar 2013 22:21:00 -0800 (PST) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id r286KxHd002418 for ; Fri, 8 Mar 2013 01:20:59 -0500 Received: from mailhub-dmz-4.mit.edu (MAILHUB-DMZ-4.MIT.EDU [18.7.62.38]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id r286Kt6X002415 for ; Fri, 8 Mar 2013 01:20:55 -0500 Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by mailhub-dmz-4.mit.edu (8.13.8/8.9.2) with ESMTP id r286KlNo015720 for ; Fri, 8 Mar 2013 01:20:55 -0500 Authentication-Results: symauth.service.identifier Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 28.16.32259.64389315; Fri, 8 Mar 2013 01:20:55 -0500 (EST) X-AuditID: 12074423-b7f5b6d000007e03-01-513983467512 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 6E.4F.02430.54389315; Fri, 8 Mar 2013 07:20:54 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0318.004; Fri, 8 Mar 2013 01:20:53 -0500 From: Suresh Krishnan To: "Scott G. Kelly" Thread-Topic: secdir review of draft-ietf-intarea-nat-reveal-analysis-05 Thread-Index: AQHOG5BrjjJ9GD3Ee0CwotPG6hmADJibUwuE Date: Fri, 8 Mar 2013 06:20:52 +0000 Message-ID: References: <1362701013.542210453@apps.rackspace.com> In-Reply-To: <1362701013.542210453@apps.rackspace.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphk+JIrShJLcpLzFFi42I5JsGmq+vebBlocPoqi0Xbs91sDoweTWeO MgcwRnHZpKTmZJalFunbJXBldE5rZi74z1Nx+MkzxgbG+1xdjBwcEgImEl3N2l2MnByMAkYS u8+9YgWxJQTEJC7cW8/WxcjFISRwmVFi9qwuRoiEicT3X7eZIBJHGCXudf1jh3CWMUo0fWhh AqliA6rasPMzmC0ioCsxbW0rK0gRs8BuRolpz+ewgySEBdwlPq/eBVXkITHv5xZmCNtI4sD3 /2wg57EIqEic+S0MYvIKuElMPCsJUiEkYCrR//UGWCengJlE74Fb7BAfiEl8P7UGLM4sIC5x 68l8JoijBSSW7DnPDGGLSrx8/I8VokZHYsHuT2wQtrbEsoWvwWp4BQQlTs58wgJysoTADDaJ rysfMU1glJyFZO4sJP2zkPTPQtK/gJFlFaNsSm6Vbm5iZk5xarJucXJiXl5qka6ZXm5miV5q SukmRmAUCrG7KO9g/HNQ6RCjAAejEg9vxSaLQCHWxLLiytxDjJIcTEqivBYNloFCfEn5KZUZ icUZ8UWlOanFhxglOJiVRHh/ywDleFMSK6tSi/JhUtIcLErivNdSbvoLCaQnlqRmp6YWpBbB ZJk42A8xynBwKEnwhjYBdQsWpaanVqRl5pQgq+EEEVwga3iA1niDFPIWFyTmFmemQxSdYlSU EucVBEkIgCQySvPgBsAS5yVGWSlhXkYGBgYhHqALgB5HlX/FKA70tDDEeJ7MvBK46a+AFjMB LfYLtgBZXJKIkJJqYMyJbawoqbE/m7xsx7fvj5ek+y+Y+SxfqJ/NR1/nYrKGV4pAzdaj0W1K HtbKUk/NH+b/ORgQeozrf7Fa6LuEiyzpvaWvTs0/LXFzi+2t6gttnUvCi3V9ly1p+Rw4b9eL OqlpDyetm6X583y46wM7a20ZvRXN5tzLC6I3Lpb4qCXDuKxMenZnvRJLcUaioRZzUXEiACmc BzOXAwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyuXSPn65bs2WgwfS5PBb7X5ZazPgzkdni 65YJjBZtz3azObB47NhxisVjyZKfTB5NZ44ye3y5/JktgCWKyyYlNSezLLVI3y6BK6NzWjNz wX+eisNPnjE2MN7n6mLk5JAQMJH4/us2E4QtJnHh3nq2LkYuDiGBI4wS97r+sUM4yxglmj60 gFWxAXVs2PkZzBYR0JWYtraVFaSIWWA3o8S053PYQRLCAu4Sn1fvgirykJj3cwszhG0kceD7 f6AVHBwsAioSZ34Lg5i8Am4SE89KglQICZhK9H+9AdbJKWAm0XvgFthERqDjvp9aAxZnFhCX uPVkPtTRAhJL9pxnhrBFJV4+/scKUaMjsWD3JzYIW1ti2cLXYDW8AoISJ2c+YZnAKDoLyahZ SFpmIWmZhaRlASPLKkaO0uLUstx0I4NNjMCYOSbBpruDcc9Ly0OM0hwsSuK8Qa4XAoQE0hNL UrNTUwtSi+KLSnNSiw8xMnFwSjUwzms4ouV/vXzHnumcsoJfzyhp3pycNoG97U7UcTafqNS7 yrw7dOL8MoXXl+xiuVXm3nf07dtTr5w/vJ9rz/db7Jq25KITp3r2GzyP3dj6YckLjf6Ja5uU 31Ws/K7e49SXL+rscjlJ+umsxx6pgTGq165seaP7rrEruiK1Q3/l9oi9Zg/vKGp+U2Ipzkg0 1GIuKk4EAC5FIsRnAgAA X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id r286Kt6X002415 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Cc: secdir , "iesg@ietf.org" , "draft-ietf-intarea-nat-reveal-analysis.all@tools.ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-intarea-nat-reveal-analysis-05 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 06:21:01 -0000 Hi Scott, Thanks a lot for the review. Much appreciated. Regards Suresh ----- Original Message ----- From: "Scott G. Kelly" To: "draft-ietf-intarea-nat-reveal-analysis.all@tools.ietf.org" , "iesg@ietf.org" , secdir Sent: 3/7/2013 7:03 PM Subject: secdir review of draft-ietf-intarea-nat-reveal-analysis-05 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 intended status is Informational. From the abstract, the document describes a collection of solutions to reveal a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. The document looks at several options for adding an identifier to packets that facilitates source disambiguation by endpoints. The document includes a section on privacy considerations, and the security considerations section points out that servers should not rely on HOST_ID for trust decisions, and that admins should be aware of the potential for unwanted information leakage. It also says that HOST_ID specification documents should elaborate further on threats specific to the particular solution. I think this pretty well covers it, and I have no concerns with this document. --Scott _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From catherine.meadows@nrl.navy.mil Fri Mar 8 15:45:30 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B64F21F85A2; Fri, 8 Mar 2013 15:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSQU2-DCA31e; Fri, 8 Mar 2013 15:45:29 -0800 (PST) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfa.amsl.com (Postfix) with ESMTP id E133921F859C; Fri, 8 Mar 2013 15:45:25 -0800 (PST) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.14.4/8.13.6) with ESMTP id r28Nigbt006403; Fri, 8 Mar 2013 18:44:42 -0500 Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id r28NjNf5013636; Fri, 8 Mar 2013 18:45:23 -0500 (EST) Received: from ashurbanipal.fw5540.net ([10.0.3.109]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2013030818452318813 ; Fri, 08 Mar 2013 18:45:23 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_73B6F91F-790B-4457-B167-8774D6042900" Date: Fri, 8 Mar 2013 18:45:22 -0500 Message-Id: To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-xrblock-rtcp-xr-decodability.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [secdir] Secdir review of draft-ietf-xrblock-rtcp-xr-decodability-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 23:45:30 -0000 --Apple-Mail=_73B6F91F-790B-4457-B167-8774D6042900 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 ID concerns a new RTP Control Protocol Extended Report Block that = reports decodability statistics metrics for RTP applications using MPEG2 TS over RTP. These = are parameters necessary or helpful to ensure that TS transmissions can be decoded. This includes information such as transport stream synchronization losses, sync byte errors, and = continuity count errors, and others, apply to all MPEG2 applications. The ID gives the format for each of the parameters in the Report Block. The authors of the document point out in the Security Considerations = section that the ID introduces no new security considerations beyond those described in RFC 3611. RFC 3611 describes RTP Extended = Reports Blocks in general. The security considerations discussed are that the information in the Report Blocks, which are generally = unencrypted, could reveal confidential information, and that an attacker could possibly take advantage of the size of the Extended Report Blocks = to launch a denial of service attack. I agree that the Report Blocks = described in this ID to not introduce any security considerations beyond that, and = thus do not believe that this ID needs any further examination from a security point of view. Cathy =20 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=_73B6F91F-790B-4457-B167-8774D6042900 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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=_73B6F91F-790B-4457-B167-8774D6042900-- From mcr@sandelman.ca Fri Mar 8 22:26:41 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B3C21F854F for ; Fri, 8 Mar 2013 22:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlqLEfiCrD6o for ; Fri, 8 Mar 2013 22:26:41 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id D4C9F21F8528 for ; Fri, 8 Mar 2013 22:26:40 -0800 (PST) Received: from sandelman.ca (unknown [209.128.20.133]) by relay.sandelman.ca (Postfix) with ESMTPS id 3FED82206A; Sat, 9 Mar 2013 06:26:40 +0000 (UTC) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 44277CA0C8; Fri, 8 Mar 2013 20:40:00 -0500 (EST) From: Michael Richardson To: "Dan Harkins" In-reply-to: <11d667a994d9c2f139958c2e605048fa.squirrel@www.trepanning.net> References: <11d667a994d9c2f139958c2e605048fa.squirrel@www.trepanning.net> Comments: In-reply-to "Dan Harkins" message dated "Wed, 20 Feb 2013 14:31:53 -0800." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) Date: Fri, 08 Mar 2013 20:40:00 -0500 Message-ID: <16833.1362793200@sandelman.ca> Sender: mcr@sandelman.ca X-Mailman-Approved-At: Sat, 09 Mar 2013 04:46:50 -0800 Cc: secdir@ietf.org Subject: Re: [secdir] secdir review of draft-richardson-roll-applicability-template-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2013 06:26:41 -0000 >>>>> "Dan" == Dan Harkins writes: Dan> I have reviewed this document as part of the security Dan> directorate's ongoing effort to review all IETF documents being Dan> processed by the IESG. These comments were written primarily Dan> for the benefit of the security area directors. Document Dan> editors and WG chairs should treat these comments just like any Dan> other last call comments. A new revision will be posted on Monday. -- Michael Richardson -on the road- From kent@bbn.com Sun Mar 10 07:26:12 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4B121F86B1 for ; Sun, 10 Mar 2013 07:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Afb5ujTxSHeG for ; Sun, 10 Mar 2013 07:26:10 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id E217621F87D6 for ; Sun, 10 Mar 2013 07:26:09 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:53504 helo=dhcp-1067.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UEhCO-0000J4-8Y; Sun, 10 Mar 2013 10:26:04 -0400 Message-ID: <513C97FB.2000006@bbn.com> Date: Sun, 10 Mar 2013 10:26:03 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: secdir , angel.lozano@upf.edu, vanesa.daza@upf.edu, mischa.dohler@cttc.es, roger.alexander@cooperindustries.com, Michael Richardson , jpv@cisco.com, Adrian Farrel Content-Type: multipart/alternative; boundary="------------010500060605040502000202" Subject: [secdir] SECDIR review of draft-ietf-roll-security-threats-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 14:26:12 -0000 This is a multi-part message in MIME format. --------------010500060605040502000202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit SECDIR review of draft-ietf-roll-security-threats-01 I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors and WG chairs should treat these comments just like any other last call comments. This is a review of the revised version of the -00 draft that I reviewed on 1/17/13. I am _very_ disappointed to see that essentially all of the comments that I made, many of which were easy to address, were ignored. Only my edits of typos seem to have been incorporated. -3.3: the term sleep node is still used but not defined. -3.4: several terms used here (misappropriated, legitimacy, and truthfulness) still represent poor choices of terminology, and should be fixed -4.1.1: sniffing should still be replaced with passive wiretapping, everywhere -4.2: the authors did not fix the definition of traffic analysis -4.2.2: "misappropriation", again -4.3.1: overload attack mentioned, w/o definition -4.3.2: selective forwarding, wormhole and sinkhole attacks are mentioned, w/o definitions, still -5.1.1: still incorrect assertions re countering deliberate exposure, i.e., no mention of authorization -5.1.2: device compromise is not usually considered as part of passive wiretapping attacks -5.1.3: TA still mischaracterized as "may be passive" -5.1.4: I suggested that anti-tamper should be out of scope for this document -5.2.2: a trivial, brief discussion that is not helpful -5.2.3: still an oversimplified symmetric vs. asymmetric cryptographic discussion, and the authors did not update the text to a more recent cite that I provided I have chosen to not continue because it appears that NONE of the specific comments I made have been addressed, based on a quick look at the -00 vs. -01 diff file. --------------010500060605040502000202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

SECDIR review of draft-ietf-roll-security-threats-01

 

I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments. This is a review of the revised version of the -00 draft that I reviewed on 1/17/13.

I am very disappointed to see that essentially all of the comments that I made, many of which were easy to address, were ignored. Only my edits of typos seem to have been incorporated.

 

-   3.3: the term sleep node is still used but not defined.

-   3.4: several terms used here (misappropriated, legitimacy, and truthfulness) still represent poor choices of terminology, and should be fixed

-   4.1.1: sniffing should still be replaced with passive wiretapping, everywhere

-   4.2: the authors did not fix the definition of traffic analysis

-   4.2.2: “misappropriation”, again

-   4.3.1: overload attack mentioned, w/o definition

-   4.3.2: selective forwarding, wormhole and sinkhole attacks are mentioned, w/o definitions, still

-   5.1.1: still incorrect assertions re countering deliberate exposure, i.e., no mention of authorization

-   5.1.2: device compromise is not usually considered as part of passive wiretapping attacks

-   5.1.3: TA still mischaracterized as “may be passive”

-   5.1.4: I suggested that anti-tamper should be out of scope for this document

-   5.2.2: a trivial, brief discussion that is not helpful

-   5.2.3: still an oversimplified symmetric vs. asymmetric cryptographic discussion, and the authors did not update the text to a more recent cite that I provided

 

 

I have chosen to not continue because it appears that NONE of the specific comments I made have been addressed, based on a quick look at the -00 vs. -01 diff file.

 

 

--------------010500060605040502000202-- From new-work-bounces@ietf.org Mon Mar 11 18:03:54 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8696D21F8F0F; Mon, 11 Mar 2013 18:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1363050234; bh=kHGzCEiTJ99Jza42NWVzaLHSPkwv/aEnjKeRDwHe854=; h=From:To:Date:Message-ID:MIME-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=FVjxVwO62w+PDWREXnCR7I+2XPzWXuX+EX2CJOGCvC6hArMbUpxxhIqIDTKAy8xnB kcbhbwvMn/Lj7CBIWSNf24dMQY34oN4MEO6KhXVmX/wHQ11V7JssS6MQIP0tktY3Qw +VpO65jtN1H8DjkChtNPbebMRHie7yrm1We+Z1bg= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EED21F8EE6 for ; Mon, 11 Mar 2013 18:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwBU+QtjNhyI for ; Mon, 11 Mar 2013 18:03:51 -0700 (PDT) Received: from ausxippc101.us.dell.com (ausxippc101.us.dell.com [143.166.85.207]) by ietfa.amsl.com (Postfix) with ESMTP id AF2CE21F8F0F for ; Mon, 11 Mar 2013 18:03:51 -0700 (PDT) X-LoopCount0: from 10.170.28.40 X-IronPort-AV: E=Sophos; i="4.84,827,1355119200"; d="scan'208,217"; a="92748871" From: To: Date: Mon, 11 Mar 2013 20:03:49 -0500 Thread-Topic: IEEE 802 New Work Under Consideration in March 2013 Thread-Index: Ac4euXyYG/FLyRRxR7C/d+LNogLDKg== Message-ID: <93720FE55DA3044C9F74B2962338F7DEC374C94805@AUSX7MCPC109.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: multipart/mixed; boundary="===============0169946015939609487==" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 12 Mar 2013 05:17:28 -0700 Subject: [secdir] [new-work] IEEE 802 New Work Under Consideration in March 2013 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 01:03:54 -0000 --===============0169946015939609487== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_93720FE55DA3044C9F74B2962338F7DEC374C94805AUSX7MCPC109A_" --_000_93720FE55DA3044C9F74B2962338F7DEC374C94805AUSX7MCPC109A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following Project Authorization Requests (PARs) will be considered at t= he March 2013 IEEE 802 Plenary: * 802 - Standard for Local and Metropolitan Area Networks: Overview and = Architecture * 802.1Qcb - amendment for Frame Replication and Elimination for Reliabi= lity * 802.3bm - PAR modification request & Updated 5C * 802.3bq - amendment for 40GBASE-T * 802.15.4p - PAR modification Request The PARs can be found at http://ieee802.org/PARs.shtml along with the suppo= rting 5 criteria (i.e. the explanations of how they fit the IEEE 802 criter= ia for initiating new work). Any comments on a proposed PAR should be sent to the Working Group chair id= entified on the PAR to be received by 5:00 PM March 19, 2013 (0000 UTC Marc= h 20, 2013). Regards, John D'Ambrosia IEEE 802 LMSC Recording Secretary --_000_93720FE55DA3044C9F74B2962338F7DEC374C94805AUSX7MCPC109A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The following Project Authorization Requests (PARs) will be = considered at the March 2013 IEEE 802 Plenary:

  • 802 - Standard for Local and Metropolitan= Area Networks: Overview and Architecture
  • 802.1Qcb - amendment for Frame Replication and Elimination f= or Reliability
  • 802.3bm – PAR modification request & Updated 5C =
  • 802.3bq - amendment for 40GBASE= -T
  • 802.15.4p - PAR modificat= ion Request

The PARs can be found at http://ieee802.org/PARs.shtml along with the supporting 5 criteria (i.= e. the explanations of how they fit the IEEE 802 criteria for initiating ne= w work).

Any comments on a proposed PAR should be sent to the Worki= ng Group chair identified on the PAR to be received by 5:00 PM March 19, 20= 13 (0000 UTC March 20, 2013).

Regards,

John DR= 17;Ambrosia

IEEE 802 LMSC Recording Secr= etary

 

= = --_000_93720FE55DA3044C9F74B2962338F7DEC374C94805AUSX7MCPC109A_-- --===============0169946015939609487== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============0169946015939609487==-- From stephen.farrell@cs.tcd.ie Tue Mar 12 06:38:42 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E60421F8B5B for ; Tue, 12 Mar 2013 06:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmBZT8iRwOBD for ; Tue, 12 Mar 2013 06:38:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 16C2B21F8A99 for ; Tue, 12 Mar 2013 06:38:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B0783BE3C for ; Tue, 12 Mar 2013 13:38:19 +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 3CZgsk7MHHy8 for ; Tue, 12 Mar 2013 13:38:14 +0000 (GMT) Received: from [130.129.20.50] (dhcp-1432.meeting.ietf.org [130.129.20.50]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8C90EBE47 for ; Tue, 12 Mar 2013 13:38:13 +0000 (GMT) Message-ID: <513F2FC4.1070403@cs.tcd.ie> Date: Tue, 12 Mar 2013 13:38:12 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: secdir@ietf.org References: <5123AFCB.8090804@ieca.com> In-Reply-To: <5123AFCB.8090804@ieca.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] secdir lunch details X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 13:38:42 -0000 Just a reminder of today's location S On 02/19/2013 05:00 PM, Sean Turner wrote: > We've been assigned a room at our usual Tuesday lunch time: > > Assigned Room: Caribbean 7 > Assigned Date: 03/12/2013 > Assigned Start Time: 11:30:00 > > At this point, I'm unsure what lunch options are available. > > spt > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > From prvs=776cb6add=Tzeta.Tsao@cooperindustries.com Tue Mar 12 07:14:22 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159EB21F8706 for ; Tue, 12 Mar 2013 07:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYuZjiamGZWa for ; Tue, 12 Mar 2013 07:14:21 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfa.amsl.com (Postfix) with ESMTP id 37ED221F86E3 for ; Tue, 12 Mar 2013 07:14:20 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.84,830,1355115600"; d="scan'208,217";a="91615544" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 12 Mar 2013 10:14:04 -0400 Received: from EVS2.NAM.CI.ROOT ([10.132.108.170]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Mar 2013 10:14:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CE1F2B.D93E6A25" Date: Tue, 12 Mar 2013 10:14:02 -0400 Message-ID: <85A23E0910B2FB4B8EF60D0888CB083602658653@EVS2.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: SECDIR review of draft-ietf-roll-security-threats-01 Thread-Index: Ac4fK9kkIDxeQjnIQhqK8sBWJNFcuw== From: "Tsao, Tzeta" To: , X-OriginalArrivalTime: 12 Mar 2013 14:14:04.0056 (UTC) FILETIME=[D9ECE980:01CE1F2B] X-Mailman-Approved-At: Tue, 12 Mar 2013 07:15:45 -0700 Cc: angel.lozano@upf.edu, vanesa.daza@upf.edu, secdir@ietf.org, jpv@cisco.com, "Alexander, Roger" , mischa.dohler@cttc.es, adrian@olddog.co.uk Subject: Re: [secdir] SECDIR review of draft-ietf-roll-security-threats-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:14:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CE1F2B.D93E6A25 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephen, =20 It was just brought to my attention about your email on March 10 of the subject SECDIR review of draft-ietf-roll-security-threats-01. I wish to point out that it had been explicitly stated in the notice to the WG of that revision that it still did not address SECDIR's comments. At this juncture, because of the reorientation of the focus of the draft, it would seem better to wait out for more input from the WG before starting to consider how to best address the questions raised in your comments. =20 Let me assure you that there is no intention to side step your comments and any such impression would mostly be due to my fault of not communicating effectively. =20 Regards, Tzeta ------_=_NextPart_001_01CE1F2B.D93E6A25 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Stephen,

 

It was just = brought to my attention about your email on March 10 of the subject = SECDIR = review of draft-ietf-roll-security-threats-01. I wish to point = out that it had been explicitly stated in the notice to = the WG of that revision that it still did not address SECDIR's = comments. At this juncture, because of the reorientation of the focus of = the draft, it would seem better to wait out for more input from the WG = before starting to consider how to best address the questions raised in = your comments.

 

Let me = assure you that there is no intention to side step your comments and any = such impression would mostly be due to my fault of not communicating = effectively.

 

Regards,=

Tzeta<= o:p>

------_=_NextPart_001_01CE1F2B.D93E6A25-- From kent@bbn.com Tue Mar 12 07:34:47 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A854021F8B4A for ; Tue, 12 Mar 2013 07:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NS8L8tjIqjOw for ; Tue, 12 Mar 2013 07:34:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0E60E21F867B for ; Tue, 12 Mar 2013 07:34:47 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49266 helo=dhcp-1067.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UFQHo-0004O0-PJ; Tue, 12 Mar 2013 10:34:40 -0400 Message-ID: <513F3CFF.2010506@bbn.com> Date: Tue, 12 Mar 2013 10:34:39 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Tsao, Tzeta" References: <85A23E0910B2FB4B8EF60D0888CB083602658653@EVS2.nam.ci.root> In-Reply-To: <85A23E0910B2FB4B8EF60D0888CB083602658653@EVS2.nam.ci.root> Content-Type: multipart/alternative; boundary="------------010305060903000806080202" Cc: angel.lozano@upf.edu, mcr+ietf@sandelman.ca, vanesa.daza@upf.edu, secdir@ietf.org, jpv@cisco.com, "Alexander, Roger" , mischa.dohler@cttc.es, adrian@olddog.co.uk Subject: Re: [secdir] SECDIR review of draft-ietf-roll-security-threats-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:34:47 -0000 This is a multi-part message in MIME format. --------------010305060903000806080202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Tzeta, Thanks for the message, and the explanation. I was asked to re-review the doc because it was scheduled for IESG review soon, which would imply that it was completed. Feel free to send me email with any questions you have re my comments. I'm happy to provide additional details. Steve On 3/12/13 10:14 AM, Tsao, Tzeta wrote: > > Hi Stephen, > > It was just brought to my attention about your email on March 10 of > the subject SECDIR review of draft-ietf-roll-security-threats-01. I > wish to point out that it had been explicitly stated in the notice to > the WG of that revision that it still did not address SECDIR's > comments. At this juncture, because of the reorientation of the focus > of the draft, it would seem better to wait out for more input from the > WG before starting to consider how to best address the questions > raised in your comments. > > Let me assure you that there is no intention to side step your > comments and any such impression would mostly be due to my fault of > not communicating effectively. > > Regards, > > Tzeta > --------------010305060903000806080202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Tzeta,

Thanks for the message, and the explanation.  I was asked to re-review the doc because it
was scheduled for IESG review soon, which would imply that it was completed.

Feel free to send me email with any questions you have re my comments. I'm happy to provide additional
details.

Steve

On 3/12/13 10:14 AM, Tsao, Tzeta wrote:

Hi Stephen,

 

It was just brought to my attention about your email on March 10 of the subject SECDIR review of draft-ietf-roll-security-threats-01. I wish to point out that it had been explicitly stated in the notice to the WG of that revision that it still did not address SECDIR's comments. At this juncture, because of the reorientation of the focus of the draft, it would seem better to wait out for more input from the WG before starting to consider how to best address the questions raised in your comments.

 

Let me assure you that there is no intention to side step your comments and any such impression would mostly be due to my fault of not communicating effectively.

 

Regards,

Tzeta


--------------010305060903000806080202-- From adrian@olddog.co.uk Tue Mar 12 08:46:18 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5278211E80E0 for ; Tue, 12 Mar 2013 08:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L66+F0hbtCcR for ; Tue, 12 Mar 2013 08:46:15 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF7B11E80D3 for ; Tue, 12 Mar 2013 08:46:13 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2CFdl3R010921; Tue, 12 Mar 2013 15:39:47 GMT Received: from 950129200 (dhcp-1045.meeting.ietf.org [130.129.16.69]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r2CFdhja010874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Mar 2013 15:39:44 GMT From: "Adrian Farrel" To: "'Stephen Kent'" , "'Tsao, Tzeta'" References: <85A23E0910B2FB4B8EF60D0888CB083602658653@EVS2.nam.ci.root> <513F3CFF.2010506@bbn.com> In-Reply-To: <513F3CFF.2010506@bbn.com> Date: Tue, 12 Mar 2013 15:39:42 -0000 Message-ID: <03f001ce1f37$d304e9e0$790ebda0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03F1_01CE1F37.D3089360" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIrY366ZbZdYlxdxmbysueACRJffgK5UOLbl9HcDzA= Content-Language: en-gb Cc: angel.lozano@upf.edu, mcr+ietf@sandelman.ca, vanesa.daza@upf.edu, secdir@ietf.org, jpv@cisco.com, "'Alexander, Roger'" , mischa.dohler@cttc.es Subject: Re: [secdir] SECDIR review of draft-ietf-roll-security-threats-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2013 15:46:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03F1_01CE1F37.D3089360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yeah, sorry, that was my screw-up in the run-up to the IETF meeting. I missed your review as needing work. The authors have promised to work on this very soon, but if I don't see an update in fairly short order I will punt the document to a later IESG call. A From: Stephen Kent [mailto:kent@bbn.com] Sent: 12 March 2013 14:35 To: Tsao, Tzeta Cc: mcr+ietf@sandelman.ca; secdir@ietf.org; angel.lozano@upf.edu; vanesa.daza@upf.edu; mischa.dohler@cttc.es; Alexander, Roger; jpv@cisco.com; adrian@olddog.co.uk Subject: Re: SECDIR review of draft-ietf-roll-security-threats-01 Tzeta, Thanks for the message, and the explanation. I was asked to re-review the doc because it was scheduled for IESG review soon, which would imply that it was completed. Feel free to send me email with any questions you have re my comments. I'm happy to provide additional details. Steve On 3/12/13 10:14 AM, Tsao, Tzeta wrote: Hi Stephen, It was just brought to my attention about your email on March 10 of the subject SECDIR review of draft-ietf-roll-security-threats-01. I wish to point out that it had been explicitly stated in the notice to the WG of that revision that it still did not address SECDIR's comments. At this juncture, because of the reorientation of the focus of the draft, it would seem better to wait out for more input from the WG before starting to consider how to best address the questions raised in your comments. Let me assure you that there is no intention to side step your comments and any such impression would mostly be due to my fault of not communicating effectively. Regards, Tzeta ------=_NextPart_000_03F1_01CE1F37.D3089360 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yeah, sorry, that was = my screw-up in the run-up to the IETF meeting. I missed your review as = needing work.

 

The authors have = promised to work on this very soon, but if I don't see an update in = fairly short order I will punt the document to a later IESG = call.

 

A

 

From: = Stephen Kent [mailto:kent@bbn.com]
Sent: 12 March 2013 = 14:35
To: Tsao, Tzeta
Cc: mcr+ietf@sandelman.ca; = secdir@ietf.org; angel.lozano@upf.edu; vanesa.daza@upf.edu; = mischa.dohler@cttc.es; Alexander, Roger; jpv@cisco.com; = adrian@olddog.co.uk
Subject: Re: SECDIR review of = draft-ietf-roll-security-threats-01

 

Tzeta,

Thanks = for the message, and the explanation.  I was asked to re-review the = doc because it
was scheduled for IESG review soon, which would imply = that it was completed.

Feel free to send me email with any = questions you have re my comments. I'm happy to provide = additional
details.

Steve

On 3/12/13 10:14 AM, Tsao, Tzeta = wrote:

Hi = Stephen,

 =

It was just = brought to my attention about your email on March 10 of the subject = SECDIR = review of draft-ietf-roll-security-threats-01. I wish to point = out that it had been explicitly stated in the notice to = the WG of that revision that it still did not address SECDIR's = comments. At this juncture, because of the reorientation of the focus of = the draft, it would seem better to wait out for more input from the WG = before starting to consider how to best address the questions raised in = your comments.

 =

Let me = assure you that there is no intention to side step your comments and any = such impression would mostly be due to my fault of not communicating = effectively.

 =

Regards,

Tzeta<= o:p>

 

------=_NextPart_000_03F1_01CE1F37.D3089360-- From mcr@sandelman.ca Tue Mar 12 10:48:14 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7787E21F8A2A for ; Tue, 12 Mar 2013 10:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ra2-hVL+FX6 for ; Tue, 12 Mar 2013 10:48:09 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB2621F8A0B for ; Tue, 12 Mar 2013 10:48:07 -0700 (PDT) Received: from sandelman.ca (unknown [130.129.16.118]) by relay.sandelman.ca (Postfix) with ESMTPS id 5B92B22060; Tue, 12 Mar 2013 17:48:06 +0000 (UTC) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1D5D6CA0CB; Tue, 12 Mar 2013 13:48:03 -0400 (EDT) From: Michael Richardson To: "Tsao, Tzeta" In-reply-to: <85A23E0910B2FB4B8EF60D0888CB083602658653@EVS2.nam.ci.root> References: <85A23E0910B2FB4B8EF60D0888CB083602658653@EVS2.nam.ci.root> Comments: In-reply-to "Tsao, Tzeta" message dated "Tue, 12 Mar 2013 10:14:02 -0400." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 12 Mar 2013 13:48:02 -0400 Message-ID: <11981.1363110482@sandelman.ca> Sender: mcr@sandelman.ca Cc: angel.lozano@upf.edu, vanesa.daza@upf.edu, secdir@ietf.org, jpv@cisco.com, "Alexander, Roger" , mischa.dohler@cttc.es, adrian@olddog.co.uk Subject: Re: [secdir] SECDIR review of draft-ietf-roll-security-threats-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 17:48:14 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Tsao," =3D=3D Tsao, Tzeta writes: Tsao> juncture, because of the reorientation of the focus of the draft,= it Tsao> would seem better to wait out for more input from the WG before s= tarting Tsao> to consider how to best address the questions raised in your Tsao> comments.=20 If the WG is going to be able to provide you with more input, then we need to take the comments and structure them into a series of discussions.=20=20 The easiest way to do this is to turn them into issues in the tracker.=20 Again, would you like me to do this, or would you prefer to do this yourself? =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJRP2pRAAoJEKD0KQ7Gj3P2Ge4H/AnVcKsiiG2ukZlAUBV4x8Fc XM03HgJnhxBwvNDem6HAhLmnk+Fg68/O8bIK/6UyCNTs8vgha4UVGQKwYU09bCJ/ MXFKBA4bLzUEr9bn9PQc08NcttDGWr+bTfSkbs1GQ35r9pjfVo4t+yTJE/KfN4Rx SSXBgiazRKH2cqG9FZ2PskIoXbFG/1kBvI2Tg9x/Wm4w2fTwjvmxxA0bgg3zycO4 GSB0BVOR3rTyOp6DSTi/HoMugvZYxV84nyhQgNFwQCRAv48vOieFMQtqidXG5WDY jw5me8FIQuM6hUeV8zNq8EsWScgpp/U8RJWb6kblpS2bMTTj6RJ2mVmAt1FUuIQ= =rbF2 -----END PGP SIGNATURE----- --=-=-=-- From prvs=776cb6add=Tzeta.Tsao@cooperindustries.com Tue Mar 12 11:19:58 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9689211E80FB for ; Tue, 12 Mar 2013 11:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRf-c-94DBeB for ; Tue, 12 Mar 2013 11:19:57 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfa.amsl.com (Postfix) with ESMTP id AFBD321F8AC1 for ; Tue, 12 Mar 2013 11:19:56 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.84,832,1355115600"; d="scan'208";a="91680143" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 12 Mar 2013 14:19:56 -0400 Received: from EVS2.NAM.CI.ROOT ([10.132.108.170]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Mar 2013 14:19:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Mar 2013 14:19:54 -0400 Message-ID: <85A23E0910B2FB4B8EF60D0888CB0836026A7219@EVS2.nam.ci.root> In-Reply-To: <11981.1363110482@sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SECDIR review of draft-ietf-roll-security-threats-01 Thread-Index: Ac4fScTWinY+ziqHRUeu33Yof+OKXgAArgYA References: <85A23E0910B2FB4B8EF60D0888CB083602658653@EVS2.nam.ci.root> <11981.1363110482@sandelman.ca> From: "Tsao, Tzeta" To: "Michael Richardson" X-OriginalArrivalTime: 12 Mar 2013 18:19:56.0028 (UTC) FILETIME=[32C933C0:01CE1F4E] Cc: angel.lozano@upf.edu, vanesa.daza@upf.edu, secdir@ietf.org, jpv@cisco.com, "Alexander, Roger" , mischa.dohler@cttc.es, adrian@olddog.co.uk Subject: Re: [secdir] SECDIR review of draft-ietf-roll-security-threats-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 18:19:58 -0000 So far, the biggest structure change discussed is the removal of Section 6, even though that was a result of a lot of effort. If that is where we want to go, let me take the first cut; will also see what I can manage in that process in terms of Steve's comments. We can then decide what exactly will need further attention. Let me know if you see a different approach. Thanks, Tzeta=20 > -----Original Message----- > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael > Richardson > Sent: Tuesday, March 12, 2013 1:48 PM > To: Tsao, Tzeta > Cc: kent@bbn.com; secdir@ietf.org; angel.lozano@upf.edu; > vanesa.daza@upf.edu; mischa.dohler@cttc.es; Alexander, Roger; > jpv@cisco.com; adrian@olddog.co.uk > Subject: Re: SECDIR review of draft-ietf-roll-security-threats-01 >=20 >=20 > >>>>> "Tsao," =3D=3D Tsao, Tzeta = writes: > Tsao> juncture, because of the reorientation of the focus of the draft, it > Tsao> would seem better to wait out for more input from the WG before > starting > Tsao> to consider how to best address the questions raised in your > Tsao> comments. >=20 > If the WG is going to be able to provide you with more input, then we need > to take the comments and structure them into a series of discussions. > The easiest way to do this is to turn them into issues in the tracker. >=20 > Again, would you like me to do this, or would you prefer to do this yourself? >=20 > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From stephen.farrell@cs.tcd.ie Thu Mar 14 08:07:18 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D720311E8249 for ; Thu, 14 Mar 2013 08:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TXgRKEtrBZU for ; Thu, 14 Mar 2013 08:07:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1F611E8244 for ; Thu, 14 Mar 2013 08:07:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A15EBBE5A for ; Thu, 14 Mar 2013 15:06:45 +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 xsHRn3Bd-0gd for ; Thu, 14 Mar 2013 15:06:36 +0000 (GMT) Received: from [130.129.96.60] (dhcp-603c.meeting.ietf.org [130.129.96.60]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B799BBE58 for ; Thu, 14 Mar 2013 15:06:35 +0000 (GMT) Message-ID: <5141E77A.5000802@cs.tcd.ie> Date: Thu, 14 Mar 2013 15:06:34 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "secdir@ietf.org" References: <53051.1363266874@olddog.co.uk> In-Reply-To: <53051.1363266874@olddog.co.uk> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <53051.1363266874@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] Fwd: Re: Improved mentoring program X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:07:19 -0000 FYI. Would we be willing to do something similar for the SEC area? Doesn't have to be secdir folks only but maybe one of you would be willing to be a contact point and a few of you would be willing to help? S. -------- Original Message -------- Subject: Re: Improved mentoring program Date: Thu, 14 Mar 2013 13:14:34 +0000 From: Adrian Farrel Reply-To: adrian@olddog.co.uk To: IESG , Brian Haberman Brian, I now have a list of volunteers culled from last night. New people still coming in. In the Routing Area meeting this afternoon, Stewart and I will be launching the Routing Area Mentor Team, and the Routing Area Buddy Program. Details TBD. A On Thu 14/03/13 1:01 PM , "Brian Haberman" brian@innovationslab.net sent: > All, > I mentioned to Jari this morning that I am going to look into ways > to increase the level of mentoring within the IETF. If you have ideas, > let me know. Otherwise, I am hoping to have some ideas pulled together > by the retreat. > > Brian > > > From stephen.farrell@cs.tcd.ie Fri Mar 15 18:57:40 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722B311E8111 for ; Fri, 15 Mar 2013 18:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Itr8Ff5hPX+1 for ; Fri, 15 Mar 2013 18:57:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C524911E80C5 for ; Fri, 15 Mar 2013 18:57:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 26BC1BE70 for ; Sat, 16 Mar 2013 01:57:15 +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 hILGVpSBCcMJ for ; Sat, 16 Mar 2013 01:57:13 +0000 (GMT) Received: from [130.129.129.49] (unknown [130.129.129.49]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 839BCBE6F for ; Sat, 16 Mar 2013 01:57:13 +0000 (GMT) Message-ID: <5143D178.3060300@cs.tcd.ie> Date: Sat, 16 Mar 2013 01:57:12 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "secdir@ietf.org" References: <5143D0A4.8090209@cs.tcd.ie> In-Reply-To: <5143D0A4.8090209@cs.tcd.ie> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <5143D0A4.8090209@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] Fwd: directorates helping ADs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 01:57:40 -0000 Hiya, This is how I summarised our lunch discussion to the IESG. Please let me know if I got something horribly wrong. And of course, more discussion/ideas on this list is also welcome. Cheers, S. -------- Original Message -------- Subject: directorates helping ADs Date: Sat, 16 Mar 2013 01:53:40 +0000 From: Stephen Farrell To: IESG Hi, The AD-time-crunch discussion seems to throw up a recurring response - get the directorates to do more. We talked about that at the secdir lunch this week. Note that we started by saying that there are no proposals to change anything now, we were just looking to base our discussion on some secdir input, and this was only about the SEC area. At the end of our discussion this is what I noted: - secdir members are also busy, mostly 120% as well, so we can't assume that they have the bandwidth to do more - we currently get about 80% of drafts reviewed with 50+ secdir reviewers, if secdir membership becomes more onerous a lot felt that the 80% figure would decrease, maybe by a lot - if secdir members are given more responsibility (e.g. to follow up discusses) then what power goes with that responsibility? - some argued that there ought be less review of drafts, but others argued that reviews are very good and an important part of IETF quality control - some argued that moving reviews earlier might reduce the workload on ADs, but nobody knows how to get there - the idea of having 3 (or 4) AD-like roles per area was raised, but obviously wasn't fleshed out - I think the idea might be along the lines of having 2 assistant AD positions and one AD with tasks and powers distributed amongst those (maybe the assistants do reviews or something) - if we figure out something that looks like its worth trying then we probably want to start by trying that for a few drafts where all parties are ok with trying out whatever is to be tried out, i.e. start any directorate experiments on a doc by doc basis. I guess I'd summarise by saying that shifting from having directorates help to making them responsible is not an easy change to make. Cheers, S. From clonvick@cisco.com Mon Mar 18 13:27:39 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F86221F9135; Mon, 18 Mar 2013 13:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRaNNXXLVmUF; Mon, 18 Mar 2013 13:27:38 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A6F8221F8F4F; Mon, 18 Mar 2013 13:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1778; q=dns/txt; s=iport; t=1363638458; x=1364848058; h=date:from:to:subject:message-id:mime-version; bh=1ABfMKyAP2Q6IPO15zAHUUBy++N8fWGZPG0+GIHb3+g=; b=R9girF5kpVq2g7ATKzMw4D5hwZoXBSCEx+3jXa2qOs5HahzUMmagg+6c AcHCJylM6S66GeBK9dkT/s5RS0R/+Q1kJV1ep4hZgi4g/53KpBOq8dtm1 qY3TC7woTOJHoYqYVi77IyEad+L5v1RnmrgFd5cSjUC8v8JU6V8NqENd3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANl3R1GrRDoJ/2dsb2JhbABDxncWdIJjAoF+iCXCEpJcA4h1nmuDKg X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208";a="73366187" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 18 Mar 2013 20:27:38 +0000 Received: from sjc-xdm-114 (sjc-xdm-114.cisco.com [171.71.188.119]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2IKRcFI021337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Mar 2013 20:27:38 GMT Date: Mon, 18 Mar 2013 13:27:38 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-ietf-xrblock-rtcp-xr-burst-gap-loss.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 Subject: [secdir] SECDIR review of draft-ietf-xrblock-rtcp-xr-burst-gap-loss-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 20:27:39 -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. I don't see any problems with this. The only nit that I found was that I couldn't fully understand a part of section 3.2. Loss and Discard Combination flag (C): 1 bit The 'C' flag is used to indicate whether combining loss/discard report is needed. This field MUST be set to '1' if the burst gap loss report is present in conjunction with the burst gap discard report in the same compound RTCP packet and MUST be set to '0' otherwise. If the burst gap discard is not sent with the burst gap loss, then the receiver MUST discard the burst gap loss with 'C' flag set to 1. If the 'C' flag is set to 0, then receiver MUST NOT discard the burst gap loss Metrics Block when the burst gap discard is not received. Maybe something like the following: The 'C' flag is used to indicate whether the loss/discard report is combined with the burst gap loss report in the same compound RTCP packet. The value MUST be set to '1' if the loss/discard report and the burst gap loss report are combined. Otherwise, the value MUST be set to '0'. If the burst gap discard is not sent with the burst gap loss, then the receiver MUST discard the burst gap loss with 'C' flag set to 1. If the 'C' flag is set to 0, then receiver MUST NOT discard the burst gap loss Metrics Block when the burst gap discard is not received. Best regards, Chris From Tina.Tsou.Zouting@huawei.com Tue Mar 19 16:54:18 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6AA21F87C5 for ; Tue, 19 Mar 2013 16:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMFuYyLDnCuG for ; Tue, 19 Mar 2013 16:54:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A155221F8667 for ; Tue, 19 Mar 2013 16:54:16 -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.5-GA FastPath queued) with ESMTP id APO54312; Tue, 19 Mar 2013 23:54:14 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 19 Mar 2013 23:53:18 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 19 Mar 2013 23:54:13 +0000 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.86]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Tue, 19 Mar 2013 16:54:06 -0700 From: Tina TSOU To: "secdir@ietf.org" Thread-Topic: Request for Operations Directorate Review of draft-ietf-pkix-rfc2560bis-15 by 2013-03-27 Thread-Index: Ac4k6ER0uw9hFVcFSEO2mwioQ20uhwAOxcSAAAmoNzA= Date: Tue, 19 Mar 2013 23:54:05 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.94] Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A815D168D2dfweml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ops-ads@tools.ietf.org" Subject: [secdir] FW: Request for Operations Directorate Review of draft-ietf-pkix-rfc2560bis-15 by 2013-03-27 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 23:54:18 -0000 --_000_C0E0A32284495243BDE0AC8A066631A815D168D2dfweml513mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQpXb3VsZCBhbnkgb2YgeW91IGxpa2UgdG8gcmV2aWV3IGRyYWZ0LWlldGYtcGtp eC1yZmMyNTYwYmlzLTE1LCBhbmQgcmVzcG9uZCB0byB0aGUgT1BTIEFyZWEgcXVlc3Rpb25zIGlu IEFwcGVuZGl4IEEgb2YgUkZDIDU3MDY/DQoNClRoYW5rIHlvdSwNClRpbmENCg0KRnJvbTogRnJl ZCBCYWtlciAoZnJlZCkgW21haWx0bzpmcmVkQGNpc2NvLmNvbV0NClNlbnQ6IDIwMTPE6jPUwjE5 yNUgMTY6MjgNClRvOiBUaW5hIFRTT1UNCkNjOiBvcHMtYWRzQHRvb2xzLmlldGYub3JnDQpTdWJq ZWN0OiBSZTogUmVxdWVzdCBmb3IgT3BlcmF0aW9ucyBEaXJlY3RvcmF0ZSBSZXZpZXcgb2YgZHJh ZnQtaWV0Zi1wa2l4LXJmYzI1NjBiaXMtMTUgYnkgMjAxMy0wMy0yNw0KDQpJIGhhdmUgbm8gZXhw ZXJ0aXNlIGluIHRoaXMgYXJlYS4gSSB3b3VsZCBzdHJvbmdseSBzdWdnZXN0IHlvdSBnZXQgYSBy ZXZpZXcgZnJvbSB0aGUgU2VjdXJpdHkgRGlyZWN0b3JhdGUgYXNraW5nIHRoZW0gdG8gcmVzcG9u ZCB0byB0aGUgT3BzIEFyZWEgcXVlc3Rpb25zLg0KDQpPbiBNYXIgMTksIDIwMTMsIGF0IDI6MjUg UE0sIFRpbmEgVFNPVSA8VGluYS5Uc291LlpvdXRpbmdAaHVhd2VpLmNvbTxtYWlsdG86VGluYS5U c291LlpvdXRpbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQoNCkhlbGxvLA0KQXMgYSBtZW1iZXIg b2YgdGhlIE9wZXJhdGlvbnMgRGlyZWN0b3JhdGUgeW91IGFyZSBiZWluZyBhc2tlZCB0byByZXZp ZXcgdGhlIGZvbGxvd2luZyBkcmFmdCB3aGljaCBpcyBpbiBJRVRGIGxhc3QgY2FsbCBmb3IgaXQn cyBvcGVyYXRpb25hbCBpbXBhY3QuDQoNCklFVEYgTGFzdCBDYWxsOg0KDQpUaGUgZmlsZSBjYW4g YmUgb2J0YWluZWQgdmlhDQoNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1wa2l4LXJmYzI1NjBiaXMvDQoNCklFU0cgZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2 aWENCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wa2l4LXJmYzI1 NjBiaXMvYmFsbG90Lw0KDQpQbGVhc2UgcHJvdmlkZSB5b3VyIHJldmlldyBieSAyMDEzLTAzLTI3 Lg0KU2VuZCB5b3VyIHJldmlldyB0byB0aGUgT1BTIERJUiBtYWlsaW5nIGxpc3QgKG9wcy1kaXJA aWV0Zi5vcmc8bWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmc+KSBhbmQgdG8gdGhlIGF1dGhvcnMsIFdH IGNoYWlycywgYW5kIHJlc3BlY3RpdmUgQUQuDQpUaGUgd2F5IHRvIHJlYWNoIHRoZSBhdXRob3Jz LCBXRyBjaGFpcnMsIGFuZCByZXNwZWN0aXZlIEFEIGlzIHRvIHNlbmQgYW4gZW1haWwgdG8gPGRy YWZ0LW5hbWU+LmFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86LmFsbEB0b29scy5pZXRmLm9yZz4N Cg0KQSBDaGVjay1saXN0IG9mIHBvc3NpYmxlIHF1ZXN0aW9ucy90b3BpY3MgdG8gYWRkcmVzcyBp biBhbiBPUFMtRElSIHJldmlldyBtYXkgYmUgZm91bmQgaW4gQXBwZW5kaXggQSBvZiBSRkMgNTcw Ni4NCk9ubHkgaW5jbHVkZSB0aGUgcXVlc3Rpb25zIHRoYXQgYXBwbHkgdG8geW91ciByZXZpZXcu DQoNCldvdWxkIHlvdSBhZGQgdGhlIHJldmlldyByZXF1ZXN0cyBhbmQgdXBkYXRlIHRoZSBzdGF0 dXMgYnkgeW91cnNlbGYgYXQgb3VyIHdpa2kgcGFnZT8NCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYu b3JnL2FyZWEvb3BzL3RyYWMvd2lraS9SZXZpZXdzDQoNCg0KVGhhbmsgeW91LA0KVGluYQ0KDQoN Cg0KDQoNCg== --_000_C0E0A32284495243BDE0AC8A066631A815D168D2dfweml513mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Dear all,

Would any of you like to = review draft-ietf-pkix-rfc2560bis-15, and respond to the OPS Area questions= in Appendix A of RFC 5706?

 <= /p>

Thank you,

Tina

 <= /p>

From: Fred Bak= er (fred) [mailto:fred@cisco.com]
Sent: 2013=C4=EA3=D4=C219= =C8=D5 16:28
To: Tina TSOU
Cc: ops-ads@tools.ietf.org
Subject: Re: Request for Operations Directorate Review of draft-ietf= -pkix-rfc2560bis-15 by 2013-03-27

 

I have no expertise in this area. I would strongly s= uggest you get a review from the Security Directorate asking them to respon= d to the Ops Area questions.

 

On Mar 19, 2013, at 2:25 PM, Tina TSOU <Tina.Tsou.Zouting@huawei.com&g= t; wrote:



Hello,

As a member of the Operations Directorate you are being as= ked to review the following draft which is in IETF last call for it's opera= tional impact.

 

IETF Last Call:

The file can be obtained via

http://datatracker.ietf.org/d= oc/draft-ietf-pkix-rfc2560bis/

IESG discussion can be tracked via

 

Please provide your review by 2013-03-27.
Send your review to the OPS DIR mailing list (ops-dir@ietf.org) and to= the authors, WG chairs, and respective AD. 
The way to reach the authors, WG chairs, and respective AD is to send an em= ail to <draft-name>.all@tools.ietf.org

 

A Check-list of possible questions/topics to address in an= OPS-DIR review may be found in Appendix A of RFC 5706.

Only include the questions that apply to your review.

 

Would you add the review requests and update the status by= yourself at our wiki page?

 

 

Thank you,

Tina

 

 

 

 

 

--_000_C0E0A32284495243BDE0AC8A066631A815D168D2dfweml513mbschi_-- From bill.wu@huawei.com Thu Mar 21 04:13:38 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5553921F9014; Thu, 21 Mar 2013 04:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.037 X-Spam-Level: X-Spam-Status: No, score=-3.037 tagged_above=-999 required=5 tests=[AWL=1.809, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIlGuW0Wd5s3; Thu, 21 Mar 2013 04:13:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2E43221F8A4E; Thu, 21 Mar 2013 04:13:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQY28656; Thu, 21 Mar 2013 11:13:34 +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.1.323.7; Thu, 21 Mar 2013 11:13:34 +0000 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 11:13:33 +0000 Received: from w53375 (10.138.41.149) by szxeml418-hub.china.huawei.com (10.82.67.157) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 19:13:28 +0800 Message-ID: From: Qin Wu To: Chris Lonvick , , , References: Date: Thu, 21 Mar 2013 19:13:28 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [secdir] SECDIR review of draft-ietf-xrblock-rtcp-xr-burst-gap-loss-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 11:13:38 -0000 SGksIENocmlzOg0KWW91ciBwcm9wb3NlZCBjaGFuZ2UgbG9va3MgZ29vZCB0byBtZSwgdGhhbmtz IQ0KDQpSZWdhcmRzDQotUWluDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTog IkNocmlzIExvbnZpY2siIDxjbG9udmlja0BjaXNjby5jb20+DQpUbzogPGllc2dAaWV0Zi5vcmc+ OyA8c2VjZGlyQGlldGYub3JnPjsgPGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLWJ1cnN0LWdh cC1sb3NzLmFsbEB0b29scy5pZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDE5LCAyMDEz IDQ6MjcgQU0NClN1YmplY3Q6IFNFQ0RJUiByZXZpZXcgb2YgZHJhZnQtaWV0Zi14cmJsb2NrLXJ0 Y3AteHItYnVyc3QtZ2FwLWxvc3MtMDgNCg0KDQo+IEhpLA0KPiANCj4gSSBoYXZlIHJldmlld2Vk IHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncw0KPiBv bmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3Nl ZCBieSB0aGUNCj4gSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkg Zm9yIHRoZSBiZW5lZml0IG9mIHRoZQ0KPiBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3Vt ZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQNCj4gdGhlc2UgY29tbWVudHMg anVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+IA0KPiBJIGRvbid0IHNl ZSBhbnkgcHJvYmxlbXMgd2l0aCB0aGlzLiAgVGhlIG9ubHkgbml0IHRoYXQgSSBmb3VuZCB3YXMg dGhhdCBJIA0KPiBjb3VsZG4ndCBmdWxseSB1bmRlcnN0YW5kIGEgcGFydCBvZiBzZWN0aW9uIDMu Mi4NCj4gDQo+ICAgTG9zcyBhbmQgRGlzY2FyZCBDb21iaW5hdGlvbiBmbGFnIChDKTogMSBiaXQN Cj4gDQo+ICAgICAgIFRoZSAnQycgZmxhZyBpcyB1c2VkIHRvIGluZGljYXRlIHdoZXRoZXIgY29t YmluaW5nIGxvc3MvZGlzY2FyZA0KPiAgICAgICByZXBvcnQgaXMgbmVlZGVkLiAgVGhpcyBmaWVs ZCBNVVNUIGJlIHNldCB0byAnMScgaWYgdGhlIGJ1cnN0IGdhcA0KPiAgICAgICBsb3NzIHJlcG9y dCBpcyBwcmVzZW50IGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIGJ1cnN0IGdhcCBkaXNjYXJkDQo+ ICAgICAgIHJlcG9ydCBpbiB0aGUgc2FtZSBjb21wb3VuZCBSVENQIHBhY2tldCBhbmQgTVVTVCBi ZSBzZXQgdG8gJzAnDQo+ICAgICAgIG90aGVyd2lzZS4gIElmIHRoZSBidXJzdCBnYXAgZGlzY2Fy ZCBpcyBub3Qgc2VudCB3aXRoIHRoZSBidXJzdA0KPiAgICAgICBnYXAgbG9zcywgdGhlbiB0aGUg cmVjZWl2ZXIgTVVTVCBkaXNjYXJkIHRoZSBidXJzdCBnYXAgbG9zcyB3aXRoDQo+ICAgICAgICdD JyBmbGFnIHNldCB0byAxLiAgSWYgdGhlICdDJyBmbGFnIGlzIHNldCB0byAwLCB0aGVuIHJlY2Vp dmVyDQo+ICAgICAgIE1VU1QgTk9UIGRpc2NhcmQgdGhlIGJ1cnN0IGdhcCBsb3NzIE1ldHJpY3Mg QmxvY2sgd2hlbiB0aGUgYnVyc3QNCj4gICAgICAgZ2FwIGRpc2NhcmQgaXMgbm90IHJlY2VpdmVk Lg0KPiANCj4gTWF5YmUgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZzoNCj4gDQo+IFRoZSAn QycgZmxhZyBpcyB1c2VkIHRvIGluZGljYXRlIHdoZXRoZXIgdGhlIGxvc3MvZGlzY2FyZCByZXBv cnQgaXMgDQo+IGNvbWJpbmVkIHdpdGggdGhlIGJ1cnN0IGdhcCBsb3NzIHJlcG9ydCBpbiB0aGUg c2FtZSBjb21wb3VuZCBSVENQIHBhY2tldC4gDQo+IFRoZSB2YWx1ZSBNVVNUIGJlIHNldCB0byAn MScgaWYgdGhlIGxvc3MvZGlzY2FyZCByZXBvcnQgYW5kIHRoZSBidXJzdCBnYXAgDQo+IGxvc3Mg cmVwb3J0IGFyZSBjb21iaW5lZC4gIE90aGVyd2lzZSwgdGhlIHZhbHVlIE1VU1QgYmUgc2V0IHRv ICcwJy4gIElmIA0KPiB0aGUgYnVyc3QgZ2FwIGRpc2NhcmQgaXMgbm90IHNlbnQgd2l0aCB0aGUg YnVyc3QgZ2FwIGxvc3MsIHRoZW4gdGhlIA0KPiByZWNlaXZlciBNVVNUIGRpc2NhcmQgdGhlIGJ1 cnN0IGdhcCBsb3NzIHdpdGggJ0MnIGZsYWcgc2V0IHRvIDEuICBJZiB0aGUgDQo+ICdDJyBmbGFn IGlzIHNldCB0byAwLCB0aGVuIHJlY2VpdmVyIE1VU1QgTk9UIGRpc2NhcmQgdGhlIGJ1cnN0IGdh cCBsb3NzIA0KPiBNZXRyaWNzIEJsb2NrIHdoZW4gdGhlIGJ1cnN0IGdhcCBkaXNjYXJkIGlzIG5v dCByZWNlaXZlZC4NCj4gDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IENocmlz From kivinen@iki.fi Thu Mar 21 14:03:00 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA9721F8970 for ; Thu, 21 Mar 2013 14:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sb-pvvnvvB5r for ; Thu, 21 Mar 2013 14:03: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 84B2721F8CCF for ; Thu, 21 Mar 2013 14:02:59 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r2LL2rFP011919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Mar 2013 23:02:53 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r2LL2qZj015267; Thu, 21 Mar 2013 23:02:52 +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: <20811.30076.686637.240917@fireball.kivinen.iki.fi> Date: Thu, 21 Mar 2013 23:02:52 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2013 21:03:00 -0000 Note, that there are some quite big documents in this assignment round. Including RFC2560bis (OCSP, 43 pages), Coap protocol (110 pages), and RFC3530bis (NFSv4, 321 pages), so suggest making sure you start your reviews early... Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Eric Rescorla is next in the rotation. For telechat 2013-03-28 Reviewer LC end Draft Jeffrey Hutzelman TR2013-02-26 draft-laurie-pki-sunlight-09 Glen Zorn T 2013-02-11 draft-ietf-mpls-tp-use-cases-and-design-07 For telechat 2013-04-11 Warren Kumari T 2013-03-26 draft-merkle-ikev2-ke-brainpool-03 Julien Laganier T 2013-03-18 draft-ietf-appsawg-webfinger-11 Sandy Murphy T 2013-03-27 draft-ietf-pkix-rfc2560bis-15 Hilarie Orman T 2013-03-29 draft-ietf-tls-multiple-cert-status-extension-04 Radia Perlman T 2013-04-09 draft-saintandre-urn-example-04 Last calls and special requests: Rob Austein 2013-03-06 draft-arkko-iesg-crossarea-03 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Dan Harkins R2013-04-01 draft-ietf-ipfix-flow-selection-tech-14 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-09 Ben Laurie 2013-03-29 draft-ietf-ospf-ipv4-embedded-ipv6-routing-07 Matt Lepinski 2013-03-15 draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10 Alexey Melnikov 2013-03-27 draft-ietf-core-coap-14 Kathleen Moriarty 2013-04-03 draft-ietf-dnsext-dnssec-algo-signal-09 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Russ Mundy 2013-03-30 draft-ietf-roll-terminology-12 Yoav Nir 2013-04-16 draft-ietf-nfsv4-rfc3530bis-25 Magnus Nystrom 2013-04-16 draft-ietf-nfsv4-rfc3530bis-dot-x-16 Eric Rescorla 2013-01-24 draft-ietf-ospf-ospfv3-iid-registry-update-02 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-04 Nico Williams - draft-ietf-httpbis-p5-range-22 -- kivinen@iki.fi From vincent.roca@inria.fr Fri Mar 22 04:39:35 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA96B21F8511; Fri, 22 Mar 2013 04:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.249 X-Spam-Level: X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+V0ejU7dQH6; Fri, 22 Mar 2013 04:39:33 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfa.amsl.com (Postfix) with ESMTP id 016A021F8992; Fri, 22 Mar 2013 04:39:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,891,1355094000"; d="scan'208";a="8826029" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 22 Mar 2013 12:39:22 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: Date: Fri, 22 Mar 2013 12:39:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0C83FA61-4E84-432B-A946-A052C8E0C30D@inria.fr> References: To: Chris Lonvick X-Mailer: Apple Mail (2.1085) Cc: draft-ietf-rmt-fcast.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-rmt-fcast-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 11:39:35 -0000 Hello Chris, Thanks a lot for your review. Here are our answers. And sorry for our very long delay. > 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 > Overall, I believe that security was addressed fairly well in the = document. I do have some problems with the text in the Security = Considerations section. It would help if the authors would review RFC = 4949, "The Internet Security Glossary, v2", and consistently apply the = terms throughout the paper. Along that line, I'm suggesting some = corrections for the Security Considerations section, below. Some are = editorial just to make some statements more clear. I was not aware of this glossary. That's impressive and useful. Thanks for the pointer. > I would also recommend that the Working Group perform a quick threat = analysis and use that as the basis for addressing the potential = weaknesses. This can be done by referencing BCP72 and creating a list = of threats that the WG consider to be significant and describing the = mechanisms that would appropriately address them. The WG may wish to = look at Section 2 of RFC 5425 as an example. We agree, and we already wrote such an I-D: http://tools.ietf.org/html/draft-ietf-rmt-sec-discussion-07 > Also, the subsection titles in 4.2 and 4.3 could be straightened out. = Right now you have: > 4.2 Attacks Against blahblah > 4.2.1 Abc > 4.2.2 Bcd > ... > 4.3 Attacks Against otherblahblah > 4.3.1 Attacks Against Klm > 4.3.2 Attacks Against Lmn Done. > My comments are preceded by "CML%" and my suggested text is preceded = by "CML>". >=20 > =3D=3D=3Dvvv=3D=3D=3D >=20 >=20 > 4. Security Considerations >=20 > 4.1. Problem Statement >=20 > A content delivery system is potentially subject to attacks. = Attacks > may target: >=20 > CML> A content deliver system may be subject to attacks that may = target the following: Done. > o the network (to compromise the routing infrastructure, e.g., by > creating congestion), >=20 > CML> the network; to compromise the delivery infrastructure (e.g., by > CML> creating congestion), Done. > o the Content Delivery Protocol (CDP) (e.g., to compromise the > normal behavior of FCAST), or >=20 > CML> the Content Delivery Protocol (CDP); to compromise the delivery > CML> mechanism (i.e., FCAST in this case), Done. > o the content itself (e.g., to corrupt the objects being > transmitted). >=20 > CML> the content itself; to corrupt the objects being transmitted. Done. > These attacks can be launched either: >=20 > CML> These attacks can be launched against all or any subset of the = CML> following: Done. > o against the data flow itself (e.g., by sending forged packets), >=20 > o against the session control parameters (e.g., by corrupting the > session description, the CID, the object meta-data, or the = ALC/LCT > control parameters), that are sent either in-band or out-of-band, > or >=20 > o against some associated building blocks (e.g., the congestion > control component). >=20 > In the following sections we provide more details on these possible > attacks and sketch some possible counter-measures. We finally > provide recommendations in Section 4.5. >=20 > CML> More details on these potential attacks are provided in the = following > CML> sections along with possible counter-measures. Recommendations = are > CML> made in Section 4.5. Done. > 4.2. Attacks Against the Data Flow >=20 > Let us consider attacks against the data flow first. At least, the > following types of attacks exist: >=20 > CML> The following types of attacks exist against the data flow: Done. > o attacks that are meant to give access to a confidential object > (e.g., in case of a non-free content) and >=20 > CML> attacks that are meant to gain unauthorized access to a = confidential > CML> object (e.g., obtaining non-free content without purchasing it) = and Done > o attacks that try to corrupt the object being transmitted (e.g., = to > inject malicious code within an object, or to prevent a receiver > from using an object, which is a kind of Denial of Service = (DoS)). >=20 > 4.2.1. Access to Confidential Objects >=20 > Access control to the object being transmitted is typically provided > by means of encryption. This encryption can be done over the whole > object (e.g., by the content provider, before submitting the object > to FCAST), or be done on a packet per packet basis (e.g., when = IPsec/ > ESP is used [RFC4303], see Section 4.5). If confidentiality is a > concern, it is RECOMMENDED that one of these solutions be used. >=20 > CML% When you say "typically provided" you're indicating that some = other > CML% solution has been used in the past. I don't see that prior = mechanism > CML% has been referenced. On the other hand, if you're indicating = that > CML% some general solution has been applied, and is applicable in this > CML% solution then I'll recommend the following replacement paragraph. > CML> > CML> Modern cryptographic mechanisms can provide access controls to > CML> transmitted objects. One way to do this is by encrypting the > CML> entire object prior to transmission knowing that authenticated > CML> receivers have the cryptographic mechanisms to decrypt the > CML> content. Another mechanism that has been employed is to encrypt > CML> individual packets using IPsec/ESP [RFC4303] (Section 4.5). If > CML> access control is desired, one of these mechanisms is RECOMMENDED > CML> and should be deployed. Fully agree. Done. > CML% In the last sentence, you're suddenly bringing in = confidentiality. > CML% That should be described in a separate paragraph. Perhaps like > CML% the following paragraph. > CML> > CML> Modern cryptographic services can also provide confidentiality of = the > CML> object being transferred to prevent the content from being = reassembled > CML> by an unauthorized observer. See section 4.5 if that is desired. I agree. NEW: Modern cryptographic mechanisms can provide access control to=20 transmitted objects. One way to do this is by encrypting the entire object prior to transmission, knowing that authenticated receivers have the cryptographic mechanisms to decrypt the content. Another way is to encrypt individual packets using IPsec/ESP [RFC4303] (Section 5.5). These two technics can also provide confidentiality to the objects being transferred. =20 If access control and/or confidentiality services are desired, one of these mechanisms is RECOMMENDED and SHOULD be deployed. > 4.2.2. Object Corruption >=20 > Protection against corruptions (e.g., if an attacker sends forged > packets) is achieved by means of a content integrity verification/ > sender authentication scheme. This service can be provided at the > object level, but in that case a receiver has no way to identify > which symbol(s) is(are) corrupted if the object is detected as > corrupted. This service can also be provided at the packet level. > In this case, after removing all corrupted packets, the file may be > in some cases recovered. Several techniques can provide this = content > integrity/sender authentication service: >=20 > CML% An attacker injecting forged packets is not corruption. =46rom = the > CML% list below, I believe that you want to say something more like = the > CML% following. > CML> > CML> 4.2.2 Object Data Integrity > CML> > CML> Protection against attacks on the data integrity of the object = may > CML> be achieved by a mechanism agreed upon between the sender and > CML> receiver that features sender authentication and a method to > CML> verify that the integrity of the object has remained intact = during > CML> transmission. This service can be provided at the > CML> object level, but in that case a receiver has no way to identify > CML> which symbol(s) is(are) corrupted if the object is detected as > CML> corrupted. This service can also be provided at the packet = level. > CML> In some cases, after removing all corrupted packets, the file may = be > CML> recovered. Several techniques can provide a data integrity = service as > CML> well as a service that provides sender authentication. Done. > o at the object level, the object can be digitally signed, for > instance by using RSASSA-PKCS1-v1_5 [RFC3447]. This signature > enables a receiver to check the object integrity, once this = latter > CML% I'd suggest removing ", once this latter has been fully decoded." > CML% It's not needed. Done. > has been fully decoded. Even if digital signatures are > computationally expensive, this calculation occurs only once per > object, which is usually acceptable; >=20 > o at the packet level, each packet can be digitally signed > [RFC6584]. A major limitation is the high computational and > transmission overheads that this solution requires. To avoid = this > problem, the signature may span a set of packets (instead of a > single one) in order to amortize the signature calculation. But > if a single packets is missing, the integrity of the whole set > cannot be checked; > CML% I'm not real familiar with RFC6584 so I just glanced through it. > CML% It appears that each mechanism described in that document = requires > CML% a signature per packet. I may be wrong but I'll ask that you > CML% review that to ensure that your recommendation of providing a > CML% signature across a group of packets is correct. Our sentence is misleading. RFC6584 does not consider signing a group of packets. It is restricted to a per-packet signature. I've = removed any reference to signing across a group of packets. Good point. > o at the packet level, a Group Message Authentication Code (MAC) > [RFC2104][RFC6584] scheme can be used, for instance by using = HMAC- > SHA-256 with a secret key shared by all the group members, = senders > and receivers. This technique creates a cryptographically = secured > digest of a packet that is sent along with the packet. The Group > MAC scheme does not create prohibitive processing load nor > transmission overhead, but it has a major limitation: it only > provides a group authentication/integrity service since all group > members share the same secret group key, which means that each > member can send a forged packet. It is therefore restricted to > situations where group members are fully trusted (or in > association with another technique as a pre-check); > CML% I don't understand that last parenthetical. What is the meaning = of: > CML% "(or in association with another technique as a pre-check)"? NEW: It is therefore restricted to situations where group members are fully trusted, or in association with another technique as a pre-check to quickly detect attacks initiated by non-group members and discard their packets; > o at the packet level, Timed Efficient Stream Loss-Tolerant > Authentication (TESLA) [RFC4082][RFC5776] is an attractive > solution that is robust to losses, provides a true = authentication/ > integrity service, and does not create any prohibitive processing > load or transmission overhead. Yet checking a packet requires a > small delay (a second or more) after its reception; > CML% I don't like the use of the slash between authentication and > CML% integrity. ...but that may just be me. I'd suggest properly > CML% expanding that. I also wouldn't use "true" to describe an > CML% authentication service. Again, however, that's probably just me. > CML% Also, I would suggest that you not attempt to say how long it = takes > CML% to perform a validation. Perhaps reword that last sentence to = be: > CML> > CML> Yet, a delay is incurred in checking a TESLA authenticated packet > CML> which may be more than what is desired in some deployments. Done. NEW: o at the packet level, Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4082][RFC5776] is an attractive solution that is robust to losses, provides an authentication and integrity verification service, and does not create any prohibitive processing load or transmission overhead. Yet, a delay is incurred in checking a TESLA authenticated packet which may be more than what is desired in some use-cases; > o at the packet level, IPsec/ESP [RFC4303] can be used to check the > integrity and authenticate the sender of all the packets being > exchanged in a session (see Section 4.5). >=20 > Techniques relying on public key cryptography (digital signatures = and > TESLA during the bootstrap process, when used) require that public > keys be securely associated to the entities. This can be achieved = by > a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by > pre-distributing securely the public keys of each group member. > CML% I'd suggest rewording that last phrase for clarity: > CML> ,or by securely pre-distributing the public keys... Done. > Techniques relying on symmetric key cryptography (Group MAC) require > that a secret key be shared by all group members. This can be > achieved by means of a group key management protocol, or simply by > pre-distributing securely the secret key (but this manual solution > has many limitations). > CML% Again, I'd suggest rewording: > CML> , or simply by securely pre-distributing the secret... Done. > It is up to the developer and deployer, who know the security > requirements and features of the target application area, to define > which solution is the most appropriate. In any case, whenever there > is any concern of the threat of file corruption, it is RECOMMENDED > that at least one of these techniques be used. > CML% Should that be "object corruption" rather than "file corruption"? Yes. Done. > 4.3. Attacks Against the Session Control Parameters and Associated > Building Blocks >=20 > Let us now consider attacks against the session control parameters > and the associated building blocks. The attacker has at least the > following opportunities to launch an attack: >=20 > o the attack can target the session description, >=20 > o the attack can target the FCAST CID, >=20 > o the attack can target the meta-data of an object, >=20 > o the attack can target the ALC/LCT parameters, carried within the > LCT header or >=20 > o the attack can target the FCAST associated building blocks, for > instance the multiple rate congestion control protocol. >=20 > The consequences of these attacks are potentially serious, since = they > can compromise the behavior of content delivery system or even > compromise the network itself. > CML> ...compromise the behavior of the content... Done. > 4.3.1. Attacks Against the Session Description >=20 > An FCAST receiver may potentially obtain an incorrect Session > Description for the session. The consequence of this is that > legitimate receivers with the wrong Session Description are unable = to > CML> ...wrong Session Descriptors will be unable to... There's a single Session Description by default, so singular is = preferable. > correctly receive the session content, or that receivers > CML> ...receivers will inadvertently... > inadvertently try to receive at a much higher rate than they are > capable of, thereby possibly disrupting other traffic in the = network. > CML% Just suggestions to keep the same verb tenses. :-) Done. > To avoid these problems, it is RECOMMENDED that measures be taken to > prevent receivers from accepting incorrect Session Descriptions. = One > such measure is the sender authentication to ensure that receivers > CML> ...such measure is sender authentication... Done. > only accept legitimate Session Descriptions from authorized senders. > How these measures are achieved is outside the scope of this = document > since this session description is usually carried out-of-band. >=20 > 4.3.2. Attacks Against the FCAST CID >=20 > Corrupting the FCAST CID is one way to create a Denial of Service > attack. For example, the attacker can insert an = "FCAST-CID-Complete" > meta-data entry to make the receivers believe that no further > modification will be done. >=20 > It is therefore RECOMMENDED that measures be taken to guarantee the > integrity and to check the sender's identity of the CID. To that > purpose, one of the counter-measures mentioned above (Section 4.2.2) > SHOULD be used. These measures will either be applied on a packet > level, or globally over the whole CID object. When there is no > packet level integrity verification scheme, it is RECOMMENDED to > digitally sign the CID. >=20 > 4.3.3. Attacks Against the Object Meta-Data >=20 > Corrupting the object meta-data is another way to create a Denial of > Service attack. For example, the attacker changes the MD5 sum > associated to a file. This possibly leads a receiver to reject the > files received, no matter whether the files have been correctly > received or not. When the meta-data are appended to the object, > corrupting the meta-data means that the Compound Object will be > corrupted. > CML% Welllll.... If the MD5 is changed in transit, then that's a Man = in > CML% the Middle (MIIM) attack and the result is a loss of service = since > CML% there is a recovery mechanism. A DOS would be more like what's > CML% described in the Security Considerations section of RFC 5740, > CML% excessive NACKing, or via replay attacks. This paragraph has been rewording, taking into account other comments. It also addresses this remark. NEW: Modifying the object meta-data is another way to launch an attack. For example, the attacker may change the message digest associated to a file, leading a receiver to reject a file, even if it has been correctly received. More generally, a receiver SHOULD be very careful during meta-data processing. For instance a receiver SHOULD NOT try to follow links (e.g., the URI contained in th Content- Location meta-data). As another example, malformed HTTP contents can be used as an attack vector and a receiver should take great care. > It is therefore RECOMMENDED that measures be taken to guarantee the > integrity and to check the sender's identity of the Compound Object. > To that purpose, one of the counter-measures mentioned above > (Section 4.2.2) SHOULD be used. These measures will either be > applied on a packet level, or globally over the whole Compound > Object. When there is no packet level integrity verification = scheme, > it is RECOMMENDED to digitally sign the Compound Object. > CML% Actually, I'd write it up something like the following. > CML> > CML> As noted in RFC 2616, a message integrity check is not > CML> sufficient proof against malicious attacks. The content-MD5 MIC = can > CML> indicate to a receiver that the meta-data has been inadvertently > CML> modified in transit, > CML> but a clever attacker would provide a correct MIC to cover any > CML> malicious changes made in an attack. It is therefore RECOMMENDED > CML> that measures be taken to guarantee the > CML> integrity and to check the sender's identity of the Compound = Object. > CML> To that purpose, one of the counter-measures mentioned above > CML> (Section 4.2.2) SHOULD be used. These measures will either be > CML> applied on a packet level, or globally over the whole Compound > CML> Object. When there is no packet level integrity verification = scheme, > CML> it is RECOMMENDED to digitally sign the Compound Object. OKAY for the attack were both the content and the MIC are modified. However in this section we restrict ourselves to meta-data. I don't want to enter such discussions. The "Security Considerations" section is already pretty detailed.=20 I've changed "file" for "object". > 4.3.4. Attacks Against the ALC/LCT and NORM Parameters >=20 > By corrupting the ALC/LCT header (or header extensions) one can > execute attacks on the underlying ALC/LCT implementation. For > example, sending forged ALC packets with the Close Session flag (A) > set to one can lead the receiver to prematurely close the session. > Similarly, sending forged ALC packets with the Close Object flag (B) > set to one can lead the receiver to prematurely give up the = reception > of an object. The same comments can be made for NORM. >=20 > It is therefore RECOMMENDED that measures be taken to guarantee the > integrity and to check the sender's identity of each ALC or NORM > packet received. To that purpose, one of the counter-measures > mentioned above (Section 4.2.2) SHOULD be used. >=20 > 4.3.5. Attacks Against the Associated Building Blocks >=20 > Let us first focus on the congestion control building block that may > be used in an ALC or NORM session. A receiver with an incorrect or > corrupted implementation of the multiple rate congestion control > building block may affect the health of the network in the path > between the sender and the receiver. That may also affect the > reception rates of other receivers who joined the session. >=20 > When congestion control is applied with FCAST, it is therefore > RECOMMENDED that receivers be required to identify themselves as > legitimate before they receive the Session Description needed to = join > the session. If authenticating a receiver does not prevent this > latter to launch an attack, it will enable the network operator to > identify him and to take counter-measures. This authentication can > be made either toward the network operator or the session sender (or > a representative of the sender) in case of NORM. The details of how > it is done are outside the scope of this document. > CML% I don't understand that paragraph. Can you rephrase it? I have simplified it a lot, removing useless considerations. NEW: When congestion control is applied with FCAST, it is therefore RECOMMENDED that receivers be authenticated as legitimate receivers before they can join the session. If authenticating a receiver does not prevent this latter to launch an attack, it will enable the network operator to easily identify him and to take counter-measures. The details of how this is done are outside the scope of this document. > When congestion control is applied with FCAST, it is also = RECOMMENDED > that a packet level authentication scheme be used, as explained in > Section 4.2.2. Some of them, like TESLA, only provide a delayed > authentication service, whereas congestion control requires a rapid > reaction. It is therefore RECOMMENDED [RFC5775] that a receiver > using TESLA quickly reduces its subscription level when the receiver > believes that a congestion did occur, even if the packet has not yet > been authenticated. Therefore TESLA will not prevent DoS attacks > where an attacker makes the receiver believe that a congestion > occurred. This is an issue for the receiver, but this will not > compromise the network. Other authentication methods that do not > feature this delayed authentication could be preferred, or a group > MAC scheme could be used in parallel to TESLA to prevent attacks > launched from outside of the group. >=20 > 4.4. Other Security Considerations >=20 > Lastly, we note that the security considerations that apply to, and > are described in, ALC [RFC5775], LCT [RFC5651], NORM [RFC5740] and > FEC [RFC5052] also apply to FCAST as FCAST builds on those > specifications. In addition, any security considerations that apply > to any congestion control building block used in conjunction with > FCAST also applies to FCAST. Finally, the security discussion of > [I-D.ietf-rmt-sec-discussion] also applies here. > CML% If you have this here, then you do not need sections 4.3.4 and > CML% 4.3.5, unless you are making different recommendations. Is that > CML% the case? If so, then you'll need to explain the differences. I'm not happy with the Security Considerations of these documents, in the sense that it is not structured and discussed in the way I'd like it to be, at least for some parts of them. But the present document does not contradict them, of course. I therefore prefer to leave it as it is. =20 > 4.5. Minimum Security Recommendations >=20 > We now introduce a mandatory to implement but not necessarily to use > security configuration, in the sense of [RFC3365]. Since FCAST/ALC > relies on ALC/LCT, it inherits the "baseline secure ALC operation" = of > [RFC5775]. Similarly, since FCAST/NORM relies on NORM, it inherits > the "baseline secure NORM operation" of [RFC5740]. More precisely, > in both cases security is achieved by means of IPsec/ESP in = transport > mode. [RFC4303] explains that ESP can be used to potentially = provide > confidentiality, data origin authentication, content integrity, = anti- > replay and (limited) traffic flow confidentiality. [RFC5775] > specifies that the data origin authentication, content integrity and > anti-replay services SHALL be used, and that the confidentiality > service is RECOMMENDED. If a short lived session MAY rely on manual > keying, it is also RECOMMENDED that an automated key management > scheme be used, especially in case of long lived sessions. > CML% In my very humble opinion, you should start the Security = Considerations > CML% section with this paragraph. That will establish a baseline for > CML% development of FCAST. The next several parts of the section = should > CML% then look at specific concerns for FCAST. I prefer having a (long) description of the general issues and possible counter-measures first, all of them being specific to FCAST. And then, a description of the MTI recommendations. This is also what we did for FLUTE (rfc 6726) where it turns out that the IETF MTI recommendations are not in line with the security framework defined by 3GPP-MBMS where is it widely deployed. Different use cases and assumptions lead to different security architectures. That's normal = of course. But it also makes me believe it's better to stick with the = current organization that puts more emphasizes on the concepts, presented first. > Therefore, the RECOMMENDED solution for FCAST provides per-packet > security, with data origin authentication, integrity verification = and > anti-replay. This is sufficient to prevent most of the in-band > attacks listed above. If confidentiality is required, a per-packet > encryption SHOULD also be used. >=20 >=20 > =3D=3D=3D^^^=3D=3D=3D >=20 > Regards, > Chris In any case, thanks a lot for your detailed review. Cheers, Vincent From radiaperlman@gmail.com Fri Mar 22 20:08:52 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C9F21F8B6D; Fri, 22 Mar 2013 20:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4eYjCPW-KSM; Fri, 22 Mar 2013 20:08:52 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8FB21F8B3B; Fri, 22 Mar 2013 20:08:44 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ec20so8477623lab.37 for ; Fri, 22 Mar 2013 20:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=XRzVfL8uxFyB+rXkIgaMY7YmzNrx5sAoTwUMYcVKR6s=; b=mBrjn/nlgjrwzHRqk9zyiBwgO9PXQAESq1O5zzQYPhi88FVbeOzq4dxslTzdYEXhR8 xblBGyfLWpImXorUz6GVSVT9whPCjAYoOKe/zvgl3yvC5kyrq4OBaMTxAwBV1N+ZPhU4 I6IE65RzrOWOye3W3OUKwjB0l8V7XEGK3FEQFmJUsYD/Oz4x7mtVe5Jf9+kH+yqiqiL+ tMZp2KM4/g+W2Ctu/p7bl+pvFih7BPc9dgrJZ4izRHMR+f/8FkMS0yuTc2lTjRCaii+K QAwKcgUA4CpsTMvMONElhj0UuCq/elH7pL3XkzY5Co/cV6KlmwLupMHyPGHgcoJem+LL /BdQ== MIME-Version: 1.0 X-Received: by 10.152.122.100 with SMTP id lr4mr2126641lab.28.1364008123437; Fri, 22 Mar 2013 20:08:43 -0700 (PDT) Received: by 10.112.137.161 with HTTP; Fri, 22 Mar 2013 20:08:43 -0700 (PDT) Date: Fri, 22 Mar 2013 20:08:43 -0700 Message-ID: From: Radia Perlman To: secdir@ietf.org, The IESG , draft-saintandre-urn-example@tools.ietf.org Content-Type: multipart/alternative; boundary=f46d042ef661ab188904d88ee38a Subject: [secdir] secdir review of draft-saintandre-urn-example-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 03:08:53 -0000 --f46d042ef661ab188904d88ee38a Content-Type: text/plain; charset=ISO-8859-1 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 proposes to standardize the use of "example" as a namespace identifier in URNs (like "example.com" is for DNS names), and is harmless. I could (and perhaps should, or is it SHOULD) stop there. However, I'll editorialize a bit. I more or less understand what a URL is. You type it into a browser, though mercifully, actual humans seldom have to type https://www.example.com/extrastuff/whatever/934573895838. But then I started hearing about URNs and URIs. I pretty much ignored them because my life seemed to be complete without needing to understand them. But then since I was assigned this draft to review, I decided to investigate what URNs and URIs are and how they are different. The definition given in RFC 2141 is "Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space." I could memorize that definition and it still wouldn't help me understand why my life was incomplete without URNs. Then I read RFC 1630 to find out about URIs, and that was equally non-illuminating to me, who was simply groping for "why do I need one of these things, and when would I use it". Then I read yet another incomprehensible RFC, #3986, which has this sentence: "Future specifications and related documentation should use the general term "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305]." So, why are we, today, in 2013, tweaking URNs if we are supposedly trying to mercifully put the term "URN" to bed? And why is the NSS (Namespace Specific String, which is part of the URN) ASCII? Given that I'm never planning on using a URN, I don't really care, but if people wanted these things for whatever reason, mightn't they want to use International characters? So my conclusion is that invention of UR* terminology is a low level denial of service attack on people, but is otherwise harmless. Radia --f46d042ef661ab188904d88ee38a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security = directorate's ongoing effort to review all IETF documents being process= ed by the IESG. These comments were written primarily for the benefit of th= e security area directors. =A0Document editors and WG chairs should treat t= hese comments just like any other last call comments.

This d= ocument proposes to standardize the use of "example" as a namespa= ce identifier in URNs (like "example.com" is for DNS names), and is harmless.

I coul= d (and perhaps should, or is it SHOULD) stop there. =A0However, I'll ed= itorialize a bit. =A0I more or less understand what a URL is. =A0You type i= t into a browser, though mercifully, actual humans seldom have to type https://www.example.com/extrastuff/whatever/934573895838.

But th= en I started hearing about URNs and URIs. =A0I pretty much ignored them bec= ause my life seemed to be complete without needing to understand them. =A0B= ut then since I was assigned this draft to review, I decided to investigate= what URNs and URIs are and how they are different.

The de= finition given in RFC 2141 is "Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource ide= ntifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space."

I could memorize that definition and it still wou= ldn't help me understand why my life was incomplete without URNs. Then = I read RFC 1630 to find out about URIs, and that was equally non-illuminati= ng to me, who was simply groping for "why do I need one of these thing= s, and when would I use it".

Then I read yet another incomprehensible RFC, #39= 86, which has this sentence:
"Future specificat= ions and related documentation should use the general term "URI" rather than the more restrictiv= e terms "URL" and &qu= ot;URN" [RFC3305]." So, why are we, today, in 2013, tweaking URN= s if we are supposedly trying to mercifully put the term "URN" to= bed?

And why is the NSS (Namespace Specific String, wh= ich is part of the URN) ASCII? Given that I'm never planning on using = a URN, I don't really care, but if people wanted these things for whate= ver reason, mightn't they want to use International characters?<= /div>

So my conclusion is that invention of UR* termino= logy is a low level denial of service attack on people, but is otherwise ha= rmless.

Radia


<= /span>
--f46d042ef661ab188904d88ee38a-- From barryleiba.mailing.lists@gmail.com Sat Mar 23 07:53:14 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193D021F8A54; Sat, 23 Mar 2013 07:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlGiO3l7AOQX; Sat, 23 Mar 2013 07:53:12 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6A19221F8A8F; Sat, 23 Mar 2013 07:53:04 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ht11so3832683vcb.13 for ; Sat, 23 Mar 2013 07:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Kc7K49mzYc2jID83RjRNoAPgYNxE3NTBKpWITlkcrkA=; b=E4ygZG6tLH1aQ3ZVX4YzUz5+O0DNm7jJiG6MYJBjLJp+mCGnZxX8YwDpD5qXGg6YjP nLbdPizaCSUpH5W/7eN9MvVe8B4aVaX/hKmQBLH5d3SqDVZuH1LzjyPagIvUvm0ktYAJ tbz63VAk+ADooWLSIDheA/iBM1fGf18tQNyvGRyB8RvuryiDrJJH5Tihns6Jhf8Hwm0d NUUjsUkRn5HxFVRBhIAcajSndIcV04PSFAEUteVCfcQDpjpV3z0kzPqsQFsokPjUklPI AFP4Pyo12yO8hlyTDu2S/dA+Vi32GBkf+z7kKFr9O+COZaDUjkQCoRh/2cjI4Opb7BFn NNrQ== MIME-Version: 1.0 X-Received: by 10.52.155.5 with SMTP id vs5mr6170857vdb.24.1364050383906; Sat, 23 Mar 2013 07:53:03 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Sat, 23 Mar 2013 07:53:03 -0700 (PDT) In-Reply-To: References: Date: Sat, 23 Mar 2013 10:53:03 -0400 X-Google-Sender-Auth: UwgJEfH5C4Z5jm6f93bNU9BDYCc Message-ID: From: Barry Leiba To: Radia Perlman Content-Type: text/plain; charset=ISO-8859-1 Cc: The IESG , draft-saintandre-urn-example@tools.ietf.org, secdir Subject: Re: [secdir] secdir review of draft-saintandre-urn-example-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 14:53:14 -0000 Hi, Radia, and thanks for the review. On the chance that you really do want some of your questions answered, let me take a stab: > But then I started hearing about URNs and URIs. I pretty much ignored them > because my life seemed to be complete without needing to understand them. > But then since I was assigned this draft to review, I decided to investigate > what URNs and URIs are and how they are different. "URI" is an abstraction. We have here a protocol (or a data format), and in this spot in the protocol we want the client to send the server something. We're going to say that the something is a URI, which is rather like saying that the something is a fruit. Broadly speaking, we've divided URIs into two types: locators and names. A URL (locator) tells you where to find something and/or what to do with it. A URN (name) tells you what something is called. Different sub-abstractions, like "fruit that needs to be peeled" and "fruit that you can eat without peeling". The first part of a URI is called a "scheme" -- it's the part that looks like "http:" or "sip:" or "mailto:" or "urn:". That's what tells you how to interpret this particular URI; it's the concrete instantiation of the abstraction -- the lemon or the apple. When you see a URI with the scheme "http:", you know you're meant to go look at RFC 2616 to see how to process it, and you'll usually end up contacting a server on port 80 and sending it certain stuff, expecting certain stuff in response. When you see "mailto:", you know you'll be using SMTP (RFC 5321). But names are different. URIs with the "urn:" scheme are a type of URN, and they're just meant to name things (but there are other URNs; the "ni:" scheme, defined in http://tools.ietf.org/html/draft-farrell-decade-ni , also defines names, not locators). There are documents that say how to map ISBNs into URNs (RFC 3187), how to map serial numbers into URNs (RFC 3044), and so on. The URN just gives you a name, and it doesn't tell you what to do with the name. But they're still part of the abstract thing called a URI, and they're syntactically valid where URIs are allowed. Of course, specifications can, and often do, limit the types of URIs that are semantically appropriate in any particular spot in any particular protocol or application. A web browser probably knows how to deal with http: and ftp: URIs. Many can deal with mailto: URIs. They're less likely to know what to do with sip: URIs and probably won't do anything at all useful with urn: URIs. But because of the common syntax imposed by the abstraction, the web browsers know how to start parsing the sip: and urn: URIs, and, thus, know when to throw them out as unsupported instantiations. > Then I read yet another incomprehensible RFC, #3986, which has this > sentence: > "Future specifications and related documentation should use the general term > "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305]." So, > why are we, today, in 2013, tweaking URNs if we are supposedly trying to > mercifully put the term "URN" to bed? What the text in 3986 (which needs updating, by the way, an update which is on the radar, if not actually in the works yet) is trying to get across is that in the general case, specifications should refer to the abstraction, the URI. But there certainly are times when, for example, something specifically needs to be a name, a URN... and in those cases it's perfectly sensible to use the term "URN". Today, in 2013, we're still tweaking URNs because we still need resource names (see the aforementioned draft-farrell-decade-ni, for example). > And why is the NSS (Namespace Specific String, which is part of the URN) > ASCII? Given that I'm never planning on using a URN, I don't really care, > but if people wanted these things for whatever reason, mightn't they want to > use International characters? That's an artifact of history, and of the need to maintain compatibility. For better or worse (well, worse, surely) our protocols and the implementations thereof were set up to expect only ASCII character encoding. We can and should move over to UTF-8, and we are working on it, a few protocols at a time. But look at the difficulty the seven-year effort on EAI (email address internationalization) has had, and you can see that it's not as simple as suddenly saying, "OK, we can now send these protocol elements encoded in UTF-8." For URIs, specifically, much of the internationalization can be handled by the encoding mechanisms specified in RFC 3986, and it's working well. The IRI (internationalized resource identifier) work has tried to expand that, but there've been bumps in that road. But the bottom line is that URIs *can* use international characters, by encoding them, and it's the job of the presentation layers to encode the user input and to decode for display. > So my conclusion is that invention of UR* terminology is a low level denial > of service attack on people, but is otherwise harmless. You won't hear much argument about that from me, indeed. Though I'll point out that that describes more of what we do than most of us would like to admit. Barry From new-work-bounces@ietf.org Mon Mar 25 09:23:07 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D7921E8086; Mon, 25 Mar 2013 09:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1364228587; bh=8r+m69G+G4SNEIIhsC7FhhBiqO1PwEUNTvqrwmgzxH8=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=Mrz4lqHsORDxhH7pX3p5pHKMvpSK+9lQajFdjB+NKvSR279zNu2gomrzW28K/Csjd 0Oiho+ItHkJz0Oguny4tO2XuhotvSjtN00tAbnaJEmC4xpb9ziKZOEi+0nZcHLkyNY rvjam/EIRjVS9v+WRlnvdcIn3352KaGzoO7joSqk= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49FD21F902E for ; Mon, 25 Mar 2013 09:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvNSdLl6Whzf for ; Mon, 25 Mar 2013 09:23:04 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id D131A21F902D for ; Mon, 25 Mar 2013 09:23:04 -0700 (PDT) Received: from bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1UKAAp-0005TV-MA for new-work@ietf.org; Mon, 25 Mar 2013 12:23:03 -0400 To: new-work@ietf.org Date: Mon, 25 Mar 2013 17:23:03 +0100 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/12.14 (MacIntel) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 26 Mar 2013 08:03:00 -0700 Subject: [secdir] [new-work] Proposed renewal of the W3C XML Activity and Working Groups (until 2013-04-26) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 16:23:08 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the XML Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes draft charters for the following groups: Efficient XML Working Group: http://www.w3.org/XML/2013/exi-charter.html XML Query Working Group: http://www.w3.org/XML/2013/query-charter.html XML Core Working Group: http://www.w3.org/XML/2013/xml-core-charter.html XML Processing Model Working Group: http://www.w3.org/XML/2013/xproc-charter.html XSLT Working Group: http://www.w3.org/XML/2013/xsl-charter.html In addition, the XML Coordination Group proposed charter: http://www.w3.org/XML/2013/xml-cg-charter.html As part of ensuring that the community is aware of proposed work at W3C, the draft charters are public during the Advisory Committee review period. W3C invites public comments through 2013-04-26 on the proposed renewal of the W3C XML Activity and group charters. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Liam Quin, XML Activity Lead . Thank you, Coralie Mercier, W3C Communications [0] https://www.w3.org/2002/09/wbs/33280/XMLact2013/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +33643220001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Mar 26 13:16:19 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF40421F8DD1; Tue, 26 Mar 2013 13:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1364328978; bh=0KuyeFIeWbujD++rOXa3rkzm8+/Bgty5hqA2Lg+yt+8=; h=To:Date:MIME-Version:From:Message-ID:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=G5d5ePUCNJ+mkdx5RnlgVRh3kX/sDD8sW16PjOcX/WvfBiP2kCZWm7DERdb4IAIt/ UWmSyYloiYLGSNmh//CN9GDEE7JzcXItM0dLLK2psTVJ2LHK4b5gSt2b57YVPl3s+8 wADf2rWuWYV2VTeZLypBvFCZXdkE6vGgpG3igb/8= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62A621F8DD8 for ; Tue, 26 Mar 2013 13:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhGqRiI4jSe4 for ; Tue, 26 Mar 2013 13:16:17 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 2193A21F8D67 for ; Tue, 26 Mar 2013 13:16:17 -0700 (PDT) Received: from bleuazur.com ([88.173.33.195] helo=sith.local) by jay.w3.org with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1UKaI4-00077F-65 for new-work@ietf.org; Tue, 26 Mar 2013 16:16:16 -0400 To: new-work@ietf.org Date: Tue, 26 Mar 2013 21:16:15 +0100 MIME-Version: 1.0 From: "Coralie Mercier" Organization: W3C Message-ID: User-Agent: Opera Mail/12.14 (MacIntel) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 26 Mar 2013 13:18:40 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web and TV Interest Group (until 2013-04-26) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 20:16:19 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Web and TV Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web and TV Interest Group: http://www.w3.org/2012/11/webTVIGcharter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2013-04-26 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Kazuyuki Ashimura, Web and TV Activity Lead . Thank you, Coralie Mercier, W3C Communications [0] http://www.w3.org/2011/webtv/Activity [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Communications Team - http://www.w3.org mailto:coralie@w3.org +33643220001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From psaintan@cisco.com Tue Mar 26 18:59:48 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DEA21F86EF; Tue, 26 Mar 2013 18:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oPjuJ0k2-IJ; Tue, 26 Mar 2013 18:59:47 -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 9A56221F8555; Tue, 26 Mar 2013 18:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2450; q=dns/txt; s=iport; t=1364349587; x=1365559187; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=yBFGEAkn8ccgl4mGfLvpO38MsMqnHMma4HRWGe14gbs=; b=AP2OrLtpHQF/VrJLMxdGJZ3T6vjOCaB6Nb2czE+Fxo4RadbQnjWZQojf seS4rIJiX+CBjDcb+d3qPgo8pmaKKwAraMsE6DMeGxawBkoa6lYP0jV4d nU83U2VNCOnwH9SqT2rIWPmBUslM5SpInct/MOGnDqR41cgt2QY8T5TuJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FABlRUlGrRDoG/2dsb2JhbABDgzvAaIEIFoEqgh8BAQEDATgCPwULCy0ZVwYTiA4Fr12PZY1SgUAHCoJVYQOIeI1vhX+LCIMqHYE3 X-IronPort-AV: E=Sophos;i="4.84,915,1355097600"; d="scan'208";a="76817562" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 27 Mar 2013 01:59:47 +0000 Received: from [192.168.1.3] (sjc-vpn7-1020.cisco.com [10.21.147.252]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2R1xj6i025137; Wed, 27 Mar 2013 01:59:46 GMT Message-Id: <1A55CC1D-2CB3-4A20-B9B0-6F20C2514E6B@cisco.com> From: Peter Saint-Andre To: Charlie Kaufman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Mar 2013 19:59:45 -0600 References: X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Wed, 27 Mar 2013 01:09:14 -0700 Cc: "draft-ietf-appsawg-acct-uri.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-appsawg-acct-uri-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 01:59:48 -0000 On Feb 27, 2013, at 12:10 PM, Charlie Kaufman wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The fact that this document only defines a syntax and does not > define uses for it implies that the security implications are minimal. > > This document specifies a new URI format for specifying names of > accounts. The syntax looks like: > > acct:johnsmith@example.com > > The chosen syntax is apparently already proposed for use in the > WebFinger protocol in a separate I-D and one could imagine lots of > other uses. This draft does not specify any semantics associated > with the account specification or any means of contacting the > entity, though it will likely be a common practice to have the value > be usable as an email address to reach the named entity. This draft > specifies that any protocols using this new URI format must specify > the associated semantics. The Security Considerations notes this and > says that therefore any security considerations must therefore be > described by the protocol using this syntax. > > My only quibble is that the spec does not specify any algorithm by > which two acct URIs can be compared for equality. Perhaps the world > has evolved to the point where everyone accepts that as being > impossible. The part after the @ is a DNS host, subject to IDN > rules, while the part before may contain many ASCII characters and %- > encoded UTF8. I believe that makes this different from what is > allowed in the name portion of an email address in many subtle > cases. Case-blind comparisons are probably intended but are not > specified. Having an "almost canonical" way to specify an account > identifier has the potential of introducing security problems, but > they may be unavoidable. Charlie, thank you for the review and my apologies for the delay in replying. Stephen Farrell has raised the same issue about comparison in his IESG review of this specification, and I will work to address that issue. Would you and the secdir like to be cc'd on the text that results from that discussion? Peter From benl@google.com Thu Mar 28 06:38:34 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5711F21F8E6E for ; Thu, 28 Mar 2013 06:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT-t0auT5k8C for ; Thu, 28 Mar 2013 06:38:33 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id CC75521F8E54 for ; Thu, 28 Mar 2013 06:38:33 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id qd14so10267450ieb.28 for ; Thu, 28 Mar 2013 06:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4PyK/Ow1qiETQiVtReVoLrtf0hLQ8jzzZahW+7tkdXg=; b=IUyiznccMNcKqIKXIv570QzQe2RtEVKf7qdKjF5urrFjkUmfb2scIZiZ9cWmEvDaC7 82ZXgVHpvoWNGr7m/A5KAAOZl8oQdBVR5zoXngjmUxxc9VJI3YuM6B111D46MuBFkqWH 8TSM2FxPpSbdXYJr8epSQOW7b+mGgJUyXgZLNDKbF5BI29K4tbZBWIUJAUW7J5FFQ8qb e9TYAtTokH4M/+jnrtn+A6vDRPcVVXvSr1J4TyWsDiPcqNsmT911YCNxiSvPeb4tYvH8 pgnYJxvGkV4eIb7VC24hSrClj2qqdw/K7N38YXb7NFC+v5DpJWR6DFutA9GorLfQnIVy gCPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=4PyK/Ow1qiETQiVtReVoLrtf0hLQ8jzzZahW+7tkdXg=; b=c3LBgCTs/Z9SpvfAeMZbo5GANVEzpuvEtiCpPcqX9qXwmOj17MTsKsn6IbddsknfDo bkwQ8CzdeHJMF4ju6RiD67DP1N4FAaH5mKUppMM/acrKWpXsA/NzbPOysf+hRByrWV/Y AlkkIANeJ+eFccJzMRXL8ppczfUOY5+bbUiVb+djdWq6U7wPznPPFwKoicb1w7Q40YRu 14zkzrFMvaZKSFUPehGrODluEpRil11xp8XsFHc40McHsg+vNEX6F7J9OAjcuIkLnO5+ H2h108PFbAo7pilKWc1c6G2D09kyRiAFTsXa5MUr2AmWm8Ti8kV+H4p2smRpJx2c8cIC uDFw== MIME-Version: 1.0 X-Received: by 10.50.136.130 with SMTP id qa2mr7195831igb.1.1364477913339; Thu, 28 Mar 2013 06:38:33 -0700 (PDT) Received: by 10.64.20.131 with HTTP; Thu, 28 Mar 2013 06:38:33 -0700 (PDT) In-Reply-To: <20811.30076.686637.240917@fireball.kivinen.iki.fi> References: <20811.30076.686637.240917@fireball.kivinen.iki.fi> Date: Thu, 28 Mar 2013 13:38:33 +0000 Message-ID: From: Ben Laurie To: secdir-secretary@mit.edu Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkYoX5fz1tQnzFinXjHX2QlLfrc8MHxgqvLUCui4eigc0TshNTVZPraMnXzqMDSKMwcM0L3ORxko+s/C9oGsQ1+nfNflvZ7mtKa81Wrvzs7RxIAvi8574PeHo7E7Bl142z8CoIu30Md11pBvh0O9Ef1JA8z2IaS7I8acjl9VokvH3EV+9oM92c8EcuOn194fPHIZGZS Cc: "secdir@ietf.org" Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 13:38:34 -0000 On 21 March 2013 21:02, Tero Kivinen wrote: > Ben Laurie 2013-03-29 draft-ietf-ospf-ipv4-embedded-ipv6-routing-07 I just took a look at this, and whilst it looks safe enough, my lack of detailed knowledge of IPv6 means I'm probably not a great reviewer for it... From kivinen@iki.fi Fri Mar 29 04:23:13 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C8A21F85C6 for ; Fri, 29 Mar 2013 04:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh4Tqmmt63E0 for ; Fri, 29 Mar 2013 04:23:13 -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 E6DFA21F85C4 for ; Fri, 29 Mar 2013 04:23:12 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r2TBN7gW011692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Mar 2013 13:23:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r2TBN6v8026904; Fri, 29 Mar 2013 13:23:06 +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: <20821.31130.670978.546052@fireball.kivinen.iki.fi> Date: Fri, 29 Mar 2013 13:23:06 +0200 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 29 Mar 2013 11:23:14 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Joe Salowey is next in the rotation. For telechat 2013-04-11 Reviewer LC end Draft Warren Kumari T 2013-03-26 draft-merkle-ikev2-ke-brainpool-03 Julien Laganier T 2013-03-18 draft-ietf-appsawg-webfinger-12 Sandy Murphy T 2013-03-27 draft-ietf-pkix-rfc2560bis-16 Hilarie Orman T 2013-03-29 draft-ietf-tls-multiple-cert-status-extension-04 For telechat 2013-04-25 Yoav Nir T 2013-04-16 draft-ietf-nfsv4-rfc3530bis-25 Magnus Nystrom T 2013-04-16 draft-ietf-nfsv4-rfc3530bis-dot-x-16 Last calls and special requests: Rob Austein 2013-03-06 draft-arkko-iesg-crossarea-03 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Dan Harkins R2013-04-01 draft-ietf-ipfix-flow-selection-tech-14 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Warren Kumari 2013-01-21 draft-ietf-lisp-mib-09 Ben Laurie 2013-03-29 draft-ietf-ospf-ipv4-embedded-ipv6-routing-07 Matt Lepinski 2013-03-15 draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10 Alexey Melnikov 2013-03-27 draft-ietf-core-coap-14 Kathleen Moriarty 2013-04-03 draft-ietf-dnsext-dnssec-algo-signal-09 Russ Mundy 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Russ Mundy 2013-03-30 draft-ietf-roll-terminology-12 Eric Rescorla 2013-01-24 draft-ietf-ospf-ospfv3-iid-registry-update-02 Eric Rescorla 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Eric Rescorla 2012-11-27 draft-ietf-lisp-eid-block-04 Eric Rescorla 2013-04-10 draft-ietf-6renum-gap-analysis-05 Vincent Roca 2013-04-08 draft-ietf-pcp-upnp-igd-interworking-07 Nico Williams - draft-ietf-httpbis-p5-range-22 -- kivinen@iki.fi From hilarie@purplestreak.com Fri Mar 29 13:35:17 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97DA21F8F01; Fri, 29 Mar 2013 13:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiosWgAsG5Qb; Fri, 29 Mar 2013 13:35:17 -0700 (PDT) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by ietfa.amsl.com (Postfix) with ESMTP id 55BCA21F8EF2; Fri, 29 Mar 2013 13:35:11 -0700 (PDT) Received: from mx03.mta.xmission.com ([166.70.13.213]) by out03.mta.xmission.com with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1ULg0z-0004ML-VY; Fri, 29 Mar 2013 14:35:10 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=sylvester.rhmr.com) by mx03.mta.xmission.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1ULg0u-00016M-NY; Fri, 29 Mar 2013 14:35:09 -0600 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.3/Debian-9.1ubuntu1) with ESMTP id r2TKYuPu025063; Fri, 29 Mar 2013 14:34:56 -0600 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id r2TKYtu4025061; Fri, 29 Mar 2013 14:34:55 -0600 Date: Fri, 29 Mar 2013 14:34:55 -0600 Message-Id: <201303292034.r2TKYtu4025061@sylvester.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx03.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on mx03.mta.xmission.com) Cc: draft-ietf-tls-multiple-cert-status-extension@tools.ietf.org Subject: [secdir] Security review of draft-ietf-tls-multiple-cert-status-extension-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 20:35:17 -0000 Security review of draft-ietf-tls-multiple-cert-status-extension-04 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The final paragraph in section 2.2 discusses using an unauthenticated session for the purpose of obtaining certificates in order to authenticate the session. Sending usernames and passwords over the connection while unauthenticated is regarded as "inappropriate". This seems to be a serious problem, deserving of at least a "MUST NOT". In section 2.2, "A server that receive a client hello" should be "A server that receives a client hello". Later, "require trust in the server, and the server certificate has not been" reads better without the comma. Hilarie From yngve@spec-work.net Fri Mar 29 14:30:15 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B310D21F8D26; Fri, 29 Mar 2013 14:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwtgdTjw4zkR; Fri, 29 Mar 2013 14:30:15 -0700 (PDT) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id E826921F8C7D; Fri, 29 Mar 2013 14:30:08 -0700 (PDT) Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:62399 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1ULgs7-0007O9-EE; Fri, 29 Mar 2013 22:30:03 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: iesg@ietf.org, secdir@ietf.org, "Hilarie Orman" References: <201303292034.r2TKYtu4025061@sylvester.rhmr.com> Date: Fri, 29 Mar 2013 22:29:53 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <201303292034.r2TKYtu4025061@sylvester.rhmr.com> User-Agent: Opera Mail/12.14 (Win32) X-Mailman-Approved-At: Sat, 30 Mar 2013 08:01:52 -0700 Cc: draft-ietf-tls-multiple-cert-status-extension@tools.ietf.org Subject: Re: [secdir] Security review of draft-ietf-tls-multiple-cert-status-extension-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 21:30:15 -0000 Hello Hilarie, Thanks for the review. On Fri, 29 Mar 2013 21:34:55 +0100, Hilarie Orman wrote: > Security review of draft-ietf-tls-multiple-cert-status-extension-04 > > Do not be alarmed. I have reviewed this document as part of the > security directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written primarily > for the benefit of the security area directors. Document editors and > WG chairs should treat these comments just like any other last call > comments. > > The final paragraph in section 2.2 discusses using an unauthenticated > session for the purpose of obtaining certificates in order to > authenticate the session. Sending usernames and passwords over the > connection while unauthenticated is regarded as "inappropriate". This > seems to be a serious problem, deserving of at least a "MUST NOT". I changed that to: "In this case, the client could continue with the handshake, but it MUST NOT disclose a username and password until it has fully validated the server certificate." It will be included in the -06 version. I'll probably wait until next week with that one, since I released -05 earlier today. > In section 2.2, "A server that receive a client hello" should be > "A server that receives a client hello". Later, This has already been fixed in the -05 version. > "require trust in the server, and the server certificate has not been" > reads better without the comma. I am not sure about this one. The original version was without the comma, but I asked a former colleague (a document writer/reviewer) to review that update, and she suggested the comma. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/