From d3e3e3@gmail.com Mon Jan 2 18:22:09 2012 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 523F521F8516; Mon, 2 Jan 2012 18:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.181 X-Spam-Level: X-Spam-Status: No, score=-104.181 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_00=-2.599, 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 Dqr9fnbV50EB; Mon, 2 Jan 2012 18:22:08 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4879221F8484; Mon, 2 Jan 2012 18:22:08 -0800 (PST) Received: by laah2 with SMTP id h2so6650091laa.31 for ; Mon, 02 Jan 2012 18:22:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=IQvnxZ0XgODSKWDWOLhwoJuXch0YyYOnG6jzDXiM/ms=; b=MoEzxSb31UUQC4mC1sWNVwAW+i2LXay5g521QIPrf8l1F4buUkWCVFzLZgHLapuwyJ 4TnBikfw+dSVUddDlzTbFqG72pZyNWmVQMAgR4yEyKZTraUf+6d8wOoBMDwkR7nqxGnH AuALNi94yLrodNcnjphPDmcjRE/QdB585bQ3E= Received: by 10.152.128.196 with SMTP id nq4mr42814850lab.35.1325557327272; Mon, 02 Jan 2012 18:22:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.112.99 with HTTP; Mon, 2 Jan 2012 18:21:46 -0800 (PST) From: Donald Eastlake Date: Mon, 2 Jan 2012 21:21:46 -0500 Message-ID: To: draft-ietf-6lowpan-nd.all@tools.ietf.org, iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: secdir@ietf.org Subject: [secdir] draft-ietf-6lowpan-nd-18.txt SECDIR Review 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, 03 Jan 2012 02:22:09 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes optimizations to IPv6 neighbor discovery (ND) for low-power lossy networks, such a IEEE 802.15.4, that limit or do not support multicast and may have other network differences. It makes 8 extensions to IPv6 Neighbor Discovery. SECURITY CONSIDERATIONS: Although this is a fairly extensive and complex specification, the Security Considerations appear to be adequate. The Security Considerations depend heavily on the assumption of lower level security of the link layer that prevents tampering with or replaying the messages involved. Versions are created of some ND address messages which are no longer restricted to one hop by a hop-count test but these versions are not permitted except where explicitly configured and are not allowed to change Neighbor Address Caches. These assumptions and mechanisms appear to be sufficient. Finally, the Security Considerations section suggest future investigation of the use of Secure Neighbor Discover (SEND). POSSIBLE Security Considerations: Section 4.3: There seems to be no discussion of how rapidly the Version Number could change and whether there is any risk of it incrementing >8K while some cached value was not updated resulting in sequence number arithmetic confusion. Section 7.2 on Context Configuration and Management does not indicate what the consequences of improper management might be. MINOR: I found the first sentence of Section 1.5 to be hard to understand and of slightly questionable grammar. In Section 3.3, should "A host retransmits the Address Registration option until it is acknowledged by the receipt of a Address Registration option." be augmented by adding "with zero Statius" at the end. In Section 4.1, page 17: "... amount of time in a unit of 60 seconds that ..." is peculiar wording. Does it mean "... amount of time in units of 60 seconds that ..." (which might better be "... amount of time in units of a minute that ...")? Or does it mean "... amount of time as a fraction of the unit of 60 seconds, with the decimal point just before the first bit of the field, that ..."? - ditto Section 4.2, page 18. - ditto Section 4.4, page 21. =3D=3D OK, now that I've read the rest of the document, I guess these 16-bit fields are supposed to max out at ~18 hours. That seems to imply that it is really "... amount of time in units of 1 second that ...", something I would never have guessed from the original wording. In Section 4.3, for "... sequence number arithmetic ..." suggest adding a reference to [RFC1982] which is already including in the normative references. In Section 4.4, for first occurrence of "ip-over-foo", suggest adding an Informative reference to [RFC3092]. TYPO: Replace "an Neighbor" with "a Neighbor" globally. Section 10.3.2: "the its" -> "its" Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com From william.polk@nist.gov Tue Jan 3 13:43:19 2012 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 F27E811E80DD; Tue, 3 Jan 2012 13:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 PA-5lZH59JTu; Tue, 3 Jan 2012 13:43:18 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 26A9E11E80AC; Tue, 3 Jan 2012 13:43:18 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 3 Jan 2012 16:43:02 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 3 Jan 2012 16:42:36 -0500 From: "Polk, William T." To: "draft-kucherawy-fkim-atps@tools.ietf.org" , The IESG , "secdir@ietf.org" Date: Tue, 3 Jan 2012 16:43:15 -0500 Thread-Topic: Secdir review of draft-kucherawy-fkim-atps Thread-Index: AczKYJu9555qigAfRE+b4qVg3B7nvw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-kucherawy-fkim-atps 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, 03 Jan 2012 21:43:19 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies a suite of mechanisms for "authorized" third party DKIM signatures. The suite of mechanisms includes: (1) DNS TXT records advertising that a third party has been authorized to apply DKIM signatures on behalf of the Administrative Mail Domain (ADMD); (2) a pair of DKIM signature tags to specify (a) the domain of the ADMD on whose behalf the signature was generated and (b) the selected hash algorithm; and (3) an algorithm for determining whether a third party signature should be considered equivalent to a signature applied by the ADMD. Since the working group did not have consensus that such a mechanism was required, this document is intended for publication as an experimental RFC. In my opinion, this document is appropriate and ready for publication as an Experimental RFC. I found it a nice straightforward read. (Thanks!) There are two issues that I would like to raise for discussion, though. First, Section 4.3 states: "Note that the algorithm uses hashing, but this is not a security mechanism. See Section 9.2 for discussion." However, Section 9.1 begins with: "The selection of the hash algorithm to be used (see Section 4.1) has security implications, as weaker algorithms have more risk of collision ..." This seems to be a contradiction of sorts! If it has security implications, isn't it a security mechanism? The author should give some thought to the properties they expect from the hash in this situation and revise either 4.3 or 9.1. Secondly, the more interesting issue (at least to me) is in Section 4.4. If an error is returned from the ATPS Query, the document states that the Verifier SHOULD stop processing and defer the message for later processing. This establishes an obvious denial of service vector, but that may be an acceptable tradeoff in some environments. A feature, as it were. However, DKIM "deliberately makes no binding between the DNS domain of the signer and any other identity found in the message" (Section 1). I can envision environment where the message would be accepted by the Verifier, even without the ATPS signature tag. In this case, we are deferring an acceptable message because additional information *might* be available. That seems odd to me. Is there any reason a ATPS aware verifier couldn't process the message and either (a) accept or (b) defer until the ATPS query succeeds? At a minimum, I think a brief addition to the security considerations is in order... Thanks, Tim Polk From william.polk@nist.gov Tue Jan 3 13:51:57 2012 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 DE1E311E8107; Tue, 3 Jan 2012 13:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 iGlKZjWEXRK0; Tue, 3 Jan 2012 13:51:57 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id F40F111E80AC; Tue, 3 Jan 2012 13:51:55 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 3 Jan 2012 16:51:39 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 3 Jan 2012 16:51:55 -0500 From: "Polk, William T." To: "draft-kucherawy-dkim-atps@tools.ietf.org" , The IESG , "secdir@ietf.org" Date: Tue, 3 Jan 2012 16:51:50 -0500 Thread-Topic: Secdir review of draft-kucherawy-fkim-atps Thread-Index: AczKYdAYCb8aZjENRPSoipvi0d41aQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [secdir] Secdir review of draft-kucherawy-fkim-atps 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, 03 Jan 2012 21:51:58 -0000 [Sorry for the multiple emails, fat fingered the tools address!] On 1/3/12 4:43 PM, "Polk, William T." wrote: >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the IESG. >These comments were written primarily for the benefit of the security area >directors. Document editors and WG chairs should treat these comments >just like any other last call comments. > >This draft specifies a suite of mechanisms for "authorized" third party >DKIM signatures. The suite of mechanisms includes: >(1) DNS TXT records advertising that a third party has been authorized to >apply DKIM signatures on behalf of the Administrative Mail Domain (ADMD); >(2) a pair of DKIM signature tags to specify (a) the domain of the ADMD on >whose behalf the signature was generated and (b) the selected hash >algorithm; and >(3) an algorithm for determining whether a third party signature should be >considered equivalent to a signature applied by the ADMD. > >Since the working group did not have consensus that such a mechanism was >required, this document is intended for publication as an experimental >RFC. > >In my opinion, this document is appropriate and ready for publication as >an Experimental RFC. I found it a nice straightforward read. (Thanks!) >There are two issues that I would like to raise for discussion, though. > >First, Section 4.3 states: > > "Note that the algorithm uses hashing, but this is not a security >mechanism. See Section 9.2 for discussion." > >However, Section 9.1 begins with: > > "The selection of the hash algorithm to be used (see Section 4.1) has >security implications, as weaker algorithms have more risk of collision >..." > >This seems to be a contradiction of sorts! If it has security >implications, isn't it a security mechanism? The author should give some >thought to the properties they expect from the hash in this situation and >revise either 4.3 or 9.1. > >Secondly, the more interesting issue (at least to me) is in Section 4.4. >If an error is returned from the ATPS Query, the document states that the >Verifier SHOULD stop processing and defer the message for later >processing. This establishes an obvious denial of service vector, but >that may be an acceptable tradeoff in some environments. A feature, as it >were. > >However, DKIM "deliberately makes no binding between the DNS domain of the >signer and any other identity found in the message" (Section 1). I can >envision environment where the message would be accepted by the Verifier, >even without the ATPS signature tag. In this case, we are deferring an >acceptable message because additional information *might* be available. > >That seems odd to me. Is there any reason a ATPS aware verifier couldn't >process the message and either (a) accept or (b) defer until the ATPS >query succeeds? > >At a minimum, I think a brief addition to the security considerations is >in order... > >Thanks, > >Tim Polk > > > > > From shawn.emery@oracle.com Wed Jan 4 00:41:41 2012 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 07F6F21F86C0; Wed, 4 Jan 2012 00:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 17xzkIFs9Nj5; Wed, 4 Jan 2012 00:41:40 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 753A921F868A; Wed, 4 Jan 2012 00:41:40 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q048fbuI016465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Jan 2012 08:41:38 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q048fZBd019095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jan 2012 08:41:36 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q048fYQN022725; Wed, 4 Jan 2012 02:41:35 -0600 Received: from [10.159.208.113] (/10.159.208.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Jan 2012 00:41:34 -0800 Message-ID: <4F0410AE.8050600@oracle.com> Date: Wed, 04 Jan 2012 01:41:18 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:8.0) Gecko/20111202 Thunderbird/8.0 MIME-Version: 1.0 To: secdir@ietf.org References: <4E9A7AC9.1000803@oracle.com> In-Reply-To: <4E9A7AC9.1000803@oracle.com> X-Forwarded-Message-Id: <4E9A7AC9.1000803@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-CT-RefId: str=0001.0A090208.4F0410C3.002B,ss=1,re=0.000,fgs=0 Cc: draft-ietf-rtgwg-lfa-applicability.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-rtgwg-lfa-applicability-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: Wed, 04 Jan 2012 08:41:41 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This informational draft describes optimizations for Loop-Free Alternates (LFA) in Service Provider (SP) networks. The security considerations section does exist and states that there is no new security considerations, which I believe to be the case. General comments: Not being a routing expert this was slow to read (e.g. not knowing some of the unexpanded abbreviations and terminology). As a result, the editorial comments are just from the Abstract and Introduction sections. Editorial comments: s/applicability of LoopFree Alternates/applicability of LoopFree Alternates (LFA)/ s/Service Provider networks/Service Provider (SP) networks/ I haven't looked the common abbreviations list, but should ISIS, et. al. be expanded? Shawn. -- From stbryant@cisco.com Wed Jan 4 03:10:39 2012 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 47CA321F8682; Wed, 4 Jan 2012 03:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.676 X-Spam-Level: X-Spam-Status: No, score=-110.676 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 fuZcrF0wLgRt; Wed, 4 Jan 2012 03:10:38 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id DA20721F854D; Wed, 4 Jan 2012 03:10:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2391; q=dns/txt; s=iport; t=1325675438; x=1326885038; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=LwYi6jdv6s5BAAZyvazyGSt1peOjAtcpaH+NwSvMUog=; b=RiujoFTAlth8LdAM6qS/Qyxn2BIjoV8IHdDh3WRLrU9hCWr/ZzULcwBh 3kAlQuqIpX0qyNrwT+RxKSpkRX11ObtbG3w0PDT1g3aIaZb7T/gBAOFoE tr9H7dVA/5Wfn9WLDr7Xg8BS8LVO7Uz1cs9z6+J6oFSMEeh8mriwKOHQE 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFADEyBE+Q/khR/2dsb2JhbABDggWoJoI8gQWBcgEBAQQSAQIBIjMNARALGAkWDwkDAgECAUUGAQwBBwEBHp8cAYMuDwGaZYwPBJUEkjQ X-IronPort-AV: E=Sophos;i="4.71,455,1320624000"; d="scan'208";a="62716186" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 04 Jan 2012 11:10:16 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q04BAGfG015254; Wed, 4 Jan 2012 11:10:16 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q04BAF5n021801; Wed, 4 Jan 2012 11:10:15 GMT Message-ID: <4F043397.2090706@cisco.com> Date: Wed, 04 Jan 2012 11:10:15 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Shawn Emery , draft-ietf-rtgwg-lfa-applicability.all@tools.ietf.org, rtgwg-chairs@tools.ietf.org, rtgwg-chairs@tools.ietf.org References: <4E9A7AC9.1000803@oracle.com> <4F0410AE.8050600@oracle.com> In-Reply-To: <4F0410AE.8050600@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-rtgwg-lfa-applicability-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 11:10:39 -0000 On 04/01/2012 08:41, Shawn Emery wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > This informational draft describes optimizations for Loop-Free > Alternates (LFA) > in Service Provider (SP) networks. > > The security considerations section does exist and states that there is > no new security considerations, which I believe to be the case. > > General comments: > > Not being a routing expert this was slow to read (e.g. not knowing > some of the > unexpanded abbreviations and terminology). As a result, the editorial > comments are just > from the Abstract and Introduction sections. > > Editorial comments: > > s/applicability of LoopFree Alternates/applicability of LoopFree > Alternates (LFA)/ > s/Service Provider networks/Service Provider (SP) networks/ > I haven't looked the common abbreviations list, but should ISIS, et. > al. be expanded? > > Shawn. > -- > > Shawn Thank you for your review, and for picking up an inconsistency that we had all missed. "ISIS" is well known, but technically it should be IS-IS. There is some security text that is in previous work on this subject that it is useful to reference that I have added in via an editor's note. For everyone's benefit I append the editors notes for the document. Though out the document please: s/ISIS/IS-IS/ s/LoopFree/loop-free/ Then s/Service Provider networks/Service Provider (SP) networks/ In section 1 Old In this document, we analyze the applicability of LoopFree Alternates in both core and access parts of Service Provider networks. New In this document, we analyze the applicability of Loop-Free Alternates (LFA) [RFC5714][RFC5286] in both core and access parts of Service Provider (SP) networks. End ===== In References add normative ref to RFC 5286 ===== In Section 8 Old This document does not introduce any new security considerations. New The security considerations applicable to LFAs are described in RFC5286. This document does not introduce any new security considerations. End ===== - Stewart From tobias.gondrom@gondrom.org Wed Jan 4 05:00:31 2012 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 A3A7921F8715 for ; Wed, 4 Jan 2012 05:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.778 X-Spam-Level: X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=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 ZX6yK8eHu460 for ; Wed, 4 Jan 2012 05:00:31 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8184B21F86D1 for ; Wed, 4 Jan 2012 05:00:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=fj1qibpSU75/00Jf85dpgiksn/SYul/imUQQ6U96Hb35H5lsG15WJLXrUgaDQZF21XKqRFbo21SRPfPzmCTMheO25hABvcUKo/+wx8MoS/U5N/EDjFdiSE9VEyVELfQp; h=Received:Received:Message-ID:Disposition-Notification-To:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type; Received: (qmail 3826 invoked from network); 4 Jan 2012 14:00:05 +0100 Received: from unknown (HELO ?10.5.8.84?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Jan 2012 14:00:05 +0100 Message-ID: <4F044D50.7090709@gondrom.org> Date: Wed, 04 Jan 2012 13:00:00 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: draft-ietf-softwire-gateway-init-ds-lite.all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Content-Type: multipart/alternative; boundary="------------090104030409090802010707" Subject: [secdir] Secdir review of draft-ietf-softwire-gateway-init-ds-lite 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, 04 Jan 2012 13:00:31 -0000 This is a multi-part message in MIME format. --------------090104030409090802010707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The Security Considerations of this document refer to four other documents. Unfortunately it does not state whether any new security issues are introduced by GI-DS-lite (or claims that no additional security issues are introduced by this spec). A few security questions come to mind reading the spec: - is there an implication that it is allowed to establish the softwire between Gateway and AFTR at any point in time (not just startup)? - does the required uniqueness of combination of CID and SWID result in any attack vectors? (btw. in section 3 do you mean "The combination of CID and SWID must be unique between gateway and AFTR" or "The combination of CID and SWID MUST be unique between gateway and AFTR" - to define that the translation scheme configuration will be done either manually or out-of-band seems to solve some security worries, however, does this imply these MUST be done manually or out-of-band (e.g. for security purposes)? COMMENT/DISCUSS: I am concerned about the weak or possibly not proper use of RFC2119 wording in wide parts of the drafts. In several cases I would expect RFC-2119 language instead of the currently used can/may/must (e.g. take a read of section 4 and 5). typos: Section 1: s/GRE based encapsulation mechanisms is chosen/a GRE based encapsulation mechanism is chosen Best regards, Tobias --------------090104030409090802010707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

The Security Considerations of this document refer to four other documents. Unfortunately it does not state whether any new security issues are introduced by GI-DS-lite (or claims that no additional security issues are introduced by this spec).

A few security questions come to mind reading the spec:
- is there an implication that it is allowed to establish the softwire between Gateway and AFTR at any point in time (not just startup)?
- does the required uniqueness of combination of CID and SWID result in any attack vectors?
(btw. in section 3 do you mean "The combination of CID and SWID must be unique between gateway and AFTR" or "The combination of CID and SWID MUST be unique between gateway and AFTR"
- to define that the translation scheme configuration will be done either manually or out-of-band seems to solve some security worries, however, does this imply these MUST be done manually or out-of-band (e.g. for security purposes)?

COMMENT/DISCUSS:
I am concerned about the weak or possibly not proper use of RFC2119 wording in wide parts of the drafts. In several cases I would expect RFC-2119 language instead of the currently used can/may/must (e.g. take a read of section 4 and 5).

typos:
Section 1:
s/GRE based encapsulation mechanisms is chosen/a GRE based encapsulation mechanism is chosen

Best regards, Tobias

 --------------090104030409090802010707-- From weiler+secdir@watson.org Thu Jan 5 09:03:16 2012 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 C473221F87E0 for ; Thu, 5 Jan 2012 09:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_40=-0.185] 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 sVxvNjANm-6h for ; Thu, 5 Jan 2012 09:03:16 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id F0BAB21F87DF for ; Thu, 5 Jan 2012 09:03:15 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q05H3FY7071217 for ; Thu, 5 Jan 2012 12:03:15 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q05H3EaJ071203 for ; Thu, 5 Jan 2012 12:03:14 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 5 Jan 2012 12:03:14 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 05 Jan 2012 12:03:15 -0500 (EST) 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, 05 Jan 2012 17:03:17 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Tero Kivinen is next in the rotation. For telechat 2012-01-19 Reviewer LC end Draft Rob Austein T 2012-01-11 draft-ash-gcac-algorithm-spec-03 Alan DeKok T 2012-01-06 draft-yevstifeyev-disclosure-relation-02 Phillip Hallam-Baker T 2012-01-18 draft-jiang-a6-to-historic-00 Sam Hartman T 2012-01-05 draft-ietf-kitten-sasl-saml-07 Jeffrey Hutzelman T 2012-01-18 draft-ietf-marf-authfailure-report-09 Leif Johansson T 2012-01-16 draft-ietf-mile-rfc6045-bis-05 Leif Johansson T 2012-01-17 draft-ietf-mile-rfc6046-bis-05 Charlie Kaufman T 2012-01-18 draft-ietf-netext-radius-pmip6-06 Julien Laganier T 2012-01-18 draft-ietf-marf-redaction-04 Last calls and special requests: Reviewer LC end Draft Dave Cridland 2012-01-03 draft-os-ietf-sshfp-ecdsa-sha2-04 Steve Hanna 2012-01-13 draft-nottingham-http-new-status-03 Paul Hoffman 2012-01-12 draft-ietf-alto-reqs-12 Love Hornquist-Astrand 2012-01-13 draft-ietf-pcn-signaling-requirements-07 Scott Kelly 2012-01-17 draft-ietf-netext-bulk-re-registration-09 Stephen Kent - draft-ietf-dhc-secure-dhcpv6-03-04 Tina TSOU 2011-04-23 draft-shin-augmented-pake-08 From secdir-bounces@mit.edu Mon Jan 9 04:27:35 2012 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 41A8821F86DB for ; Mon, 9 Jan 2012 04:27:35 -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 YDPQm2pZ2ipv for ; Mon, 9 Jan 2012 04:27:31 -0800 (PST) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF4E21F873A for ; Mon, 9 Jan 2012 04:27:31 -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 q09CRUbU007475 for ; Mon, 9 Jan 2012 07:27:30 -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 q09CRRXX007472 for ; Mon, 9 Jan 2012 07:27:27 -0500 Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by mailhub-dmz-3.mit.edu (8.13.8/8.9.2) with ESMTP id q09CRJbs000327 for ; Mon, 9 Jan 2012 07:27:27 -0500 X-AuditID: 12074422-b7fd66d0000008f9-9a-4f0add2fe98f Authentication-Results: symauth.service.identifier Received: from mail-lpp01m010-f49.google.com (mail-lpp01m010-f49.google.com [209.85.215.49]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 41.F4.02297.F2DDA0F4; Mon, 9 Jan 2012 07:27:27 -0500 (EST) Received: by lahc1 with SMTP id c1so2315528lah.36 for ; Mon, 09 Jan 2012 04:27:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=rnYaooja30Tfjgoj+C9NJiuqB0JcEZH7oMu8rvt6QqY=; b=CgJyU73avCu/93WRb5htBOCzyCsJB1PqL8UF5OagwU+nhT2ID1iUmgl1w742a8OZwK eTTw/0F7J+tsRFIEr2Saxptjasd8x0oCXKdPCydTYbkulWqR0ZEgnn/ueulYzy4TuauQ o2zSbihiVo0nuYJ28O6TpM9OqQV+dplho8PFE= Received: by 10.112.45.198 with SMTP id p6mr3278246lbm.11.1326112046682; Mon, 09 Jan 2012 04:27:26 -0800 (PST) Received: from a88-112-207-191.elisa-laajakaista.fi (a88-112-207-191.elisa-laajakaista.fi. [88.112.207.191]) by mx.google.com with ESMTPS id jn4sm72256514lab.16.2012.01.09.04.27.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Jan 2012 04:27:25 -0800 (PST) From: jouni korhonen Date: Mon, 9 Jan 2012 14:27:16 +0200 Message-Id: <35510875-4467-40D9-BABE-FD35C298F115@gmail.com> To: secdir@mit.edu Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBKsWRWlGSWpSXmKPExsVyMfS6oa7+XS5/gz/LdCzanu1mc2D0aDpz lDmAMYrLJiU1J7MstUjfLoEro+F3K2vBbpaKe513WRoYLzF3MXJySAiYSEzedIEVxGYUMJLY fe4VK0RcTOLCvfVsXYxcHEICTxkljt6/ygKSEBIok9j17x0TSIJF4DKzxOUfh9ggEuUSC7ZO g7JVJb7tns8K0T2TSeLoolPsIAk2AV2JDY1rwCYxC2hJ3Pj3kgnC1pZYtvA10EkcHMIClhJT l4OFWQRUJJbN3Q92Ea+AjcTU6W1gFzELzGSUmH/yJ9gLIgJCEjcW/GeBKDKUWLqpnR1kjoSA rETTsowJjMKzkGybhWTbLCQdCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFuma6uVmluilppRu YgQGtxC7i9IOxp8HlQ4xCnAwKvEAncXlL8SaWFZcmXuIUZKDSUmUd95toBBfUn5KZUZicUZ8 UWlOavEhRgkOZiUR3so+oBxvSmJlVWpRPkxKmoNFSZxXXeudn5BAemJJanZqakFqEUyWiYP9 EKMMB4eSBO+kO0DdgkWp6akVaZk5JchqOEEEF8gaHqA1E0EKeYsLEnOLM9Mhik4xWnLMaJ57 jpHj0Kv5QPLc9AXnGIVY8vLzUqXEeReCNAiANGSU5sENBiWw+v///19ilJUS5mVkYGAQ4gG6 DBggCHlQAnzFKA4MDGHebpApPJl5JXBbXwEdxAR00IM/7CAHlSQipKQaGOuM/adNkb+TIttU MdGo81PKJsEHswx+9E7W/80Z6HanbangXrWjRSGMR3IFAz8b/v1pHjCns0R65ovFMrx9qiFv GbbObGTvO35p/elDnYsaFBivuM/eIL54YrxB3jeVva7fN/v+nihVcH17qOn+1S0TzRb/2jkn Qe5Ht4jB67YCt/LfGrpNs5VYijMSDbWYi4oTAUob9klbAwAA X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id q09CRRXX007472 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: Jouni Korhonen , "Mauricio \(HP Networking\) Sanchez" , "Dan \(Dan\) Romascanu" Subject: [secdir] Requesting review of draft-ietf-radext-radsec-09 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, 09 Jan 2012 12:27:35 -0000 Dear Security Directorate, We (RADEXT chairs) solicit for security expert review for "TLS encryption for RADIUS" I-D. The I-D can be found at: http://tools.ietf.org/html/draft-ietf-radext-radsec-09 Do not mind about the expired state. There will shortly be -10 revision just to keep the I-D alive and fixing one outdated reference [I-D.winter-dynamic-discovery]. We are moving the document to IESG process shortly thus the review comments should be directed to document authors, AD and RADEXT chairs. Best regards, Jouni - RADEXT co-chair _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From new-work-bounces@ietf.org Mon Jan 9 11:38:42 2012 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 9D42A21F85FD; Mon, 9 Jan 2012 11:38:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326137922; bh=wYPTnal9XTLapqv9/PAuhg/vo61Kuhvy7D/nQyKNwFY=; h=From:Date:Message-Id:To:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=L9flbFqBlygeh0yUrW+Ot4b39X34cNCKsjmz3RX8Bqbe3DNmkdCH3HsmlQb/xH4m2 hG4uqQB6TGqXyzS3PFRPey2+yHVV3ry+WxWkYisT75XZBjoDvKikL1UBIQ0VSwCtWT G5BZkfiwAok3MTrqEqPxvuYbb8EhNCRyKAmd/NeU= 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 BC14421F85FD for ; Mon, 9 Jan 2012 11:38:40 -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=[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 yzRLykz-aTHt for ; Mon, 9 Jan 2012 11:38:40 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:123a::1:14]) by ietfa.amsl.com (Postfix) with ESMTP id 393E221F85F6 for ; Mon, 9 Jan 2012 11:38:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 1D91312D145 for ; Mon, 9 Jan 2012 11:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrJ58ANmUsEC for ; Mon, 9 Jan 2012 11:38:37 -0800 (PST) Received: from [192.168.147.50] (unknown [74.202.225.34]) by c8a.amsl.com (Postfix) with ESMTPSA id D046B12C8A0 for ; Mon, 9 Jan 2012 11:38:36 -0800 (PST) From: IETF Chair Date: Mon, 9 Jan 2012 14:38:05 -0500 Message-Id: To: new-work@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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: Mon, 09 Jan 2012 11:41:04 -0800 Subject: [secdir] [new-work] Considering adding ONF to the new-work mail list 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, 09 Jan 2012 19:38:42 -0000 We are considering adding ONF (https://www.opennetworking.org/) to the new-work mail list. Before doing so, we would like to know if any current members of the mail list would have any concerns regarding this action. If you have concerns, please let me know in the next week. Thanks, Russ Housley IETF Chair _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Mon Jan 9 11:45:59 2012 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 E194D21F86C4; Mon, 9 Jan 2012 11:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326138359; bh=ZaEYSo+sLyXv3/RNXAjGDwsiws0ZFAPMV78ORaN9KFg=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=V1viMN3jNAtjngu6ne//2DtomC1OXFDwBKKqbNP6ir3pqaw5hni3uA9OLrzMXpwca H8KYUJfTawPnlPwrNRh5hyDcghsLuGO5NNvWVIbs3ikjJQEzD/9cYYAHHOWT6aNER/ 4ELDsnOUvLexgz5d+KYRLea8f9zEIkRNR1mf7uBU= 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 8A64521F86C4; Mon, 9 Jan 2012 11:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 JFVHSmDN1NkD; Mon, 9 Jan 2012 11:45:58 -0800 (PST) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by ietfa.amsl.com (Postfix) with ESMTP id 03E1621F8693; Mon, 9 Jan 2012 11:45:57 -0800 (PST) Received: from G2W1953G.americas.hpqcorp.net (g2w1953g.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id 328D138289; Mon, 9 Jan 2012 19:45:57 +0000 (UTC) Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 9 Jan 2012 19:45:03 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Mon, 9 Jan 2012 19:45:02 +0000 From: "Congdon, Paul T (HPLabs)" To: IETF Chair , "new-work@ietf.org" Date: Mon, 9 Jan 2012 19:45:01 +0000 Thread-Topic: [new-work] Considering adding ONF to the new-work mail list Thread-Index: AczPBlJrYhRjHvwpThKWXxZNPggr1QAAJYlQ Message-ID: References: In-Reply-To: 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: 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: Mon, 09 Jan 2012 11:49:38 -0800 Subject: Re: [secdir] [new-work] Considering adding ONF to the new-work mail list 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, 09 Jan 2012 19:46:00 -0000 Just as FYI.. This is NOT how we have handled IEEE (as far as I understand). A liaison person is on new-work and forwards important messages to IEEE's EC reflector. Also, IEEE EC members do not post to new-work on IETF. Is there any reason why we need to do this differently? We could have Dan Pitt on the new-work list and if he sees the need to forward things to the ONF mailing list, he can do so. Paul -----Original Message----- From: new-work-bounces@ietf.org [mailto:new-work-bounces@ietf.org] On Behalf Of IETF Chair Sent: Monday, January 09, 2012 11:38 AM To: new-work@ietf.org Subject: [new-work] Considering adding ONF to the new-work mail list We are considering adding ONF (https://www.opennetworking.org/) to the new-work mail list. Before doing so, we would like to know if any current members of the mail list would have any concerns regarding this action. If you have concerns, please let me know in the next week. Thanks, Russ Housley IETF Chair _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Mon Jan 9 11:46:48 2012 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 C91E621F8752; Mon, 9 Jan 2012 11:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326138408; bh=rjxpH3u+rMOO3qOzIPmJjceyJ8c9evLgFW6103vftBo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Sender; b=t73K6wWmWSAaS7R/uCQfrx4Uj9rkLXZakg4U88WbFD4xzjOBN+/1VdD+FIwUEg4fI x51hpYJYn6z6adK3/VAihdHPyM/rYi7cm0QLuKuTZetqziV/4g6ZqsXPqNBZWC4KEI V26ClxaFmQS7WqjXfpZYjE8JMsLDb7aFImVMRqg0= 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 8AA5821F875A; Mon, 9 Jan 2012 11:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wIVXOjLf+XJP; Mon, 9 Jan 2012 11:46:47 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC5D21F8693; Mon, 9 Jan 2012 11:46:40 -0800 (PST) Received: by wibhj6 with SMTP id hj6so3688452wib.31 for ; Mon, 09 Jan 2012 11:46:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gSO1ukWQBUMTH4QmCRwtYHKd43fkevARIUTZABXowPk=; b=IrX/psNNfZPDH030QUnya+bH58Soyd7vRtL2OTHW7F+NYNU/CGKXDCe8/X2GufIe3+ 22lJDeQAE2Vtr2F5eUub6NrxKFq1k5bploOsDDXVmn6N6gceVXMMZk8832TtknvGtvpT xkfDrhlSS5Mmd9tj85gtcHI4tP5WMJhXMtQgg= Received: by 10.180.91.201 with SMTP id cg9mr30065756wib.15.1326138398253; Mon, 09 Jan 2012 11:46:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.180.83.201 with HTTP; Mon, 9 Jan 2012 11:46:17 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Mon, 9 Jan 2012 14:46:17 -0500 Message-ID: To: IETF Chair X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: multipart/mixed; boundary="===============4263849369324045107==" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 09 Jan 2012 11:49:38 -0800 Cc: new-work@ietf.org Subject: Re: [secdir] [new-work] Considering adding ONF to the new-work mail list 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, 09 Jan 2012 19:46:49 -0000 --===============4263849369324045107== Content-Type: multipart/alternative; boundary=f46d043bdf1426a27d04b61da859 --f46d043bdf1426a27d04b61da859 Content-Type: text/plain; charset=ISO-8859-1 Russ, I think this would be a very good thing. So no concerns here! Cheers, Andy On Mon, Jan 9, 2012 at 2:38 PM, IETF Chair wrote: > We are considering adding ONF (https://www.opennetworking.org/) to the > new-work mail list. Before doing so, we would like to know if any current > members of the mail list would have any concerns regarding this action. If > you have concerns, please let me know in the next week. > > Thanks, > Russ Housley > IETF Chair > _______________________________________________ > new-work mailing list > new-work@ietf.org > https://www.ietf.org/mailman/listinfo/new-work > --f46d043bdf1426a27d04b61da859 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Russ,

I think this would be a very good thing. So no concerns here!<= br>
Cheers,
Andy

On Mon, Jan 9, 201= 2 at 2:38 PM, IETF Chair <chair@ietf.org> wrote:
We are considering adding ONF (https://www.opennetworking= .org/) to the new-work mail list. =A0Before doing so, we would like to = know if any current members of the mail list would have any concerns regard= ing this action. =A0If you have concerns, please let me know in the next we= ek.

Thanks,
=A0Russ Housley
=A0IETF Chair
_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

--f46d043bdf1426a27d04b61da859-- --===============4263849369324045107== 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 --===============4263849369324045107==-- From new-work-bounces@ietf.org Mon Jan 9 13:33:35 2012 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 5E3ED21F86C4; Mon, 9 Jan 2012 13:33:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326144815; bh=m6LfjAsIT/HWUwBONygBhTlJPx5zX70+Y1kX5GkUaHo=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=LFE+FgNBdWeGyt3oIZTLwbSQgjGLaFeSNAV5rfPl9BTLNnv4sSD8UfPeINbcvU/rx 5A0w+BZMaET//flaPanrAP11+ZnFpL/CSfHw2fhxR4t0Mj3yUo2GvTF/c7Og6VB2N7 yEzrKNr/sY0/UFypKRUMG5s6rt/FPh2Qz+jr9ytE= 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 EDD6221F86C4 for ; Mon, 9 Jan 2012 13:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 l3i-h8wPuIYu for ; Mon, 9 Jan 2012 13:33:33 -0800 (PST) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA1A21F86A0 for ; Mon, 9 Jan 2012 13:33:32 -0800 (PST) Received: from G4W3011G.americas.hpqcorp.net (g4w3011g.houston.hp.com [16.234.25.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id 582112C183; Mon, 9 Jan 2012 21:33:32 +0000 (UTC) Received: from G6W0644.americas.hpqcorp.net (16.230.34.80) by G4W3011G.americas.hpqcorp.net (16.234.25.125) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 9 Jan 2012 21:32:52 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.3]) by G6W0644.americas.hpqcorp.net ([16.230.34.80]) with mapi; Mon, 9 Jan 2012 21:32:51 +0000 From: "Congdon, Paul T (HPLabs)" To: Russ Housley Date: Mon, 9 Jan 2012 21:32:50 +0000 Thread-Topic: [new-work] Considering adding ONF to the new-work mail list Thread-Index: AczPFMmzDuZPolH1RoeDrhDbG1QqWAAAVZug Message-ID: References: In-Reply-To: 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: 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: Mon, 09 Jan 2012 14:16:07 -0800 Cc: "new-work@ietf.org" Subject: Re: [secdir] [new-work] Considering adding ONF to the new-work mail list 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, 09 Jan 2012 21:33:35 -0000 Given this, then, I agree and support the idea. -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Monday, January 09, 2012 1:22 PM To: Congdon, Paul T (HPLabs) Cc: new-work@ietf.org Subject: Re: [new-work] Considering adding ONF to the new-work mail list Paul: This was not a suggestion to change the way this list is used. In this case, someone (perhaps Dan Pitt) or a small number of people from ONF would be added. The mail list member(s) would pass the message to others in the ONF as needed. I do not want to bring new organizations to the new-work mail list without the knowledge and consent of the existing members. Russ On Jan 9, 2012, at 2:45 PM, Congdon, Paul T (HPLabs) wrote: > Just as FYI.. This is NOT how we have handled IEEE (as far as I understand). A liaison person is on new-work and forwards important messages to IEEE's EC reflector. Also, IEEE EC members do not post to new-work on IETF. Is there any reason why we need to do this differently? We could have Dan Pitt on the new-work list and if he sees the need to forward things to the ONF mailing list, he can do so. > > Paul > > -----Original Message----- > From: new-work-bounces@ietf.org [mailto:new-work-bounces@ietf.org] On Behalf Of IETF Chair > Sent: Monday, January 09, 2012 11:38 AM > To: new-work@ietf.org > Subject: [new-work] Considering adding ONF to the new-work mail list > > We are considering adding ONF (https://www.opennetworking.org/) to the new-work mail list. Before doing so, we would like to know if any current members of the mail list would have any concerns regarding this action. If you have concerns, please let me know in the next week. > > Thanks, > Russ Housley > IETF Chair _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Mon Jan 9 13:34:22 2012 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 4041C21F8557; Mon, 9 Jan 2012 13:34:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326144862; bh=1OQCcVa/qokrTwFDI4NecXCGvzpC+fXDB/kd2ZdQnB8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:From:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=w25dFkGmyiZaTWIZJ7mFbzD14E12KHaD89cNsn8HBXbeBRYgTfXc3+FpHIHTKeT9m 4VyHMOH6fvPdt1fte7L2ao42/fPt5WkoJhKhboinP/o8gzW9/c+0mECEYEebUJpN5Z 4eTbU7dxfFiv6KtGhxyEzt/PAz+TKJWvuiyBzvfk= 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 D952021F86F9; Mon, 9 Jan 2012 13:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 sDr6plgFz2Ry; Mon, 9 Jan 2012 13:34:20 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66DA021F86EC; Mon, 9 Jan 2012 13:34:20 -0800 (PST) Received: by pbdd12 with SMTP id d12so3392552pbd.31 for ; Mon, 09 Jan 2012 13:34:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.74.4 with SMTP id p4mr44093026pbv.123.1326144860137; Mon, 09 Jan 2012 13:34:20 -0800 (PST) Received: by 10.68.197.39 with HTTP; Mon, 9 Jan 2012 13:34:20 -0800 (PST) X-Originating-IP: [128.223.156.117] In-Reply-To: References: Date: Mon, 9 Jan 2012 13:34:20 -0800 Message-ID: From: David Meyer To: IETF Chair X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 09 Jan 2012 14:16:07 -0800 Cc: new-work@ietf.org Subject: Re: [secdir] [new-work] Considering adding ONF to the new-work mail list 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, 09 Jan 2012 21:34:22 -0000 On Mon, Jan 9, 2012 at 11:38 AM, IETF Chair wrote: > We are considering adding ONF (https://www.opennetworking.org/) to the ne= w-work mail list. =A0Before doing so, we would like to know if any current = members of the mail list would have any concerns regarding this action. =A0= If you have concerns, please let me know in the next week. Sounds like a good idea to me. Dave _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Jan 10 13:29:28 2012 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 7D0E721F8566; Tue, 10 Jan 2012 13:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326230968; bh=ZSD9Cmxvl+eZEjKUPS0AVdfvOr94zb6YfqeVko/TY0w=; h=Date:From:In-reply-to:To:Message-id:MIME-version:References: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=pd4CavzK2kWdudaTJbrFg6zw0RJcP8sP2l3TT/zMn7xUJhMDI/qwylk4OkuB1TPZf Lfp6liGb3rzqJi/rQ4hfvprM0TsCk3IAAVWxBXXHFE4IJoYfWtlKv0cuFc7c3tYpq1 0V6ARffX7QxLYSkvwyCoLLDTsbt+ztql9K4lz0vg= 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 10DFC21F8709; Mon, 9 Jan 2012 11:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.568 X-Spam-Level: X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 SpPY6+B8Q0Sr; Mon, 9 Jan 2012 11:56:11 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 44D4621F8748; Mon, 9 Jan 2012 11:56:11 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXJ00HXIRDETZ@szxga03-in.huawei.com>; Tue, 10 Jan 2012 03:56:02 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXJ00BDQRDEG5@szxga03-in.huawei.com>; Tue, 10 Jan 2012 03:56:02 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGI04640; Tue, 10 Jan 2012 03:56:02 +0800 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 10 Jan 2012 03:55:58 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Tue, 10 Jan 2012 03:55:41 +0800 Date: Mon, 09 Jan 2012 19:55:40 +0000 From: Tina TSOU In-reply-to: X-Originating-IP: [10.212.244.76] To: "Congdon, Paul T (HPLabs)" , IETF Chair , "new-work@ietf.org" Message-id: MIME-version: 1.0 Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [secdir] [new-work] Considering adding ONF to the new-work mail list Thread-index: AQHMzwfsdgtBpgO0sUO37hVgko2/GpYEcx9A X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: X-Mailman-Approved-At: Tue, 10 Jan 2012 13:29:27 -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, 11 Jan 2012 15:51:06 -0800 Subject: Re: [secdir] [new-work] Considering adding ONF to the new-work mail list 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, 10 Jan 2012 21:29:28 -0000 Support. Tina >-----Original Message----- >From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf Of >Congdon, Paul T (HPLabs) >Sent: Monday, January 09, 2012 1:45 PM >To: IETF Chair; new-work@ietf.org >Subject: Re: [secdir] [new-work] Considering adding ONF to the new-work >mail list > >Just as FYI.. This is NOT how we have handled IEEE (as far as I understand). >A liaison person is on new-work and forwards important messages to IEEE's >EC reflector. Also, IEEE EC members do not post to new-work on IETF. Is >there any reason why we need to do this differently? We could have Dan >Pitt on the new-work list and if he sees the need to forward things to the >ONF mailing list, he can do so. > >Paul > >-----Original Message----- >From: new-work-bounces@ietf.org [mailto:new-work-bounces@ietf.org] On >Behalf Of IETF Chair >Sent: Monday, January 09, 2012 11:38 AM >To: new-work@ietf.org >Subject: [new-work] Considering adding ONF to the new-work mail list > >We are considering adding ONF (https://www.opennetworking.org/) to the new- >work mail list. Before doing so, we would like to know if any current >members of the mail list would have any concerns regarding this action. If >you have concerns, please let me know in the next week. > >Thanks, > Russ Housley > IETF Chair >_______________________________________________ >new-work mailing list >new-work@ietf.org >https://www.ietf.org/mailman/listinfo/new-work >_______________________________________________ >new-work mailing list >new-work@ietf.org >https://www.ietf.org/mailman/listinfo/new-work >_______________________________________________ >secdir mailing list >secdir@ietf.org >https://www.ietf.org/mailman/listinfo/secdir >wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Jan 10 13:31:06 2012 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 6329E21F86D5; Tue, 10 Jan 2012 13:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326231066; bh=m8O52pkN0sAc9qszknE/3roFSQOtoYsd3btIL4Vx+sg=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=hsjUi4ZCXomAX4aUeFu6wB3bAK2WsikQCXxTTc1Qzl51hZc8eZwrhw8AE3zQauvvD 5DwZ4V5Dz4kBuzzk30oVbVosvY8IYRqpBg14UfEhml52uoJMPruZk7SYTyg635nm+3 MC1XFS7s7x69JCDMv2IhGMmPMa1OgPJ26BVCg8ak= 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 AB24521F8748 for ; Mon, 9 Jan 2012 13:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 8t8s1TyAMhsD for ; Mon, 9 Jan 2012 13:22:09 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id DA25B21F873E for ; Mon, 9 Jan 2012 13:22:08 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 8BA189A47A0; Mon, 9 Jan 2012 16:22:14 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id GRyFNWPGQ3ft; Mon, 9 Jan 2012 16:22:03 -0500 (EST) Received: from [192.168.2.104] (pool-96-241-165-215.washdc.fios.verizon.net [96.241.165.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id D17B49A474D; Mon, 9 Jan 2012 16:22:13 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) From: Russ Housley In-Reply-To: Date: Mon, 9 Jan 2012 16:22:06 -0500 Message-Id: References: To: "Congdon, Paul T (HPLabs)" X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 10 Jan 2012 13:31:06 -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, 11 Jan 2012 15:51:06 -0800 Cc: "new-work@ietf.org" Subject: Re: [secdir] [new-work] Considering adding ONF to the new-work mail list 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, 10 Jan 2012 21:31:06 -0000 Paul: This was not a suggestion to change the way this list is used. In this case, someone (perhaps Dan Pitt) or a small number of people from ONF would be added. The mail list member(s) would pass the message to others in the ONF as needed. I do not want to bring new organizations to the new-work mail list without the knowledge and consent of the existing members. Russ On Jan 9, 2012, at 2:45 PM, Congdon, Paul T (HPLabs) wrote: > Just as FYI.. This is NOT how we have handled IEEE (as far as I understand). A liaison person is on new-work and forwards important messages to IEEE's EC reflector. Also, IEEE EC members do not post to new-work on IETF. Is there any reason why we need to do this differently? We could have Dan Pitt on the new-work list and if he sees the need to forward things to the ONF mailing list, he can do so. > > Paul > > -----Original Message----- > From: new-work-bounces@ietf.org [mailto:new-work-bounces@ietf.org] On Behalf Of IETF Chair > Sent: Monday, January 09, 2012 11:38 AM > To: new-work@ietf.org > Subject: [new-work] Considering adding ONF to the new-work mail list > > We are considering adding ONF (https://www.opennetworking.org/) to the new-work mail list. Before doing so, we would like to know if any current members of the mail list would have any concerns regarding this action. If you have concerns, please let me know in the next week. > > Thanks, > Russ Housley > IETF Chair _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Jan 10 13:39:54 2012 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 17B9321F8783; Tue, 10 Jan 2012 13:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326231594; bh=XA3u4H3JN/fzvZ9P6YCzIdjMCjDgvDnuYTUIwfxDdXw=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=i0/C2SVF6uhPXNqXkUq6K4+5ompbUctd6RksmmQfxEw7I40uc6Ikokvy7tJnRwd55 oJ4cUqUSb4N4+Xsc4gYz7B9bcOWDaExaDvCv2ya4e3MYsSrZkU5IRcMwETetTILDb4 Fi2X6bFmDi0rMfSxqA2hBYCukkfmdfFuPsSoQzRI= 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 0BDE621F8569 for ; Tue, 10 Jan 2012 13:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 EApjhfkTbGXf for ; Tue, 10 Jan 2012 13:39:51 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id EBF7321F851E for ; Tue, 10 Jan 2012 13:39:50 -0800 (PST) Received: from [10.0.0.232] (user.216.126.222.zhong-ren.net [222.126.216.9]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MTAxK-1SAcYW3SbO-00S706; Tue, 10 Jan 2012 16:39:50 -0500 Message-ID: <4F0CB01F.3040107@wonderhamster.org> Date: Tue, 10 Jan 2012 15:39:43 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: new-work@ietf.org References: In-Reply-To: X-Provags-ID: V02:K0:4l8g83bC1A/sfehjXeBP8QKiPJOLJiSdTKa+c93ZzvR wgHkd/cHch+GZhs6tkQ6lY69vQu0iCETIGujEOqwNilcN/Zwnl phoq3llrCUkCCukmwl3YDfFyW3IxzG6A074/so3hWlcP+blncn F6+b9lxcrbXX2fGWyTXfBN0GPypHVwTlCgXJmUiV4cKIuVlTx2 krsPPF2jPwmIBLFBHKJ+LX3u90uz5kE6DOd+cK7DBjrV/sPpP7 NmcXu1BXz6Ckd8WXoKa6fy9E4tMGkIvu+h6GcT0hGNRA6g3BfA uhs1h+Imhqikc9INqO783WDZrKNKtfMx2Hu19FnB0tTbWGDK3r uePgBzRND9T3yTJAve6Czayj3Ff20QduLC05faeqP 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" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 11 Jan 2012 15:51:06 -0800 Cc: Bernard Aboba Subject: Re: [secdir] [new-work] Considering adding ONF to the new-work mail list 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, 10 Jan 2012 21:39:54 -0000 On 1/9/2012 1:38 PM, IETF Chair wrote: > We are considering adding ONF (https://www.opennetworking.org/) to the new-work mail list. Before doing so, we would like to know if any current members of the mail list would have any concerns regarding this action. If you have concerns, please let me know in the next week. > > Thanks, > Russ Housley > IETF Chair So ... My suggestion as list moderator, and as the IAB prime for the Liaison Oversight IAB program that includes New-Work, is that anyone with concerns about Russ's question please contact Russ directly. I've released a couple of moderated posts (including one by Russ :-) because this probably wasn't clear to people who were replying, but we're not set up to be both an announcement list and a discussion list. There are a large number of new-work list participants who are only monitoring, looking for announcements of interest to their own SDOs (which are not the IETF). I would prefer that we not generate more traffic than we need to, in order to make sure they notice when someone DOES make announcements of interest. And my apologies for not sending this sooner - I'm traveling this week, with limited access to the Internet. Thanks, Spencer _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Wed Jan 11 08:38:43 2012 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 BE91221F8863; Wed, 11 Jan 2012 08:38:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326299923; bh=+UhCEEus07sr7hKrpTBkGleewk9/tq6Pqj3dX0tgDhg=; h=From:To:Mime-Version:Message-Id:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=hoPRvdn0cWZ4grrg4h0dcqvYSi6ZfFJQKHGFrqoy3R/XD80KwLLWTJFil58V9Q+Np skG/ttNMP0lBlBnmNVsk5VDSQN3Rh2e7D3MAqUsyAgOrgbYek5wRkcEkFiLPZrf1eR ex/qtcXBIEQA/wNMwjEXKMLyo31DVqOdDipXsM6k= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id D6E3921F8855; Wed, 11 Jan 2012 08:38:41 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20120111163841.D6E3921F8855@ietfa.amsl.com> Date: Wed, 11 Jan 2012 08:38:41 -0800 (PST) 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, 11 Jan 2012 15:51:06 -0800 Subject: [secdir] [new-work] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 16:38:44 -0000 A modified charter has been submitted for the Diameter Maintenance and Extensions (dime) working group in the Operations and Management Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, January 18, 2012. Diameter Maintenance and Extensions (dime) ----------------------------------------- Current Status: Active Last Modified: 2012-01-10 Chairs: Lionel Morand Jouni Korhonen Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting, charging in network access, provisioning of configuration information within the network, and for new AAA session management uses within the extensibility rules of the Diameter base protocol. The DIME working group plans to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Protocol extensions for bulk and grouped AAA session management. The aim of this work is to study and standardize a solution for handling groups of AAA sessions within the Diameter base protocol context. The solution would define how to identify and handle grouped AAA sessions in commands and operations. Additionally, Diameter-based systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed, and is within the extensibility rules of Diameter and AAA scope. Coordination with other IETF working groups and other SDOs (e.g. 3GPP) will be used to ensure this. Goals and Milestones: Done - Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standards:* 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done - Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Done - Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done - Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter NAT Control Application' as DIME working group item Done - Submit 'Diameter Capabilities Update' as DIME working group item Done - Submit 'Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' as DIME working group item Done - Submit 'Realm-Based Redirection In Diameter' as DIME working group item Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' as DIME working group item Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' as DIME working group item Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME working group item Done - Submit 'Diameter IKEv2 PSK' as DIME working group item Done - Submit Revision of 'Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic Key Transport' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Priority Attribute Value Pairs' to the IESG for consideration as a Proposed Standard Done - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' as DIME working group item Done - Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized Routing' to the IESG for consideration as a Proposed Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG for consideration as a Proposed Standard Mar 2012 - Submit Revision of 'Diameter Network Access Server Application - RFC 4005bis' to the IESG for consideration as a Proposed Standard May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Standard Jul 2012 - Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Aug 2012 - Submit a document on 'Protocol extension for bulk and group signaling' as a working group item Aug 2013 - Submit a document on 'Protocol extension for bulk and group signaling' to the IESG for consideration as a Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Wed Jan 11 14:18:38 2012 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 225B011E80A5; Wed, 11 Jan 2012 14:18:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1326320318; bh=atffWlua/OVRDiQd9Ieft9Mja2H9/uMDE2OImq/nz8U=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=lk0ZGD+QAjwOyfHV8jB/s6+aSZ3IKhCKb8dc0FR3VxYtYSqyYBBzMQStwXvkQmHdO dSJvCYvHZvcU1nr8vFvw+uYMWZIG6WnMQ8siZNmh7+HiWQhyct/PuBqy2O8urPKgdj 8l/4KONSHijsCVNtQbUmwzFwQkvS2snvevJI9WPU= 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 A769F11E80A5 for ; Wed, 11 Jan 2012 14:18:36 -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 BzqoxKsF3P1o for ; Wed, 11 Jan 2012 14:18:36 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFCC11E8074 for ; Wed, 11 Jan 2012 14:18:35 -0800 (PST) Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Rl6V8-0006Jc-Nz; Wed, 11 Jan 2012 17:18:34 -0500 From: Ian Jacobs Date: Wed, 11 Jan 2012 16:18:34 -0600 To: new-work@ietf.org Message-Id: <8D8C4FB3-A93D-4202-B970-425B2637DF36@w3.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) 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, 11 Jan 2012 15:51:05 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Independent User Interface (Indie UI) Working Group (until 2012-02-10) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 22:18:38 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the WAI Technical Activity and WAI International Program Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Independent User Interface (Indie UI) Working Group: http://www.w3.org/2011/11/indie-ui-charter As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2012-02-10 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 Judy Brewer, WAI Domain Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/WAI/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From hallam@gmail.com Thu Jan 12 05:18:26 2012 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 CE44D21F8592; Thu, 12 Jan 2012 05:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1] 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 Rpl42IQ3ZWVb; Thu, 12 Jan 2012 05:18:26 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC06A21F85AC; Thu, 12 Jan 2012 05:18:25 -0800 (PST) Received: by obcwo10 with SMTP id wo10so900434obc.31 for ; Thu, 12 Jan 2012 05:18:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=LIsVtywh4gm5fp5GTNF/D3TMwJ5Sb8tMuBtbYaA6CFw=; b=uhPaEwTC5ZvdDQsihOaoXA4ZnbLaoaSdcYwqr3w5mvMyWMhfGtdbQ0/yfuDDeXwzEx eZtI7J/zEzHvOob/S2k+X9I7ZvGHKMPls31QSvQdiHRfTLcfDOxARBVmqabLBNedVkXY AOu0E6NSRd7mN/XQtTf5eR8xd2nLFrt89Ih5o= MIME-Version: 1.0 Received: by 10.182.72.74 with SMTP id b10mr2878372obv.69.1326374305509; Thu, 12 Jan 2012 05:18:25 -0800 (PST) Received: by 10.182.45.134 with HTTP; Thu, 12 Jan 2012 05:18:25 -0800 (PST) Date: Thu, 12 Jan 2012 08:18:25 -0500 Message-ID: From: Phillip Hallam-Baker To: secdir@ietf.org, iesg@ietf.org, jiangsheng@huawei.com, drc@cloudflare.com, brian.e.carpenter@gmail.com Content-Type: multipart/alternative; boundary=f46d0447a08f51b27e04b654954e Subject: [secdir] Secdir review: http://www.ietf.org/id/draft-jiang-a6-to-historic-00.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: Thu, 12 Jan 2012 13:18:26 -0000 --f46d0447a08f51b27e04b654954e 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. Overview A6 was a proposed replacement for AAAA records. A6 has not achieved the anticipated level of support or provided the anticipated benefits in practice. This draft moves A6 to historic, deprecating use of A6 records. Comments: Removing A6 removes a potential source of inconsistency and thus improves consistency. One possible consequence of this particular change is that information that was previously expressible via the A6 mechanism will no longer be visible. While this is not necessarily good or bad from a security standpoint it is an issue that should be mentioned in the Security Considerations. Another possible security impact is that it will not be possible to divide up administrative duties in the manner originally envisaged in the A6 proposal. While it is far from clear that this division is useful (or achievable) it should probably be noted. In particular it will not be possible to achieve renumbering of whole domains by changing one record. It is quite possible that some domains will continue to employ A6 domains as an administrative convenience, generating the corresponding AAAA records as required. This case needs more consideration from a security point of view. It would be useful to require that such records be ignored by applications and preferably be blocked from external view. -- Website: http://hallambaker.com/ --f46d0447a08f51b27e04b654954e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dire= ctorate's
ongoing effort to review all IETF= documents being processed by the IESG.
These c= omments were written primarily for the benefit of the security area<= br style> directors. =A0Document editors and WG chairs should treat these= comments
just like any other last call comment= s.

Overview

A6 was a proposed replacement for AAAA records. A6 has not achieved th= e anticipated level of support or provided the anticipated benefits in prac= tice. This draft moves A6 to historic, deprecating use of A6 records.


Comments:

Removing A6 remo= ves a potential source of inconsistency and thus improves consistency.=A0

One possible consequence of this particular change = is that information that was previously expressible via the A6 mechanism wi= ll no longer be visible. While this is not necessarily good or bad from a s= ecurity standpoint it is an issue that should be mentioned in the Security = Considerations.

Another possible security impact is that it will not be= possible to divide up administrative duties in the manner originally envis= aged in the A6 proposal. While it is far from clear that this division is u= seful (or achievable) it should probably be noted. In particular it will no= t be possible to achieve renumbering of whole domains by changing one recor= d.

It is quite possible that some domains will continue to= employ A6 domains as an administrative convenience, generating the corresp= onding AAAA records as required. This case needs more consideration from a = security point of view. It would be useful to require that such records be = ignored by applications and preferably be blocked from external view.



--f46d0447a08f51b27e04b654954e-- From weiler+secdir@watson.org Thu Jan 12 08:29:50 2012 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 F38F921F84DF for ; Thu, 12 Jan 2012 08:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.712, 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 HG9h3mhPNBo8 for ; Thu, 12 Jan 2012 08:29:49 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6854C21F846A for ; Thu, 12 Jan 2012 08:29:48 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q0CGTl3L097332 for ; Thu, 12 Jan 2012 11:29:47 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q0CGTlcb097325 for ; Thu, 12 Jan 2012 11:29:47 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 12 Jan 2012 11:29:47 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 12 Jan 2012 11:29:47 -0500 (EST) 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, 12 Jan 2012 16:29:50 -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 2012-01-19 Reviewer LC end Draft Rob Austein T 2012-01-11 draft-ash-gcac-algorithm-spec-03 Alan DeKok T 2012-01-06 draft-yevstifeyev-disclosure-relation-02 Sam Hartman T 2012-01-05 draft-ietf-kitten-sasl-saml-08 Jeffrey Hutzelman T 2012-01-18 draft-ietf-marf-authfailure-report-09 Leif Johansson T 2012-01-16 draft-ietf-mile-rfc6045-bis-05 Leif Johansson T 2012-01-17 draft-ietf-mile-rfc6046-bis-05 Charlie Kaufman T 2012-01-18 draft-ietf-netext-radius-pmip6-06 Scott Kelly T 2012-01-17 draft-ietf-netext-bulk-re-registration-10 Julien Laganier T 2012-01-18 draft-ietf-marf-redaction-04 Julien Laganier T - draft-ietf-lisp-map-versioning-06 David McGrew T - draft-kompella-l2vpn-l2vpn-08 For telechat 2012-02-02 Reviewer LC end Draft Tero Kivinen T 2012-01-24 draft-ietf-6man-3627-historic-01 Chris Lonvick T 2012-01-23 draft-ietf-v6ops-ipv6-discard-prefix-02 Last calls and special requests: Reviewer LC end Draft Dave Cridland 2012-01-03 draft-os-ietf-sshfp-ecdsa-sha2-04 Steve Hanna 2012-01-13 draft-nottingham-http-new-status-03 Paul Hoffman 2012-01-12 draft-ietf-alto-reqs-12 Stephen Kent - draft-ietf-dhc-secure-dhcpv6-03-04 Warren Kumari 2012-01-24 draft-ietf-dime-pmip6-lr-06 Barry Leiba 2012-01-13 draft-ietf-pcn-signaling-requirements-07 Matt Lepinski 2012-01-26 draft-ietf-radext-radsec-10 Catherine Meadows 2012-02-03 draft-kucherawy-authres-spf-erratum-01 Tina TSOU 2011-04-23 draft-shin-augmented-pake-10 From meadows@itd.nrl.navy.mil Thu Jan 12 09:14:36 2012 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 41DDC21F84D8; Thu, 12 Jan 2012 09:14:36 -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 yLgt-JJG7TPc; Thu, 12 Jan 2012 09:14:35 -0800 (PST) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6D13C21F846A; Thu, 12 Jan 2012 09:14:34 -0800 (PST) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q0CHEWCG008200; Thu, 12 Jan 2012 12:14:32 -0500 (EST) 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 q0CHEVod021227; Thu, 12 Jan 2012 12:14:31 -0500 (EST) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2012011212143129193 ; Thu, 12 Jan 2012 12:14:31 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary=Apple-Mail-9-189556564 Date: Thu, 12 Jan 2012 12:25:07 -0500 Message-Id: <8991BA91-8252-4DCF-8FCA-DEF5C04632D6@itd.nrl.navy.mil> To: iesg@ietf.org, secdir@ietf.org, draft-kucherawy-authres-spf-erratum.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Catherine Meadows Subject: [secdir] Secdir review of draft-kucherawy-authres-spf-erratum-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: Thu, 12 Jan 2012 17:14:36 -0000 --Apple-Mail-9-189556564 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. The purpose of this ID is summed up in the introduction as follows: [RFC 5451] defined a new header field for electronic mail messages that presents the results of a message authentication effort in a machine-readable format. That Request For Comments created a registry of results for a few message authentication mechanisms, one of which was the Sender Policy Framework [SPF]. The registry contains one entry that is inconsistent with the latter specification, which was noted in an erratum filed with the RFC Editor. This memo updates the IANA registries accordingly. The inconsistent header entry identifies the case in which an evaluation according to RFC 4408 fails. The result of failing such an evaluation = is that the client is explicitly not authorized to inject or relay mail using = the sender's DNS domain. RFC 5451 gave "hardfail" as the result to be listed here, while = RFC 4408 used "fail" to mean the same thing. The purpose of this ID is to recommend that = IANA mark "hardfail" as deprecated and amend the "fail" entry appropriately. This ID is definitely security relevant, as use of the wrong header = could cause a failure to recognize a failed authorization. Thus in the = Security Considerations section the authors say that "cautious implementers may wish to support = both result strings for some period of time." One quibble: I believe that the above is good advice, but it seems a = little hesitant. Why the use of the words "cautious" and "may"? Why not say that "we recommend = that"? Even if failure to recognize a failed authorization doesn't lead to any immediate = security problem, it could prevent recognition of a potential attack, or more benignly, of = a possible misconfiguration. =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-9-189556564 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
to mean the same thing.  The purpose of this ID is = to recommend that IANA mark
"hardfail" as deprecated and amend = the "fail" entry appropriately.

This ID is = definitely security relevant, as use of the wrong header = could
cause a failure to recognize a failed authorization. =  Thus in the Security Considerations
section the authors = say that "cautious implementers may wish to support = both
result strings for some period of = time."

One quibble: I believe that the above is = good advice, but it seems a little hesitant.  Why the = use
of the words "cautious" and "may"?  Why not say that = "we recommend that"?  Even if failure
to recognize a = failed authorization doesn't lead to any immediate security = problem,
it could prevent recognition of a potential attack, = or more benignly, of a possible
misconfiguration. =  


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-9-189556564-- From meadows@itd.nrl.navy.mil Thu Jan 12 09:36:00 2012 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 F027221F85B6; Thu, 12 Jan 2012 09:36:00 -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 rj4ivSmx6tTh; Thu, 12 Jan 2012 09:36:00 -0800 (PST) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfa.amsl.com (Postfix) with ESMTP id 32A8021F859B; Thu, 12 Jan 2012 09:35:59 -0800 (PST) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id q0CHZwmW010515; Thu, 12 Jan 2012 12:35:58 -0500 (EST) 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 q0CHZwgW022675; Thu, 12 Jan 2012 12:35:58 -0500 (EST) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2012011212355729234 ; Thu, 12 Jan 2012 12:35:57 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-10-190842733 From: Catherine Meadows In-Reply-To: Date: Thu, 12 Jan 2012 12:46:33 -0500 Message-Id: References: <8991BA91-8252-4DCF-8FCA-DEF5C04632D6@itd.nrl.navy.mil> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1084) Cc: "draft-kucherawy-authres-spf-erratum.all@tools.ietf.org" , "secdir@ietf.org" , Catherine Meadows , "iesg@ietf.org" Subject: Re: [secdir] Secdir review of draft-kucherawy-authres-spf-erratum-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: Thu, 12 Jan 2012 17:36:01 -0000 --Apple-Mail-10-190842733 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 OK, sounds good! Cathy Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil On Jan 12, 2012, at 12:24 PM, Murray S. Kucherawy wrote: > --> > Hi Catherine, thanks for your comments. >=20 > =20 >=20 > The language chosen is basically acknowledgement that few if any = implementations ever actually used =93hardfail=94. The error was = pointed out not long after RFC5451 was published and all of the = implementations I know of did it properly from the beginning. So the = posture is really one of =93In case anyone ever did do it the wrong way, = =85.=94 >=20 > =20 >=20 > Also, the word =93recommended=94 has specific meaning under RFC2119 = and it=92s my understanding that use of such normative language in = Security Considerations ought to be avoided. >=20 > =20 >=20 > Given all that, I=92d be fine with saying =93implementers are advised=94= versus =93cautious implementers may wish=94. I=92ll add that to the = -02 version. >=20 > =20 >=20 > -MSK >=20 > =20 >=20 > From: Catherine Meadows [mailto:meadows@itd.nrl.navy.mil]=20 > Sent: Thursday, January 12, 2012 9:25 AM > To: iesg@ietf.org; secdir@ietf.org; = draft-kucherawy-authres-spf-erratum.all@tools.ietf.org > Cc: Catherine Meadows > Subject: Secdir review of draft-kucherawy-authres-spf-erratum-01 >=20 > =20 >=20 > This ID is definitely security relevant, as use of the wrong header = could >=20 > cause a failure to recognize a failed authorization. Thus in the = Security Considerations >=20 > section the authors say that "cautious implementers may wish to = support both >=20 > result strings for some period of time." >=20 > =20 >=20 > One quibble: I believe that the above is good advice, but it seems a = little hesitant. Why the use >=20 > of the words "cautious" and "may"? Why not say that "we recommend = that"? Even if failure >=20 > to recognize a failed authorization doesn't lead to any immediate = security problem, >=20 > it could prevent recognition of a potential attack, or more benignly, = of a possible >=20 > misconfiguration. =20 >=20 > =20 >=20 > =20 >=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 >=20 > =20 >=20 --Apple-Mail-10-190842733 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 OK, = sounds good!

Cathy


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

On Jan 12, 2012, at 12:24 PM, Murray S. Kucherawy = wrote:

-->

Hi Catherine, thanks for your = comments.

 

The language chosen is basically = acknowledgement that few if any implementations ever actually used = =93hardfail=94.  The error was pointed out not long after RFC5451 = was published and all of the implementations I know of did it properly = from the beginning.  So the posture is really one of =93In case = anyone ever did do it the wrong way, =85.=94

 

Also, the word =93recommended=94 has = specific meaning under RFC2119 and it=92s my understanding that use of = such normative language in Security Considerations ought to be = avoided.

 

Given all that, I=92d be fine with saying = =93implementers are advised=94 versus =93cautious implementers may = wish=94.  I=92ll add that to the -02 = version.

 

-MSK

 

From: Catherine Meadows [mailto:meadows@itd.nrl.navy.mil] =
Sent: Thursday, January 12, 2012 9:25 AM
To: iesg@ietf.org; secdir@ietf.org; dra= ft-kucherawy-authres-spf-erratum.all@tools.ietf.org
Cc: = Catherine Meadows
Subject: Secdir review of = draft-kucherawy-authres-spf-erratum-01

 

This= ID is definitely security relevant, as use of the wrong header = could

cause a failure to = recognize a failed authorization.  Thus in the Security = Considerations

section = the authors say that "cautious implementers may wish to support = both

result strings for = some period of time."

 

One quibble: I believe that the above is good = advice, but it seems a little hesitant.  Why the = use

of the words = "cautious" and "may"?  Why not say that "we recommend that"? =  Even if failure

to = recognize a failed authorization doesn't lead to any immediate security = problem,

it could = prevent recognition of a potential attack, or more benignly, of a = possible

misconfiguration.=  

 

 

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-10-190842733-- From msk@cloudmark.com Thu Jan 12 09:24:55 2012 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 B59E921F85BE; Thu, 12 Jan 2012 09:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HTML_MESSAGE=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 gd3Miz3S1a3Z; Thu, 12 Jan 2012 09:24:54 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD7521F859A; Thu, 12 Jan 2012 09:24:54 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 12 Jan 2012 09:24:46 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 12 Jan 2012 09:24:53 -0800 From: "Murray S. Kucherawy" To: Catherine Meadows , "iesg@ietf.org" , "secdir@ietf.org" , "draft-kucherawy-authres-spf-erratum.all@tools.ietf.org" Date: Thu, 12 Jan 2012 09:24:53 -0800 Thread-Topic: Secdir review of draft-kucherawy-authres-spf-erratum-01 Thread-Index: AczRTbJverHZqFKRSHS5fILx6J8F7AAADXvg Message-ID: References: <8991BA91-8252-4DCF-8FCA-DEF5C04632D6@itd.nrl.navy.mil> In-Reply-To: <8991BA91-8252-4DCF-8FCA-DEF5C04632D6@itd.nrl.navy.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C15848EXCHC2corpclo_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 12 Jan 2012 10:19:55 -0800 Subject: Re: [secdir] Secdir review of draft-kucherawy-authres-spf-erratum-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: Thu, 12 Jan 2012 17:24:55 -0000 --_000_F5833273385BB34F99288B3648C4F06F19C6C15848EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Catherine, thanks for your comments. The language chosen is basically acknowledgement that few if any implementa= tions ever actually used "hardfail". The error was pointed out not long af= ter RFC5451 was published and all of the implementations I know of did it p= roperly from the beginning. So the posture is really one of "In case anyon= e ever did do it the wrong way, ...." Also, the word "recommended" has specific meaning under RFC2119 and it's my= understanding that use of such normative language in Security Consideratio= ns ought to be avoided. Given all that, I'd be fine with saying "implementers are advised" versus "= cautious implementers may wish". I'll add that to the -02 version. -MSK From: Catherine Meadows [mailto:meadows@itd.nrl.navy.mil] Sent: Thursday, January 12, 2012 9:25 AM To: iesg@ietf.org; secdir@ietf.org; draft-kucherawy-authres-spf-erratum.all= @tools.ietf.org Cc: Catherine Meadows Subject: Secdir review of draft-kucherawy-authres-spf-erratum-01 This ID is definitely security relevant, as use of the wrong header could cause a failure to recognize a failed authorization. Thus in the Security = Considerations section the authors say that "cautious implementers may wish to support bot= h result strings for some period of time." One quibble: I believe that the above is good advice, but it seems a little= hesitant. Why the use of the words "cautious" and "may"? Why not say that "we recommend that"? = Even if failure to recognize a failed authorization doesn't lead to any immediate security = problem, it could prevent recognition of a potential attack, or more benignly, of a = possible misconfiguration. 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 --_000_F5833273385BB34F99288B3648C4F06F19C6C15848EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Cather= ine, thanks for your comments.

 

The language c= hosen is basically acknowledgement that few if any implementations ever act= ually used “hardfail”.  The error was pointed out not long= after RFC5451 was published and all of the implementations I know of did i= t properly from the beginning.  So the posture is really one of “= ;In case anyone ever did do it the wrong way, ….”

 

Also, the word “recommended” has specific mean= ing under RFC2119 and it’s my understanding that use of such normativ= e language in Security Considerations ought to be avoided.

 

Given all that, I’d be fine with saying “implemen= ters are advised” versus “cautious implementers may wish”= .  I’ll add that to the -02 version.

 

-MSK

 <= /span>

From: Catherine Meadows = [mailto:meadows@itd.nrl.navy.mil]
Sent: Thursday, January 12, 20= 12 9:25 AM
To: iesg@ietf.org; secdir@ietf.org; draft-kucherawy-au= thres-spf-erratum.all@tools.ietf.org
Cc: Catherine Meadows
= Subject: Secdir review of draft-kucherawy-authres-spf-erratum-01

 

<= p class=3DMsoNormal>This ID is definitely security relevant, as use of the = wrong header could

cause a fa= ilure to recognize a failed authorization.  Thus in the Security Consi= derations

section the authors= say that "cautious implementers may wish to support both

result strings for some period of time.&q= uot;

 

One quibble: I believe that the above is good = advice, but it seems a little hesitant.  Why the use

of the words "cautious" and "ma= y"?  Why not say that "we recommend that"?  Even i= f failure

to recognize a fail= ed authorization doesn't lead to any immediate security problem,=

it could prevent recognition of a poten= tial attack, or more benignly, of a possible

misconfiguration.  

 

&nbs= p;

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

 

= --_000_F5833273385BB34F99288B3648C4F06F19C6C15848EXCHC2corpclo_-- From kivinen@iki.fi Fri Jan 13 05:25:02 2012 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 CDC9121F8433; Fri, 13 Jan 2012 05:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 7wk8QtFx1ez5; Fri, 13 Jan 2012 05:25:02 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22CA21F844C; Fri, 13 Jan 2012 05:25:01 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q0DDOspb005379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jan 2012 15:24:54 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q0DDOoCS028575; Fri, 13 Jan 2012 15:24:50 +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: <20240.12450.545737.582209@fireball.kivinen.iki.fi> Date: Fri, 13 Jan 2012 15:24:50 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: draft-ietf-6man-3627-historic.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-6man-3627-historic-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: Fri, 13 Jan 2012 13:25:02 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document moves RFC3627 (Use of /127 Prefix Length Between Routers Considered Harmful) to historic as it has already been superseded by standard track document RFC6164 (Using 127-Bit IPv6 Prefixes on Inter-Router Links). The security considerations section says there are no new security considerations, and I think thisi is accurate. I have no comments for this document. -- kivinen@iki.fi From shanna@juniper.net Fri Jan 13 12:01:14 2012 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 12B3221F8448; Fri, 13 Jan 2012 12:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 H8DSbSPTIox0; Fri, 13 Jan 2012 12:01:13 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id AD57711E80AD; Fri, 13 Jan 2012 12:00:52 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTxCNdI2mv9psM928MBHXSxY+WsabjS/h@postini.com; Fri, 13 Jan 2012 12:00:59 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 13 Jan 2012 11:59:55 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 13 Jan 2012 14:59:54 -0500 From: Stephen Hanna To: "draft-nottingham-http-new-status@tools.ietf.org" , "secdir@ietf.org" , "ietf@ietf.org" Date: Fri, 13 Jan 2012 14:59:53 -0500 Thread-Topic: secdir review of draft-nottingham-http-new-status-03 Thread-Index: AczSLeo7PTPAq42hRwirXy24basViA== Message-ID: 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 Subject: [secdir] secdir review of draft-nottingham-http-new-status-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: Fri, 13 Jan 2012 20:01:14 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document specifies new HTTP status codes for a variety of common situations. Although I am not an HTTP expert, it seems to me that this document is clear, well-written, and reasonable. >From a security perspective, this document seems to have little impact either positive or negative. However, the Security Considerations section does not meet our usual standards. While the authors include a subsection on each new status code, they do not explain clearly what the security implications are for each status code and how any possible negative impacts could be reduced. Riccardo Bernardini already commented on this issue during IETF LC. However, I do not agree with Mr. Bernardini that sections 7.1 and 7.2 are not security related. Rather, the security implications are just not clearly stated. For example, section 7.2 points out that servers may not want to always use the 429 status code when receiving too many requests from one client. This has security implications in that a server under attack with excessive requests from one client may compound the problem by queuing 429 status codes for every request from that client. However, this is not stated explicitly in section 7.2. Fleshing out the subsections of section 7 (Security Considerations) should help solve the problem by providing a clear description of security problems related to these result codes and recommended mitigations. Section 7.4 does a decent job of describing the problems but fails to describe mitigations. I think that having the client use HTTPS instead of HTTP for important requests and limiting the effects of HTTP (not HTTPS) responses is an obvious mitigation. I do have a question about the issues raised in Appendix B. These are all legitimate issues. However, it seems to me that having status code 511 should help with these. A browser or non-browser application could recognize status code 511 as an indication that a captive portal is in use and avoid capturing favicons, looking for P3P files, and doing other things that should wait until after the captive portal is blocking access. When the original website stops returning 511, such activities could resume. I may be wrong in suggesting these ideas but if not it would be good to note them here. From shanna@juniper.net Fri Jan 13 13:38:01 2012 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 3FE2711E8072; Fri, 13 Jan 2012 13:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 jmLJwx5rmiPG; Fri, 13 Jan 2012 13:38:00 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id E33431F0C38; Fri, 13 Jan 2012 13:37:45 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTxCkKbHP00G72Ri3Abpj4eTMkCEanwp7@postini.com; Fri, 13 Jan 2012 13:37:51 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 13 Jan 2012 13:26:30 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 13 Jan 2012 16:26:29 -0500 From: Stephen Hanna To: Julian Reschke Date: Fri, 13 Jan 2012 16:26:28 -0500 Thread-Topic: secdir review of draft-nottingham-http-new-status-03 Thread-Index: AczSMbESPXFYh7cpTSiWb/c10V+TNAABO4tQ Message-ID: References: <4F109383.1090505@gmx.de> In-Reply-To: <4F109383.1090505@gmx.de> 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 Cc: "draft-nottingham-http-new-status@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-nottingham-http-new-status-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: Fri, 13 Jan 2012 21:38:01 -0000 Julian, I'm sure that in your view one sentence is adequate to explain all the security implications of each status code. However, you may want to consider that some readers may not have quite the same deep grasp of the matter that you do. Therefore, I think it would be wise to provide more explanation. Here's an example for section 7.2 on status code 429 (Too Many Requests): Section 7.2 429 Too Many Requests While status code 429 can be helpful in figuring out why a server is not responding to requests, it can also be harmful. When a server is under attack or simply receiving a very large number of requests from a single party, responding to each of these requests with a 429 status code will consume resources that could be better used in other ways. Therefore, a server in such circumstances may choose to send a 429 status code only the first time a client exceeds its limit and ignore subsequent requests from this client until its limit is no longer exceeded. Other approaches may also be employed. As you can see, I described security problems that could occur with this status code and explained how those problems can be avoided or mitigated. While it's true that these problems could occur when a more generic status code is used to handle the case of "too many requests", that does not mean that they are not relevant to this document. On the contrary, the fact that this document is providing more detailed status codes gives us the opportunity and one can argue the obligation to provide more detailed security analysis relevant to these more detailed status codes. And I'm glad that you saw the value in my comment about Appendix B! Thanks, Steve > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, January 13, 2012 3:27 PM > To: Stephen Hanna > Cc: draft-nottingham-http-new-status@tools.ietf.org; secdir@ietf.org; > ietf@ietf.org > Subject: Re: secdir review of draft-nottingham-http-new-status-03 >=20 > On 2012-01-13 20:59, Stephen Hanna wrote: > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > This document specifies new HTTP status codes for a variety of > > common situations. Although I am not an HTTP expert, it seems > > to me that this document is clear, well-written, and reasonable. >=20 > +1 >=20 > >> From a security perspective, this document seems to have little > > impact either positive or negative. However, the Security > > Considerations section does not meet our usual standards. > > While the authors include a subsection on each new status code, > > they do not explain clearly what the security implications are > > for each status code and how any possible negative impacts > > could be reduced. >=20 > In general, the proposed new codes just allow to describe a problem > more > clearly; previously, a more generic status code would have to be used. >=20 > As such, they do not change security at all. >=20 > > Riccardo Bernardini already commented on this issue during > > IETF LC. However, I do not agree with Mr. Bernardini that > > sections 7.1 and 7.2 are not security related. Rather, the > > security implications are just not clearly stated. For example, > > section 7.2 points out that servers may not want to always > > use the 429 status code when receiving too many requests > > from one client. This has security implications in that > > a server under attack with excessive requests from one > > client may compound the problem by queuing 429 status codes > > for every request from that client. However, this is not > > stated explicitly in section 7.2. Fleshing out the subsections >=20 > "Servers are not required to use the 429 status code; when limiting > resource usage, it may be more appropriate to just drop connections, or > take other steps." >=20 > > of section 7 (Security Considerations) should help solve the > > problem by providing a clear description of security problems > > related to these result codes and recommended mitigations. > > Section 7.4 does a decent job of describing the problems > > but fails to describe mitigations. I think that having the > > client use HTTPS instead of HTTP for important requests > > and limiting the effects of HTTP (not HTTPS) responses > > is an obvious mitigation. >=20 > It's not the job of this spec to completely describe security > considerations with respect to captive portals. >=20 > All the spec does is defining a new status code that, when used, makes > captive portals a bit better to work with. >=20 > > I do have a question about the issues raised in Appendix B. > > These are all legitimate issues. However, it seems to me > > that having status code 511 should help with these. A >=20 > Indeed; that's why 511 is there in the first place. The introduction to > Appendix B should state that. >=20 > > ... >=20 > Best regards, Julian From paul.hoffman@vpnc.org Sat Jan 14 15:46:28 2012 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 4751B21F84CE for ; Sat, 14 Jan 2012 15:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 o3OI5nLOvuJu for ; Sat, 14 Jan 2012 15:46:28 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D8FB321F84C4 for ; Sat, 14 Jan 2012 15:46:27 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0ENkNMF094256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 14 Jan 2012 16:46:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Jan 2012 15:46:23 -0800 Message-Id: To: secdir Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Cc: draft-ietf-alto-reqs-all@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-alto-reqs 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, 14 Jan 2012 23:46:28 -0000 Greetings again. This is a security review of draft-ietf-alto-reqs, = "Application-Layer Traffic Optimization (ALTO) Requirements". An ALTO = protocol would allow optimization of network resources when information = is in multiple places; a client can ask a server where to get the = information, and the server can give hopefully-intelligent answers based = on what the server knows of the network load, server load, network = topology, and so on. This document does quite a good job of covering the many security issues = with such a protocol. It lays out many of the competing security = considerations, particularly the privacy of each party and, being a = requirements document, doesn't answer any of the hard questions that = will need to come in the upcoming protocol document. --Paul Hoffman From brian.e.carpenter@gmail.com Sat Jan 14 18:52:09 2012 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 866F021F84AF; Sat, 14 Jan 2012 18:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.568 X-Spam-Level: X-Spam-Status: No, score=-103.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, 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 SXWxvtVuAxo6; Sat, 14 Jan 2012 18:52:09 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 956BB21F84AA; Sat, 14 Jan 2012 18:52:08 -0800 (PST) Received: by eaad11 with SMTP id d11so614716eaa.31 for ; Sat, 14 Jan 2012 18:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7pa9oy1GahKFJlFML1oAjbVF85gxb8d6jpb7CUlNAYo=; b=wlc+imrm5yRsCe8qWJAOBXgaOmtRkWExZah8SchnVL3X+wqNWi2d1HDZY7FD9ggH5B 3JWJdtZ+PF9m0HkpiPvWgZPiXPhytvkWyDgjI+WoI1mAR0OB5yCJjCHBgaz0S+utkTZK f5mdbvI5cKtMTcQG+cc2wdlpgR3dU9eJ0D1fo= Received: by 10.213.19.139 with SMTP id a11mr2057071ebb.87.1326595926472; Sat, 14 Jan 2012 18:52:06 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id t1sm52096113eeb.3.2012.01.14.18.52.02 (version=SSLv3 cipher=OTHER); Sat, 14 Jan 2012 18:52:06 -0800 (PST) Message-ID: <4F123F4B.3000403@gmail.com> Date: Sun, 15 Jan 2012 15:51:55 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: drc@cloudflare.com, jiangsheng@huawei.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review: http://www.ietf.org/id/draft-jiang-a6-to-historic-00.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: Sun, 15 Jan 2012 02:52:09 -0000 PHB, Thanks for the review. See below. On 2012-01-13 02:18, Phillip Hallam-Baker 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. > > Overview > > A6 was a proposed replacement for AAAA records. A6 has not achieved the > anticipated level of support or provided the anticipated benefits in > practice. This draft moves A6 to historic, deprecating use of A6 records. > > > Comments: > > Removing A6 removes a potential source of inconsistency and thus improves > consistency. > > One possible consequence of this particular change is that information that > was previously expressible via the A6 mechanism will no longer be visible. > While this is not necessarily good or bad from a security standpoint it is > an issue that should be mentioned in the Security Considerations. Can do. > > Another possible security impact is that it will not be possible to divide > up administrative duties in the manner originally envisaged in the A6 > proposal. While it is far from clear that this division is useful (or > achievable) it should probably be noted. In particular it will not be > possible to achieve renumbering of whole domains by changing one record. Indeed; that was the hope when A6 was designed, and in fact it's because the 6renum WG is taking a new look at this area that we decided it was time to clear the decks. > > It is quite possible that some domains will continue to employ A6 domains > as an administrative convenience, generating the corresponding AAAA records > as required. This case needs more consideration from a security point of > view. It would be useful to require that such records be ignored by > applications and preferably be blocked from external view. We already recommend "Removing A6 handling from all new or updated host stacks" and we could add a recommendation for apps to ignore them. Blocking visibility of RRs is generally not something the DNS community likes, though. Brian From leifj@sunet.se Mon Jan 16 02:02:31 2012 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 F3A1821F8584; Mon, 16 Jan 2012 02:02:30 -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 t3TSnMptXaem; Mon, 16 Jan 2012 02:02:30 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0DD21F853C; Mon, 16 Jan 2012 02:02:29 -0800 (PST) Received: from [109.105.104.164] (dhcp30.se-tug.nordu.net [109.105.104.164] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q0GA2NYP017760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jan 2012 11:02:26 +0100 (CET) Message-ID: <4F13F5AE.9060205@sunet.se> Date: Mon, 16 Jan 2012 11:02:22 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: secdir@ietf.org, draft-ietf-mile-rfc6045-bis.all@tools.ietf.org, iesg@ietf.org X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review: draft-ietf-mile-rfc6045-bis-05 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, 16 Jan 2012 10:02:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. These document updates RFC6045 - Real-time Inter-network Defence (RID) The document defines a way to communicate IODEF objects between Service Providers. In general I find the document well written and I especially like the way the XML schema is described in ASCII graphics. A few comments: - - The term "Network Provider" is still used in parts of the document where it might be better to be consistent with the new term "Service Provider" (the name-change is announced in the introduction). - - The introduction states that the document moves RFC6505 to Historic status and also that it updates RFC6505. This is confusing to me. It seems like this is a simple case of an update that changes the document status (Informational -> Standards Track) and I'm not sure Historic needs to enter into it. - - The discussions on PKI issues and trust is quite good but I would have liked to see an explicit mention of the fact that strong name- key binding is the key to establishing a good trust infrastructure. The use of PKI is strongly encouraged but for smaller consortia it would be entirely feasible to establish the required level of trust by manually sharing keys instead of running a PKI. - - The security considerations section re-iterates a dependency on PKI and PKI federations to fulfill the trust requirements of RID consortia. However it is worth noting that very few examples of the type of PKI federations that RID depend on, exist in the wild. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8T9asACgkQ8Jx8FtbMZndm7ACfaMed3PP8yZcLCOAbvfAk6QsN Lx8An1G/mntbsaGHJp8OQ88tgjawpx6d =qsnU -----END PGP SIGNATURE----- From kathleen.moriarty@emc.com Mon Jan 16 05:55:05 2012 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 56D3021F85DA; Mon, 16 Jan 2012 05:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 ueeZ-GhYH92z; Mon, 16 Jan 2012 05:55:04 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 736CB21F85B8; Mon, 16 Jan 2012 05:55:04 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0GDsq5p029465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jan 2012 08:55:02 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 16 Jan 2012 08:54:47 -0500 Received: from mxhub34.corp.emc.com (mxhub34.corp.emc.com [10.254.93.82]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0GDsk4a019601; Mon, 16 Jan 2012 08:54:46 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub34.corp.emc.com ([::1]) with mapi; Mon, 16 Jan 2012 08:54:46 -0500 From: To: , , , Date: Mon, 16 Jan 2012 08:54:45 -0500 Thread-Topic: Secdir review: draft-ietf-mile-rfc6045-bis-05 Thread-Index: AczUNiTspYAh0W1uQy+8X1SNhyYRqwAH4Qdw Message-ID: References: <4F13F5AE.9060205@sunet.se> In-Reply-To: <4F13F5AE.9060205@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] Secdir review: draft-ietf-mile-rfc6045-bis-05 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, 16 Jan 2012 13:55:05 -0000 Hello Leif, Thank you very much for the security review! I agree with your comments on PKI and will update the draft accordingly. I= agree that keys could be shared directly or that a consortium may be the p= rovider of keys so that there is only one PKI for the entire sharing group = as an alternative to each participant having a PKI (that would be a barrier= to use if it were required). Sean Turner had provided some specific guidance on the updates RFC6045 that= I have ready to go in the next revision. This included some comments from= David Harrington where they assisted with recommended text on how this sho= uld be handled. I will clean up the use of NP/Network Provider as well. Thank you, Kathleen -----Original Message----- From: Leif Johansson [mailto:leifj@sunet.se]=20 Sent: Monday, January 16, 2012 5:02 AM To: secdir@ietf.org; draft-ietf-mile-rfc6045-bis.all@tools.ietf.org; iesg@i= etf.org Subject: Secdir review: draft-ietf-mile-rfc6045-bis-05 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. These document updates RFC6045 - Real-time Inter-network Defence (RID) The document defines a way to communicate IODEF objects between Service Providers. In general I find the document well written and I especially like the way the XML schema is described in ASCII graphics. A few comments: - - The term "Network Provider" is still used in parts of the document where it might be better to be consistent with the new term "Service Provider" (the name-change is announced in the introduction). - - The introduction states that the document moves RFC6505 to Historic status and also that it updates RFC6505. This is confusing to me. It seems like this is a simple case of an update that changes the document status (Informational -> Standards Track) and I'm not sure Historic needs to enter into it. - - The discussions on PKI issues and trust is quite good but I would have liked to see an explicit mention of the fact that strong name- key binding is the key to establishing a good trust infrastructure. The use of PKI is strongly encouraged but for smaller consortia it would be entirely feasible to establish the required level of trust by manually sharing keys instead of running a PKI. - - The security considerations section re-iterates a dependency on PKI and PKI federations to fulfill the trust requirements of RID consortia. However it is worth noting that very few examples of the type of PKI federations that RID depend on, exist in the wild. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8T9asACgkQ8Jx8FtbMZndm7ACfaMed3PP8yZcLCOAbvfAk6QsN Lx8An1G/mntbsaGHJp8OQ88tgjawpx6d =3DqsnU -----END PGP SIGNATURE----- From leifj@sunet.se Tue Jan 17 04:39:43 2012 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 60F1721F85E4; Tue, 17 Jan 2012 04:39:43 -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 g7M0JBkdjrSd; Tue, 17 Jan 2012 04:39:42 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 4881421F85DF; Tue, 17 Jan 2012 04:39:42 -0800 (PST) Received: from [192.36.125.231] (dhcp.pilsnet.sunet.se [192.36.125.231] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q0HCdZm8012011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jan 2012 13:39:39 +0100 (CET) Message-ID: <4F156C07.5000200@sunet.se> Date: Tue, 17 Jan 2012 13:39:35 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: secdir@ietf.org, draft-ietf-mile-rfc6046-bis.all@tools.ietf.org, iesg@ietf.org X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review of draft-ietf-mile-rfc6046-bis-05 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, 17 Jan 2012 12:39:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. These document updates RFC6046 - Transport of Real-time Internetwork Defense (RID) Messages over HTTP/TLS This document defines HTTP/TLS as a transport for RID/IODEF messages and is part of a joint update of RFC6046 and RFC6045. In general I find the document clearly written. I have only a few comments - - The text on PKI requirements from RFC6045bis should be more clearly and consistently referenced in RFC6046bis. In particular I found the following somewhat confusing: "At minimum, each RID system MUST trust a set of X.509 Issuer identities ("Certificate Authorities") [RFC5280] to directly authenticate RID system peers with which it is willing to exchange information, and/or a specific white list of X.509 Subject identities of RID system peers." Does the "directly" mean that there should be no intermediary CAs? I would move any discussion on the nature of the PKI beast to RFC6045bis and reference it from here. - - The RID-Callback-Token is underspecified, or I'm missing a reference to where its defined. I would have liked to see ABNF (yes I know its very simple), the semantics for how the peer should act when receiving a callback token (which may have expired, not point to anything useful, etc etc) some advice on how to generate the tokens and a discussion (in the security considerations!) on what can happen if you screw up and introduce collisions. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8VbAcACgkQ8Jx8FtbMZncXtQCdH6EXyJxECGipAYbiSQvXSj8L KxcAoKMQWwNgCubVfHR98jbhzOJPYrgQ =KK6r -----END PGP SIGNATURE----- From julian.reschke@gmx.de Fri Jan 13 12:26:53 2012 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 CDD2721F8498 for ; Fri, 13 Jan 2012 12:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.604 X-Spam-Level: X-Spam-Status: No, score=-103.604 tagged_above=-999 required=5 tests=[AWL=-1.005, 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 VGe2x8lyJqVk for ; Fri, 13 Jan 2012 12:26:52 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 7CF1021F848C for ; Fri, 13 Jan 2012 12:26:52 -0800 (PST) Received: (qmail invoked by alias); 13 Jan 2012 20:26:51 -0000 Received: from p5DCC28C9.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.40.201] by mail.gmx.net (mp069) with SMTP; 13 Jan 2012 21:26:51 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/1gFl4Jo31RC5WyQUqS1V15w7h84H03l+atE5rFN Ih+kw4M/O5gn69 Message-ID: <4F109383.1090505@gmx.de> Date: Fri, 13 Jan 2012 21:26:43 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Stephen Hanna References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Wed, 18 Jan 2012 08:22:31 -0800 Cc: "draft-nottingham-http-new-status@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-nottingham-http-new-status-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: Fri, 13 Jan 2012 20:26:53 -0000 On 2012-01-13 20:59, Stephen Hanna wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document specifies new HTTP status codes for a variety of > common situations. Although I am not an HTTP expert, it seems > to me that this document is clear, well-written, and reasonable. +1 >> From a security perspective, this document seems to have little > impact either positive or negative. However, the Security > Considerations section does not meet our usual standards. > While the authors include a subsection on each new status code, > they do not explain clearly what the security implications are > for each status code and how any possible negative impacts > could be reduced. In general, the proposed new codes just allow to describe a problem more clearly; previously, a more generic status code would have to be used. As such, they do not change security at all. > Riccardo Bernardini already commented on this issue during > IETF LC. However, I do not agree with Mr. Bernardini that > sections 7.1 and 7.2 are not security related. Rather, the > security implications are just not clearly stated. For example, > section 7.2 points out that servers may not want to always > use the 429 status code when receiving too many requests > from one client. This has security implications in that > a server under attack with excessive requests from one > client may compound the problem by queuing 429 status codes > for every request from that client. However, this is not > stated explicitly in section 7.2. Fleshing out the subsections "Servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps." > of section 7 (Security Considerations) should help solve the > problem by providing a clear description of security problems > related to these result codes and recommended mitigations. > Section 7.4 does a decent job of describing the problems > but fails to describe mitigations. I think that having the > client use HTTPS instead of HTTP for important requests > and limiting the effects of HTTP (not HTTPS) responses > is an obvious mitigation. It's not the job of this spec to completely describe security considerations with respect to captive portals. All the spec does is defining a new status code that, when used, makes captive portals a bit better to work with. > I do have a question about the issues raised in Appendix B. > These are all legitimate issues. However, it seems to me > that having status code 511 should help with these. A Indeed; that's why 511 is there in the first place. The introduction to Appendix B should state that. > ... Best regards, Julian From sra@hactrn.net Wed Jan 18 10:27:29 2012 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 5B84221F870A; Wed, 18 Jan 2012 10:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 yjT-ofe95sFF; Wed, 18 Jan 2012 10:27:28 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0B921F8714; Wed, 18 Jan 2012 10:27:28 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 2A82E2845C; Wed, 18 Jan 2012 18:27:26 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id F280817C86; Wed, 18 Jan 2012 13:27:25 -0500 (EST) Date: Wed, 18 Jan 2012 13:27:25 -0500 From: Rob Austein To: iesg@ietf.org, secdir@ietf.org, draft-ash-gcac-algorithm-spec.all@tools.ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20120118182725.F280817C86@thrintun.hactrn.net> Subject: [secdir] draft-ash-gcac-algorithm-spec-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, 18 Jan 2012 18:27:29 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes an experimental "connection admission control" algorithm, that is, an algorithm by which an IP/MPLS service provider's equipment might decide whether or not to allow a new connection such as a new VoIP call, given various constraints such as quality of service issues. The draft is slated for experimental status and cautions against indiscriminate deployment on operational networks. I am sorry to have to say at this late date that I found the Security Considerations of this draft woefully inadequate. The IESG will have to decide to what extent (if any) this matters for document on the experimental track. The algorithm is not a protocol, rather it is layered on top of a barrel full of existing protocols, and appears to be an attempt to provide a uniform and generic decision layer on top of all that. As such, it depends on various parameters carried by the underlying protocols. Nowhere do I see any discussion of the extent to which this makes the algorithm's decisions vulnerable to attacks on any of the underlying protocols (or, more likely, to attacks on whichever happens to be the weakest of the underlying protocols this week). To reader who is not an MPLS expert, it's unclear where one would even begin such an analysis, which is one of the reasons why such things are supposed to be discussed in the Security Considerations. Furthermore, there is very little discussion of threats that might derive from gaming the algorithm itself. The entirety of the Security Considerations section consists of a brief discussion of one threat ("theft-of-service attacks" due to users claiming emergency priority for their flows) with a somewhat opaque claim that RSVP-TE signalling policy can be used to defeat the attack. I see no discussion of other results of gaming the algorithm, such as DoS attacks by allowing new flows when the algorithm should have prevented them, denying resources to legitimate flows by rejecting new flows when the algorithm should have allowed them, tinkering with the bandwidth parameters, etc. In view of the lateness of this review and the experimental status requested, I will understand if the IESG passes this document in spite of these issues. Caveat: As may be obvious from the above, I am not an MPLS expert. From kent@bbn.com Thu Jan 19 15:51:21 2012 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 CD54621F8471 for ; Thu, 19 Jan 2012 15:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.84 X-Spam-Level: X-Spam-Status: No, score=-105.84 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 JvftrPlv-3YR for ; Thu, 19 Jan 2012 15:51:19 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B866921F86F1 for ; Thu, 19 Jan 2012 15:51:18 -0800 (PST) Received: from dhcp89-089-066.bbn.com ([128.89.89.66]:49338) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Ro1lA-0008yr-0l; Thu, 19 Jan 2012 18:51:12 -0500 Mime-Version: 1.0 Message-Id: Date: Thu, 19 Jan 2012 18:51:09 -0500 To: secdir@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-885105424==_ma============" Cc: rdroms.ietf@gmail.com, john_brzozowski@cable.comcast.com, ted.lemon@nominum.com, shenshuo@cnnic.cn, jiangsheng@huawei.com Subject: [secdir] review of draft-ietf-dhc-secure-dhcpv6-04.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: Thu, 19 Jan 2012 23:51:21 -0000 --============_-885105424==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable I reviewed this document=20 (draft-ietf-dhc-secure-dhcpv6-04.txt) as part of=20 the security directorate's ongoing effort to=20 review all IETF documents being processed by the=20 IESG. These comments were written primarily for=20 the benefit of the security area directors.=20 Document editors and WG chairs should treat these=20 comments just like any other last call comments. This document needs significant work because: - numerous English language errors that make it hard to read - inconsistencies between different sections of the document are present - the incomplete description of sender and receiver processing - it contains a questionable technical proposal for flexibility re placement of the new sig option - alg agility is not correctly described for the sig option, and examples are alg specific - some examples are erroneous The comments provided below are keyed to the sections of the document. Abstract "If not secured, DHCPv6 is vulnerable to various=20 attacks, particularly fake attack." Presumably=20 the authors are referring to "spoofing" attacks.=20 The commonly employed terminology should be used=20 here. 1. Introduction Same comment for 1st paragraph here. The 2nd paragraph cites=20 draft-ietf-csi-dhcpv6-cga-ps and says that it=20 introduced "requirements of using CGA to secure=20 DHCPv6." The cited document does not define=20 requirements for using use CGAs to secure DHCP,=20 contrary to what is stated here. The cited=20 document analyzes how one might use DHCPv6 to=20 configure CGA parameters in host clients, and how=20 one might use CGAs to counter spoofing attacks=20 against DHCPv6 servers. At the time this SECDIR=20 review is being written, the cited document has=20 6 DISCUSS votes, suggesting that it requires=20 significant revision, and making it a=20 questionable basis for establishing=20 "requirements" for CGA use in the DHCHv6 context. The following statement "=8Aor where available=20 security mechanisms are not sufficient, =8A" is too=20 vague, e.g., it fails to say what/why available=20 security mechanisms do no suffice. 2. Security Overview It appears that this section is intended to=20 describe the need for security mechanisms that=20 counter DHCPv6 server spoofing attacks. It does=20 so very poorly. It is haphazard and redundant in=20 its organization, and some of the text is=20 confusing, at best. This section begins by stating "DHCPv6 is a=20 client/server protocol that provides managed and=20 stateful configuration of devices." I question=20 the "stateful" part of this assertion. DHCP is=20 designed to avoid the need for hosts to manually=20 configured, which is very "stateful." Since a=20 DHCP server typically assigns an address to a=20 host from a pool, and only for the duration of a=20 "lease" this behavior is not a great example of=20 statefullness. SO, it is not clear what aspects=20 of "state" the authors have in mind here. The text says "In the basic DHCPv6=20 specifications, regular IPv6 addresses are used."=20 I presume the authors mean that the DHCP server=20 uses a "regular" IPv6 address for itself, but=20 since DHCPv6 servers provide IPv6 addresses to=20 their clients, this statement is ambiguous. The last paragraph on page 3 begins with double=20 quotes, but this appears to be a typo. This=20 paragraph provides two examples of possible=20 motivations for attacker that spoofs DHCP=20 responses. Do the authors assert that these the=20 most important motivations, the only ones, or=20 what? The document quotes from RFC 3315. It isn't clear=20 if this is intended to extend the description of=20 adverse outcomes from spoofing a DHCPv6 server,=20 or if it is merely a restatement of the generic=20 concern cited in the prior paragraphs. The next paragraph uses many words to describe a=20 MITM attack, which the document already noted at=20 the bottom of page 3. The paragraph then goes on=20 to say "This becomes important to detect and=20 prevent when encrypted traffic is allowed to pass=20 through firewalls." This is a confusing statement=20 at best. If the traffic is encrypted, a MITM=20 attack does not provide an adversary with a lot=20 of interesting info to collect via a MITM attack.=20 It isn't clear what the authors were trying to=20 communicate here. The document states "Once servers start updating=20 DNS and other directory services, attackers may=20 spoof DHCP servers to register incorrect=20 information in those services." Which "servers"=20 are being cited as the subject here? Who is=20 updating them? This 1-sentence paragraph does not=20 explain the role that DHCPv6 server spoofing=20 plays in the cited concern. The document states "Another possible attack is=20 that attackers may be able to gain unauthorized=20 access to some resources, such as network=20 access." Unauthorized network access is a valid=20 security concern, but the authors fail to explain=20 how DHCP spoofing is related to this generic=20 concern. One usually associates RADIUS, NEA and=20 similar protocols as more relevant to network=20 access control. The authors discuss two key management mechanisms=20 defined for DHCPv6, and conclude by saying "In=20 either way, the security of key itself is in=20 question mark." Even if one deletes the last word=20 to make the sentence readable, the assertion is=20 not supported when discussing the first option,=20 i.e., initial manual distribution of a symmetric=20 key. Kerberos has made use of this approach for=20 many years, with reasonable success. A better=20 criticism is that manual key distribution runs=20 counter to the goal of minimizing the=20 configuration data needed at each host,=20 consistent with the goals of DHCP use. Also,=20 manual key distribution is viewed as less secure=20 than automated key distribution mechanisms. This section ends with a paragraph citing another=20 security option, i.e., use of IPsec, to secure=20 server and relay agent communications. (The=20 document misspells the protocol name.)=20 "Furthermore, the manual configuration and static=20 keys are potential issue makers." IPsec does not=20 require use of manual key management or static=20 keys, so this comment is inappropriate. 3. Secure DHCPv6 Overview The proposed mechanism calls for each DHCPv6=20 server to use a CGA for its own address, and to=20 digitally sign the messages it sends using the=20 private key corresponding to the public key=20 linked to the DHCPv6 server address. This=20 mechanism counters DHCPv6 server spoofing, IF all=20 clients are configured with the CGAs of=20 authorized DHCPv6 servers. This section of the=20 document does not describe this critical=20 configuration requirement. Instead, this document=20 cite draft-ietf-dhc-cga-config-dhcpv6. The cited=20 document talks about how to use DHCPv6 to control=20 CGA generation on clients. It does not describe=20 configuring client with the CGAs of authorized=20 DHCPv6 servers. Thus the cited document does not=20 address this issue. The text includes a curious statement "By using=20 the signature option, the verification of data=20 integrity and replay protections can also be=20 achieved without the authentication option." It=20 is true that if one were to verify a signature on=20 a received message, but not verify that the=20 sending CGA is that of an authorized DHCPv6=20 server, that connectionless message integrity is=20 achieved. However, it is not clear that this=20 security function is useful, in isolation. Also,=20 the text in this section provides no analysis to=20 show why use of the signature, by itself,=20 provides replay protection. (One would need to=20 describe the context established by DHCP message=20 exchanges to make such an argument.) The section ends with a very confusing paragraph.=20 The paragraph appears to be discussing how to=20 make use of the proposed CGA-based security=20 mechanism when a relay agent lies between the=20 server and clients. The text is not clear, and=20 thus does not constitute a solid argument for why=20 this works. 4.1 New Components In discussing how to extend DHCPv6 syntax to make=20 use of the proposed CGA security mechanism, the=20 section includes a statement "The authority of a=20 public key is established through the address=20 ownership proof mechanism, by using CGAs." This=20 is not true, unless clients are configured to=20 know the CGAs of all authorized DHCPv6 servers=20 with which the clients may interact. 4.2 Support for algorithm agility This section begins with a sloppy=20 characterization of hash function requirements,=20 including a quote from RFC 4270 "The recent=20 attacks have demonstrated that one of those=20 security properties is not true." This quote is=20 not useful on this context, since the authors=20 fail to indicate which of the two cited security=20 properties is not true here. The section goes on=20 to say that "=8Aour analysis shows none of these=20 attacks are currently doable." The authors=20 provide no analysis to support this assertion,=20 nor a cite to a document that would do so. Thus,=20 either this statement needs to be removed, or=20 support for it needs to be provided. More importantly, it appears that algorithm=20 agility support for Secure DHCPv6 is based (in=20 large part) on carrying the hash and signature=20 algorithm IDs in the Signature Option. That is=20 different from the RFC 4270 analysis of how to=20 enable algorithm agility for the CGA itself.=20 Moreover, a credible algorithm agility solution=20 requires a system-level discussion of how=20 communicating servers, relays, and clients know=20 which algorithms can be used in dealing with each=20 other. This document does not include such a=20 discussion, nor does it describe how to=20 transition from one algorithm to another, within=20 the context of a network. For example, do all=20 servers have to be upgraded to offer a new=20 algorithm simultaneously? How about relays and=20 clients? 5 Extensions for Secure DHCPv6 Since this section introduces a new DHCPv6=20 option, the document needs to state that it=20 updates RFC 3315. 5.1 CGA Parameters Option The description of this new option includes the=20 following text: "Note that a future extension MAY=20 provide a mechanism allowing the owner of an=20 address and the signer to be different parties."=20 =46irst, this is a misuse of "MAY." Second, this=20 text is not appropriate for a syntax=20 specification at this time, i.e., what should an=20 implementer do based on this statement? 5.2 Signature Option I question the soundness of the proposed design.=20 The fact that the signature option can be placed=20 anywhere in the DHCPv6 message strikes me as=20 dangerous. It imposes a requirement on a receiver=20 to treat the protected and unprotected portions=20 of the message differently, for any possible=20 placement of the signature option. This adds=20 complexity to implementations, since the security=20 checking would have to indicate to the rest of=20 message processing which parts of a message were=20 checked and which were not verified. Unless there=20 are DHCHv6 options that may be modified (or=20 added) legitimately when a message traverses a=20 relay, it is not clear why there needs to be a=20 provision to exclude any portions of a DHCPv6=20 message from the integrity/authentication check.=20 "COULD" is not an RFC 2119-defined term. The option carries an explicit hash algorithm ID,=20 which is good, but the text says: "RSA signature=20 [RSA] with SHA-1 [sha-1] is adopted. In order to=20 provide hash algorithm agility, SHA-1 is assigned=20 an initial value 0x0000 in this document." Why is=20 a signature algorithm part of this definition=20 (vs. just a hash algorithm), when there is a=20 separate signature algorithm ID field? The text=20 here is inconsistent with the latter IANA=20 considerations. It appears that the mention of=20 RSA is an error, but it would be better to just=20 remove any mention of an initial algorithm value=20 here. The description of initial values for the=20 signature algorithm ID, and the second hash=20 algorithm ID also should be removed from this=20 text, and appear only in the IANA considerations=20 section. The discussion of the key hash field runs counter=20 to the goal of algorithm agility. The reference=20 to SHA-1 should be removed, if the intent is to=20 define the key hash algorithm via the=20 previously-mentioned parameter. The key hash, if=20 it is to be a fixed length, merely needs to be=20 defined as the leftmost 128 bits of the hash=20 value of the public key of the sender. The description of how to compute the signature=20 field is wrong. The text describes the fields=20 over which the hash is to be computed. Instead=20 the text says "The signature constructed by using=20 the sender's private key over the following=20 sequence of octets." The first value is a message type tag value,=20 which is said to have been computed as a random=20 value by the editor of the specification. The=20 document needs to explain why this value needs to=20 be part of the input to the hash function, and=20 how is was generated. The current text is=20 inadequate. 6.1 Processing rules of sender The discussion of processing provided here is=20 piecemeal. The text should provide comprehensive,=20 step-by-step processing instructions. As noted in my comments above, authentication of=20 an address, as provided by CGA use, does not=20 prevent spoofing attacks related to higher layer=20 functionality. Thus, for example, unless a client=20 knows the CGA of a server or relay agent,=20 authenticating the address of the purported=20 server or relay agent does not prevent spoofing,=20 the type of attack cited at the beginning of this=20 document as the primary rationale for the=20 mechanisms proposed here. The text at the end of the introductory sentence=20 says: "can be configured to send Secure DHCPv6=20 messages only if CGAs have been configured on=20 it." It is not clear whether this is saying that=20 the sender has to have a "configured" CGA (e.g.,=20 vs. a dynamically-generated CGA), or if the=20 sender needs to have a configured list of=20 recipient CGAs, or something else. It probably is=20 feasible to configure clients with the CGAs of=20 servers or relay agents, but this document did=20 not address that issue. If the authors envision=20 client use of CGAs for DHCPv6 security, they need=20 to explain how this will be managed. The=20 management ought not undermine the anonymity=20 features that are a hallmark of client use of=20 CGAs, and it must not include a circular=20 dependency. (For example, one of the documents=20 cited in this document calls for using DHCPv6 to=20 supply CGA configuration parameters to client.=20 That would not seem to be compatible with a=20 client using DHCPv6 and CGAs to communicate with=20 a server, initially.) This section ends with the statement: "The CGA of=20 DHCPv6 server will not lose during relaying so=20 that the client can verify CGA address and=20 signature." I presume this means that the CGA or=20 the server will not be lost when it passes=20 through the relay, but the English is awkward, at=20 best. 6.2 Receiver processing Here too the discussion of processing is=20 piecemeal. The text should provide comprehensive,=20 step-by-step processing instructions. The "Minbits" discussion is NOT supportive of=20 algorithm agility. It seems to refer to a minimum=20 RSA key size, without mentioning RSA. This key=20 size recommendation would be inappropriate for=20 DSA, ECDSA, etc. Also, the phrase "SHOULD be=20 1024 bits" is inappropriate. If this were the=20 default length, then it ought to be a MUST. Also,=20 the text says: "Any implementation SHOULD follow=20 prudent cryptographic practice in determining the=20 appropriate key lengths." This might be=20 reasonable (though ambiguous) advice for a site,=20 but not for an implementation. Protocol standards=20 establish requirements for default or mandatory=20 to implement algorithms and key sizes, and ALL=20 compliant implementations support the cited=20 algorithms. The guidance provided re messages that fail to=20 include the CGA or Signature options is not=20 helpful, as it fails to say what behavior is=20 required when a receiver treats a message as=20 unsecured? Saying that a receiver MAY discard the=20 message is too vague, i.e., if the receiver=20 processes it, what SHOULD/MUST the receiver do=20 differently, in the absence of either or both of=20 these options? This ambiguity seems to contradict=20 the later statement that "Only the messages that=20 get through both CGA and signature verifications=20 are accepted as secured DHCPv6 messages and=20 continue to be handled for their contained DHCPv6=20 options." It is also runs counter to the later=20 statement "Messages that do not pass all the=20 above tests MUST be silently discarded if the=20 host has been configured to accept only secured=20 DHCPv6 messages." This discrepancy needs to be=20 resolved. The text mandates verification of the Signature=20 option using a public key that is either acquired=20 from the CGA option, or "one known by other=20 means." The latter phrase is too vague to be=20 useful. It also contradicts the statement in=20 section 5.1: "This specification requires that=20 the public key found from the CGA Parameters=20 field in the CGA option MUST be that referred by=20 the Key Hash field in the Signature option." Later in this section there is a discussion of=20 how to handle messages that fail the requisite=20 checks. The texts states "Messages that do not=20 pass all the above tests MUST be silently=20 discarded if the host has been configured to=20 accept only secured DHCPv6 messages. The messages=20 MAY be accepted if the host has been configured=20 to accept both secured and unsecured messages but=20 MUST be treated as an unsecured message. The=20 receiver MAY also otherwise silently discard=20 packets." This last sentence is confusing, given=20 the previous two sentences. Also, what are the=20 security semantics of a receiver that is=20 configured to accept both secured and unsecured=20 DHCPv6 messages? Does this makes sense for=20 servers, clients, and relays? The document seems=20 to be lacking a system-level discussion of the=20 issue of how Secure DHCPv6 can be deployed,=20 incrementally, and whether a mixed mode of=20 operation makes sense on a long term or only a=20 transient basis. The text later in Section 6.1 states that the=20 Signature option is the last one in the message,=20 hence all the prior options are covered by the=20 signature. That seems appropriate, but the text=20 there does not restrict what options MAY be=20 present (as opposed to the two options that MUST=20 be present). Thus this might create ambiguity for=20 a receiver, e.g., how SHOULD/MUST a receiver deal=20 with a secured messages that also contains=20 unsigned options? Is this something that needs to=20 be configured for each server/relay/client? What=20 are the right configuration capabilities to deal=20 with this, e.g., does the configuration need to=20 enumerate what unsigned options are allowed to be=20 processed, etc? 6.3 Processing rules of Relay Agent Two more instances of "will not lose" in this section, that need to be fixed= =2E 7. Security Considerations At the top of page 13 the discussion is=20 confusing, at best. The authors seem to suggest=20 that the proposed mechanisms do not require use=20 of a "pre-notified DHCPv6 server address." But,=20 absent such configuration info, the use of the=20 proposed mechanisms do NOT prevent server=20 spoofing. Then the text suggests that such=20 configuration info may be needed, but that this=20 creates potential DoS vulnerabilities. The=20 authors then punt on this question. This is not=20 acceptable. The authors cannot have it both ways.=20 Either they are mandating use of fixed CGAs for=20 servers, or not. The security properties of the=20 proposed mechanisms are greatly affected by this=20 choice. There are several examples here of incorrect use=20 of MAY, when referring to future options that=20 might be defined to deal with a mix of secured=20 and unsecured messages. As noted above, the=20 current specification allows a node to accept=20 both secured and unsecured message, without=20 discussing what behavior is required, and without=20 a specification of how such a node might be=20 configured to limit possible damage. There is=20 also no system-level discussion of whether it is=20 necessary to configure some nodes, e.g., servers,=20 to operate in this mode because of an anticipated=20 deployment model. The text here provides vague security advice=20 "=8Awhen link-local CGAs are used by the DHCPv6=20 clients, it is recommended to use a slightly=20 higher Sec value." The text then asserts that=20 "When higher Sec values are used, the relative=20 advantage of attacking link-local addresses=20 becomes insignificant." Since no specific Sec=20 values are recommended, this latter statement is=20 unsupported, at best. There is a typo in the ultimate paragraph for=20 this section: "=8Aused in the RSA signature in=20 Secure." Should be "=8Aused in the RSA signature in=20 Secure DHCPv6." Since algorithm agility is=20 emphasized here, why are only RSA-based=20 signatures cited? --============_-885105424==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable review of draft-ietf-dhc-secure-dhcpv6-04.txt
I reviewed this document (draft-ietf-dhc-secure-dhcpv6-04.txt) 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 needs significant work because:
  -  numerous English language errors that make it hard to read
  - inconsistencies between different sections of the document are present
  - the incomplete description of sender and receiver processing
  - it contains a questionable technical proposal for flexibility re
    placement of the new sig option
  - alg agility is not correctly described for the sig option, and
    examples are alg specific
  - some examples are erroneous


The comments provided below are keyed to the sections of the document.

Abstract

"If not secured, DHCPv6 is vulnerable to various attacks, particularly fake attack." Presumably the authors are referring to "spoofing" attacks. The commonly employed terminology should be used here.


1. Introduction

Same comment for 1st paragraph here.

The 2nd paragraph cites draft-ietf-csi-dhcpv6-cga-ps and says that it introduced "requirements of using CGA to secure DHCPv6." The cited document does not define requirements for using use CGAs to secure DHCP, contrary to what is stated here. The cited document analyzes how one might use DHCPv6 to configure CGA parameters in host clients, and how one might use CGAs to counter spoofing attacks against DHCPv6 servers. At the time this SECDIR review is being written,  the cited document has 6 DISCUSS votes, suggesting that it requires significant revision, and making it a questionable basis for establishing "requirements" for CGA use in the DHCHv6 context.

The following statement "=8Aor where available security mechanisms are not sufficient, =8A" is too vague, e.g., it fails to say what/why available security mechanisms do no suffice.


2. Security Overview

It appears that this section is intended to describe the need for security mechanisms that counter DHCPv6 server spoofing attacks. It does so very poorly. It is haphazard and redundant in its organization, and some of the text is confusing, at best.

This section begins by stating "DHCPv6 is a client/server protocol that provides managed and stateful configuration of devices." I question the "stateful" part of this assertion. DHCP is designed to avoid the need for hosts to manually configured, which is very "stateful." Since a DHCP server typically assigns an address to a host from a pool, and only for the duration of a "lease" this behavior is not a great example of statefullness. SO, it is not clear what aspects of "state" the authors have in mind here.

The text says "In the basic DHCPv6 specifications, regular IPv6 addresses are used." I presume the authors mean that the DHCP server uses a "regular" IPv6 address for itself, but since DHCPv6 servers provide IPv6 addresses to their clients, this statement is ambiguous.

The last paragraph on page 3 begins with double quotes, but this appears to be a typo. This paragraph provides two examples of possible motivations for attacker that spoofs DHCP responses. Do the authors assert that these the most important motivations, the only ones, or what?

The document quotes from RFC 3315. It isn't clear if this is intended to extend the description of adverse outcomes from spoofing a DHCPv6 server, or if it is merely a restatement of the generic concern cited in the prior paragraphs.

The next paragraph uses many words to describe a MITM attack, which the document already noted at the bottom of page 3. The paragraph then goes on to say "This becomes important to detect and prevent when encrypted traffic is allowed to pass through firewalls." This is a confusing statement at best. If the traffic is encrypted, a MITM attack does not provide an adversary with a lot of interesting info to collect via a MITM attack. It isn't clear what the authors were trying to communicate here.

The document states "Once servers start updating DNS and other directory services, attackers may spoof DHCP servers to register incorrect information in those services." Which "servers" are being cited as the subject here? Who is updating them? This 1-sentence paragraph does not explain the role that DHCPv6 server spoofing plays in the cited concern.

The document states "Another possible attack is that attackers may be able to gain unauthorized access to some resources, such as network access." Unauthorized network access is a valid security concern, but the authors fail to explain how DHCP spoofing is related to this generic concern. One usually associates RADIUS, NEA and similar protocols as more relevant to network access control.

The authors discuss two key management mechanisms defined for DHCPv6, and conclude by saying "In either way, the security of key itself is in question mark." Even if one deletes the last word to make the sentence readable, the assertion is not supported when discussing the first option, i.e., initial manual distribution of a symmetric key. Kerberos has made use of this approach for many years, with reasonable success. A better criticism is that manual key distribution runs counter to the goal of minimizing the configuration data needed at each host, consistent with the goals of DHCP use. Also, manual key distribution is viewed as less secure than automated key distribution mechanisms.

This section ends with a paragraph citing another security option, i.e., use of IPsec, to secure server and relay agent communications. (The document misspells the protocol name.) "Furthermore, the manual configuration and static keys are potential issue makers." IPsec does not require use of manual key management or static keys, so this comment is inappropriate.


3. Secure DHCPv6 Overview

The proposed mechanism calls for each DHCPv6 server to use a CGA for its own address, and to digitally sign the messages it sends using the private key corresponding to the public key linked to the DHCPv6 server address. This mechanism counters DHCPv6 server spoofing, IF all clients are configured with the CGAs of authorized DHCPv6 servers. This section of the document does not describe this critical configuration requirement. Instead, this document cite draft-ietf-dhc-cga-config-dhcpv6. The cited document talks about how to use DHCPv6 to control CGA generation on clients. It does not describe configuring client with the CGAs of authorized DHCPv6 servers. Thus the cited document does not address this issue.

The text includes a curious statement "By using the signature option, the verification of data integrity and replay protections can also be achieved without the authentication option." It is true that if one were to verify a signature on a received message, but not verify that the sending CGA is that of an authorized DHCPv6 server, that connectionless message integrity is achieved. However, it is not clear that this security function is useful, in isolation. Also, the text in this section provides no analysis to show why use of the signature, by itself, provides replay protection. (One would need to describe the context established by DHCP message exchanges to make such an argument.)

The section ends with a very confusing paragraph. The paragraph appears to be discussing how to make use of the proposed CGA-based security mechanism when a relay agent lies between the server and clients. The text is not clear, and thus does not constitute a solid argument for why this works.

4.1 New Components

In discussing how to extend DHCPv6 syntax to make use of the proposed CGA security mechanism, the section includes a statement "The authority of a public key is established through the address ownership proof mechanism, by using CGAs." This is not true, unless clients are configured to know the CGAs of all authorized DHCPv6 servers with which the clients may interact.

4.2 Support for algorithm agility

This section begins with a sloppy characterization of hash function requirements, including a quote from RFC 4270 "The recent attacks have demonstrated that one of those security properties is not true." This quote is not useful on this context, since the authors fail to indicate which of the two cited security properties is not true here. The section goes on to say that "=8Aour analysis shows none of these attacks are currently doable." The authors provide no analysis to support this assertion, nor a cite to a document that would do so. Thus, either this statement needs to be removed, or support for it needs to be provided.

More importantly, it appears that algorithm agility support for Secure DHCPv6 is based (in large part) on carrying the hash and signature algorithm IDs in the Signature Option. That is different from the RFC 4270 analysis of how to enable algorithm agility for the CGA itself. Moreover, a credible algorithm agility solution requires a system-level discussion of how communicating servers, relays, and clients know which algorithms can be used in dealing with each other. This document does not include such a discussion, nor does it describe how to transition from one algorithm to another, within the context of a network. For example, do all servers have to be upgraded to offer a new algorithm simultaneously? How about relays and clients?


5 Extensions for Secure DHCPv6

Since this section introduces a new DHCPv6 option, the document needs to state that it updates RFC 3315.


5.1 CGA Parameters Option

The description of this new option includes the following text: "Note that a future extension MAY provide a mechanism allowing the owner of an address and the signer to be different parties." First, this is a misuse of "MAY." Second, this text is not appropriate for a syntax specification at this time, i.e., what should an implementer do based on this statement?

5.2 Signature Option

I question the soundness of the proposed design. The fact that the signature option can be placed anywhere in the DHCPv6 message strikes me as dangerous. It imposes a requirement on a receiver to treat the protected and unprotected portions of the message differently, for any possible placement of the signature option. This adds complexity to implementations, since the security checking would have to indicate to the rest of message processing which parts of a message were checked and which were not verified. Unless there are DHCHv6 options that may be modified (or added) legitimately when a message traverses a relay, it is not clear why there needs to be a provision to exclude any portions of a DHCPv6 message from  the integrity/authentication check. "COULD" is not an RFC 2119-defined term.

The option carries an explicit hash algorithm ID, which is good, but the text says: "RSA signature [RSA] with SHA-1 [sha-1] is adopted. In order to provide hash algorithm agility, SHA-1 is assigned an initial value 0x0000 in this document." Why is a signature algorithm part of this definition (vs. just a hash algorithm), when there is a separate signature algorithm ID field?  The text here is inconsistent with the latter IANA considerations. It appears that the mention of RSA is an error, but it would be better to just remove any mention of an initial algorithm value here. The description of initial values for the signature algorithm ID, and the second hash algorithm ID also should be removed from this text, and appear only in the IANA considerations section.

The discussion of the key hash field runs counter to the goal of algorithm agility. The reference to SHA-1 should be removed, if the intent is to define the key hash algorithm via the previously-mentioned parameter. The key hash, if it is to be a fixed length, merely needs to be defined as the leftmost 128 bits of the hash value of the public key of the sender.

The description of how to compute the signature field is wrong. The text describes the fields over which the hash is to be computed. Instead the text says "The signature constructed by using the sender's private key over the following sequence of octets."

The first value is a message type tag value, which is said to have been computed as a random value by the editor of the specification. The document needs to explain why this value needs to be part of the input to the hash function, and how is was generated. The current text is inadequate.


6.1 Processing rules of sender
 
The discussion of processing provided here is piecemeal. The text should provide comprehensive, step-by-step processing instructions.
As noted in my comments above, authentication of an address, as provided by CGA use, does not prevent spoofing attacks related to higher layer functionality. Thus, for example, unless a client knows the CGA of a server or relay agent, authenticating the address of the purported server or relay agent does not prevent spoofing, the type of attack cited at the beginning of this document as the primary rationale for the mechanisms proposed here.

The text at the end of the introductory sentence says: "can be configured to send Secure DHCPv6 messages only if CGAs have been configured on it." It is not clear whether this is saying that the sender has to have a "configured" CGA (e.g., vs. a dynamically-generated CGA), or if the sender needs to have a configured list of recipient CGAs, or something else. It probably is feasible to configure clients with the CGAs of servers or relay agents, but this document did not address that issue. If the authors envision client use of CGAs for DHCPv6 security, they need to explain how this will be managed. The management ought not undermine the anonymity features that are a hallmark of client use of CGAs, and it must not include a circular dependency. (For example, one of the documents cited in this document calls for using DHCPv6 to supply CGA configuration parameters to client. That would not seem to be compatible with a client using DHCPv6 and CGAs to communicate with a server, initially.)

This section ends with the statement: "The CGA of DHCPv6 server will not lose during relaying so that the client can verify CGA address and signature." I presume this means that the CGA or the server will not be lost when it passes through the relay, but the English is awkward, at best.


6.2 Receiver processing

Here too the discussion of processing is piecemeal. The text should provide comprehensive, step-by-step processing instructions.

The "Minbits" discussion is NOT supportive of algorithm agility. It seems to refer to a minimum RSA key size, without mentioning RSA. This key size recommendation would be inappropriate for DSA, ECDSA, etc.  Also, the phrase "SHOULD be 1024 bits" is inappropriate. If this were the default length, then it ought to be a MUST. Also, the text says: "Any implementation SHOULD follow prudent cryptographic practice in determining the appropriate key lengths." This might be reasonable (though ambiguous) advice for a site, but not for an implementation. Protocol standards establish requirements for default or mandatory to implement algorithms and key sizes, and ALL compliant implementations support the cited algorithms.

The guidance provided re messages that fail to include the CGA or Signature options is not helpful, as it fails to say what behavior is required when a receiver treats a message as unsecured? Saying that a receiver MAY discard the message is too vague, i.e., if the receiver processes it, what SHOULD/MUST the receiver do differently, in the absence of either or both of these options? This ambiguity seems to contradict the later statement that "Only the messages that get through both CGA and signature verifications are accepted as secured DHCPv6 messages and continue to be handled for their contained DHCPv6 options." It is also runs counter to the later statement "Messages that do not pass all the above tests MUST be silently discarded if the host has been configured to accept only secured DHCPv6 messages." This discrepancy needs to be resolved.

The text mandates verification of the Signature option using a public key that is either acquired from the CGA option, or "one known by other means." The latter phrase is too vague to be useful. It also contradicts the statement in section 5.1: "This specification requires that the public key found from the CGA Parameters field in the CGA option MUST be that referred by the Key Hash field in the Signature option."

Later in this section there is a discussion of how to handle messages that fail the requisite checks. The texts states "Messages that do not pass all the above tests MUST be silently discarded if the host has been configured to accept only secured DHCPv6 messages. The messages MAY be accepted if the host has been configured to accept both secured and unsecured messages but MUST be treated as an unsecured message. The receiver MAY also otherwise silently discard packets." This last sentence is confusing, given the previous two sentences. Also, what are the security semantics of a receiver that is configured to accept both secured and unsecured DHCPv6 messages? Does this makes sense for servers, clients, and relays? The document seems to be lacking a system-level discussion of the issue of how Secure DHCPv6 can be deployed, incrementally, and whether a mixed mode of operation makes sense on a long term or only a transient basis.

The text later in Section 6.1 states that the Signature option is the last one in the message, hence all the prior options are covered by the signature. That seems appropriate, but the text there does not restrict what options MAY be present (as opposed to the two options that MUST be present). Thus this might create ambiguity for a receiver, e.g., how SHOULD/MUST a receiver deal with a secured messages that also contains unsigned options? Is this something that needs to be configured for each server/relay/client? What are the right configuration capabilities to deal with this, e.g., does the configuration need to enumerate what unsigned options are allowed to be processed, etc?


6.3 Processing rules of Relay Agent

Two more instances of "will not lose" in this section, that need to be fixed.



7. Security Considerations

At the top of page 13 the discussion is confusing, at best. The authors seem to suggest that the proposed mechanisms do not require use of a "pre-notified DHCPv6 server address." But, absent such configuration info, the use of the proposed mechanisms do NOT prevent server spoofing. Then the text suggests that such configuration info may be needed, but that this creates potential DoS vulnerabilities. The authors then punt on this question. This is not acceptable. The authors cannot have it both ways. Either they are mandating use of fixed CGAs for servers, or not. The security properties of the proposed mechanisms are greatly affected by this choice.

There are several examples here of incorrect use of MAY, when referring to future options that might be defined to deal with a mix of secured and unsecured messages. As noted above, the current specification allows a node to accept both secured and unsecured message, without discussing what behavior is required, and without a specification of how such a node might be configured to limit possible damage. There is also no system-level discussion of whether it is necessary to configure some nodes, e.g., servers, to operate in this mode because of an anticipated deployment model.

The text here provides vague security advice "=8Awhen link-local CGAs are used by the DHCPv6 clients, it is recommended to use a slightly higher Sec value." The text then asserts that "When higher Sec values are used, the relative advantage of attacking link-local addresses becomes insignificant." Since no specific Sec values are recommended, this latter statement is unsupported, at best.

There is a typo in the ultimate paragraph for this section:  "=8Aused in the RSA signature in Secure." Should be "=8Aused in the RSA signature in Secure DHCPv6." Since algorithm agility is emphasized here, why are only RSA-based signatures cited?
--============_-885105424==_ma============-- From new-work-bounces@ietf.org Thu Jan 19 13:39:15 2012 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 E138521F86D7; Thu, 19 Jan 2012 13:39:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327009155; bh=j+ePg8OGFsLixDSWtTvCWVrdQ8fd3b+3F3skcvNPRmE=; h=From:To:Mime-Version:Message-Id:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=H6jOYLDfGiUuNgf+CXtoOWuv5pqKo2mpY1yT9TSPgdc6b9e18HJiyOYElHCeKuYGZ ciaO9OGNLKbYYxrSzqG+6bTlZSjtzR0BS950BrgQ37A9XR2GbRuL9LJm+jNBjkPF6c Q1QG0oq6Xy8bTnyVhhZTyUJ3RO2WAdA/uUnMVkPU= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id CA48521F86D7; Thu, 19 Jan 2012 13:39:14 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20120119213914.CA48521F86D7@ietfa.amsl.com> Date: Thu, 19 Jan 2012 13:39:14 -0800 (PST) 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: Fri, 20 Jan 2012 05:21:40 -0800 Subject: [secdir] [new-work] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 21:39:16 -0000 A modified charter has been submitted for the Locator/ID Separation Protocol (lisp) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Thursday, January 26, 2012 Locator/ID Separation Protocol (lisp) ------------------------------------- Current Status: Active Last updated: 2012-01-19 Chairs: Joel Halpern Terry Manderson Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Secretaries: Wassim Haddad Luigi Iannone Mailing Lists: General Discussion: lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of approaches are being looked at in parallel in other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG is chartered to work on the LISP base protocol, completing the ongoing work, and any items which directly impact LISP protocol structures and are related to using LISP for improving Internet routing scalability. Specifically, the group will work on: - LISP security threats and solutions - MIBs - deployment models - allocation of EID space - alternate mapping system designs In addition, if work chartered in some other IETF WG requires changes in the LISP base protocol or any items which directly impact LISP protocol structures, then the LISP WG is chartered to work on such changes. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for LISP and the various LISP mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF to understand which type of a solution is optimal. The LISP WG is not chartered to develop a standard solution for solving the routing scalability problem at this time. The specifications developed by the WG are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on as well as the manageability and operability of LISP. Specifically, the group will work on: - documenting areas that need experimentation - summarizing the results of implementation, experiments, and deployment experience - describing the implications of employing LISP - operational guidance for using LISP Goals and Milestones Jun 2012 Forward draft-ietf-lisp-mib to the IESG Jun 2012 Forward draft-ietf-lisp-sec to the IESG Jun 2012 Forward to the IESG an operational document which should include cache management and ETR synchronization techniques (draft-ietf-lisp-deployment). Oct 2012 Forward to the IESG a document providing a solution to replay issues with Map-Register/Map-Notify Dec 2013 Publish an example cache management specification. Dec 2013 Forward to the IESG an evaluation of the security threat to cache maintenance (draft-ietf-lisp-threats) Dec 2013 Forward to the IESG a document addressing the areas which require further experimentation. Jun 2014 Evaluate the applicability and coverage for LISP from a reuse of SIDR technology. Jun 2014 Summarize results of specifying, implementing, and testing LISP and forward to IESG and/or IRTF. Jun 2014 Analyze and document the implications of LISP deployments in Internet topologies and forward to IESG for publication. Dec 2014 Re-charter or close _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From jiangsheng@huawei.com Thu Jan 19 17:09:35 2012 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 88B1121F8597 for ; Thu, 19 Jan 2012 17:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 LASAacVeysIZ for ; Thu, 19 Jan 2012 17:09:31 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id C16A721F858F for ; Thu, 19 Jan 2012 17:09:30 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY200JTPOJNIM@szxga03-in.huawei.com> for secdir@ietf.org; Fri, 20 Jan 2012 09:09:23 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LY200LB8OJN4O@szxga03-in.huawei.com> for secdir@ietf.org; Fri, 20 Jan 2012 09:09:23 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGL16044; Fri, 20 Jan 2012 09:09:20 +0800 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 20 Jan 2012 09:09:09 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.236]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Fri, 20 Jan 2012 09:09:13 +0800 Date: Fri, 20 Jan 2012 01:09:11 +0000 From: Sheng Jiang In-reply-to: X-Originating-IP: [10.108.4.99] To: Stephen Kent , "secdir@ietf.org" Message-id: <5D36713D8A4E7348A7E10DF7437A4B92185A715D@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_1qSLGszScnzXsRNcb8ymdw)" Content-language: zh-CN Accept-Language: en-GB, zh-CN, en-US Thread-topic: review of draft-ietf-dhc-secure-dhcpv6-04.txt Thread-index: AQHM1wVGR+IsEftM3kywUBVOpvWIcZYUcUbw X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: DvzT EhS3 SU5P XyDZ Y1hP gyNm iDC5 sMI9 u8SB v2PZ xdVk 1k7+ 4Npp 4XRJ 81OG /JQ5; 6; agBvAGgAbgBfAGIAcgB6AG8AegBvAHcAcwBrAGkAQABjAGEAYgBsAGUALgBjAG8AbQBjAGEAcwB0AC4AYwBvAG0AOwBrAGUAbgB0AEAAYgBiAG4ALgBjAG8AbQA7AHIAZAByAG8AbQBzAC4AaQBlAHQAZgBAAGcAbQBhAGkAbAAuAGMAbwBtADsAcwBlAGMAZABpAHIAQABpAGUAdABmAC4AbwByAGcAOwBzAGgAZQBuAHMAaAB1AG8AQABjAG4AbgBpAGMALgBjAG4AOwB0AGUAZAAuAGwAZQBtAG8AbgBAAG4AbwBtAGkAbgB1AG0ALgBjAG8AbQA=; Sosha1_v1; 7; {A454111C-2104-497E-98FF-F61E3CC09FC8}; agBpAGEAbgBnAHMAaABlAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Fri, 20 Jan 2012 01:09:01 GMT; UgBFADoAIAByAGUAdgBpAGUAdwAgAG8AZgAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBkAGgAYwAtAHMAZQBjAHUAcgBlAC0AZABoAGMAcAB2ADYALQAwADQALgB0AHgAdAA= x-cr-puzzleid: {A454111C-2104-497E-98FF-F61E3CC09FC8} X-CFilter-Loop: Reflected References: X-Mailman-Approved-At: Fri, 20 Jan 2012 05:21:40 -0800 Cc: "rdroms.ietf@gmail.com" , "ted.lemon@nominum.com" , "shenshuo@cnnic.cn" , "john_brzozowski@cable.comcast.com" Subject: Re: [secdir] review of draft-ietf-dhc-secure-dhcpv6-04.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: Fri, 20 Jan 2012 01:09:35 -0000 --Boundary_(ID_1qSLGszScnzXsRNcb8ymdw) Content-type: text/plain; charset=iso-8859-2 Content-transfer-encoding: quoted-printable Hi, Stephen, Thanks so much for your carefully reviewing. It is very helpful for us to i= mprove this draft. I will integrate your comments in next version and come = back to you before submission (it will be early Feb, giving that we will st= art the Chinese New Year holiday soon) . Best regards, Sheng From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, January 20, 2012 7:51 AM To: secdir@ietf.org Cc: shenshuo@cnnic.cn; Sheng Jiang; ted.lemon@nominum.com; john_brzozowski@= cable.comcast.com; rdroms.ietf@gmail.com Subject: review of draft-ietf-dhc-secure-dhcpv6-04.txt I reviewed this document (draft-ietf-dhc-secure-dhcpv6-04.txt) as part of t= he security directorate's ongoing effort to review all IETF documents being= processed by the IESG. These comments were written primarily for the bene= fit of the security area directors. Document editors and WG chairs should = treat these comments just like any other last call comments. This document needs significant work because: - numerous English language errors that make it hard to read - inconsistencies between different sections of the document are present - the incomplete description of sender and receiver processing - it contains a questionable technical proposal for flexibility re placement of the new sig option - alg agility is not correctly described for the sig option, and examples are alg specific - some examples are erroneous The comments provided below are keyed to the sections of the document. Abstract "If not secured, DHCPv6 is vulnerable to various attacks, particularly fake= attack." Presumably the authors are referring to "spoofing" attacks. The c= ommonly employed terminology should be used here. 1. Introduction Same comment for 1st paragraph here. The 2nd paragraph cites draft-ietf-csi-dhcpv6-cga-ps and says that it intro= duced "requirements of using CGA to secure DHCPv6." The cited document does= not define requirements for using use CGAs to secure DHCP, contrary to wha= t is stated here. The cited document analyzes how one might use DHCPv6 to c= onfigure CGA parameters in host clients, and how one might use CGAs to coun= ter spoofing attacks against DHCPv6 servers. At the time this SECDIR review= is being written, the cited document has 6 DISCUSS votes, suggesting that= it requires significant revision, and making it a questionable basis for e= stablishing "requirements" for CGA use in the DHCHv6 context. The following statement "=A9or where available security mechanisms are not = sufficient, =A9" is too vague, e.g., it fails to say what/why available sec= urity mechanisms do no suffice. 2. Security Overview It appears that this section is intended to describe the need for security = mechanisms that counter DHCPv6 server spoofing attacks. It does so very poo= rly. It is haphazard and redundant in its organization, and some of the tex= t is confusing, at best. This section begins by stating "DHCPv6 is a client/server protocol that pro= vides managed and stateful configuration of devices." I question the "state= ful" part of this assertion. DHCP is designed to avoid the need for hosts t= o manually configured, which is very "stateful." Since a DHCP server typica= lly assigns an address to a host from a pool, and only for the duration of = a "lease" this behavior is not a great example of statefullness. SO, it is = not clear what aspects of "state" the authors have in mind here. The text says "In the basic DHCPv6 specifications, regular IPv6 addresses a= re used." I presume the authors mean that the DHCP server uses a "regular" = IPv6 address for itself, but since DHCPv6 servers provide IPv6 addresses to= their clients, this statement is ambiguous. The last paragraph on page 3 begins with double quotes, but this appears to= be a typo. This paragraph provides two examples of possible motivations fo= r attacker that spoofs DHCP responses. Do the authors assert that these the= most important motivations, the only ones, or what? The document quotes from RFC 3315. It isn't clear if this is intended to ex= tend the description of adverse outcomes from spoofing a DHCPv6 server, or = if it is merely a restatement of the generic concern cited in the prior par= agraphs. The next paragraph uses many words to describe a MITM attack, which the doc= ument already noted at the bottom of page 3. The paragraph then goes on to = say "This becomes important to detect and prevent when encrypted traffic is= allowed to pass through firewalls." This is a confusing statement at best.= If the traffic is encrypted, a MITM attack does not provide an adversary w= ith a lot of interesting info to collect via a MITM attack. It isn't clear = what the authors were trying to communicate here. The document states "Once servers start updating DNS and other directory se= rvices, attackers may spoof DHCP servers to register incorrect information = in those services." Which "servers" are being cited as the subject here? Wh= o is updating them? This 1-sentence paragraph does not explain the role tha= t DHCPv6 server spoofing plays in the cited concern. The document states "Another possible attack is that attackers may be able = to gain unauthorized access to some resources, such as network access." Una= uthorized network access is a valid security concern, but the authors fail = to explain how DHCP spoofing is related to this generic concern. One usuall= y associates RADIUS, NEA and similar protocols as more relevant to network = access control. The authors discuss two key management mechanisms defined for DHCPv6, and c= onclude by saying "In either way, the security of key itself is in question= mark." Even if one deletes the last word to make the sentence readable, th= e assertion is not supported when discussing the first option, i.e., initia= l manual distribution of a symmetric key. Kerberos has made use of this app= roach for many years, with reasonable success. A better criticism is that m= anual key distribution runs counter to the goal of minimizing the configura= tion data needed at each host, consistent with the goals of DHCP use. Also,= manual key distribution is viewed as less secure than automated key distri= bution mechanisms. This section ends with a paragraph citing another security option, i.e., us= e of IPsec, to secure server and relay agent communications. (The document = misspells the protocol name.) "Furthermore, the manual configuration and st= atic keys are potential issue makers." IPsec does not require use of manual= key management or static keys, so this comment is inappropriate. 3. Secure DHCPv6 Overview The proposed mechanism calls for each DHCPv6 server to use a CGA for its ow= n address, and to digitally sign the messages it sends using the private ke= y corresponding to the public key linked to the DHCPv6 server address. This= mechanism counters DHCPv6 server spoofing, IF all clients are configured w= ith the CGAs of authorized DHCPv6 servers. This section of the document doe= s not describe this critical configuration requirement. Instead, this docum= ent cite draft-ietf-dhc-cga-config-dhcpv6. The cited document talks about h= ow to use DHCPv6 to control CGA generation on clients. It does not describe= configuring client with the CGAs of authorized DHCPv6 servers. Thus the ci= ted document does not address this issue. The text includes a curious statement "By using the signature option, the v= erification of data integrity and replay protections can also be achieved w= ithout the authentication option." It is true that if one were to verify a = signature on a received message, but not verify that the sending CGA is tha= t of an authorized DHCPv6 server, that connectionless message integrity is = achieved. However, it is not clear that this security function is useful, i= n isolation. Also, the text in this section provides no analysis to show wh= y use of the signature, by itself, provides replay protection. (One would n= eed to describe the context established by DHCP message exchanges to make s= uch an argument.) The section ends with a very confusing paragraph. The paragraph appears to = be discussing how to make use of the proposed CGA-based security mechanism = when a relay agent lies between the server and clients. The text is not cle= ar, and thus does not constitute a solid argument for why this works. 4.1 New Components In discussing how to extend DHCPv6 syntax to make use of the proposed CGA s= ecurity mechanism, the section includes a statement "The authority of a pub= lic key is established through the address ownership proof mechanism, by us= ing CGAs." This is not true, unless clients are configured to know the CGAs= of all authorized DHCPv6 servers with which the clients may interact. 4.2 Support for algorithm agility This section begins with a sloppy characterization of hash function require= ments, including a quote from RFC 4270 "The recent attacks have demonstrate= d that one of those security properties is not true." This quote is not use= ful on this context, since the authors fail to indicate which of the two ci= ted security properties is not true here. The section goes on to say that "= =A9our analysis shows none of these attacks are currently doable." The auth= ors provide no analysis to support this assertion, nor a cite to a document= that would do so. Thus, either this statement needs to be removed, or supp= ort for it needs to be provided. More importantly, it appears that algorithm agility support for Secure DHCP= v6 is based (in large part) on carrying the hash and signature algorithm ID= s in the Signature Option. That is different from the RFC 4270 analysis of = how to enable algorithm agility for the CGA itself. Moreover, a credible al= gorithm agility solution requires a system-level discussion of how communic= ating servers, relays, and clients know which algorithms can be used in dea= ling with each other. This document does not include such a discussion, nor= does it describe how to transition from one algorithm to another, within t= he context of a network. For example, do all servers have to be upgraded to= offer a new algorithm simultaneously? How about relays and clients? 5 Extensions for Secure DHCPv6 Since this section introduces a new DHCPv6 option, the document needs to st= ate that it updates RFC 3315. 5.1 CGA Parameters Option The description of this new option includes the following text: "Note that = a future extension MAY provide a mechanism allowing the owner of an address= and the signer to be different parties." First, this is a misuse of "MAY."= Second, this text is not appropriate for a syntax specification at this ti= me, i.e., what should an implementer do based on this statement? 5.2 Signature Option I question the soundness of the proposed design. The fact that the signatur= e option can be placed anywhere in the DHCPv6 message strikes me as dangero= us. It imposes a requirement on a receiver to treat the protected and unpro= tected portions of the message differently, for any possible placement of t= he signature option. This adds complexity to implementations, since the sec= urity checking would have to indicate to the rest of message processing whi= ch parts of a message were checked and which were not verified. Unless ther= e are DHCHv6 options that may be modified (or added) legitimately when a me= ssage traverses a relay, it is not clear why there needs to be a provision = to exclude any portions of a DHCPv6 message from the integrity/authenticat= ion check. "COULD" is not an RFC 2119-defined term. The option carries an explicit hash algorithm ID, which is good, but the te= xt says: "RSA signature [RSA] with SHA-1 [sha-1] is adopted. In order to pr= ovide hash algorithm agility, SHA-1 is assigned an initial value 0x0000 in = this document." Why is a signature algorithm part of this definition (vs. j= ust a hash algorithm), when there is a separate signature algorithm ID fiel= d? The text here is inconsistent with the latter IANA considerations. It a= ppears that the mention of RSA is an error, but it would be better to just = remove any mention of an initial algorithm value here. The description of i= nitial values for the signature algorithm ID, and the second hash algorithm= ID also should be removed from this text, and appear only in the IANA cons= iderations section. The discussion of the key hash field runs counter to the goal of algorithm = agility. The reference to SHA-1 should be removed, if the intent is to defi= ne the key hash algorithm via the previously-mentioned parameter. The key h= ash, if it is to be a fixed length, merely needs to be defined as the leftm= ost 128 bits of the hash value of the public key of the sender. The description of how to compute the signature field is wrong. The text de= scribes the fields over which the hash is to be computed. Instead the text = says "The signature constructed by using the sender's private key over the = following sequence of octets." The first value is a message type tag value, which is said to have been com= puted as a random value by the editor of the specification. The document ne= eds to explain why this value needs to be part of the input to the hash fun= ction, and how is was generated. The current text is inadequate. 6.1 Processing rules of sender The discussion of processing provided here is piecemeal. The text should pr= ovide comprehensive, step-by-step processing instructions. As noted in my comments above, authentication of an address, as provided by= CGA use, does not prevent spoofing attacks related to higher layer functio= nality. Thus, for example, unless a client knows the CGA of a server or rel= ay agent, authenticating the address of the purported server or relay agent= does not prevent spoofing, the type of attack cited at the beginning of th= is document as the primary rationale for the mechanisms proposed here. The text at the end of the introductory sentence says: "can be configured t= o send Secure DHCPv6 messages only if CGAs have been configured on it." It = is not clear whether this is saying that the sender has to have a "configur= ed" CGA (e.g., vs. a dynamically-generated CGA), or if the sender needs to = have a configured list of recipient CGAs, or something else. It probably is= feasible to configure clients with the CGAs of servers or relay agents, bu= t this document did not address that issue. If the authors envision client = use of CGAs for DHCPv6 security, they need to explain how this will be mana= ged. The management ought not undermine the anonymity features that are a h= allmark of client use of CGAs, and it must not include a circular dependenc= y. (For example, one of the documents cited in this document calls for usin= g DHCPv6 to supply CGA configuration parameters to client. That would not s= eem to be compatible with a client using DHCPv6 and CGAs to communicate wit= h a server, initially.) This section ends with the statement: "The CGA of DHCPv6 server will not lo= se during relaying so that the client can verify CGA address and signature.= " I presume this means that the CGA or the server will not be lost when it = passes through the relay, but the English is awkward, at best. 6.2 Receiver processing Here too the discussion of processing is piecemeal. The text should provide= comprehensive, step-by-step processing instructions. The "Minbits" discussion is NOT supportive of algorithm agility. It seems t= o refer to a minimum RSA key size, without mentioning RSA. This key size re= commendation would be inappropriate for DSA, ECDSA, etc. Also, the phrase = "SHOULD be 1024 bits" is inappropriate. If this were the default length, th= en it ought to be a MUST. Also, the text says: "Any implementation SHOULD f= ollow prudent cryptographic practice in determining the appropriate key len= gths." This might be reasonable (though ambiguous) advice for a site, but n= ot for an implementation. Protocol standards establish requirements for def= ault or mandatory to implement algorithms and key sizes, and ALL compliant = implementations support the cited algorithms. The guidance provided re messages that fail to include the CGA or Signature= options is not helpful, as it fails to say what behavior is required when = a receiver treats a message as unsecured? Saying that a receiver MAY discar= d the message is too vague, i.e., if the receiver processes it, what SHOULD= /MUST the receiver do differently, in the absence of either or both of thes= e options? This ambiguity seems to contradict the later statement that "Onl= y the messages that get through both CGA and signature verifications are ac= cepted as secured DHCPv6 messages and continue to be handled for their cont= ained DHCPv6 options." It is also runs counter to the later statement "Mess= ages that do not pass all the above tests MUST be silently discarded if the= host has been configured to accept only secured DHCPv6 messages." This dis= crepancy needs to be resolved. The text mandates verification of the Signature option using a public key t= hat is either acquired from the CGA option, or "one known by other means." = The latter phrase is too vague to be useful. It also contradicts the statem= ent in section 5.1: "This specification requires that the public key found = from the CGA Parameters field in the CGA option MUST be that referred by th= e Key Hash field in the Signature option." Later in this section there is a discussion of how to handle messages that = fail the requisite checks. The texts states "Messages that do not pass all = the above tests MUST be silently discarded if the host has been configured = to accept only secured DHCPv6 messages. The messages MAY be accepted if the= host has been configured to accept both secured and unsecured messages but= MUST be treated as an unsecured message. The receiver MAY also otherwise s= ilently discard packets." This last sentence is confusing, given the previo= us two sentences. Also, what are the security semantics of a receiver that = is configured to accept both secured and unsecured DHCPv6 messages? Does th= is makes sense for servers, clients, and relays? The document seems to be l= acking a system-level discussion of the issue of how Secure DHCPv6 can be d= eployed, incrementally, and whether a mixed mode of operation makes sense o= n a long term or only a transient basis. The text later in Section 6.1 states that the Signature option is the last = one in the message, hence all the prior options are covered by the signatur= e. That seems appropriate, but the text there does not restrict what option= s MAY be present (as opposed to the two options that MUST be present). Thus= this might create ambiguity for a receiver, e.g., how SHOULD/MUST a receiv= er deal with a secured messages that also contains unsigned options? Is thi= s something that needs to be configured for each server/relay/client? What = are the right configuration capabilities to deal with this, e.g., does the = configuration need to enumerate what unsigned options are allowed to be pro= cessed, etc? 6.3 Processing rules of Relay Agent Two more instances of "will not lose" in this section, that need to be fixe= d. 7. Security Considerations At the top of page 13 the discussion is confusing, at best. The authors see= m to suggest that the proposed mechanisms do not require use of a "pre-noti= fied DHCPv6 server address." But, absent such configuration info, the use o= f the proposed mechanisms do NOT prevent server spoofing. Then the text sug= gests that such configuration info may be needed, but that this creates pot= ential DoS vulnerabilities. The authors then punt on this question. This is= not acceptable. The authors cannot have it both ways. Either they are mand= ating use of fixed CGAs for servers, or not. The security properties of the= proposed mechanisms are greatly affected by this choice. There are several examples here of incorrect use of MAY, when referring to = future options that might be defined to deal with a mix of secured and unse= cured messages. As noted above, the current specification allows a node to = accept both secured and unsecured message, without discussing what behavior= is required, and without a specification of how such a node might be confi= gured to limit possible damage. There is also no system-level discussion of= whether it is necessary to configure some nodes, e.g., servers, to operate= in this mode because of an anticipated deployment model. The text here provides vague security advice "=A9when link-local CGAs are u= sed by the DHCPv6 clients, it is recommended to use a slightly higher Sec v= alue." The text then asserts that "When higher Sec values are used, the rel= ative advantage of attacking link-local addresses becomes insignificant." S= ince no specific Sec values are recommended, this latter statement is unsup= ported, at best. There is a typo in the ultimate paragraph for this section: "=A9used in th= e RSA signature in Secure." Should be "=A9used in the RSA signature in Secu= re DHCPv6." Since algorithm agility is emphasized here, why are only RSA-ba= sed signatures cited? --Boundary_(ID_1qSLGszScnzXsRNcb8ymdw) Content-type: text/html; charset=iso-8859-2 Content-transfer-encoding: quoted-printable review of draft-ietf-dhc-secure-dhcpv6-04.txt

Hi, Stephen,

 <= /p>

Thanks so much for your c= arefully reviewing. It is very helpful for us to improve this draft. I will= integrate your comments in next version and come back to you before submission (it will be early Feb, giving that we will start the= Chinese New Year holiday soon) .

 <= /p>

Best regards,<= /span>

 <= /p>

Sheng

 <= /p>

From: Stephen = Kent [mailto:kent@bbn.com]
Sent: Friday, January 20, 2012 7:51 AM
To: secdir@ietf.org
Cc: shenshuo@cnnic.cn; Sheng Jiang; ted.lemon@nominum.com; john_brzo= zowski@cable.comcast.com; rdroms.ietf@gmail.com
Subject: review of draft-ietf-dhc-secure-dhcpv6-04.txt

 

I reviewed this document= (draft-ietf-dhc-secure-dhcpv6-04.txt) as part of the security directorate'= s ongoing effort to review all IETF documents being processed by the IESG.&= nbsp; 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 commen= ts.

 

This document needs sign= ificant work because:

  -&nb= sp; numerous English language errors tha= t make it hard to read

  - inconsistencies= between different sections of the document are present

  - the incomplete = description of sender and receiver processing

  - it contains a q= uestionable technical proposal for flexibility re

    place= ment of the new sig option

  - alg agility is = not correctly described for the sig option, and

    examp= les are alg specific

  - some examples a= re erroneous



The comments provided below are keyed to the sections of the document.

Abstract

"If not secured, DHCPv6 is vulnerable to various attacks, particularly= fake attack." Presumably the authors are referring to "spoofing&= quot; attacks. The commonly employed terminology should be used here.


1. Introduction

Same comment for 1st paragraph here.

The 2nd paragraph cites draft-ietf-csi-dhcpv6-cga-ps and says that it intro= duced "requirements of using CGA to secure DHCPv6." The cited doc= ument does not define requirements for using use CGAs to secure DHCP, contr= ary to what is stated here. The cited document analyzes how one might use DHCPv6 to configure CGA parameters in ho= st clients, and how one might use CGAs to counter spoofing attacks against = DHCPv6 servers. At the time this SECDIR review is being written,  the = cited document has 6 DISCUSS votes, suggesting that it requires significant revision, and making it a questionable basis = for establishing "requirements" for CGA use in the DHCHv6 context= .

The following statement "=A9or where available security mechanisms are= not sufficient, =A9" is too vague, e.g., it fails to say what/why ava= ilable security mechanisms do no suffice.


2. Security Overview

It appears that this section is intended to describe the need for security = mechanisms that counter DHCPv6 server spoofing attacks. It does so very poo= rly. It is haphazard and redundant in its organization, and some of the tex= t is confusing, at best.

This section begins by stating "DHCPv6 is a client/server protocol tha= t provides managed and stateful configuration of devices." I question = the "stateful" part of this assertion. DHCP is designed to avoid = the need for hosts to manually configured, which is very "stateful." Since a DHCP server typically assigns an addres= s to a host from a pool, and only for the duration of a "lease" t= his behavior is not a great example of statefullness. SO, it is not clear w= hat aspects of "state" the authors have in mind here.

The text says "In the basic DHCPv6 specifications, regular IPv6 addres= ses are used." I presume the authors mean that the DHCP server uses a = "regular" IPv6 address for itself, but since DHCPv6 servers provi= de IPv6 addresses to their clients, this statement is ambiguous.

The last paragraph on page 3 begins with double quotes, but this appears to= be a typo. This paragraph provides two examples of possible motivations fo= r attacker that spoofs DHCP responses. Do the authors assert that these the= most important motivations, the only ones, or what?

The document quotes from RFC 3315. It isn't clear if this is intended to ex= tend the description of adverse outcomes from spoofing a DHCPv6 server, or = if it is merely a restatement of the generic concern cited in the prior par= agraphs.

The next paragraph uses many words to describe a MITM attack, which the doc= ument already noted at the bottom of page 3. The paragraph then goes on to = say "This becomes important to detect and prevent when encrypted traff= ic is allowed to pass through firewalls." This is a confusing statement at best. If the traffic is encrypted, a MITM= attack does not provide an adversary with a lot of interesting info to col= lect via a MITM attack. It isn't clear what the authors were trying to comm= unicate here.


The document states "Once servers start updating DNS and other directo= ry services, attackers may spoof DHCP servers to register incorrect informa= tion in those services." Which "servers" are being cited as = the subject here? Who is updating them? This 1-sentence paragraph does not explain the role that DHCPv6 server spoofing plays in t= he cited concern.

The document states "Another possible attack is that attackers may be = able to gain unauthorized access to some resources, such as network access.= " Unauthorized network access is a valid security concern, but the aut= hors fail to explain how DHCP spoofing is related to this generic concern. One usually associates RADIUS, NEA and si= milar protocols as more relevant to network access control.

The authors discuss two key management mechanisms defined for DHCPv6, and c= onclude by saying "In either way, the security of key itself is in que= stion mark." Even if one deletes the last word to make the sentence re= adable, the assertion is not supported when discussing the first option, i.e., initial manual distribution of a symmet= ric key. Kerberos has made use of this approach for many years, with reason= able success. A better criticism is that manual key distribution runs count= er to the goal of minimizing the configuration data needed at each host, consistent with the goals of DHCP = use. Also, manual key distribution is viewed as less secure than automated = key distribution mechanisms.

This section ends with a paragraph citing another security option, i.e., us= e of IPsec, to secure server and relay agent communications. (The document = misspells the protocol name.) "Furthermore, the manual configuration a= nd static keys are potential issue makers." IPsec does not require use of manual key management or static keys, so thi= s comment is inappropriate.


3. Secure DHCPv6 Overview

The proposed mechanism calls for each DHCPv6 server to use a CGA for its ow= n address, and to digitally sign the messages it sends using the private ke= y corresponding to the public key linked to the DHCPv6 server address. This= mechanism counters DHCPv6 server spoofing, IF all clients are configured with the CGAs of authorized DHCPv6= servers. This section of the document does not describe this critical conf= iguration requirement. Instead, this document cite draft-ietf-dhc-cga-confi= g-dhcpv6. The cited document talks about how to use DHCPv6 to control CGA generation on clients. It does not = describe configuring client with the CGAs of authorized DHCPv6 servers. Thu= s the cited document does not address this issue.

The text includes a curious statement "By using the signature option, = the verification of data integrity and replay protections can also be achie= ved without the authentication option." It is true that if one were to= verify a signature on a received message, but not verify that the sending CGA is that of an authorized DHCPv6 server= , that connectionless message integrity is achieved. However, it is not cle= ar that this security function is useful, in isolation. Also, the text in t= his section provides no analysis to show why use of the signature, by itself, provides replay protection. (= One would need to describe the context established by DHCP message exchange= s to make such an argument.)

The section ends with a very confusing paragraph. The paragraph appears to = be discussing how to make use of the proposed CGA-based security mechanism = when a relay agent lies between the server and clients. The text is not cle= ar, and thus does not constitute a solid argument for why this works.

4.1 New Components

In discussing how to extend DHCPv6 syntax to make use of the proposed CGA s= ecurity mechanism, the section includes a statement "The authority of = a public key is established through the address ownership proof mechanism, = by using CGAs." This is not true, unless clients are configured to know the CGAs of all authorized DHCPv6 servers w= ith which the clients may interact.

4.2 Support for algorithm agility

This section begins with a sloppy characterization of hash function require= ments, including a quote from RFC 4270 "The recent attacks have demons= trated that one of those security properties is not true." This quote = is not useful on this context, since the authors fail to indicate which of the two cited security properties is not true he= re. The section goes on to say that "=A9our analysis shows none of the= se attacks are currently doable." The authors provide no analysis to s= upport this assertion, nor a cite to a document that would do so. Thus, either this statement needs to be removed, or supp= ort for it needs to be provided.


More importantly, it appears that algorithm agility support for Secure DHCP= v6 is based (in large part) on carrying the hash and signature algorithm ID= s in the Signature Option. That is different from the RFC 4270 analysis of = how to enable algorithm agility for the CGA itself. Moreover, a credible algorithm agility solution requir= es a system-level discussion of how communicating servers, relays, and clie= nts know which algorithms can be used in dealing with each other. This docu= ment does not include such a discussion, nor does it describe how to transition from one algorithm to another, with= in the context of a network. For example, do all servers have to be upgrade= d to offer a new algorithm simultaneously? How about relays and clients?

5 Extensions for Secure DHCPv6

Since this section introduces a new DHCPv6 option, the document needs to st= ate that it updates RFC 3315.


5.1 CGA Parameters Option

The description of this new option includes the following text: "Note = that a future extension MAY provide a mechanism allowing the owner of an ad= dress and the signer to be different parties." First, this is a misuse= of "MAY." Second, this text is not appropriate for a syntax specification at this time, i.e., what should an implementer = do based on this statement?

5.2 Signature Option

I question the soundness of the proposed design. The fact that the signatur= e option can be placed anywhere in the DHCPv6 message strikes me as dangero= us. It imposes a requirement on a receiver to treat the protected and unpro= tected portions of the message differently, for any possible placement of the signature option. This adds complexity t= o implementations, since the security checking would have to indicate to th= e rest of message processing which parts of a message were checked and whic= h were not verified. Unless there are DHCHv6 options that may be modified (or added) legitimately when a mes= sage traverses a relay, it is not clear why there needs to be a provision t= o exclude any portions of a DHCPv6 message from  the integrity/authent= ication check. "COULD" is not an RFC 2119-defined term.

The option carries an explicit hash algorithm ID, which is good, but the te= xt says: "RSA signature [RSA] with SHA-1 [sha-1] is adopted. In order = to provide hash algorithm agility, SHA-1 is assigned an initial value 0x000= 0 in this document." Why is a signature algorithm part of this definition (vs. just a hash algorithm), when there = is a separate signature algorithm ID field?  The text here is inconsis= tent with the latter IANA considerations. It appears that the mention of RS= A is an error, but it would be better to just remove any mention of an initial algorithm value here. The descrip= tion of initial values for the signature algorithm ID, and the second hash = algorithm ID also should be removed from this text, and appear only in the = IANA considerations section.

The discussion of the key hash field runs counter to the goal of algorithm = agility. The reference to SHA-1 should be removed, if the intent is to defi= ne the key hash algorithm via the previously-mentioned parameter. The key h= ash, if it is to be a fixed length, merely needs to be defined as the leftmost 128 bits of the hash value of t= he public key of the sender.

The description of how to compute the signature field is wrong. The text de= scribes the fields over which the hash is to be computed. Instead the text = says "The signature constructed by using the sender's private key over= the following sequence of octets."

The first value is a message type tag value, which is said to have been com= puted as a random value by the editor of the specification. The document ne= eds to explain why this value needs to be part of the input to the hash fun= ction, and how is was generated. The current text is inadequate.


6.1 Processing rules of sender
 
The discussion of processing provided here is piecemeal. The text should pr= ovide comprehensive, step-by-step processing instructions.
As noted in my comments above, authentication of an address, as provided by= CGA use, does not prevent spoofing attacks related to higher layer functio= nality. Thus, for example, unless a client knows the CGA of a server or rel= ay agent, authenticating the address of the purported server or relay agent does not prevent spoofing, the type= of attack cited at the beginning of this document as the primary rationale= for the mechanisms proposed here.


The text at the end of the introductory sentence says: "can be configu= red to send Secure DHCPv6 messages only if CGAs have been configured on it.= " It is not clear whether this is saying that the sender has to have a= "configured" CGA (e.g., vs. a dynamically-generated CGA), or if the sender needs to have a configured list of recipient CGAs, = or something else. It probably is feasible to configure clients with the CG= As of servers or relay agents, but this document did not address that issue= . If the authors envision client use of CGAs for DHCPv6 security, they need to explain how this will be man= aged. The management ought not undermine the anonymity features that are a = hallmark of client use of CGAs, and it must not include a circular dependen= cy. (For example, one of the documents cited in this document calls for using DHCPv6 to supply CGA configuration = parameters to client. That would not seem to be compatible with a client us= ing DHCPv6 and CGAs to communicate with a server, initially.)

This section ends with the statement: "The CGA of DHCPv6 server will n= ot lose during relaying so that the client can verify CGA address and signa= ture." I presume this means that the CGA or the server will not be los= t when it passes through the relay, but the English is awkward, at best.


6.2 Receiver processing

Here too the discussion of processing is piecemeal. The text should provide= comprehensive, step-by-step processing instructions.

The "Minbits" discussion is NOT supportive of algorithm agility. = It seems to refer to a minimum RSA key size, without mentioning RSA. This k= ey size recommendation would be inappropriate for DSA, ECDSA, etc.  Al= so, the phrase "SHOULD be 1024 bits" is inappropriate. If this were the default length, then it ought to be a MUST. Also, the tex= t says: "Any implementation SHOULD follow prudent cryptographic practi= ce in determining the appropriate key lengths." This might be reasonab= le (though ambiguous) advice for a site, but not for an implementation. Protocol standards establish requirements for d= efault or mandatory to implement algorithms and key sizes, and ALL complian= t implementations support the cited algorithms.

The guidance provided re messages that fail to include the CGA or Signature= options is not helpful, as it fails to say what behavior is required when = a receiver treats a message as unsecured? Saying that a receiver MAY discar= d the message is too vague, i.e., if the receiver processes it, what SHOULD/MUST the receiver do differently= , in the absence of either or both of these options? This ambiguity seems t= o contradict the later statement that "Only the messages that get thro= ugh both CGA and signature verifications are accepted as secured DHCPv6 messages and continue to be handled for the= ir contained DHCPv6 options." It is also runs counter to the later sta= tement "Messages that do not pass all the above tests MUST be silently= discarded if the host has been configured to accept only secured DHCPv6 messages." This discrepancy needs to be= resolved.

The text mandates verification of the Signature option using a public key t= hat is either acquired from the CGA option, or "one known by other mea= ns." The latter phrase is too vague to be useful. It also contradicts = the statement in section 5.1: "This specification requires that the public key found from the CGA Parameters field in the CG= A option MUST be that referred by the Key Hash field in the Signature optio= n."

Later in this section there is a discussion of how to handle messages that = fail the requisite checks. The texts states "Messages that do not pass= all the above tests MUST be silently discarded if the host has been config= ured to accept only secured DHCPv6 messages. The messages MAY be accepted if the host has been configured to accept bot= h secured and unsecured messages but MUST be treated as an unsecured messag= e. The receiver MAY also otherwise silently discard packets." This las= t sentence is confusing, given the previous two sentences. Also, what are the security semantics of a receiver that is= configured to accept both secured and unsecured DHCPv6 messages? Does this= makes sense for servers, clients, and relays? The document seems to be lac= king a system-level discussion of the issue of how Secure DHCPv6 can be deployed, incrementally, and whether= a mixed mode of operation makes sense on a long term or only a transient b= asis.


The text later in Section 6.1 states that the Signature option is the last = one in the message, hence all the prior options are covered by the signatur= e. That seems appropriate, but the text there does not restrict what option= s MAY be present (as opposed to the two options that MUST be present). Thus this might create ambiguity fo= r a receiver, e.g., how SHOULD/MUST a receiver deal with a secured messages= that also contains unsigned options? Is this something that needs to be co= nfigured for each server/relay/client? What are the right configuration capabilities to deal with this, e.g., doe= s the configuration need to enumerate what unsigned options are allowed to = be processed, etc?


6.3 Processing rules of Relay Agent

Two more instances of "will not lose" in this section, that need = to be fixed.



7. Security Considerations

At the top of page 13 the discussion is confusing, at best. The authors see= m to suggest that the proposed mechanisms do not require use of a "pre= -notified DHCPv6 server address." But, absent such configuration info,= the use of the proposed mechanisms do NOT prevent server spoofing. Then the text suggests that such configuration in= fo may be needed, but that this creates potential DoS vulnerabilities. The = authors then punt on this question. This is not acceptable. The authors can= not have it both ways. Either they are mandating use of fixed CGAs for servers, or not. The security properti= es of the proposed mechanisms are greatly affected by this choice.

There are several examples here of incorrect use of MAY, when referring to = future options that might be defined to deal with a mix of secured and unse= cured messages. As noted above, the current specification allows a node to = accept both secured and unsecured message, without discussing what behavior is required, and without a speci= fication of how such a node might be configured to limit possible damage. T= here is also no system-level discussion of whether it is necessary to confi= gure some nodes, e.g., servers, to operate in this mode because of an anticipated deployment model.

The text here provides vague security advice "=A9when link-local CGAs = are used by the DHCPv6 clients, it is recommended to use a slightly higher = Sec value." The text then asserts that "When higher Sec values ar= e used, the relative advantage of attacking link-local addresses becomes insignificant." Since no specific Sec values are re= commended, this latter statement is unsupported, at best.

There is a typo in the ultimate paragraph for this section:  "=A9= used in the RSA signature in Secure." Should be "=A9used in the R= SA signature in Secure DHCPv6." Since algorithm agility is emphasized = here, why are only RSA-based signatures cited?

--Boundary_(ID_1qSLGszScnzXsRNcb8ymdw)-- From clonvick@cisco.com Fri Jan 20 10:47:08 2012 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 C3E3121F8571; Fri, 20 Jan 2012 10:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 kA0bxMSregRk; Fri, 20 Jan 2012 10:47:08 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4410E21F8522; Fri, 20 Jan 2012 10:47:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=2074; q=dns/txt; s=iport; t=1327085228; x=1328294828; h=date:from:to:subject:message-id:mime-version; bh=r/DsKDed+23qTwCACmmwGb8qF12Ect0nemiRIxSsMno=; b=LJcN6yNVk6g0IEb10YyycZtdlIdfMdaWAHbJPEajQ4ZO9jsW2E5Fi8iV 298HZVJjQrecv0Gaw/4wof4yGatYi1SiZSrvzKVyDqqUQomkMRWRVQTAJ HGBSM8gNerHLggnlwMkPskmzYsQqiRvx/6wh86U1js4M73VD0onQS34h2 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwHAIq1GU+rRDoH/2dsb2JhbABDnXsBkA2BBYILASUCgX40oXsBnjuMJgSIPJ9J X-IronPort-AV: E=Sophos;i="4.71,544,1320624000"; d="scan'208";a="26228941" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 20 Jan 2012 18:47:08 +0000 Received: from sjc-cde-021.cisco.com (sjc-cde-021.cisco.com [171.69.20.56]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0KIl886001484; Fri, 20 Jan 2012 18:47:08 GMT Date: Fri, 20 Jan 2012 10:47:07 -0800 (PST) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-ietf-v6ops-ipv6-discard-prefix.all@tools.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [secdir] SECDIR review of draft-ietf-v6ops-ipv6-discard-prefix-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: Fri, 20 Jan 2012 18:47:08 -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. Overall, the document is very straightforward and the Security Considerations section is appropriate for the content. I do have one nit to pass along. I think that a paragraph break is in the wrong place in the Introduction. Current in Introduction: (end of first paragraph) manner which is efficient, scalable and straightforward to implement. For IPv4, some networks configure RTBH installations using [RFC1918] address space or the address blocks reserved for documentation in [RFC5737]. However RTBH configurations are not documentation, but operationally important features of many public-facing production networks. Furthermore, [RFC3849] specifies that the IPv6 documentation prefix should be filtered in both local and public contexts. On this basis, it is suggested that both private network address blocks and documentation prefixes described in [RFC5737] are inappropriate for the purpose of RTBH configurations. Suggested: manner which is efficient, scalable and straightforward to implement. For IPv4, some networks configure RTBH installations using [RFC1918] address space or the address blocks reserved for documentation in [RFC5737]. However RTBH configurations are not documentation, but operationally important features of many public-facing production networks. Furthermore, [RFC3849] specifies that the IPv6 documentation prefix should be filtered in both local and public contexts. On this basis, it is suggested that both private network address blocks and documentation prefixes described in [RFC5737] are inappropriate for the purpose of RTBH configurations. Regards, Chris From joelja@bogus.com Sat Jan 21 08:14:54 2012 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 0FFAB21F84A3; Sat, 21 Jan 2012 08:14:54 -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=[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 8tpfgEI7G1An; Sat, 21 Jan 2012 08:14:53 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8B14B21F84A5; Sat, 21 Jan 2012 08:14:53 -0800 (PST) Received: from Joels-MacBook-Pro.local (user-64-9-235-240.googlewifi.com [64.9.235.240]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q0LGEndp066271 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 21 Jan 2012 16:14:49 GMT (envelope-from joelja@bogus.com) Message-ID: <4F1AE479.2010704@bogus.com> Date: Sat, 21 Jan 2012 08:14:49 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Chris Lonvick References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 21 Jan 2012 16:14:51 +0000 (UTC) Cc: draft-ietf-v6ops-ipv6-discard-prefix.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-ietf-v6ops-ipv6-discard-prefix-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: Sat, 21 Jan 2012 16:14:54 -0000 Not a big fan of the use of "however" I think this can be addressed at minimum by auth48. On 1/20/12 10:47 , Chris Lonvick wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Overall, the document is very straightforward and the Security > Considerations section is appropriate for the content. > > I do have one nit to pass along. I think that a paragraph break is in > the wrong place in the Introduction. > > Current in Introduction: > (end of first paragraph) > manner which is efficient, scalable and straightforward to implement. > For IPv4, some networks configure RTBH installations using [RFC1918] > address space or the address blocks reserved for documentation in > [RFC5737]. > > However RTBH configurations are not documentation, but operationally > important features of many public-facing production networks. > Furthermore, [RFC3849] specifies that the IPv6 documentation prefix > should be filtered in both local and public contexts. On this basis, > it is suggested that both private network address blocks and > documentation prefixes described in [RFC5737] are inappropriate for > the purpose of RTBH configurations. > > Suggested: > manner which is efficient, scalable and straightforward to implement. > > For IPv4, some networks configure RTBH installations using [RFC1918] > address space or the address blocks reserved for documentation in > [RFC5737]. However RTBH configurations are not documentation, but > operationally important features of many public-facing production > networks. Furthermore, [RFC3849] specifies that the IPv6 documentation > prefix should be filtered in both local and public contexts. On this > basis, it is suggested that both private network address blocks and > documentation prefixes described in [RFC5737] are inappropriate for > the purpose of RTBH configurations. > > Regards, > Chris > From weiler+secdir@watson.org Mon Jan 23 06:12:25 2012 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 55E6421F86B3 for ; Mon, 23 Jan 2012 06:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.534, 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 r4Lt6+NTJvXl for ; Mon, 23 Jan 2012 06:12:24 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 626BD21F86B0 for ; Mon, 23 Jan 2012 06:12:24 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q0NECMa5058825 for ; Mon, 23 Jan 2012 09:12:22 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q0NECMV3058818 for ; Mon, 23 Jan 2012 09:12:22 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 23 Jan 2012 09:12:22 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 23 Jan 2012 09:12:22 -0500 (EST) 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: Mon, 23 Jan 2012 14:12:25 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Sandy Murphy is next in the rotation. For telechat 2012-02-02 Reviewer LC end Draft Hilarie Orman TR2011-12-13 draft-ietf-sidr-rpki-rtr-24 For telechat 2012-02-16 Russ Mundy T 2012-02-14 draft-ishikawa-yrpunl-ucode-urn-01 For telechat 2012-03-15 Tina TSOU T 2012-02-14 draft-shin-augmented-pake-10 Last calls and special requests: Dave Cridland 2012-01-03 draft-os-ietf-sshfp-ecdsa-sha2-04 Warren Kumari 2012-01-24 draft-ietf-dime-pmip6-lr-06 Barry Leiba 2012-01-13 draft-ietf-pcn-signaling-requirements-07 Matt Lepinski 2012-01-26 draft-ietf-radext-radsec-10 Alexey Melnikov 2012-01-27 draft-ietf-payload-rtp-klv-02 Kathleen Moriarty 2012-02-03 draft-ietf-tsvwg-source-quench-04 From kathleen.moriarty@emc.com Mon Jan 23 07:35:14 2012 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 4199E21F8687; Mon, 23 Jan 2012 07:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.5 X-Spam-Level: X-Spam-Status: No, score=-9.5 tagged_above=-999 required=5 tests=[AWL=1.099, 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 nwC8vmWe42I5; Mon, 23 Jan 2012 07:35:13 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 441B021F8683; Mon, 23 Jan 2012 07:35:12 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0NFZ4VV009818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2012 10:35:07 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 23 Jan 2012 10:34:44 -0500 Received: from mxhub35.corp.emc.com (mxhub35.corp.emc.com [10.254.93.83]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0NFYhji028334; Mon, 23 Jan 2012 10:34:43 -0500 Received: from mx06a.corp.emc.com ([169.254.1.153]) by mxhub35.corp.emc.com ([::1]) with mapi; Mon, 23 Jan 2012 10:34:43 -0500 From: To: , , Date: Mon, 23 Jan 2012 10:34:41 -0500 Thread-Topic: Sec-dir review of draft-ietf-tsvwg-source-quench-04 Thread-Index: AczZ5IYpMliT8QTVT+uEN1JM0Ads+Q== Message-ID: 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 Cc: fernando@gont.com.ar Subject: [secdir] Sec-dir review of draft-ietf-tsvwg-source-quench-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: Mon, 23 Jan 2012 15:35:14 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is straightforward and well written. I just have a couple of = nits, but think the document is ready otherwise. Suggest replacing 'must' with 'should' since the discussion is on interpret= ation. Change from: Receipt of an ICMP Source Quench message must not be interpreted as an atte= mpt to attack the receiver. To: Receipt of an ICMP Source Quench message should not be interpreted as an at= tempt to attack the receiver. It is already clear from the rest of the draft and this section, that there= is no risk by ignoring ICMP source quench messages, which is done by 'virt= ually all current implementations of TCP'. Should this say, virtually all= current implementations of 'IP' or 'TCP' and 'ICMP'? The discussion cove= rs source quench being deprecated (RFC1812) by router implementations 20 ye= ars ago and now formally deprecates this within TCP. Thank you, Kathleen From mnot@mnot.net Tue Jan 24 15:36:46 2012 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 3C9E021F84FC; Tue, 24 Jan 2012 15:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=-2.667, 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 chVduA0TifiU; Tue, 24 Jan 2012 15:36:45 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 70EA321F84EA; Tue, 24 Jan 2012 15:36:32 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.240.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BC94922E1EB; Tue, 24 Jan 2012 18:36:30 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Wed, 25 Jan 2012 10:36:27 +1100 Content-Transfer-Encoding: 7bit Message-Id: <004F97D3-E825-4BD5-A761-1F047AAFB7AE@mnot.net> References: To: Stephen Hanna X-Mailer: Apple Mail (2.1251.1) Cc: "draft-nottingham-http-new-status@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-nottingham-http-new-status-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: Tue, 24 Jan 2012 23:36:46 -0000 On 14/01/2012, at 6:59 AM, Stephen Hanna wrote: > I do have a question about the issues raised in Appendix B. > These are all legitimate issues. However, it seems to me > that having status code 511 should help with these. A > browser or non-browser application could recognize status > code 511 as an indication that a captive portal is in use > and avoid capturing favicons, looking for P3P files, and > doing other things that should wait until after the captive > portal is blocking access. When the original website stops > returning 511, such activities could resume. I may be wrong > in suggesting these ideas but if not it would be good to > note them here. I've added a note linking the issues to 511 more explicitly. Thanks, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Jan 24 15:36:49 2012 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 D9F1A11E80A0; Tue, 24 Jan 2012 15:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.885 X-Spam-Level: X-Spam-Status: No, score=-104.885 tagged_above=-999 required=5 tests=[AWL=-2.286, 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 SmOL45xjf34N; Tue, 24 Jan 2012 15:36:49 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id DF17911E809A; Tue, 24 Jan 2012 15:36:48 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.240.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E2B2322E257; Tue, 24 Jan 2012 18:36:46 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Wed, 25 Jan 2012 10:36:45 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F109383.1090505@gmx.de> To: Stephen Hanna X-Mailer: Apple Mail (2.1251.1) Cc: Julian Reschke , "draft-nottingham-http-new-status@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-nottingham-http-new-status-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: Tue, 24 Jan 2012 23:36:50 -0000 Sorry for the delay in responding; just back from holiday. On 14/01/2012, at 8:26 AM, Stephen Hanna wrote: > Julian, >=20 > I'm sure that in your view one sentence is adequate to explain > all the security implications of each status code. However, > you may want to consider that some readers may not have quite > the same deep grasp of the matter that you do. Therefore, > I think it would be wise to provide more explanation. Here's an > example for section 7.2 on status code 429 (Too Many Requests): >=20 > Section 7.2 429 Too Many Requests >=20 > While status code 429 can be helpful in figuring out why a > server is not responding to requests, it can also be harmful. > When a server is under attack or simply receiving a very > large number of requests from a single party, responding > to each of these requests with a 429 status code will consume > resources that could be better used in other ways. Therefore, > a server in such circumstances may choose to send a 429 status > code only the first time a client exceeds its limit and > ignore subsequent requests from this client until its limit > is no longer exceeded. Other approaches may also be employed. >=20 > As you can see, I described security problems that could occur > with this status code and explained how those problems can be > avoided or mitigated. While it's true that these problems > could occur when a more generic status code is used to handle > the case of "too many requests", that does not mean that they > are not relevant to this document. On the contrary, the fact > that this document is providing more detailed status codes > gives us the opportunity and one can argue the obligation to > provide more detailed security analysis relevant to these more > detailed status codes. I'm really not sure I agree; the original text is: Servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps. If someone implementing a server doesn't understand that, I don't know = that using more words really helps; it does, however, make it harder to = find the words in the spec that *will* help. -- Mark Nottingham http://www.mnot.net/ From new-work-bounces@ietf.org Wed Jan 25 12:18:01 2012 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 E262811E8098; Wed, 25 Jan 2012 12:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1327522681; bh=yd2DTNMv76732ZlxD1xwOncJe6QsKCb7yBJ+yP0tgvc=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=f+aA2sxVP3iACir46RGpD5sFQRxTOS45itPGsOR9YEt3H2XvzO+bwHvtFU+U1GJci iwFnUEBWxVpvWnoh2o+BwO0DOAtPdxwH2gDJvnntTLFaIo9FIHD0eDII2o9Rggbvel C9RSD2y7PNwZl0np/J+cYPM4J6ObkomVux/yhI+I= 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 DEE2011E808F for ; Wed, 25 Jan 2012 12:18: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=[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 FOQv5MGHqJwO for ; Wed, 25 Jan 2012 12:18:00 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:123a::1:14]) by ietfa.amsl.com (Postfix) with ESMTP id E537721F8448 for ; Wed, 25 Jan 2012 12:17:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E244C12BF1D for ; Wed, 25 Jan 2012 12:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6pLqYDGGpvs for ; Wed, 25 Jan 2012 12:17:59 -0800 (PST) Received: from 149-166-25-70.dhcp-in.iupui.edu (unknown [149.166.24.15]) by c8a.amsl.com (Postfix) with ESMTPSA id 6773112BF15 for ; Wed, 25 Jan 2012 12:17:59 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) From: IETF Chair In-Reply-To: Date: Wed, 25 Jan 2012 15:17:55 -0500 Message-Id: <29EB437A-2329-47BF-A738-BDEABE94D3EA@ietf.org> References: To: new-work@ietf.org X-Mailer: Apple Mail (2.1084) 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, 25 Jan 2012 16:47:06 -0800 Subject: Re: [secdir] [new-work] Considering adding ONF to the new-work mail list X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 20:18:02 -0000 ONF has been added to the new-work mail list. Welcome. This is the first message to the new-work mail list that ONF is receiving. Russ On Jan 9, 2012, at 2:38 PM, IETF Chair wrote: > We are considering adding ONF (https://www.opennetworking.org/) to the new-work mail list. Before doing so, we would like to know if any current members of the mail list would have any concerns regarding this action. If you have concerns, please let me know in the next week. > > Thanks, > Russ Housley > IETF Chair _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From charliek@microsoft.com Thu Jan 26 10:05:56 2012 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 F13D021F86D9; Thu, 26 Jan 2012 10:05:55 -0800 (PST) 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 ctjDX7UCG4CX; Thu, 26 Jan 2012 10:05:54 -0800 (PST) Received: from TX2EHSOBE004.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9DF21F86D1; Thu, 26 Jan 2012 10:05:54 -0800 (PST) Received: from mail164-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Jan 2012 18:05:53 +0000 Received: from mail164-tx2 (localhost [127.0.0.1]) by mail164-tx2-R.bigfish.com (Postfix) with ESMTP id 66CC03E0202; Thu, 26 Jan 2012 18:05:53 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzc85fhzz1202hzz8275bh8275dhz2fhc1bhc31hc1ahc1bhc31hc1ah2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail164-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=charliek@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail164-tx2 (localhost.localdomain [127.0.0.1]) by mail164-tx2 (MessageSwitch) id 1327601151763658_11246; Thu, 26 Jan 2012 18:05:51 +0000 (UTC) Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.254]) by mail164-tx2.bigfish.com (Postfix) with ESMTP id B6BCC80045; Thu, 26 Jan 2012 18:05:51 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Jan 2012 18:05:49 +0000 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.7]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0247.005; Thu, 26 Jan 2012 10:05:41 -0800 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-geopriv-deref-protocol.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-geopriv-deref-protocol-04 Thread-Index: AczcUlHhlR2Jyp4+QACa3zENEynQrQ== Date: Thu, 26 Jan 2012 18:05:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: multipart/alternative; boundary="_000_D80EDFF2AD83E648BD1164257B9B091241945C0DTK5EX14MBXC117r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [secdir] Secdir review of draft-ietf-geopriv-deref-protocol-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: Thu, 26 Jan 2012 18:05:56 -0000 --_000_D80EDFF2AD83E648BD1164257B9B091241945C0DTK5EX14MBXC117r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document specifies a relatively trivial extension to the HELD protocol= to allow that protocol to be used to look up someone's (or something's) lo= cation. It's previous use was in connection with a device learning and/or s= etting its own location. It specifies an access control mechanism based on = keeping location URIs secret and leaves open the possibility of alternate a= ccess control mechanisms being added in the future. It recommends use of TL= S, but does not require it. The Security Considerations section addresses t= hese issues well. I see no security issues with this document. I found no typos. I have a few readability suggestions: The document is not very free-standing, in that it would be difficult for s= omeone outside the geopriv community to figure out what's going on in this = document without reading some others first. It would be helpful if the intr= oduction recommended some other RFC where such a context might be learned. Section 3.3 paragraph 1 says: "This document does not describe a specific a= uthentication mechanism. This means that authorization policies are unable = to specifically identify authorized Location Recipients." As is clarified l= ater in the section, what is really meant is that no mechanism for doing so= is specified in this document. It is explicitly intended that such functio= nality be addable later without invalidating this document. In particular, = paragraph 6 says: "Authentication of Location Recipients and use of identit= y-based authorization policy is not precluded." Clarifying that in the firs= t paragraph would avoid confusion. This last one is a real nit, but it bugged me... Section 4.1 paragraph 3 says: "The LS MUST ignore any parameters that it do= es not understand unless it knows the parameters to be invalid". I would cl= aim that you must understand something to know that it is invalid, and so w= ould leave off the "unless" clause. --_000_D80EDFF2AD83E648BD1164257B9B091241945C0DTK5EX14MBXC117r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

This document specifies a relatively trivial extensi= on to the HELD protocol to allow that protocol to be used to look up someon= e’s (or something’s) location. It’s previous use was in c= onnection with a device learning and/or setting its own location. It specifies an access control mechanism based on keeping lo= cation URIs secret and leaves open the possibility of alternate access cont= rol mechanisms being added in the future. It recommends use of TLS, but doe= s not require it. The Security Considerations section addresses these issues well.

 

I see no security issues with this document.

 

I found no typos.

 

I have a few readability suggestions:

 

The document is not very free-standing, in that it w= ould be difficult for someone outside the geopriv community to figure out w= hat’s going on in this document without reading some others first. It= would be helpful if the introduction recommended some other RFC where such a context might be learned.

 

Section 3.3 paragraph 1 says: “This document d= oes not describe a specific authentication mechanism. This means that autho= rization policies are unable to specifically identify authorized Location R= ecipients.” As is clarified later in the section, what is really meant is that no mechanism for doing so is specifi= ed in this document. It is explicitly intended that such functionality be a= ddable later without invalidating this document. In particular, paragraph 6= says: “Authentication of Location Recipients and use of identity-based authorization policy is not precluded= .” Clarifying that in the first paragraph would avoid confusion.=

 

This last one is a real nit, but it bugged me…=

 

Section 4.1 paragraph 3 says: “The LS MUST ign= ore any parameters that it does not understand unless it knows the paramete= rs to be invalid”. I would claim that you must understand something t= o know that it is invalid, and so would leave off the “unless” clause.

--_000_D80EDFF2AD83E648BD1164257B9B091241945C0DTK5EX14MBXC117r_-- From Tina.Tsou.Zouting@huawei.com Thu Jan 26 14:39:50 2012 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 3255121F8630 for ; Thu, 26 Jan 2012 14:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 JLZ9Qkb+y3FR for ; Thu, 26 Jan 2012 14:39:49 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 951C921F8627 for ; Thu, 26 Jan 2012 14:39:49 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYF00NWMGA556@szxga05-in.huawei.com> for secdir@ietf.org; Fri, 27 Jan 2012 06:39:42 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYF001GRGA5J9@szxga05-in.huawei.com> for secdir@ietf.org; Fri, 27 Jan 2012 06:39:41 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGO08844; Fri, 27 Jan 2012 06:39:39 +0800 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Jan 2012 06:39:19 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Fri, 27 Jan 2012 06:39:49 +0800 Date: Thu, 26 Jan 2012 22:39:32 +0000 From: Tina TSOU In-reply-to: <4F20D424.1060901@gmail.com> X-Originating-IP: [10.193.34.128] To: "secdir@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: SECDIR review of draft-shin-augmented-pake-10 Thread-index: AQHM3Htfakgv3SEVMEyWW1S7NY+DIA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4F20D424.1060901@gmail.com> Cc: "draft-shin-augmented-pake@tools.ietf.org" Subject: [secdir] SECDIR review of draft-shin-augmented-pake-10 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, 26 Jan 2012 22:39:50 -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 found some editorial glitches and the use of "temporal" when "temporary" was intended, but someone else can catch those. Reference K11 is now RFC 6467. That means the Notify message type and the GSPM payload type have now been assigned (16424 and 49 respectively) and can be inserted into the document where it currently says "TBD". The request to IANA names the wrong registry. The correct name is "IKEv2 Secure Password Methods" registry, established by RFC 6467. The relationship between this document and RFC 6467 is odd. In the ordinary course of events this document would have a normative dependency on RFC 6467. It is obvious that the latter was written after the present document, and avoidance of the dependency was deliberate on both sides. Still, the authors of this document might reconsider, even though RFC 6467 would be a down-reference since it is Informational. Tina From ondrej.sury@nic.cz Fri Jan 27 02:25:08 2012 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 783A921F850D for ; Fri, 27 Jan 2012 02:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, 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 RVEEh-uLrq9s for ; Fri, 27 Jan 2012 02:25:08 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C947A21F84CE for ; Fri, 27 Jan 2012 02:25:07 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:e0b7:7a23:933c:691b] (unknown [IPv6:2001:1488:ac14:1400:e0b7:7a23:933c:691b]) by mail.nic.cz (Postfix) with ESMTPSA id 0AB322A3017 for ; Fri, 27 Jan 2012 11:25:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1327659907; bh=0fW8yppUteWOrAXNE4R7Modt6A1lLPKcR8Eh9aQh3R0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=Xj9nn/VhFZdnxbgS7rMQyykqsiuy7FmbOtW5y/tQH8lLa9FSkkJznDy8Dj3Erh9xD 5rgQq1AKJncCJ5FSy/5SkwOeW+jGXKpU/Wak6EkNcaqAcnlhaA/7Ihf9JVs3pHALuJ UfDVdaNavSiaGpwxOrEXPcqdOW+WuOtB7p8z5Jeg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1251.1) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 27 Jan 2012 11:25:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1610A494-DA56-4749-BAB2-E238C5C0DD2D@nic.cz> References: To: secdir@ietf.org X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean 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: Fri, 27 Jan 2012 10:25:08 -0000 This really needs a review. There were couple of points raised by other directorates about SHA-1 vs SHA-256 and they all referred to secdir = review and I still miss it. I have incorporated all changes from last call, so there's draft-os-ietf-sshfp-ecdsa-sha2-05 now. On 23. 1. 2012, at 15:12, Samuel Weiler wrote: > Dave Cridland 2012-01-03 draft-os-ietf-sshfp-ecdsa-sha2-04 -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From kivinen@iki.fi Fri Jan 27 05:51:00 2012 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 A851921F858E for ; Fri, 27 Jan 2012 05:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 33dZqhfykI60 for ; Fri, 27 Jan 2012 05:51:00 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id D447521F8572 for ; Fri, 27 Jan 2012 05:50:59 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id q0RDogb4025613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 15:50:42 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q0RDofPf026085; Fri, 27 Jan 2012 15:50:41 +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: <20258.43953.678320.842027@fireball.kivinen.iki.fi> Date: Fri, 27 Jan 2012 15:50:41 +0200 From: Tero Kivinen To: Tina TSOU In-Reply-To: References: <4F20D424.1060901@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: "draft-shin-augmented-pake@tools.ietf.org" , "secdir@ietf.org" Subject: [secdir] SECDIR review of draft-shin-augmented-pake-10 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, 27 Jan 2012 13:51:00 -0000 Tina TSOU writes: > The relationship between this document and RFC 6467 is odd. In the > ordinary course of events this document would have a normative > dependency on RFC 6467. Not exactly. The original intention is that all documents using numbers defined in my draft (now RFC6467) would be self-containing, and there might not even be need for publishing my draft as RFC, it was originally just written as tool so that all secure password method drafts could coordinate their numbers. As it is now published as RFC, I think it is ok to make either normative or non-normative reference to it, depending whether the document itself is self-containing or not. Currently I think all the secure password method documents are self-containing, thus non-normative reference is needed, the implementor who is implementing the secure password method in question, does not NEED to read RFC6467 to be able to implement for example draft-shin-augmented-pake as that draft already contains all information needed. > It is obvious that the latter was written > after the present document, and avoidance of the dependency was > deliberate on both sides. Still, the authors of this document might > reconsider, even though RFC 6467 would be a down-reference since it > is Informational. The intended status of draft-shin-augmented-pake is listed as experimental, so there really a down-reference problem there? Anyways as draft-shin-augmented-pake self-contained, the reference can be non-normative. -- kivinen@iki.fi From weiler+secdir@watson.org Fri Jan 27 10:04:03 2012 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 DEEDE21F8643 for ; Fri, 27 Jan 2012 10:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.427, 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 qdeicbsuFFyN for ; Fri, 27 Jan 2012 10:04:03 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4D84521F8642 for ; Fri, 27 Jan 2012 10:04:03 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q0RI41BS005693 for ; Fri, 27 Jan 2012 13:04:01 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q0RI41ob005690 for ; Fri, 27 Jan 2012 13:04:01 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 27 Jan 2012 13:04:01 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 27 Jan 2012 13:04:01 -0500 (EST) 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, 27 Jan 2012 18:04:04 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2012-02-02 Reviewer LC end Draft Steve Hanna TR2012-01-13 draft-nottingham-http-new-status-03 Matt Lepinski T 2012-01-26 draft-ietf-radext-radsec-11 Hilarie Orman TR2011-12-13 draft-ietf-sidr-rpki-rtr-24 For telechat 2012-02-16 Russ Mundy T 2012-02-14 draft-ishikawa-yrpunl-ucode-urn-02 Last calls and special requests: Dave Cridland 2012-01-03 draft-os-ietf-sshfp-ecdsa-sha2-06 Warren Kumari 2012-01-24 draft-ietf-dime-pmip6-lr-07 Barry Leiba 2012-01-13 draft-ietf-pcn-signaling-requirements-07 Alexey Melnikov 2012-01-27 draft-ietf-payload-rtp-klv-02 Sandy Murphy 2012-02-06 draft-ietf-dnsext-xnamercode-00 Magnus Nystrom 2012-02-07 draft-ietf-dhc-pd-exclude-04 Hilarie Orman 2012-02-07 draft-ietf-dnsext-ecdsa-04 Radia Perlman 2012-02-07 draft-ietf-hokey-erp-aak-07 Tim Polk 2012-02-07 draft-ietf-oauth-v2-bearer-15 Eric Rescorla 2012-02-08 draft-ietf-sieve-notify-sip-message-08 Vincent Roca 2012-02-06 draft-ietf-simple-chat-13 Joe Salowey 2012-02-21 draft-snell-atompub-tombstones-14 Yaron Sheffer 2012-02-06 draft-ietf-dhc-dhcpv4-bulk-leasequery-05 Ondrej Sury 2012-02-06 draft-ietf-dhc-forcerenew-nonce-03 From mlepinski@bbn.com Fri Jan 27 13:29:10 2012 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 6CD8D21F8686 for ; Fri, 27 Jan 2012 13:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 QtLBqn1T8DAP for ; Fri, 27 Jan 2012 13:29:09 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id C466321F8685 for ; Fri, 27 Jan 2012 13:29:09 -0800 (PST) Received: from [128.89.253.251] (port=1828) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RqtM5-0001f5-Bc; Fri, 27 Jan 2012 16:29:09 -0500 Message-ID: <4F231731.4080304@bbn.com> Date: Fri, 27 Jan 2012 16:29:21 -0500 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "secdir@ietf.org" , draft-ietf-radext-radsec.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SECDIR review of draft-ietf-radext-radsec-11 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, 27 Jan 2012 21:29:10 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies a TLS transport for the RADIUS protocol. It is an experimental specification that is one of several approaches to address security shortcomings in RADIUS (for example, the reliance of RADIUS upon MD5). I believe this document presents a reasonable approach to providing integrity and confidentiality protection to RADIUS packets as well as cipher suite agility. The principal security concern is that when deploying RADIUS/TLS, the system will be vulnerable to bid-down attacks to RADIUS/UDP until either the RADIUS client or the RADIUS server disables support for RADIUS/UDP. This type of bid-down attack seems to be unavoidable and is well-documented in the security considerations. I have a small number of additional comments below: -- I would strongly advise changing all instances of the phrase "acceptable Certification Authority" to "trusted Certification Authority" in order to be consistent with terminology in TLS 1.2 (RFC 5246). (I found instances of the phrase "acceptable Certification Authority" on the bottom of page 5 and the top of page 6.) I would also change "acceptable certificate" to "trusted certificate" in the fingerprint bullet on page 6. -- In bulleted list number 2 on page 5 (Section 2.3), bullets 4 and 9 seem to be redundant. Furthermore, I find it unusual to have a normative mandate that compliant implementations MUST NOT negotiate ciphersuites that do not provide confidentiality protection. (It is very common when discussing ciphersuite negotiation to mandate that implementations support certain ciphersuites offer confidentiality protection, but saying that a user MUST NOT be able to configure the implementation to use a NULL-encryption cipher suite is quite unusual.) After reading the security considerations section, I believe that the reason you have this normative requirement is because RADIUS packets include user-passwords which always require confidentiality protection. However, because the normative requirement is unusual, I would either add a sentence to 2.3 explaining the requirement or else put a forward reference to Section 6 (Security Considerations) for explanation. -- I found the fingerprint bullet on page 6 to be a bit confusing. My understanding (after reading it several times) is that you are specifying a particular ASCII encoding for certificate fingerprints. In particular, you are mandating that each of the 20 bytes of the certificate fingerprint be encoded as a pair of hexadecimal digits and that the encoding for the fingerprint is the string "sha-1:" followed by the encodings of these 20 bytes separated by colons. I am not sure what the clearest way is to get across this meaning. However, the first time I read I read the current text it was not clear to me that the document was mandating a particular ASCII encoding of certificate fingerprints. (Question: Is there an interoperability failure if two RADIUS devices do not agree on the encoding of a certificate fingerprint? If the fingerprint is just something that is configured, calculated and used locally then it doesn't seem to matter whether one implementation uses the ASCII string: "sha-1:E1:2D:53 ... 9D" and another implementation uses the UTF-8 string "SHA-1:e1:2d:53 ... 9d".) From hartmans@painless-security.com Fri Jan 27 11:47:50 2012 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 1564921F85F3; Fri, 27 Jan 2012 11:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 P5kCoMQNpC+L; Fri, 27 Jan 2012 11:47:49 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6AB21F8510; Fri, 27 Jan 2012 11:47:49 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A9B42204AF; Fri, 27 Jan 2012 14:46:55 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 528A74690; Fri, 27 Jan 2012 14:47:42 -0500 (EST) From: Sam Hartman To: radext@ietf.org,secdir@ietf.org,ietf@ietf.org Date: Fri, 27 Jan 2012 14:47:42 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sat, 28 Jan 2012 09:31:06 -0800 Subject: [secdir] Security review of draft-ietf-radext-radsec 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, 27 Jan 2012 19:47:50 -0000 Hi. I'm not the secdir reviewer assigned to this draft, but felt that this draft needed additional security review, so I decided to perform a secdir-like review. Overall, I think this is a much-needed specification and believe it is mostly ready for publication as an experimental RFC. I'd say a bit more clarity would be required if we wanted to move this to the standards track. General issues: 1) I'm reasonably sure that RADSEC MUST NOT be used with TLS versions prior to 1.1. The concern I have is that RADSEC has long-lived TLS connections under which an attacker could potentially observe ciphertext generated from some plaintext before sending additional plaintext. TLS 1.1 includes explicit IVs that prevent various attacks that may happen against earlier versions of TLS. There are implementation work arounds that can also prevent these attacks. However since all RADSEC implementations are required to support TLS 1.1, I'd prefer to add a requirement that RADSEC implementations MUST NOT negotiate TLS versions prior to 1.1 in order to avoid this issue. 2) Section 2.3 implies that you need to do cert validation all the time, even when you have a certificate fingerprint. I think it could more clearly indicate that multiple ways of figuring out if you have the right public key are provided. It's also not clear to me from section 2.3 whether there is a mandatory-to-implement strategy. You SHOULD support cert fingerprints. You MUST support cert path validation, but is there a required name form to support? There are discussions of several name forms but none seem mandatory. I see no discussion of RFC 6125, which I would have expected to see here. However, most of this is OK for an experimental spec. This is the big area where I'd expect to see more clarity before this could move to the standards track. From mlepinsk@bbn.com Fri Jan 27 13:27:20 2012 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 E509E21F861F; Fri, 27 Jan 2012 13:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 B1lXTQPZKh-G; Fri, 27 Jan 2012 13:27:20 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1192521F8577; Fri, 27 Jan 2012 13:27:20 -0800 (PST) Received: from [128.89.253.251] (port=1820) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RqtKI-0001dW-Vp; Fri, 27 Jan 2012 16:27:19 -0500 Message-ID: <4F2316C3.2010405@bbn.com> Date: Fri, 27 Jan 2012 16:27:31 -0500 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ieft-radext-radsec.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 28 Jan 2012 09:31:06 -0800 Subject: [secdir] SECDIR review of draft-ietf-radext-radsec-11 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, 27 Jan 2012 21:27:21 -0000 I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. Thes= e comments were written primarily for the benefit of the security area di= rectors. Document editors and WG chairs should treat these comments just= like any other last call comments. This document specifies a TLS transport for the RADIUS protocol. It is an= experimental specification that is one of several approaches to address = security shortcomings in RADIUS (for example, the reliance of RADIUS upon= MD5). I believe this document presents a reasonable approach to providing integ= rity and confidentiality protection to RADIUS packets as well as cipher s= uite agility. The principal security concern is that when deploying RADIU= S/TLS, the system will be vulnerable to bid-down attacks to RADIUS/UDP un= til either the RADIUS client or the RADIUS server disables support for RA= DIUS/UDP. This type of bid-down attack seems to be unavoidable and is wel= l-documented in the security considerations. I have a small number of additional comments below: -- I would strongly advise changing all instances of the phrase "acceptab= le Certification Authority" to "trusted Certification Authority" in order= to be consistent with terminology in TLS 1.2 (RFC 5246). (I found instan= ces of the phrase "acceptable Certification Authority" on the bottom of p= age 5 and the top of page 6.) I would also change "acceptable certificate= " to "trusted certificate" in the fingerprint bullet on page 6. -- In bulleted list number 2 on page 5 (Section 2.3), bullets 4 and 9 see= m to be redundant. Furthermore, I find it unusual to have a normative man= date that compliant implementations MUST NOT negotiate ciphersuites that = do not provide confidentiality protection. (It is very common when discus= sing ciphersuite negotiation to mandate that implementations support cert= ain ciphersuites offer confidentiality protection, but saying that a user= MUST NOT be able to configure the implementation to use a NULL-encryptio= n cipher suite is quite unusual.) After reading the security consideratio= ns section, I believe that the reason you have this normative requirement= is because RADIUS packets include user-passwords which always require co= nfidentiality protection. However, because the normative requirement is u= nusual, I would either add a sentence to 2.3 explaining the requirement o= r else put a forward reference to Section 6 (Security Considerations) for= explanation. -- I found the fingerprint bullet on page 6 to be a bit confusing. My und= erstanding (after reading it several times) is that you are specifying a = particular ASCII encoding for certificate fingerprints. In particular, yo= u are mandating that each of the 20 bytes of the certificate fingerprint = be encoded as a pair of hexadecimal digits and that the encoding for the = fingerprint is the string "sha-1:" followed by the encodings of these 20 = bytes separated by colons. I am not sure what the clearest way is to get = across this meaning. However, the first time I read I read the current te= xt it was not clear to me that the document was mandating a particular AS= CII encoding of certificate fingerprints. (Question: Is there an interope= rability failure if two RADIUS devices do not agree on the encoding of a = certificate fingerprint? If the fingerprint is just something that is con= figured, calculated and used locally then it doesn't seem to matter wheth= er one implementation uses the ASCII string: "sha-1:E1:2D:53 ... 9D" and = another implementation uses the UTF-8 string "SHA-1:e1:2d:53 ... 9d".) From alexey.melnikov@isode.com Sat Jan 28 11:22:12 2012 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 31A1121F842F; Sat, 28 Jan 2012 11:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.416 X-Spam-Level: X-Spam-Status: No, score=-102.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 gpOGtM4xFILQ; Sat, 28 Jan 2012 11:22:11 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 874ED21F8543; Sat, 28 Jan 2012 11:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1327778522; d=isode.com; s=selector; i=@isode.com; bh=ku4jjYDg3PiTuywExSHKLz0yt7KrUwCB1OSx9SD1x5U=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gW1wlBdRCaV28J8f19Fa1hLIjwUmxe3ns/J7vkR0lbcRFOvWKVhRTRSV6mEEF+FbTHn0pa g5VCmQxwPEl+iK2k4fPPNaKW5j43jfqAYmgKZN0sY/pyA1sWW51vPdgUFy/Hh3z4OrvNnQ 1in5K29oHQDAxP3Ey9rpM3ybiUgPfSs=; Received: from [188.28.107.210] (188.28.107.210.threembb.co.uk [188.28.107.210]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 28 Jan 2012 19:22:00 +0000 Message-ID: <4F244AE1.5000301@isode.com> Date: Sat, 28 Jan 2012 19:22:09 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-payload-rtp-klv.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SECDIR review of draft-ietf-payload-rtp-klv-02.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: Sat, 28 Jan 2012 19:22:12 -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 specifies the payload format (and the corresponding media type) for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE 336M, into the Real-time Transport Protocol (RTP). The document is well written. Its Security Considerations section talks about several ways of providing RTP payload confidentiality, integrity and source authenticity. It also talks about causing denial of service in naive decoders by specially crafted packets. I can't think of other things that needs to be covered in this section. From hilarie@purplestreak.com Sun Jan 29 15:38:22 2012 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 F38FC21F84EC; Sun, 29 Jan 2012 15:38:21 -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 paOQ4vHff4Vd; Sun, 29 Jan 2012 15:38:21 -0800 (PST) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by ietfa.amsl.com (Postfix) with ESMTP id 775A521F84EA; Sun, 29 Jan 2012 15:38:21 -0800 (PST) Received: from mx02.mta.xmission.com ([166.70.13.212]) by out02.mta.xmission.com with esmtp (Exim 4.71) (envelope-from ) id 1RreKC-0007DC-Vc; Sun, 29 Jan 2012 16:38:21 -0700 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=sylvester.rhmr.com) by mx02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RreKC-0000mm-9Z; Sun, 29 Jan 2012 16:38:20 -0700 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 q0TNbiQJ012928; Sun, 29 Jan 2012 16:37:44 -0700 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id q0TNbiLi012926; Sun, 29 Jan 2012 16:37:44 -0700 Date: Sun, 29 Jan 2012 16:37:44 -0700 Message-Id: <201201292337.q0TNbiLi012926@sylvester.rhmr.com> From: "Hilarie Orman" To: secdir@ietf.org, iesg@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx02.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-DomainKey: sender_domain=purplestreak.com; ; ; sender=hilarie@purplestreak.com; ; ; status=error X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;secdir@ietf.org, iesg@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600) X-SA-Exim-Scanned: Yes (on mx02.mta.xmission.com) Subject: [secdir] Review of RPKI/Router Protocol, draft-ietf-sidr-rpki-rtr-24 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: Sun, 29 Jan 2012 23:38:22 -0000 Security review of The RPKI/Router Protocol, draft-ietf-sidr-rpki-rtr-24 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 protocol defines the communication between a router and an Autonomous System (AS) cache validated by public keys. This is part of a work in progress to secure routing infrastructure. The caches implement a "resource public key infrastructure (RPKI)". I've previously reviewed this document and recommended that the session identifier be more than 16 bits. Because this would change the header length, those deploying the protocol were loathe to make the change. In subsequent discussion I recommended that the text of the document take a strong stance towards using an incremented counter value between reboots if the cache had persistent storage. The language of the draft has not changed to reflect the recommendation. The draft also has a confusing statement that The Session ID might be a pseudo-random, a monotonically increasing value if the cache has reliable storage, etc. I don't think this makes sense, perhaps there is a typo, and the qualifiers of "might" and "etc." don't help much. I also recommended not using the term "monkey in the middle" in place of the much more common "man in the middle" unless there was a specific reason with a citation for a definition. The statement about SSH transport states: It is assumed that the router and cache have exchanged keys out of band by some reasonably secured means. The out-of-band exchange of keys is a persistent problem in IETF protocols, and I sincerely wish that there were some guidance on this point. What is "reasonble"? The security of the out-of-band exchange should be commensurate with the security requirements of the application, as should key updates. It would be worth eine kleine BCP, perhaps. Hilarie From mnot@mnot.net Sun Jan 29 15:50:10 2012 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 3B14D21F84F2; Sun, 29 Jan 2012 15:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.021 X-Spam-Level: X-Spam-Status: No, score=-105.021 tagged_above=-999 required=5 tests=[AWL=-2.422, 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 bwrCu5iXCRxg; Sun, 29 Jan 2012 15:50:09 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C71CC21F84DE; Sun, 29 Jan 2012 15:50:07 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.240.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6D3D822E247; Sun, 29 Jan 2012 18:50:05 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Mon, 30 Jan 2012 10:50:02 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <0EEB0CDF-6D05-4EA7-9244-CA80C03BD11D@mnot.net> References: <4F109383.1090505@gmx.de> To: Stephen Hanna X-Mailer: Apple Mail (2.1251.1) Cc: Julian Reschke , "draft-nottingham-http-new-status@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-nottingham-http-new-status-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: Sun, 29 Jan 2012 23:50:10 -0000 I haven't heard any further response. After a reminder from a Security = AD, I took another look at the spec. E.g., the current Security Considerations for 428: > The 428 status code is optional; clients cannot rely upon its use to = prevent "lost update" conflicts. Like many of the status codes, that's already a risk inherent in using = HTTP today; we're effectively just noting that we can't force = implementations to use the new status code retroactively, so they can't = use the publication of this document as a magical flag day. As such, not much more can be said; the only way that people can further = mitigate the risks of lost updates is to have a private, out-of-band = agreement to use 429, and I *don't* think that's something we should be = encouraging.=20 For 429, I've changed to: > When a server is under attack or just receiving a very large number of = requests from a single party, responding to each with a 429 status code = will consume resources. >=20 > Therefore, servers are not required to use the 429 status code; when = limiting resource usage, it may be more appropriate to just drop = connections, or take other steps. 431 says: > Servers are not required to use the 431 status code; when under = attack, it may be more appropriate to just drop connections, or take = other steps. What else should be said here? This specification is not a treatise on = dealing with denial-of-service attacks; all that it notes is that = servers aren't required to use the status code. Finally, 511 says: > In common use, a response carrying the 511 status code will not come = from the origin server indicated in the request's URL. This presents = many security issues; e.g., an attacking intermediary may be inserting = cookies into the original domain's name space, may be observing cookies = or HTTP authentication credentials sent from the user agent, and so on. = However, these risks are not unique to the 511 status code; in other = words, a captive portal that is not using this status code introduces = the same issues.=20 Are there other specific threats you're aware of here?=20 Regards, On 25/01/2012, at 10:36 AM, Mark Nottingham wrote: > Sorry for the delay in responding; just back from holiday. >=20 >=20 > On 14/01/2012, at 8:26 AM, Stephen Hanna wrote: >=20 >> Julian, >>=20 >> I'm sure that in your view one sentence is adequate to explain >> all the security implications of each status code. However, >> you may want to consider that some readers may not have quite >> the same deep grasp of the matter that you do. Therefore, >> I think it would be wise to provide more explanation. Here's an >> example for section 7.2 on status code 429 (Too Many Requests): >>=20 >> Section 7.2 429 Too Many Requests >>=20 >> While status code 429 can be helpful in figuring out why a >> server is not responding to requests, it can also be harmful. >> When a server is under attack or simply receiving a very >> large number of requests from a single party, responding >> to each of these requests with a 429 status code will consume >> resources that could be better used in other ways. Therefore, >> a server in such circumstances may choose to send a 429 status >> code only the first time a client exceeds its limit and >> ignore subsequent requests from this client until its limit >> is no longer exceeded. Other approaches may also be employed. >>=20 >> As you can see, I described security problems that could occur >> with this status code and explained how those problems can be >> avoided or mitigated. While it's true that these problems >> could occur when a more generic status code is used to handle >> the case of "too many requests", that does not mean that they >> are not relevant to this document. On the contrary, the fact >> that this document is providing more detailed status codes >> gives us the opportunity and one can argue the obligation to >> provide more detailed security analysis relevant to these more >> detailed status codes. >=20 > I'm really not sure I agree; the original text is: >=20 > Servers are not required to use the 429 status code; when > limiting resource usage, it may be more appropriate to just drop > connections, or take other steps. >=20 > If someone implementing a server doesn't understand that, I don't know = that using more words really helps; it does, however, make it harder to = find the words in the spec that *will* help. >=20 >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 >=20 -- Mark Nottingham http://www.mnot.net/ From hartmans@painless-security.com Mon Jan 30 03:42:19 2012 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 228C021F8559; Mon, 30 Jan 2012 03:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 twGvAVNqPUsF; Mon, 30 Jan 2012 03:42:18 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id AF59421F84EB; Mon, 30 Jan 2012 03:42:18 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A1C92203C0; Mon, 30 Jan 2012 06:41:21 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8A60A4690; Mon, 30 Jan 2012 06:42:05 -0500 (EST) From: Sam Hartman To: Stefan Winter References: <4F2651CC.2030406@restena.lu> Date: Mon, 30 Jan 2012 06:42:05 -0500 In-Reply-To: <4F2651CC.2030406@restena.lu> (Stefan Winter's message of "Mon, 30 Jan 2012 09:16:12 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] [radext] Security review of draft-ietf-radext-radsec 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, 30 Jan 2012 11:42:19 -0000 Your proposed direction for trust validation semes like a major improvement to me. From shanna@juniper.net Mon Jan 30 07:07:17 2012 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 6ED4D21F84B4; Mon, 30 Jan 2012 07:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 TxgN45vQng+P; Mon, 30 Jan 2012 07:07:16 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id B17C621F8656; Mon, 30 Jan 2012 07:07:03 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTyayF1mWRGpM48dvFicRe1F4qA/LCRJV@postini.com; Mon, 30 Jan 2012 07:07:15 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 07:05:35 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 30 Jan 2012 10:05:34 -0500 From: Stephen Hanna To: Mark Nottingham Date: Mon, 30 Jan 2012 10:05:32 -0500 Thread-Topic: secdir review of draft-nottingham-http-new-status-03 Thread-Index: Acze4L0XIuPltSeBT2qfJxuKVa0I5AAfSypQ Message-ID: References: <4F109383.1090505@gmx.de> <0EEB0CDF-6D05-4EA7-9244-CA80C03BD11D@mnot.net> In-Reply-To: <0EEB0CDF-6D05-4EA7-9244-CA80C03BD11D@mnot.net> 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-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Cc: Julian Reschke , "draft-nottingham-http-new-status@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-nottingham-http-new-status-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: Mon, 30 Jan 2012 15:07:17 -0000 Mark, I don't want to rehash the discussion that we've already had. Clearly, you prefer brevity while I would prefer education in this instance. I can live with your text for status codes 428, 429, and 431. For 511, I don't think it's adequate to just say that big security issues already exist. You should at least give some suggestions for how to deal with them. For example, you could point out that most user agents include some indication of whether the server has been authenticated. For captive portals, this indication will generally not be displayed so the user receives some warning that the response did not come from the requested URL. Thanks, Steve > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Sunday, January 29, 2012 6:50 PM > To: Stephen Hanna > Cc: Julian Reschke; draft-nottingham-http-new-status@tools.ietf.org; > secdir@ietf.org; ietf@ietf.org > Subject: Re: secdir review of draft-nottingham-http-new-status-03 >=20 > I haven't heard any further response. After a reminder from a Security > AD, I took another look at the spec. >=20 > E.g., the current Security Considerations for 428: >=20 > > The 428 status code is optional; clients cannot rely upon its use to > prevent "lost update" conflicts. >=20 > Like many of the status codes, that's already a risk inherent in using > HTTP today; we're effectively just noting that we can't force > implementations to use the new status code retroactively, so they can't > use the publication of this document as a magical flag day. >=20 > As such, not much more can be said; the only way that people can > further mitigate the risks of lost updates is to have a private, out- > of-band agreement to use 429, and I *don't* think that's something we > should be encouraging. >=20 > For 429, I've changed to: >=20 > > When a server is under attack or just receiving a very large number > of requests from a single party, responding to each with a 429 status > code will consume resources. > > > > Therefore, servers are not required to use the 429 status code; when > limiting resource usage, it may be more appropriate to just drop > connections, or take other steps. >=20 >=20 > 431 says: >=20 > > Servers are not required to use the 431 status code; when under > attack, it may be more appropriate to just drop connections, or take > other steps. >=20 >=20 > What else should be said here? This specification is not a treatise on > dealing with denial-of-service attacks; all that it notes is that > servers aren't required to use the status code. >=20 > Finally, 511 says: >=20 > > In common use, a response carrying the 511 status code will not come > from the origin server indicated in the request's URL. This presents > many security issues; e.g., an attacking intermediary may be inserting > cookies into the original domain's name space, may be observing cookies > or HTTP authentication credentials sent from the user agent, and so on. > However, these risks are not unique to the 511 status code; in other > words, a captive portal that is not using this status code introduces > the same issues. >=20 > Are there other specific threats you're aware of here? >=20 > Regards, >=20 >=20 >=20 > On 25/01/2012, at 10:36 AM, Mark Nottingham wrote: >=20 > > Sorry for the delay in responding; just back from holiday. > > > > > > On 14/01/2012, at 8:26 AM, Stephen Hanna wrote: > > > >> Julian, > >> > >> I'm sure that in your view one sentence is adequate to explain > >> all the security implications of each status code. However, > >> you may want to consider that some readers may not have quite > >> the same deep grasp of the matter that you do. Therefore, > >> I think it would be wise to provide more explanation. Here's an > >> example for section 7.2 on status code 429 (Too Many Requests): > >> > >> Section 7.2 429 Too Many Requests > >> > >> While status code 429 can be helpful in figuring out why a > >> server is not responding to requests, it can also be harmful. > >> When a server is under attack or simply receiving a very > >> large number of requests from a single party, responding > >> to each of these requests with a 429 status code will consume > >> resources that could be better used in other ways. Therefore, > >> a server in such circumstances may choose to send a 429 status > >> code only the first time a client exceeds its limit and > >> ignore subsequent requests from this client until its limit > >> is no longer exceeded. Other approaches may also be employed. > >> > >> As you can see, I described security problems that could occur > >> with this status code and explained how those problems can be > >> avoided or mitigated. While it's true that these problems > >> could occur when a more generic status code is used to handle > >> the case of "too many requests", that does not mean that they > >> are not relevant to this document. On the contrary, the fact > >> that this document is providing more detailed status codes > >> gives us the opportunity and one can argue the obligation to > >> provide more detailed security analysis relevant to these more > >> detailed status codes. > > > > I'm really not sure I agree; the original text is: > > > > Servers are not required to use the 429 status code; when > > limiting resource usage, it may be more appropriate to just drop > > connections, or take other steps. > > > > If someone implementing a server doesn't understand that, I don't > know that using more words really helps; it does, however, make it > harder to find the words in the spec that *will* help. > > > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > > > >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 >=20 From julian.reschke@gmx.de Mon Jan 30 07:10:08 2012 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 8EB0E21F8559 for ; Mon, 30 Jan 2012 07:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.048 X-Spam-Level: X-Spam-Status: No, score=-104.048 tagged_above=-999 required=5 tests=[AWL=-1.449, 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 bq1kE85s8U3s for ; Mon, 30 Jan 2012 07:10:08 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 92D3D21F852D for ; Mon, 30 Jan 2012 07:10:07 -0800 (PST) Received: (qmail invoked by alias); 30 Jan 2012 15:10:06 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 30 Jan 2012 16:10:06 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19Fn5J0hdtFV55ezJqcoEBytfYjWN+XhDLNwycmHK X0hThGd6TQIVZs Message-ID: <4F26B2C4.9010808@gmx.de> Date: Mon, 30 Jan 2012 16:09:56 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Stephen Hanna References: <4F109383.1090505@gmx.de> <0EEB0CDF-6D05-4EA7-9244-CA80C03BD11D@mnot.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "draft-nottingham-http-new-status@tools.ietf.org" , Mark Nottingham , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-nottingham-http-new-status-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: Mon, 30 Jan 2012 15:10:08 -0000 On 2012-01-30 16:05, Stephen Hanna wrote: > Mark, > > I don't want to rehash the discussion that we've already had. > Clearly, you prefer brevity while I would prefer education in > this instance. > > I can live with your text for status codes 428, 429, and 431. For > 511, I don't think it's adequate to just say that big security > issues already exist. You should at least give some suggestions > for how to deal with them. For example, you could point out that > most user agents include some indication of whether the server > has been authenticated. For captive portals, this indication will > generally not be displayed so the user receives some warning > that the response did not come from the requested URL. Are you referring to HTTPS? Best regards, Julian From shanna@juniper.net Mon Jan 30 07:22:42 2012 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 D01C121F8530; Mon, 30 Jan 2012 07:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 4pu9uqRzm8BA; Mon, 30 Jan 2012 07:22:39 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 47DF021F8518; Mon, 30 Jan 2012 07:22:29 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTya1tFTh75tJUxYl12LmBvFtwA+U+FYl@postini.com; Mon, 30 Jan 2012 07:22:39 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 07:22:07 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 30 Jan 2012 10:22:06 -0500 From: Stephen Hanna To: Julian Reschke Date: Mon, 30 Jan 2012 10:22:05 -0500 Thread-Topic: secdir review of draft-nottingham-http-new-status-03 Thread-Index: AczfYUO3oKpAesuPQqeen+7Xx1BFdgAAZu8w Message-ID: References: <4F109383.1090505@gmx.de> <0EEB0CDF-6D05-4EA7-9244-CA80C03BD11D@mnot.net> <4F26B2C4.9010808@gmx.de> In-Reply-To: <4F26B2C4.9010808@gmx.de> 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-EXCLAIMER-MD-CONFIG: fa292fd1-9837-42fa-9560-006eca2aed31 Cc: "draft-nottingham-http-new-status@tools.ietf.org" , Mark Nottingham , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-nottingham-http-new-status-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: Mon, 30 Jan 2012 15:22:42 -0000 Yes -Steve > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, January 30, 2012 10:10 AM > To: Stephen Hanna > Cc: Mark Nottingham; draft-nottingham-http-new-status@tools.ietf.org; > secdir@ietf.org; ietf@ietf.org > Subject: Re: secdir review of draft-nottingham-http-new-status-03 >=20 > On 2012-01-30 16:05, Stephen Hanna wrote: > > Mark, > > > > I don't want to rehash the discussion that we've already had. > > Clearly, you prefer brevity while I would prefer education in > > this instance. > > > > I can live with your text for status codes 428, 429, and 431. For > > 511, I don't think it's adequate to just say that big security > > issues already exist. You should at least give some suggestions > > for how to deal with them. For example, you could point out that > > most user agents include some indication of whether the server > > has been authenticated. For captive portals, this indication will > > generally not be displayed so the user receives some warning > > that the response did not come from the requested URL. >=20 > Are you referring to HTTPS? >=20 > Best regards, Julian From stefan.winter@restena.lu Sun Jan 29 23:46:24 2012 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 8696B21F85E3 for ; Sun, 29 Jan 2012 23:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, 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 2tsR8DBc0kUX for ; Sun, 29 Jan 2012 23:46:23 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 93FC721F85D4 for ; Sun, 29 Jan 2012 23:46:23 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id C2E92106CB; Mon, 30 Jan 2012 08:46:22 +0100 (CET) Received: from [IPv6:2001:a18:1:8:2d20:ef00:5856:5dcc] (unknown [IPv6:2001:a18:1:8:2d20:ef00:5856:5dcc]) by smtprelay.restena.lu (Postfix) with ESMTPS id B5CF110691; Mon, 30 Jan 2012 08:46:22 +0100 (CET) Message-ID: <4F264AC3.4000509@restena.lu> Date: Mon, 30 Jan 2012 08:46:11 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Matt Lepinski References: <4F231731.4080304@bbn.com> In-Reply-To: <4F231731.4080304@bbn.com> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig05E072D75A112A6DEEE5E3D5" X-Virus-Scanned: ClamAV X-Mailman-Approved-At: Mon, 30 Jan 2012 08:01:01 -0800 Cc: draft-ietf-radext-radsec.all@tools.ietf.org, "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-radext-radsec-11 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, 30 Jan 2012 07:46:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig05E072D75A112A6DEEE5E3D5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, thanks for the review! > -- I would strongly advise changing all instances of the phrase > "acceptable Certification Authority" to "trusted Certification > Authority" in order to be consistent with terminology in TLS 1.2 (RFC > 5246). (I found instances of the phrase "acceptable Certification > Authority" on the bottom of page 5 and the top of page 6.) I would also= > change "acceptable certificate" to "trusted certificate" in the > fingerprint bullet on page 6. Thanks, changed the occurences in my working copy (to be -12). > -- In bulleted list number 2 on page 5 (Section 2.3), bullets 4 and 9 > seem to be redundant. That's right, thanks for spotting. I deleted bullet 9. > Furthermore, I find it unusual to have a normative > mandate that compliant implementations MUST NOT negotiate ciphersuites > that do not provide confidentiality protection. (It is very common when= > discussing ciphersuite negotiation to mandate that implementations > support certain ciphersuites offer confidentiality protection, but > saying that a user MUST NOT be able to configure the implementation to > use a NULL-encryption cipher suite is quite unusual.) After reading the= > security considerations section, I believe that the reason you have thi= s > normative requirement is because RADIUS packets include user-passwords > which always require confidentiality protection. However, because the > normative requirement is unusual, I would either add a sentence to 2.3 > explaining the requirement or else put a forward reference to Section 6= > (Security Considerations) for explanation. Forbidding NULL-encryption was indeed a conscious decision, for the reasons you already stated. RADIUS, even if providing poor confidentiality when looked at today, could not be deployed at all without security. An empty shared secret was disallowed as per spec, and every client had to be configured with a unique shared key. That behaviour is equivalent to forbidding NULL-encryption. It would have been a regression in security to allow NULL-encryption to happen with RADIUS/TLS. Given that there is already extensive text in Security Recommendations, I think the easiest way to address your comment is by making the forward reference to that section. In my working copy, the bullet in 2.3 now reads: * Negotiation of a ciphersuite providing for confidentiality as well as integrity protection is REQUIRED. Failure to comply with this requirement can lead to severe security problmes, like user passwords being recoverable by third parties. See Section 6 for details. > -- I found the fingerprint bullet on page 6 to be a bit confusing. My > understanding (after reading it several times) is that you are > specifying a particular ASCII encoding for certificate fingerprints. In= > particular, you are mandating that each of the 20 bytes of the > certificate fingerprint be encoded as a pair of hexadecimal digits and > that the encoding for the fingerprint is the string "sha-1:" followed b= y > the encodings of these 20 bytes separated by colons. I am not sure what= > the clearest way is to get across this meaning. However, the first time= > I read I read the current text it was not clear to me that the document= > was mandating a particular ASCII encoding of certificate fingerprints. > (Question: Is there an interoperability failure if two RADIUS devices d= o > not agree on the encoding of a certificate fingerprint? If the > fingerprint is just something that is configured, calculated and used > locally then it doesn't seem to matter whether one implementation uses > the ASCII string: "sha-1:E1:2D:53 ... 9D" and another implementation > uses the UTF-8 string "SHA-1:e1:2d:53 ... 9d".) That is a very good question. Indeed the encoding of the hash is a local configuration item and has no significance over the wire. There could be situations where a common way of expressing such a configuration item may make sense. I have another example of fingerprint-based identification in mind: SAML metdata. Different implementations have an easier time parsing configuration data if there's a normative encoding to it. I could imagine an organisation to have multiple RADIUS servers from different vendors, relying on the same list of fingerprints for their accepted clients. For such cases, having an agreed syntax might be beneficial. That said, more than this text would be needed to achieve that goal, and I guess it's not worth going into such detail at this stage. I could live with taking away the prescribed syntax, which would significantly shorten the paragraph: Implementations SHOULD allow to configure a list of trusted certificates, identified via certificate fingerprint. Implementations MUST support SHA-1 as the hash algorithm. Please let me know if that's okay for you. (Note that the paragraph might get reshuffled slightly due to a comment in Sam Hartman's security review; 5280 validation might be inadequate if you trust manually configured fingerprints). Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig05E072D75A112A6DEEE5E3D5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8mSs4ACgkQ+jm90f8eFWZf8gCfQqOMQntfHOhBpHW3ZWOwKP79 aM4AnjRTk/NkicnsG1JuAeUdZMqFho/s =MFN2 -----END PGP SIGNATURE----- --------------enig05E072D75A112A6DEEE5E3D5-- From stefan.winter@restena.lu Mon Jan 30 00:16:19 2012 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 F2AD621F860B; Mon, 30 Jan 2012 00:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 i8svGZ6h37oH; Mon, 30 Jan 2012 00:16:17 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 5C53121F85B4; Mon, 30 Jan 2012 00:16:17 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 920F710584; Mon, 30 Jan 2012 09:16:16 +0100 (CET) Received: from [IPv6:2001:a18:1:8:2d20:ef00:5856:5dcc] (unknown [IPv6:2001:a18:1:8:2d20:ef00:5856:5dcc]) by smtprelay.restena.lu (Postfix) with ESMTPS id 8766410581; Mon, 30 Jan 2012 09:16:16 +0100 (CET) Message-ID: <4F2651CC.2030406@restena.lu> Date: Mon, 30 Jan 2012 09:16:12 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA734C262E16C49F78C0C72F7" X-Virus-Scanned: ClamAV X-Mailman-Approved-At: Mon, 30 Jan 2012 08:01:01 -0800 Cc: ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] [radext] Security review of draft-ietf-radext-radsec 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, 30 Jan 2012 08:16:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA734C262E16C49F78C0C72F7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Hi. I'm not the secdir reviewer assigned to this draft, but felt that > this draft needed additional security review, so I decided to perform a= > secdir-like review. >=20 > Overall, I think this is a much-needed specification and believe it is > mostly ready for publication as an experimental RFC. I'd say a bit more= > clarity would be required if we wanted to move this to the standards > track. Thanks for the review! > General issues: >=20 > 1) I'm reasonably sure that RADSEC MUST NOT be used with TLS versions > prior to 1.1. The concern I have is that RADSEC has long-lived TLS > connections under which an attacker could potentially observe ciphertex= t > generated from some plaintext before sending additional plaintext. TLS= > 1.1 includes explicit IVs that prevent various attacks that may happen= > against earlier versions of TLS. > There are implementation work arounds that can also prevent these > attacks. However since all RADSEC implementations are required to > support TLS 1.1, I'd prefer to add a requirement that RADSEC > implementations MUST NOT negotiate TLS versions prior to 1.1 in order t= o > avoid this issue. That's a very useful comment, thanks! TLS 1.1 was marked as minimum-required to prevent these attacks (IIRC). But of course it might happen that even though both sides *support* TLS 1.1, they don't actually negotiate it. I've added corresponding text in my working copy, which will become -12 soon: * Support for TLS v1.1 [RFC4346] or later (e.g. TLS 1.2 [RFC5246] ]) is REQUIRED. To prevent known attacks on TLS versions prior to 1.1, implementations MUST NOT negotiate TLS versions prior to 1.1. > 2) Section 2.3 implies that you need to do cert validation all the time= , > even when you have a certificate fingerprint. I think it could more > clearly indicate that multiple ways of figuring out if you have the > right public key are provided. It's also not clear to me from section > 2.3 whether there is a mandatory-to-implement strategy. You SHOULD > support cert fingerprints. You MUST support cert path validation, but i= s > there a required name form to support? There are discussions of several= > name forms but none seem mandatory. I see no discussion of RFC 6125, > which I would have expected to see here. However, most of this is OK > for an experimental spec. This is the big area where I'd expect to see= > more clarity before this could move to the standards track. Agreed that there's a bit of an option bloat in the cert validation sections, and that there should be more guidance for standards track if the spec gets there. There's one thing I'd like to fix for the current document though. It was not really my intention to enforce e.g. 5280 checks when fingerprint-based operation is in place. My role-model existing deployment of fingerprint-based validation is SAML2 metadata. There, an entity can get identified by its fingerprint alone; regardless of other properties of the certificate (e.g. it doesn't matter whether the certificate is expired, or what CA it comes from - so lang as the configured fingerprint matches the incoming cert's fingerprint, it's fine= ). In the SAML world, that mode of operation seems to be popular; I wouldn't want to preclude that same model of operation here. I'll reformulate that section to make clearer that PKIX-style cert validation is one thing, and that manually configured fingerprints is another (and TLS-PSK is yet another thing, of course). How about this: 3. Peer authentication can be performed in any of the following three operation models: * TLS with X.509 certificates using PKIX trust models (this model is mandatory to implement): + Implementations MUST allow to configure a list of trusted Certification Authorities for incoming connections. + Certificate validation MUST include the verification rules as per [RFC5280]. + Implementations SHOULD indicate their trusted Certification Authorities as per section 7.4.4 (server side) and x.y.z ["Trusted CA Indication"] (client side) of [RFC5246] (see Section 3.2) + Peer validation always includes a check on whether the locally configured expected DNS name or IP address of the server that is contacted matches its presented certificate. DNS names and IP addresses can be contained in the Common Name (CN) or subjectAltName entries. For verification, only one of these entries is to be considered. The following precedence applies: for DNS name validation, subjectAltName:DNS has precedence over CN; for IP address validation, subjectAltName:iPAddr has precedence over CN. + Implementations SHOULD allow to configure a set of acceptable values for subjectAltName:URI. * TLS with X.509 certificates using certificate fingerprints (this model is optional to implement): Implementations SHOULD allow to configure a list of trusted certificates, identified via certificate fingerprint. Implementations MUST support SHA-1 as the hash algorithm. * TLS using TLS-PSK (this model is optional to implement) (note that some changed to this text might occur due to pending DISCUSSes and COMMENTs in the IESG review). Greetings, Stefan Winter >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigA734C262E16C49F78C0C72F7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8mUdAACgkQ+jm90f8eFWbIVQCeOrY9k9ajivBwl1gnMPhfTvcQ FfkAn11WQGdvc6IVg02OSqIbO1/OeoXR =XtZR -----END PGP SIGNATURE----- --------------enigA734C262E16C49F78C0C72F7-- From julian.reschke@gmx.de Mon Jan 30 08:09:07 2012 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 34F5221F864B for ; Mon, 30 Jan 2012 08:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.02 X-Spam-Level: X-Spam-Status: No, score=-104.02 tagged_above=-999 required=5 tests=[AWL=-1.421, 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 klcWm2InN2Me for ; Mon, 30 Jan 2012 08:09:07 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8280221F864E for ; Mon, 30 Jan 2012 08:09:06 -0800 (PST) Received: (qmail invoked by alias); 30 Jan 2012 16:09:04 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 30 Jan 2012 17:09:04 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1//hA9f/9j/IHz89cZ85ZvK5jB+2wNljL5v1oqVOV bwP6H/QfIHuIlp Message-ID: <4F26C097.1040209@gmx.de> Date: Mon, 30 Jan 2012 17:08:55 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Stephen Hanna References: <4F109383.1090505@gmx.de> <0EEB0CDF-6D05-4EA7-9244-CA80C03BD11D@mnot.net> <4F26B2C4.9010808@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "draft-nottingham-http-new-status@tools.ietf.org" , Mark Nottingham , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-nottingham-http-new-status-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: Mon, 30 Jan 2012 16:09:07 -0000 Well, a) this doesn't help for non-HTTPS traffic, anb b) in case of a captive portal intercepting https traffic, we would expect a certificate error, no? Anyway; this is not a security consideration specific to 511, but applies to captive portals in general, no matter whether the new status code is used or not. As such, it *could* be added to Appendix B. Best regards, Julian On 2012-01-30 16:22, Stephen Hanna wrote: > Yes > > -Steve > >> -----Original Message----- >> From: Julian Reschke [mailto:julian.reschke@gmx.de] >> Sent: Monday, January 30, 2012 10:10 AM >> To: Stephen Hanna >> Cc: Mark Nottingham; draft-nottingham-http-new-status@tools.ietf.org; >> secdir@ietf.org; ietf@ietf.org >> Subject: Re: secdir review of draft-nottingham-http-new-status-03 >> >> On 2012-01-30 16:05, Stephen Hanna wrote: >>> Mark, >>> >>> I don't want to rehash the discussion that we've already had. >>> Clearly, you prefer brevity while I would prefer education in >>> this instance. >>> >>> I can live with your text for status codes 428, 429, and 431. For >>> 511, I don't think it's adequate to just say that big security >>> issues already exist. You should at least give some suggestions >>> for how to deal with them. For example, you could point out that >>> most user agents include some indication of whether the server >>> has been authenticated. For captive portals, this indication will >>> generally not be displayed so the user receives some warning >>> that the response did not come from the requested URL. >> >> Are you referring to HTTPS? >> >> Best regards, Julian > From sra@hactrn.net Mon Jan 30 08:26:52 2012 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 2631E11E8072; Mon, 30 Jan 2012 08:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=0.307, 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 4iusCltWW1PU; Mon, 30 Jan 2012 08:26:51 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC8211E8071; Mon, 30 Jan 2012 08:26:51 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 6400128471; Mon, 30 Jan 2012 16:26:48 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 34CA617711; Mon, 30 Jan 2012 11:26:48 -0500 (EST) Date: Mon, 30 Jan 2012 11:26:48 -0500 From: Rob Austein To: Hilarie Orman In-Reply-To: <201201292337.q0TNbiLi012926@sylvester.rhmr.com> References: <201201292337.q0TNbiLi012926@sylvester.rhmr.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20120130162648.34CA617711@thrintun.hactrn.net> Cc: Randy Bush , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of RPKI/Router Protocol, draft-ietf-sidr-rpki-rtr-24 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, 30 Jan 2012 16:26:52 -0000 At Sun, 29 Jan 2012 16:37:44 -0700, Hilarie Orman wrote: > > I've previously reviewed this document and recommended that the > session identifier be more than 16 bits. Because this would change > the header length, those deploying the protocol were loathe to > make the change. In subsequent discussion I recommended that the text > of the document take a strong stance towards using an incremented > counter value between reboots if the cache had persistent storage. > > The language of the draft has not changed to reflect the recommendation. Hi, Hilarie. I'm a little confused. All of the following was added in response to your previous comments: Should a cache erroneously reuse a Session ID so that a router does not realize that the session has changed (old session ID and new session ID have same numeric value), the router may become confused as to the content of the cache. The time it takes the router to discover it is confused will depend on whether the serial numbers are also reused. If the serial numbers in the old and new sessions are different enough, the cache will respond to the router's Serial Query with a Cache Reset, which will solve the problem. If, however, the serial numbers are close, the cache may respond with a Cache Response, which may not be enough to bring the router into sync. In such cases, it's likely but not certain that the router will detect some discrepancy between the state that the cache expects and its own state. For example, the Cache Response may tell the router to drop a record which the router does not hold, or may tell the router to add a record which the router already has. In such cases, a router will detect the error and reset the session. The one case in which the router may stay out of sync is when nothing in the Cache Response contradicts any data currently held by the router. Using persistent storage for the session identifier or a clock- based scheme for generating session identifiers should avoid the risk of session identifier collisions. > The draft also has a confusing statement that > > The Session ID might be a pseudo-random, a monotonically > increasing value if the cache has reliable storage, etc. > > I don't think this makes sense, perhaps there is a typo, and the > qualifiers of "might" and "etc." don't help much. No doubt this could be phrased better. A cache which has neither a usable clock nor persistent storage hasn't got many options, at which point pseudo-random looks like the best of a bad lot. Of course, a cache without a usable clock can't do RPKI validation either, so perhaps this is a silly corner case. Relying on stable storage buys less than you might think here, because the most likely reason why the cache might have to generate a new session ID is that something has happened to its stable storage. The best option I know of is to use clock-based serial numbers (that is, use seconds-since-epoch as the serial number), at which point the session ID for practical purposes becomes a constant. Full disclosure: I never thought the session ID was necessary in the first place, we added it in response to a plea from the router guys. So far the only real use I've found for it is when replaying historical data for test purposes. From mnot@mnot.net Mon Jan 30 14:49:26 2012 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 3B91621F8757; Mon, 30 Jan 2012 14:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.895 X-Spam-Level: X-Spam-Status: No, score=-104.895 tagged_above=-999 required=5 tests=[AWL=-2.296, 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 gY0B9gmAlBDP; Mon, 30 Jan 2012 14:49:25 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id E458221F8748; Mon, 30 Jan 2012 14:49:24 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.240.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CB32A22E258; Mon, 30 Jan 2012 17:49:16 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Tue, 31 Jan 2012 09:49:13 +1100 Content-Transfer-Encoding: 7bit Message-Id: <8BCAB2A2-C9A8-463E-8C8C-E17FC8A2C461@mnot.net> References: <4F109383.1090505@gmx.de> <0EEB0CDF-6D05-4EA7-9244-CA80C03BD11D@mnot.net> To: Stephen Hanna X-Mailer: Apple Mail (2.1251.1) Cc: Julian Reschke , "draft-nottingham-http-new-status@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-nottingham-http-new-status-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: Mon, 30 Jan 2012 22:49:26 -0000 On 31/01/2012, at 2:05 AM, Stephen Hanna wrote: > Mark, > > I don't want to rehash the discussion that we've already had. > Clearly, you prefer brevity while I would prefer education in > this instance. > > I can live with your text for status codes 428, 429, and 431. For > 511, I don't think it's adequate to just say that big security > issues already exist. You should at least give some suggestions > for how to deal with them. For example, you could point out that > most user agents include some indication of whether the server > has been authenticated. For captive portals, this indication will > generally not be displayed so the user receives some warning > that the response did not come from the requested URL. Based upon other feedback, I've already added: Also, note that captive portals using this status code on an SSL or TLS connection (commonly, port 443) will generate a certificate error on the client. to Section 7.4; does that address your concern? Regards, > > Thanks, > > Steve > >> -----Original Message----- >> From: Mark Nottingham [mailto:mnot@mnot.net] >> Sent: Sunday, January 29, 2012 6:50 PM >> To: Stephen Hanna >> Cc: Julian Reschke; draft-nottingham-http-new-status@tools.ietf.org; >> secdir@ietf.org; ietf@ietf.org >> Subject: Re: secdir review of draft-nottingham-http-new-status-03 >> >> I haven't heard any further response. After a reminder from a Security >> AD, I took another look at the spec. >> >> E.g., the current Security Considerations for 428: >> >>> The 428 status code is optional; clients cannot rely upon its use to >> prevent "lost update" conflicts. >> >> Like many of the status codes, that's already a risk inherent in using >> HTTP today; we're effectively just noting that we can't force >> implementations to use the new status code retroactively, so they can't >> use the publication of this document as a magical flag day. >> >> As such, not much more can be said; the only way that people can >> further mitigate the risks of lost updates is to have a private, out- >> of-band agreement to use 429, and I *don't* think that's something we >> should be encouraging. >> >> For 429, I've changed to: >> >>> When a server is under attack or just receiving a very large number >> of requests from a single party, responding to each with a 429 status >> code will consume resources. >>> >>> Therefore, servers are not required to use the 429 status code; when >> limiting resource usage, it may be more appropriate to just drop >> connections, or take other steps. >> >> >> 431 says: >> >>> Servers are not required to use the 431 status code; when under >> attack, it may be more appropriate to just drop connections, or take >> other steps. >> >> >> What else should be said here? This specification is not a treatise on >> dealing with denial-of-service attacks; all that it notes is that >> servers aren't required to use the status code. >> >> Finally, 511 says: >> >>> In common use, a response carrying the 511 status code will not come >> from the origin server indicated in the request's URL. This presents >> many security issues; e.g., an attacking intermediary may be inserting >> cookies into the original domain's name space, may be observing cookies >> or HTTP authentication credentials sent from the user agent, and so on. >> However, these risks are not unique to the 511 status code; in other >> words, a captive portal that is not using this status code introduces >> the same issues. >> >> Are there other specific threats you're aware of here? >> >> Regards, >> >> >> >> On 25/01/2012, at 10:36 AM, Mark Nottingham wrote: >> >>> Sorry for the delay in responding; just back from holiday. >>> >>> >>> On 14/01/2012, at 8:26 AM, Stephen Hanna wrote: >>> >>>> Julian, >>>> >>>> I'm sure that in your view one sentence is adequate to explain >>>> all the security implications of each status code. However, >>>> you may want to consider that some readers may not have quite >>>> the same deep grasp of the matter that you do. Therefore, >>>> I think it would be wise to provide more explanation. Here's an >>>> example for section 7.2 on status code 429 (Too Many Requests): >>>> >>>> Section 7.2 429 Too Many Requests >>>> >>>> While status code 429 can be helpful in figuring out why a >>>> server is not responding to requests, it can also be harmful. >>>> When a server is under attack or simply receiving a very >>>> large number of requests from a single party, responding >>>> to each of these requests with a 429 status code will consume >>>> resources that could be better used in other ways. Therefore, >>>> a server in such circumstances may choose to send a 429 status >>>> code only the first time a client exceeds its limit and >>>> ignore subsequent requests from this client until its limit >>>> is no longer exceeded. Other approaches may also be employed. >>>> >>>> As you can see, I described security problems that could occur >>>> with this status code and explained how those problems can be >>>> avoided or mitigated. While it's true that these problems >>>> could occur when a more generic status code is used to handle >>>> the case of "too many requests", that does not mean that they >>>> are not relevant to this document. On the contrary, the fact >>>> that this document is providing more detailed status codes >>>> gives us the opportunity and one can argue the obligation to >>>> provide more detailed security analysis relevant to these more >>>> detailed status codes. >>> >>> I'm really not sure I agree; the original text is: >>> >>> Servers are not required to use the 429 status code; when >>> limiting resource usage, it may be more appropriate to just drop >>> connections, or take other steps. >>> >>> If someone implementing a server doesn't understand that, I don't >> know that using more words really helps; it does, however, make it >> harder to find the words in the spec that *will* help. >>> >>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >>> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> > -- Mark Nottingham http://www.mnot.net/