From kawamucho@mesh.ad.jp Sun Jan 31 16:30:14 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D1A3A67FC; Sun, 31 Jan 2010 16:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+w4fLjOfoGw; Sun, 31 Jan 2010 16:30:12 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by core3.amsl.com (Postfix) with ESMTP id 27ECB3A69F5; Sun, 31 Jan 2010 16:30:11 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.161]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o110UgLu029103; Mon, 1 Feb 2010 09:30:42 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o110Ug929454; Mon, 1 Feb 2010 09:30:42 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id o110UgQT003265; Mon, 1 Feb 2010 09:30:42 +0900 (JST) Received: from bsac29088.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o110Ufhd015491; Mon, 1 Feb 2010 09:30:41 +0900 Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) by bsac29088.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o110UfNI018349; Mon, 1 Feb 2010 09:30:41 +0900 Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o110UfVx001500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Feb 2010 09:30:41 +0900 Message-ID: <4B6620B0.6020208@mesh.ad.jp> Date: Mon, 01 Feb 2010 09:30:40 +0900 From: Seiichi Kawamura User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tom Yu References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 01 Feb 2010 08:09:17 -0800 Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-text-addr-representation@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secir review of draft-ietf-6man-text-addr-representation-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 00:30:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tom Thanks for your comments. I will add to the Security Considerations a short paragraph to note on this. "This document notes on some examples where IPv6 addresses are compared in textual format. The example on Section 3.2.5 is one that may cause a security risk if used for access control. Comparison of X.509 data should be done as binary. Also, care should be taken in any operational situation where security measures require the handling of an address in text." > Editorial: > > In Section 3.3.2, I believe the claim that IPv4 addresses cannot be > abbreviated is false. Historically, BSD implementations of textual > IPv4 address parsing have accepted a number of variant abbreviated > notations. I think they have generally output canonical dotted-quad > IPv4 addresses though. Ahh. needs a bit or rewording. Thank you. Regards, Seiichi Tom Yu wrote: > This draft indicates that it has no security considerations. I think > that conflicts with Section 3.2.5, which gives an example of > inappropriate (textual) verification of IPv6 addresses in an X.509 > certificate. Although (in my understanding) IPv6 addresses in X.509 > certificates are in binary form and probably should be compared as > such, if the authors feel the need to explicitly call out an example > of inappropriate textual verification of addresses, which could have > security consequences if the address values in question are used for > access control. > > The text in Section 3.3.3 about network abuse reporting would also > appear to have some operational (but probably not protocol) security > consequences, especially if a network operator would need to respond > rapidly to an ongoing attack. > > Editorial: > > In Section 3.3.2, I believe the claim that IPv4 addresses cannot be > abbreviated is false. Historically, BSD implementations of textual > IPv4 address parsing have accepted a number of variant abbreviated > notations. I think they have generally output canonical dotted-quad > IPv4 addresses though. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAktmILAACgkQcrhTYfxyMkKNZACgjA+1rE6ifRKU91jtgLjylI8y AZ0An1sOPHmWo3nBkILac/gKrKjdWuMK =BiFx -----END PGP SIGNATURE----- From CWallace@cygnacom.com Mon Feb 1 09:27:24 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 617E528C18C; Mon, 1 Feb 2010 09:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.415 X-Spam-Level: X-Spam-Status: No, score=-6.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShFQo5rTR34v; Mon, 1 Feb 2010 09:27:23 -0800 (PST) Received: from mail73.messagelabs.com (mail73.messagelabs.com [216.82.249.243]) by core3.amsl.com (Postfix) with SMTP id 6A3A528C104; Mon, 1 Feb 2010 09:27:23 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-11.tower-73.messagelabs.com!1265045277!81605450!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.13] Received: (qmail 29635 invoked from network); 1 Feb 2010 17:27:57 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.13) by server-11.tower-73.messagelabs.com with SMTP; 1 Feb 2010 17:27:57 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 1 Feb 2010 12:27:56 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-ccamp-pc-spc-rsvpte-ext-06 Thread-Index: AcqjY+R6xpIrUHuHS0mn10dyWk2XmQ== From: "Carl Wallace" To: , , , , , , Subject: [secdir] secdir review of draft-ietf-ccamp-pc-spc-rsvpte-ext-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 17:27:24 -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 describes an extension to GMPLS RSVP-TE signaling that enables the transfer of connection ownership between the Management and the Control Planes. Generally, the draft seems to cover relevant possible failures and references another draft (sec-fwk) that provides additional security considerations. My primary comment on the draft is that it was not clear to me how section 5 related to the steps in section 4. Bearing in mind that I am not familiar with RSVP, it seems like there could be one set of procedures that accommodate the two options for retrieving information. As written, some portions of the steps in section 4 appear to be generic, i.e., "Each LSR that receives a Path message with the H bit set...", while other portions of section 4 appear to limit the applicability of the steps to cases where the ERO method is used, i.e., "In this mode of handover, the Path message also carries an ERO...". Section 5 also allows an ERO to be optionally included. =20 From BEW@cisco.com Mon Feb 1 15:33:43 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE36328C163; Mon, 1 Feb 2010 15:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.474 X-Spam-Level: X-Spam-Status: No, score=-9.474 tagged_above=-999 required=5 tests=[AWL=1.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saAV0vySa4s8; Mon, 1 Feb 2010 15:33:42 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C514828C0E2; Mon, 1 Feb 2010 15:33:13 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMLzZkurRN+K/2dsb2JhbADCdJdChEUE X-IronPort-AV: E=Sophos;i="4.49,386,1262563200"; d="scan'208";a="143943526" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2010 23:33:45 +0000 Received: from dhcp-128-107-163-125.cisco.com (dhcp-128-107-163-125.cisco.com [128.107.163.125]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o11NXjnk016592; Mon, 1 Feb 2010 23:33:45 GMT Message-Id: From: Brian Weis To: secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 1 Feb 2010 15:33:43 -0800 X-Mailer: Apple Mail (2.936) Cc: nsis-chairs@tools.ietf.org, draft-ietf-nsis-y1541-qosm@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-nsis-y1541-qosm-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 23:33:43 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines additional NSIS QSPEC objects, fitting into the NSIS QSPEC framework. This document simply adds new objects to that framework. While there are many security considerations to the use of the QSPEC framework, they seem to be covered by the reference to draft- ietf-nsis-qspec-24. The new objects do not inherently add any additional risks other than the ones mentioned. I believe the current Security Considerations text is sufficient. However, I did notice the following nits that the authors should address: 1. Section 3.1 introduces a QSPEC extension (Figure 1) without actually saying which protocol is being extended. This is very confusing for a reader not familiar with NSIS. It needs to name that protocol. (I see that Russ Housley has a current DISCUSS making this same comment.) 2. Section 4.4 refers to "the example given in Section 4.4 of [I- D.ietf-nsis-qspec]". Is that the right section? It discusses extensibility of QSPEC, but there's no example. 3. Reference [Y.1221] has "Y.1541" in its title rather than "Y.1221". 4. Reference [Y.2172] has "Y.1540" in its title rather than "Y.2172". From rbarnes@bbn.com Mon Feb 1 19:40:12 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29933A68D3; Mon, 1 Feb 2010 19:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtqO6a+mzaaE; Mon, 1 Feb 2010 19:40:10 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5E6773A6899; Mon, 1 Feb 2010 19:40:10 -0800 (PST) Received: from [128.89.254.59] (helo=[192.168.1.45]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1Nc9d7-0006LW-9z; Mon, 01 Feb 2010 22:40:46 -0500 Message-Id: <12A2C4F2-7168-48B4-97AC-EC439E89FB1E@bbn.com> From: "Richard L. Barnes" To: secdir , The IESG , The IETF Content-Type: multipart/alternative; boundary=Apple-Mail-1--987984869 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 1 Feb 2010 22:40:23 -0500 X-Mailer: Apple Mail (2.936) Cc: draft-ietf-mpls-ldp-typed-wildcard@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-mpls-ldp-typed-wildcard-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 03:40:12 -0000 --Apple-Mail-1--987984869 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document extends the matching capabilities of the LDP Wildcard FEC element, which matches all Forwarding Equivalence Classes bound to a given label, by adding a second Typed Wildcard FEC element, which matches all FECs of a given type, with optional additional type- specific constraints. Because this change is relatively minor, the security considerations are mostly the same as the base protocol, as noted by the Security Considerations section; however, I would prefer if the authors explained a little better why this is the case. From an editorial perspective, this document is unclear on several important points, especially with regard to the type-specific constraints and how they are defined and managed. I think the document would would benefit from another revision, focused on making the meaning and management of all parameters clear to ensure interoperability. Detailed comments follow. --Richard Specific comments: Section 1, Para "As specified..." With respect to the phrase "relative to an optional constraint": I don't see anything in RFC 5036 that allows for such a constraint. The Wildcard FEC type "is to be applied to all FECs associated with the label within the following label TLV." Section 1, Para "1. The Wildcard FEC Element is untyped" It's not quite accurate to say that the element is untyped; it has type 0x01. Suggest something like "The Wildcard FEC element only allows very coarse selection of FECs by label." Section 1, General Clearly you're really after here isn't to change the Wildcard FEC Element (as the last sentence of the section says), but to have a new element that is a typed Wildcard. It would be clearer and more accurate to say this, e.g., in bullet (2), "There are situations where it would be useful to have a wildcard-like FEC Element, with type constraints, in Label Request messages." Section 2, TLV s/Lenth/Length/ Section 3, Para "The Typed Wildcard FEC Element..." The language about constraints here seems vague. (In what sense is the constraint "optional"?) Suggest the following: " A Typed Wildcard FEC Element specifies a FEC Type and, optionally, a constraint. An element of this type refers to all FECs of the specified FEC Type that meet the constraint. The format of the constraint field depends on the FEC Type specified. " Section 3, Para "Additional FEC Type-specific Information ..." et seq It is unclear whose responsibility it is to define the structure of this field (i.e., who is the "designer"?). Do you mean to say this: "Additional constraints that the FEC must satisfy in order to be selected. The format of the Additional FEC Type-specific Information depends on the FEC type in question. This document defines the format of this field for the Prefix FEC type." The text here and in the document suggest that there should perhaps be a procedure for defining and registering formats for this field. However, you may want to specify that any FEC Type may be specified with a zero-length Additional FEC Type-specific Information field to simply match all FECs of that FEC Type (in order to make it easy to use without a whole lot of new RFCs). Section 4, Para "It is the responsibility..." et seq The authors of this document are the designers of the Typed Wildcard FEC Element Type; who do you mean? It is meaningless to have a MUST that is conditional on "making sense". Section 4, Para "When a FEC TLV..." This constraint made sense for the generic Wildcard type, since that would overwhelm any other FEC Elements, but it's not clear why it's necessary here. Couldn't I have a Label Withdraw message that withdraws all CR-LSP FECs and a single Prefix FEC? Section 6, General You need to specify the semantics of this field. Does it match all FECs that are of the given address family? Also, this doesn't allow any constraints on prefix length or the prefix itself; is that intentional? Section 7, Para "In other words ..." s/can not/MUST NOT/ Section 9, General I would like to see a little more explanation of why this extension to LDP does not create additional security considerations. It seems like at the very least it increases the risk of misconfiguration by adding much more flexible wildcard matching rules; that is, it seems more likely that an LSR operator will accidentally match things he doesn't intend to, or vice versa. --Apple-Mail-1--987984869 Content-Type: text/html; 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 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 extends the matching = capabilities of the LDP Wildcard FEC element, which matches all = Forwarding Equivalence Classes bound to a given label, by adding a = second Typed Wildcard FEC element, which matches all FECs of a given = type, with optional additional type-specific constraints.  Because = this change is relatively minor, the security considerations are mostly = the same as the base protocol, as noted by the Security Considerations = section; however, I would prefer if the authors explained a little = better why this is the case.

=46rom an editorial perspective, this = document is unclear on several important points, especially with regard = to the type-specific constraints and how they are defined and managed. =  I think the document would would benefit from another revision, = focused on making the meaning and management of all parameters clear to = ensure interoperability.

Detailed comments = follow.



Specific = comments:

Section 1, Para "As = specified..." 
With respect to the phrase "relative to an = optional constraint": I don't see anything in RFC 5036 that allows for = such a constraint.  The Wildcard FEC type "is to be applied to all = FECs associated with the label within the following label = TLV."

Section 1, Para "1. The Wildcard FEC = Element is untyped"
It's not quite accurate to say that the = element is untyped; it has type 0x01.  Suggest something like "The = Wildcard FEC element only allows very coarse selection of FECs by = label."

Section 1, General
Clearly = you're really after here isn't to change the Wildcard FEC Element (as = the last sentence of the section says), but to have a new element that = is a typed Wildcard.  It would be clearer and more accurate to say = this, e.g., in bullet (2), "There are situations where it would be = useful to have a wildcard-like FEC Element, with type constraints, in = Label Request messages."

Section 2, = TLV
s/Lenth/Length/

Section 3, Para = "The Typed Wildcard FEC Element..."
The language about = constraints here seems vague.  (In what sense is the constraint = "optional"?)  Suggest the following: 
"
A = Typed Wildcard FEC Element specifies a FEC Type and, optionally, a = constraint.  An element of this type refers to all FECs of the = specified FEC Type that meet the constraint.  The format of the = constraint field depends on the FEC Type = specified.
"

Section 3, Para = "Additional FEC Type-specific Information ..." et seq
It is = unclear whose responsibility it is to define the structure of this field = (i.e., who is the "designer"?).  Do you mean to say this: = "Additional constraints that the FEC must satisfy in order to be = selected. The format of the Additional FEC Type-specific Information = depends on the FEC type in question.  This document defines the = format of this field for the Prefix FEC type."  
The text = here and in the document suggest that there should perhaps be a = procedure for defining and registering formats for this field. =  However, you may want to specify that any FEC Type may be = specified with a zero-length Additional FEC Type-specific Information = field to simply match all FECs of that FEC Type (in order to make it = easy to use without a whole lot of new RFCs). =  

Section 4, Para "It is the = responsibility..." et seq
The authors of this document are the = designers of the Typed Wildcard FEC Element Type; who do you mean? =  It is meaningless to have a MUST that is conditional on "making = sense".  

Section 4, Para "When a FEC = TLV..."
This constraint made sense for the generic Wildcard = type, since that would overwhelm any other FEC Elements, but it's not = clear why it's necessary here.  Couldn't I have a Label Withdraw = message that withdraws all CR-LSP FECs and a single Prefix = FEC?

Section 6, General
You need to = specify the semantics of this field.  Does it match all FECs that = are of the given address family?  Also, this doesn't allow any = constraints on prefix length or the prefix itself; is that = intentional?

Section 7, Para "In other words = ..." 
s/can not/MUST = NOT/

Section 9, General
I would like = to see a little more explanation of why this extension to LDP does not = create additional security considerations.  It seems like at the = very least it increases the risk of misconfiguration by adding much more = flexible wildcard matching rules; that is, it seems more likely that an = LSR operator will accidentally match things he doesn't intend to, or = vice versa. =  









<= div>




=










= --Apple-Mail-1--987984869-- From magnusn@gmail.com Mon Feb 1 20:44:01 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 471063A6A5C; Mon, 1 Feb 2010 20:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmbfWv85NSpl; Mon, 1 Feb 2010 20:44:00 -0800 (PST) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id 63BE83A69F7; Mon, 1 Feb 2010 20:44:00 -0800 (PST) Received: by yxe4 with SMTP id 4so4612726yxe.32 for ; Mon, 01 Feb 2010 20:44:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=rO+lafNyobpQmTq9Maub3nBoJV7qL4dN/tVxF3CnIZc=; b=vdFZZKmqTlUrTqgrffBoG6nbSZSdoc6S7ujMvVD5vahNgEJirRRv6hrXvApViH47m8 van4Vy7SbJ2pWaY8psd3jM4zKkaW7MFcdIr/bdRmpfIEu8OWWGDHv4P0J33VXm00MsUT HofpcXemPF+3l4fZcUTVQ5M6My4OphMZoKSiE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=HOOf5wW/pa2STldVRVJiQxY40gg9bt8KRwcGDJ58HVN3Mk17CXlum+WVUB/vTQ46gd btqsiT1IG9+Y3XeRYeLA0Drg64yQWv/Qa8fu5sgvgWRLxalAEPNs3QxHQMJpvKbEGR3f SGP3t6QjbQAuLHca0aMWfb/KfIVWdy3hU9VEc= MIME-Version: 1.0 Received: by 10.101.54.18 with SMTP id g18mr6896217ank.35.1265085872849; Mon, 01 Feb 2010 20:44:32 -0800 (PST) Date: Mon, 1 Feb 2010 20:44:32 -0800 Message-ID: <2f57b9e61002012044h4de38c83i57ef62873a0cd87f@mail.gmail.com> From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: iesg@ietf.org, secdir@ietf.org, simon@josefsson.org, larry.zhu@microsoft.com, jhutz@cmu.edu Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] Secdir review of draft-josefsson-kerberos5-starttls-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 04:44:01 -0000 This is a follow-up to the review I made back in December on version -07 of this document. Simon has implemented all the changes I proposed (and more!) and I have only one comment on this version, pertaining to the new text in Section 5. I cannot judge the validity of the statement that "Many client environments [presumably the ones that this protocol targets] do not have secure long-term storage, which is required to validate certificates", but assuming this statement is true, then, for clarity, I would suggest changing the 2nd and 3rd paragraph of the section to: " A goal for the protocol described in this memo is that it should be as easy to implement and deploy on clients as support for UDP/TCP. Since many client environments do not have secure long-term storage (and server certificate validation requires some form of long-term storage), the Kerberos V5 STARTTLS protocol does not require clients to verify server certificates. If server certification had been required, then environments with constrained clients such as those mentioned would be forced to disable TLS; this would arguably be worse than TLS without server certificate validation as use of TLS, even without server certificate validation, protects against some attacks that Kerberos V5 over UDP/TCP do not. For example, even without server certificate validation, TLS does protect against passive network sniffing aimed at tracking Kerberos service usage by a given client. Note however that use of TLS without server certificate verification opens up for a range of active attacks such as man-in-the-middle. " Best, -- Magnus From simon@josefsson.org Tue Feb 2 06:08:34 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07FAC3A6821; Tue, 2 Feb 2010 06:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yj0nW4nS9XE6; Tue, 2 Feb 2010 06:08:33 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id CCD883A67BD; Tue, 2 Feb 2010 06:08:32 -0800 (PST) Received: from mocca (c80-216-24-99.bredband.comhem.se [80.216.24.99]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o12E8wYk017531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 2 Feb 2010 15:09:00 +0100 From: Simon Josefsson To: Magnus =?iso-8859-1?Q?Nystr=F6m?= References: <2f57b9e61002012044h4de38c83i57ef62873a0cd87f@mail.gmail.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100202:secdir@ietf.org::lah25kmPjNO+j50z:6rEr X-Hashcash: 1:22:100202:jhutz@cmu.edu::B7h6KKH5HilujY4N:MdH1 X-Hashcash: 1:22:100202:larry.zhu@microsoft.com::7fQZYl0VXASzA3JW:EjyO X-Hashcash: 1:22:100202:iesg@ietf.org::0cxEe2HbLudlR6sR:c0+k X-Hashcash: 1:22:100202:magnusn@gmail.com::PhlBaFgBKMlesPAO:pBrL Date: Tue, 02 Feb 2010 15:08:59 +0100 In-Reply-To: <2f57b9e61002012044h4de38c83i57ef62873a0cd87f@mail.gmail.com> ("Magnus =?iso-8859-1?Q?Nystr=F6m=22's?= message of "Mon, 1 Feb 2010 20:44:32 -0800") Message-ID: <87pr4nk9vo.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.95.3 at yxa-v X-Virus-Status: Clean Cc: larry.zhu@microsoft.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-josefsson-kerberos5-starttls-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 14:08:34 -0000 Thanks Magnus, I like your new text. It appears to me like a non-technical change, so I'll apply this change to my local copy. I'll wait until after the IESG evaluation to submit a new version though, unless someone feels this should be done sooner for some reason? /Simon Magnus Nyström writes: > This is a follow-up to the review I made back in December on version > -07 of this document. > > Simon has implemented all the changes I proposed (and more!) and I > have only one comment on this version, pertaining to the new text in > Section 5. I cannot judge the validity of the statement that "Many > client environments [presumably the ones that this protocol targets] > do not have secure long-term storage, which is required to validate > certificates", but assuming this statement is true, then, for clarity, > I would suggest changing the 2nd and 3rd paragraph of the section to: > > " > A goal for the protocol described in this memo is that it should be as > easy to implement and deploy on clients as support for UDP/TCP. Since > many client environments do not have secure long-term storage (and > server certificate validation requires some form of long-term > storage), the Kerberos V5 STARTTLS protocol does not require clients > to verify server certificates. If server certification had been > required, then environments with constrained clients such as those > mentioned would be forced to disable TLS; this would arguably be worse > than TLS without server certificate validation as use of TLS, even > without server certificate validation, protects against some attacks > that Kerberos V5 over UDP/TCP do not. For example, even without server > certificate validation, TLS does protect against passive network > sniffing aimed at tracking Kerberos service usage by a given client. > > Note however that use of TLS without server certificate verification > opens up for a range of active attacks such as man-in-the-middle. > " > > Best, > -- Magnus From charliek@microsoft.com Mon Feb 1 15:42:10 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E036A28C163; Mon, 1 Feb 2010 15:42:10 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pFMQO3gjPgz; Mon, 1 Feb 2010 15:42:09 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id A41D13A6998; Mon, 1 Feb 2010 15:42:09 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 1 Feb 2010 15:42:45 -0800 Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.238]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi; Mon, 1 Feb 2010 15:42:44 -0800 From: Charlie Kaufman To: "'secdir@ietf.org'" <'secdir@ietf.org'>, "iesg@ietf.org" , "'tony+dkimov@maillennium.att.com'" <'tony+dkimov@maillennium.att.com'>, "'dkim@esiegel.net'" <'dkim@esiegel.net'>, "'phillip@hallambaker.com'" <'phillip@hallambaker.com'>, "'dcrocker@bbiw.net'" <'dcrocker@bbiw.net'>, "'stephen.farrell@cs.tcd.ie'" <'stephen.farrell@cs.tcd.ie'>, "'barryleiba@computer.org'" <'barryleiba@computer.org'>, "'ietf-dkim@mipassoc.org'" <'ietf-dkim@mipassoc.org'> Thread-Topic: Secdir review of draft-ietf-dkim-deployment-11.txt Thread-Index: AcqjmDz5fOySe71WQ46rqfik797MFg== Date: Mon, 1 Feb 2010 23:42:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 02 Feb 2010 06:23:53 -0800 Subject: [secdir] FW: Secdir review of draft-ietf-dkim-deployment-11.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2010 23:42:11 -0000 I am reviewing this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG. These com= ments 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. Feel free to forward to any appropriate forum. This is a re-review, and nothing in the document has changed that would aff= ect my review. All of my comments were in the form of questions for which i= t would be helpful to include answers in the document if the authors knew t= hem. I'm guessing they didn't. Attached is my old review of -10. --Charlie -----Original Message----- From: Charlie Kaufman=20 Sent: Friday, December 18, 2009 10:38 PM To: 'secdir@ietf.org'; iesg@ietf.org; 'tony+dkimov@maillennium.att.com'; 'd= kim@esiegel.net'; 'phillip@hallambaker.com'; 'dcrocker@bbiw.net'; 'stephen.= farrell@cs.tcd.ie'; 'barryleiba@computer.org'; 'ietf-dkim@mipassoc.org' Subject: Secdir review of draft-ietf-dkim-deployment-10.txt I am reviewing this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG. These com= ments 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. Feel free to forward to any appropriate forum. This document covers development, deployment, operations, and migration con= siderations for DKIM (DomainKeys Identified Mail). I would expect such a do= cument to give guidance to implementers and deployers of this technology th= at couldn't be included in the standards track documents because the standa= rds wanted to allow flexibility to implementers and deployers. Such guidanc= e would be particularly useful with DKIM because it's not at all obvious ho= w to use it from the specs and if everyone makes those decisions independen= tly it will limit the usefulness to everyone. Unfortunately, it appears that there hasn't been enough real world experien= ce with DKIM yet to provide a lot of useful guidance. This document seems m= ore of a tutorial on DKIM than guidance. I have no problems with the guidan= ce it gives (other than it mostly duplicates the contents of other specs), = but there is a lot more that it would be good to have (assuming anyone has = answers). Specific suggestions: In Section 7.3, the document mentions problems likely to be introduced if A= uthor Domain Signing Practices (ADSP) is enabled. There are common practice= s in mail processing that will cause email to be dropped if these practices= are followed, and it would be useful to have an explicit list of things kn= own to fail and their prevalence. For example, mailing list expanders (like= the ones that got this message to most of you) are likely to break the DKI= M signatures on messages they pass, causing those messages to subsequently = be dropped by receiving agents if the sender has enabled ADSP. It would be = good to know which of the common mail forwarders have this problem and give= advice to the authors of mail forwarders as to how to avoid problems in th= e future. The most general solution is for the forwarder to change the "Fro= m: " field in the email message to itself and copy the name of the actual s= ender somewhere else. But that causes other problems. Similarly, there have= been in the past many web sites that let you "mail a copy of this document= to a friend" and let you specify the friend's email address and your own. = ADSP would delete such mail sent by users who used such a web site if the s= ite forged the "From:" field. I've noticed that practice is decreasing (Dil= bert.com doesn't do it anymore). Guidance to web sites not to do that and t= o users about how much trouble to expect would be useful. DKIM allows the signer to choose which header fields in the message are sig= ned. Guidance on which fields should be signed and which should not would b= e helpful. When rolling over keys, it's a matter of sender policy how long the old sig= ning key should remain valid for verification after it is no longer used fo= r signing. It would be good to hear a recommendation as to how long that sh= ould be. This would be coupled with guidance to verifiers as to how long af= ter email is received it should be expected to be verifiable. Is it reasona= ble to wait until logs in and reads mail, or must it be checked as part of = placing the mail in the user's inbox? Do we expect to change keys every few= hours or every few years? It probably belonged in the original DKIM spec, but it would be good to kno= w how DKIM is supposed to interact with S/MIME or OpenPGP. It appears DKIM allows the signing of only the first 'n' bytes of a message= in order to give better performance. Advice and rationale for picking an '= n' would be helpful. On page 8, quoting RFC5672 on the issue of interpretation of the d=3D and i= =3D fields, this document says "To the extent that a receiver attempts to i= ntuit any structured semantics for either of the identifiers, this is a heu= ristic function that is outside the scope of DKIM's specification and seman= tics." While true, the purpose of those fields is so that the receiver can = intuit something from them. While DKIM may not specify the semantics to all= ow implementers flexibility, this document should suggest possibilities and= report on existing practice (if any). Another area where guidance would be useful is in what a receiving agent sh= ould display to users concerning DKIM signed messages. Perhaps the answer i= s *nothing*, where DKIM is only used as one of many heuristics for spam fil= tering. But either way, it would be good to know. If we expect users to con= figure some signers as good, advice as to how they are expected to learn wh= at to do would also be helpful. Section 8.4 begins "It is expected that the most common venue for a DKIM im= plementation will be within the infrastructure of an organization's email s= ervice". Section 8.5 begins "The DKIM specification is expected to be used = primarily between Boundary MTAs...". I don't believe these can both be true= . I'm more inclined to believe the latter because within an organization th= e organization can just filter email coming from the Internet and making su= re the return address is not within the organization. --Charlie From dhc@dcrocker.net Mon Feb 1 21:31:22 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DF6428C226; Mon, 1 Feb 2010 21:31:22 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJU4JVoCw4XR; Mon, 1 Feb 2010 21:31:20 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 9352128C222; Mon, 1 Feb 2010 21:31:20 -0800 (PST) Received: from [192.168.1.36] (adsl-68-122-70-87.dsl.pltn13.pacbell.net [68.122.70.87]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o125VpR6016786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Feb 2010 21:31:56 -0800 Message-ID: <4B67B8C5.5060006@dcrocker.net> Date: Mon, 01 Feb 2010 21:31:49 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Charlie Kaufman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/10348/Mon Feb 1 10:43:19 2010 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 01 Feb 2010 21:31:57 -0800 (PST) X-Mailman-Approved-At: Tue, 02 Feb 2010 06:23:53 -0800 Cc: DKIM IETF WG , iesg , secdir@ietf.org Subject: Re: [secdir] FW: Secdir review of draft-ietf-dkim-deployment-11.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 05:31:22 -0000 On 2/1/2010 3:42 PM, Charlie Kaufman wrote: > All of my comments were in the form of questions for which > it would be helpful to include answers in the document if the authors knew > them. I'm guessing they didn't. Charlie, I wrote a response at the time of your review, but it apparently only went to a small circle of folk, which was not intentional. (The usual disclaimer applies: the enclosed represents my personal opinion, only.) Here's what I sent: -------- Original Message -------- Subject: Re: Secdir review of draft-ietf-dkim-deployment-10.txt Date: Sat, 19 Dec 2009 12:33:56 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking To: Pasi Eronen CC: tony+dkimov@maillennium.att.com , dkim@esiegel.net , phillip@hallambaker.com , stephen.farrell@cs.tcd.ie , barryleiba@computer.org Responses to the additional review -- as before, this is on my own initiative; the other authors might have differing assessments. Overall comment: The issues raised are all reasonable, but they seek more detail that is currently available. The intent for this initial version of the Deployment document was to provide basic information about deployment, and revise the document as more field experience is gained. As such, efforts to provide increasingly broad and fine-grained information is not currently likely to be productive. This is the sort of exercise in which the classic "perfect is the enemy of good" concern applies. I did not identify any changes to the draft that are needed as a result of this review. d/ On 12/18/2009 10:38 PM, Charlie Kaufman wrote: > I have no problems with the guidance it gives ... > Specific suggestions: > > In Section 7.3, the document mentions problems likely to be introduced if > Author Domain Signing Practices (ADSP) is enabled. There are common practices > in mail processing that will cause email to be dropped if these practices are > followed, and it would be useful to have an explicit list of things known to > fail and their prevalence. 1. The document points to discussion in the ADSP specification. 2. ADSP remains controversial and the decision for the Deployment document was to make generic reference to ADSP, but not to get bogged down in the controversy. 3. The existing Deployment draft warns a potential ADSP user to be careful. For now, that is the best and most complete advice to give. > The > most general solution is for the forwarder to change the "From: " field in Changing the From: field is a particularly onerous suggestion. It modifies purported authorship and it has no empirical basis for claiming improved functional utility, safety or human usability. It is a reasonable theoretical suggestion but almost certainly a counter-productive one to implement. It does, however, nicely demonstrate why ADSP is controversial. But, again, the Deployment document sought to give a basic acknowledgment that ADSP exists, but to refrain from engaging in its controversy. > the email message to itself and copy the name of the actual sender somewhere > else. But that causes other problems. Similarly, there have been in the past > many web sites that let you "mail a copy of this document to a friend" and > let you specify the friend's email address and your own. ADSP would delete > such mail sent by users who used such a web site if the site forged the > "From:" field. Yes it would. > DKIM allows the signer to choose which header fields in the message are > signed. Guidance on which fields should be signed and which should not would > be helpful. Yes it would. Section 5.4 of RFC 5617 specifies this, and there is no additional guidance available. The community has not had discussion or formulated consensus about it. So the Deployment document cannot currently add to that discussion. My personal view is that the choice matters far less than is often believed, because data integrity -- nevermind data validity -- are not goals of DKIM. Rather, the hashing is meant to validate the d= identifier. Any data integrity benefits are strictly secondary. Hence the choice of header fields to cover is probably quite flexible. > When rolling over keys, it's a matter of sender policy how long the old > signing key should remain valid for verification after it is no longer used > for signing. It would be good to hear a recommendation as to how long that > should be. While that seems a reasonable idea, it would almost certainly be counterproductive to include now, since real recommendations need to come from some operational consensus. Since DKIM's use of signing technology carries a very different semantic than previous uses, and since it applies to transport rather than longer-term, any current recommendation for key management rollover would be theoretical rather than empirical. The decision was to avoid having the document engage in such abstract exercises. > This would be coupled with guidance to verifiers as to how long > after email is received it should be expected to be verifiable. Either the public key is in the DNS or it isn't. This is a transport-related service. There is no expectation that keys will be valid for very long. > Is it > reasonable to wait until logs in and reads mail, or must it be checked as > part of placing the mail in the user's inbox? Do we expect to change keys > every few hours or every few years? Again, this is a transport-related service, not one intended to be relevant to end-users. > It probably belonged in the original DKIM spec, but it would be good to know > how DKIM is supposed to interact with S/MIME or OpenPGP. Since DKIM has nothing to do with S/MIME or OpenPGP there is no "interaction". However, the DKIM Overview (RFC 5585) contains some brief reference to these technologies. > It appears DKIM allows the signing of only the first 'n' bytes of a message > in order to give better performance. Advice and rationale for picking an 'n' > would be helpful. l= is not for "better performance" but for robustness in the face of very specific body changes by intermediaries -- adding text at the end. l= is another controversial topic for which there is no additional, empirical information available. Again, the decision was to have the Deployment refrain from engaging in controversy. > On page 8, quoting RFC5672 on the issue of interpretation of the d= and i= > fields, this document says "To the extent that a receiver attempts to intuit > any structured semantics for either of the identifiers, this is a heuristic > function that is outside the scope of DKIM's specification and semantics." > While true, the purpose of those fields is so that the receiver can intuit > something from them. Not really. It is so that the receiver can take those exact and complete strings and use them for lookups into information bases. The d= is for use in key retrieval and reputation lookup. The i= is for an unspecified range of uses. In any event, the cited text seeks to warn the receiver off from parsing the details of either string, or at least to help the receiver to understand that any attempt to parse the strings moves the receiver beyond the scope of the DKIM specification. > While DKIM may not specify the semantics to allow > implementers flexibility, this document should suggest possibilities and > report on existing practice (if any). No it shouldn't. That moves the document into heuristics that are beyond the scope of the DKIM specification. > Another area where guidance would be useful is in what a receiving agent > should display to users concerning DKIM signed messages. Perhaps the answer > is *nothing*, where DKIM is only used as one of many heuristics for spam > filtering. But either way, it would be good to know. If we expect users to > configure some signers as good, advice as to how they are expected to learn > what to do would also be helpful. "Good to know" is the problem. There is no empirical basis for "knowing" what to recommend. Basically, DKIM is not for end-user display. The associated identifier is for processing by an assessment (and filtering) engine. Appendix D of the DKIM core specification contains some pro forma discussion of the topic. The Deployment document seeks not to replicate discussion contained elsewhere. > Section 8.4 begins "It is expected that the most common venue for a DKIM > implementation will be within the infrastructure of an organization's email > service". Section 8.5 begins "The DKIM specification is expected to be used > primarily between Boundary MTAs...". I don't believe these can both be true. Boundary MTAs are part of an organization's email service infrastructure. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From aland@deployingradius.com Tue Feb 2 06:36:54 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B357728C0D9; Tue, 2 Feb 2010 06:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXyDrZixn2Xj; Tue, 2 Feb 2010 06:36:54 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id F05D228C1BE; Tue, 2 Feb 2010 06:25:30 -0800 (PST) Message-ID: <4B683600.8010403@deployingradius.com> Date: Tue, 02 Feb 2010 15:26:08 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: secdir@ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-capwap-802dot11-mib-06@tools.ietf.org, IESG IESG Subject: [secdir] Secdir review of draft-ietf-capwap-802dot11-mib-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 14:36:54 -0000 I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document provides a MIB for CAPWAP. Section 3 defines terminology, but appears to have a number of statements about requirements. While not security related, it would be good to move requirement statements out of the terminology section. Section 5.1 contains suggestions for binding WLAN profiles to the access controller (AC). It also contains suggestions for how WLAN IDs can be assigned. These suggestions appear to be related to operation of the AC, and not directly affecting the MIB. Section 7 is a little unclear, but there appears to be no security issues there. Section 8 has some English issues: Suppose the WTP's base MAC address is '00:01:01:01:01:00'. Creates a WTP profile for it ... It's not clear what the second sentence means. There are a few sentences like " The operator could query ...". This should perhaps be " The operator can query ..." The Security Considerations section seems to have adequate text about SNMP security. The IANA considerations section needs a statement to update the MIB, which contains a reference to "RFC xxx" Alan DeKok. From william.polk@nist.gov Tue Feb 2 06:47:45 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60C93A6919; Tue, 2 Feb 2010 06:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51reNsXzOg5a; Tue, 2 Feb 2010 06:47:44 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 90D0C3A6864; Tue, 2 Feb 2010 06:47:44 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o12Elx0l014339; Tue, 2 Feb 2010 09:47:59 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Tue, 2 Feb 2010 09:47:59 -0500 From: "Polk, William T." To: Simon Josefsson , =?iso-8859-1?Q?Magnus_Nystr=F6m?= Date: Tue, 2 Feb 2010 09:49:31 -0500 Thread-Topic: Secdir review of draft-josefsson-kerberos5-starttls-08 Thread-Index: AcqkEXQoYHhVnit/Sz+qBsHxsbQyOgABXkW4 Message-ID: In-Reply-To: <87pr4nk9vo.fsf@mocca.josefsson.org> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C78DA5AB12029timpolknistgov_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Cc: "iesg@ietf.org" , "secdir@ietf.org" , "larry.zhu@microsoft.com" Subject: Re: [secdir] Secdir review of draft-josefsson-kerberos5-starttls-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 14:47:46 -0000 --_000_C78DA5AB12029timpolknistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Simon, I have added this as an RFC Editor note. If no other changes are required,= that will let us approve the document without waiting for a new draft. Thanks, Tim On 2/2/10 9:08 AM, "Simon Josefsson" wrote: Thanks Magnus, I like your new text. It appears to me like a non-technical change, so I'll apply this change to my local copy. I'll wait until after the IESG evaluation to submit a new version though, unless someone feels this should be done sooner for some reason? /Simon Magnus Nystr=F6m writes: > This is a follow-up to the review I made back in December on version > -07 of this document. > > Simon has implemented all the changes I proposed (and more!) and I > have only one comment on this version, pertaining to the new text in > Section 5. I cannot judge the validity of the statement that "Many > client environments [presumably the ones that this protocol targets] > do not have secure long-term storage, which is required to validate > certificates", but assuming this statement is true, then, for clarity, > I would suggest changing the 2nd and 3rd paragraph of the section to: > > " > A goal for the protocol described in this memo is that it should be as > easy to implement and deploy on clients as support for UDP/TCP. Since > many client environments do not have secure long-term storage (and > server certificate validation requires some form of long-term > storage), the Kerberos V5 STARTTLS protocol does not require clients > to verify server certificates. If server certification had been > required, then environments with constrained clients such as those > mentioned would be forced to disable TLS; this would arguably be worse > than TLS without server certificate validation as use of TLS, even > without server certificate validation, protects against some attacks > that Kerberos V5 over UDP/TCP do not. For example, even without server > certificate validation, TLS does protect against passive network > sniffing aimed at tracking Kerberos service usage by a given client. > > Note however that use of TLS without server certificate verification > opens up for a range of active attacks such as man-in-the-middle. > " > > Best, > -- Magnus --_000_C78DA5AB12029timpolknistgov_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Secdir review of draft-josefsson-kerberos5-starttls-08 Simon,

I have added this as an RFC Editor note.  If no other changes are requ= ired, that will let us approve the document without waiting for a new draft= .

Thanks,

Tim


On 2/2/10 9:08 AM, "Simon Josefsson" <simon@josefsson.org> wrote:

Thanks Magnus, I like your new text.  = It appears to me like a
non-technical change, so I'll apply this change to my local copy.  I'l= l
wait until after the IESG evaluation to submit a new version though,
unless someone feels this should be done sooner for some reason?

/Simon

Magnus Nyström <magnusn@gmail.com= > writes:

> This is a follow-up to the review I made back in December on version > -07 of this document.
>
> Simon has implemented all the changes I proposed (and more!) and I
> have only one comment on this version, pertaining to the new text in > Section 5. I cannot judge the validity of the statement that "Man= y
> client environments [presumably the ones that this protocol targets] > do not have secure long-term storage, which is required to validate > certificates", but assuming this statement is true, then, for cla= rity,
> I would suggest changing the 2nd and 3rd paragraph of the section to:<= BR> >
> "
> A goal for the protocol described in this memo is that it should be as=
> easy to implement and deploy on clients as support for UDP/TCP. Since<= BR> > many client environments do not have secure long-term storage (and
> server certificate validation requires some form of long-term
> storage), the Kerberos V5 STARTTLS protocol does not require clients > to verify server certificates. If server certification had been
> required, then environments with constrained clients such as those
> mentioned would be forced to disable TLS; this would arguably be worse=
> than TLS without server certificate validation as use of TLS, even
> without server certificate validation, protects against some attacks > that Kerberos V5 over UDP/TCP do not. For example, even without server=
> certificate validation, TLS does protect against passive network
> sniffing aimed at tracking Kerberos service usage by a given client. >
> Note however that use of TLS without server certificate verification > opens up for a range of active attacks such as man-in-the-middle.
> "
>
> Best,
> -- Magnus

--_000_C78DA5AB12029timpolknistgov_-- From simon@josefsson.org Tue Feb 2 06:55:17 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55DE03A6955; Tue, 2 Feb 2010 06:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHn7jdH2tPpJ; Tue, 2 Feb 2010 06:55:16 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 0F42F3A6951; Tue, 2 Feb 2010 06:55:15 -0800 (PST) Received: from mocca (c80-216-24-99.bredband.comhem.se [80.216.24.99]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o12EthBF019467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 2 Feb 2010 15:55:45 +0100 From: Simon Josefsson To: "Polk\, William T." References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:100202:jhutz@cmu.edu::VKFkCNCA9vxKL/lS:1AAI X-Hashcash: 1:22:100202:magnusn@gmail.com::Uzj9px5VL3m/5WhG:2O5V X-Hashcash: 1:22:100202:william.polk@nist.gov::bnzmjRT6UW4srQVQ:ABdB X-Hashcash: 1:22:100202:iesg@ietf.org::aHV4Lgblx/X1F5GV:UAvG X-Hashcash: 1:22:100202:larry.zhu@microsoft.com::bMOt65PYcPnGLULG:HMwS X-Hashcash: 1:22:100202:secdir@ietf.org::dZmHOPb/p06E8Z5H:a6ED Date: Tue, 02 Feb 2010 15:55:43 +0100 In-Reply-To: (William T. Polk's message of "Tue, 2 Feb 2010 09:49:31 -0500") Message-ID: <87iqafit5c.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.95.3 at yxa-v X-Virus-Status: Clean Cc: "iesg@ietf.org" , "larry.zhu@microsoft.com" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-josefsson-kerberos5-starttls-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 14:55:17 -0000 Great, thanks Tim! /Simon "Polk, William T." writes: > Simon, > > I have added this as an RFC Editor note. If no other changes are required, that will let us approve the document without waiting for a new draft. > > Thanks, > > Tim > > > On 2/2/10 9:08 AM, "Simon Josefsson" wrote: > > Thanks Magnus, I like your new text. It appears to me like a > non-technical change, so I'll apply this change to my local copy. I'll > wait until after the IESG evaluation to submit a new version though, > unless someone feels this should be done sooner for some reason? > > /Simon > > Magnus Nyström writes: > >> This is a follow-up to the review I made back in December on version >> -07 of this document. >> >> Simon has implemented all the changes I proposed (and more!) and I >> have only one comment on this version, pertaining to the new text in >> Section 5. I cannot judge the validity of the statement that "Many >> client environments [presumably the ones that this protocol targets] >> do not have secure long-term storage, which is required to validate >> certificates", but assuming this statement is true, then, for clarity, >> I would suggest changing the 2nd and 3rd paragraph of the section to: >> >> " >> A goal for the protocol described in this memo is that it should be as >> easy to implement and deploy on clients as support for UDP/TCP. Since >> many client environments do not have secure long-term storage (and >> server certificate validation requires some form of long-term >> storage), the Kerberos V5 STARTTLS protocol does not require clients >> to verify server certificates. If server certification had been >> required, then environments with constrained clients such as those >> mentioned would be forced to disable TLS; this would arguably be worse >> than TLS without server certificate validation as use of TLS, even >> without server certificate validation, protects against some attacks >> that Kerberos V5 over UDP/TCP do not. For example, even without server >> certificate validation, TLS does protect against passive network >> sniffing aimed at tracking Kerberos service usage by a given client. >> >> Note however that use of TLS without server certificate verification >> opens up for a range of active attacks such as man-in-the-middle. >> " >> >> Best, >> -- Magnus From weiler@watson.org Tue Feb 2 06:56:13 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB533A6951; Tue, 2 Feb 2010 06:56:13 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCZnzxWpWgCY; Tue, 2 Feb 2010 06:56:12 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 9ECE13A6963; Tue, 2 Feb 2010 06:56:12 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o12EuoPd085943; Tue, 2 Feb 2010 09:56:50 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o12EuouO085940; Tue, 2 Feb 2010 09:56:50 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 2 Feb 2010 09:56:50 -0500 (EST) From: Samuel Weiler To: secdir@ietf.org, iesg@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]); Tue, 02 Feb 2010 09:56:50 -0500 (EST) Cc: draft-ietf-sipcore-199@tools.ietf.org, sipcore-chairs@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-sipcore-199-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 14:56:13 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This defines an intermediate "we're done" response, allowing parties to tear down some state, while still requiring a final response. The obvious risk (forging these, just like forging a TCP reset) is documented. Even though the point of the 199 response is to allow early resource release, I notice that some state is still being maintained for these sessions. It might be worth explicitly reminding readers of when they can timeout (is there a timeout specified somewhere?). I'm also a little worried about the implications of one party or another trying to continue the dialog, perhaps maliciously, after sending or receiving one of these. What if one of these were used to disable a monitoring or billing system, but the parties continued to use the open session? (Compare to sending a weak C-tone on a wiretapped PSTN line.) Editorial: Please expand the acronyms in the abstract. (The id-nits checklist says the abstract "Should be meaningful to someone not versed in the technology; most abbreviations must be expanded on first use.") -- Sam From d3e3e3@gmail.com Tue Feb 2 17:52:09 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1BC28C143; Tue, 2 Feb 2010 17:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.072 X-Spam-Level: X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAzjC7HOkSG9; Tue, 2 Feb 2010 17:52:08 -0800 (PST) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 39C7C28C140; Tue, 2 Feb 2010 17:52:08 -0800 (PST) Received: by bwz19 with SMTP id 19so690165bwz.28 for ; Tue, 02 Feb 2010 17:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=+HxG3h4CW6M15ul6Pt58/QHo0KrIFcsXgqjSbCCjaqY=; b=sncoBO4BlZsc/PqntpSbsjq+bOecJ30If6qywF2Wl5c/+gzMZNAnOXiU2nSwz5THhb 2k9gkHYGTZJ9sTJByUrxVbfhfqoD4bzvaxgX1bA4IHBbHTI/yrwcGLWZgYdZMEpBop9Y OWqrxf+swKvPQLmjFMPC1owYLuFyiGkIZVpgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=mrvRQqn3gsZ85pYA9vvM2CQHJoUx0zkLTx97UBwJ9uOyDgtCIRTVqcZM2Bj4iBM6iv UNxocwg4p7ekp6nFjdjvzv4yGH8HuLa+nHR7NJ1T1UdSN+t/ERTV/c0reDUBW3wg6Y7V WWbQFytVgkVFUv5kjiJNicFNwfLxwCt2XO7rI= MIME-Version: 1.0 Received: by 10.204.135.153 with SMTP id n25mr5050319bkt.156.1265161965290; Tue, 02 Feb 2010 17:52:45 -0800 (PST) Date: Tue, 2 Feb 2010 20:52:45 -0500 Message-ID: <1028365c1002021752k1f3ac62s80beba9c2d1d7588@mail.gmail.com> From: Donald Eastlake To: The IESG , Spencer Dawkins , Eric Burger Content-Type: multipart/alternative; boundary=0015174c192c8643c2047ea879c0 Cc: tim.melanchuk@gmail.com, smcg.stds01@mcglashan.org, chris@ns-technologies.com, secdir@ietf.org Subject: [secdir] draft-ietf-mediactrl-ivr-control-package-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2010 01:52:09 -0000 --0015174c192c8643c2047ea879c0 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. (I previously reviewed version -03.) These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a lengthy draft specifying an XML Media Control Channel Framework Package for Interactive Voice Response (IVR) dialog interaction. The Security Considerations Section is commensurately long, listing threats and areas where security MUST be "addressed". The threats described seem reasonably comprehensive. For protection against these threats and the required addressing of security, the Security Considerations Section of this draft references the Security Consideration and other Sections of draft-ietf-mediactrl-sip-control-framework-11 (Media Control Channel Framework) as well as the Security Considerations of RFC 3023 (XML Media Types). These other document seem to provide adequate measures to protect against the threats mentioned in the document being reviewed. Overall, I believe the Security Consideration section is satisfactory and an improved from the -03 draft I previously reviewed. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com --0015174c192c8643c2047ea879c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed = this document as part of the security directorate's=A0ongoing effort to= review all IETF documents being processed by the=A0IESG. =A0(I previously = reviewed version -03.) These comments were written primarily for the benefi= t of the=A0security area directors. =A0Document editors and WG chairs shoul= d treat=A0these comments just like any other last call comments.

This is a lengthy draft specifying an XML Media Control Channel=A0Framework= Package for Interactive Voice Response (IVR) dialog=A0interaction. The Sec= urity Considerations Section is commensurately=A0long, listing threats and = areas where security MUST be "addressed". The threats described s= eem reasonably=A0comprehensive.=A0For protection against these threats and = the required addressing of security, the Security Considerations=A0Section = of this draft references the Security Consideration and other=A0Sections of= draft-ietf-mediactrl-sip-control-framework-11 (Media=A0Control Channel Fra= mework) as well as the Security Considerations of=A0RFC 3023 (XML Media Typ= es).

These other document seem to provide=A0adequate measure= s to protect against the threats mentioned in the=A0document being reviewed= .=A0Overall, I believe the Security Consideration section is satisfactory a= nd an improved from the -03 draft I previously reviewed.

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 +1-508-634-2066 (home)
=A0155 Beaver Street
=A0Milford, MA 01757 USA
=A0d3e3e3@gmail.com

--0015174c192c8643c2047ea879c0-- From adam@nostrum.com Tue Feb 2 09:02:14 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6DD3A6979; Tue, 2 Feb 2010 09:02:14 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19RpSoBjm73E; Tue, 2 Feb 2010 09:02:13 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A99F43A6958; Tue, 2 Feb 2010 09:02:12 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o12H2eVb033674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Feb 2010 11:02:40 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B685AB0.9060107@nostrum.com> Date: Tue, 02 Feb 2010 11:02:40 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Tina TSOU , Alexey Melnikov , iesg@ietf.org References: <90041D6C-0B96-482D-9CCC-C552481A187F@huawei.com> In-Reply-To: <90041D6C-0B96-482D-9CCC-C552481A187F@huawei.com> Content-Type: multipart/alternative; boundary="------------020405080302080203000001" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Wed, 03 Feb 2010 08:24:19 -0800 Cc: secdir@ietf.org Subject: Re: [secdir] secdir review of draft-roach-sip-http-subscribe-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2010 17:02:14 -0000 This is a multi-part message in MIME format. --------------020405080302080203000001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/22/64 13:59, Jul 22, Tina TSOU wrote: > 1) It is possible that the message/http NOTIFY message bodies may > contain sensitive information. This is related to the statement at the > end of the existing Security Considerations text that care should be > taken to apply the same controls over access to entity information to > SIP/SIPS subscribers as to users using other protocols. Additional > text in the Security Considerations section should point out that if > the NOTIFY requests may return sensitive information, that information > should be protected in transit by, for example, requiring that the > subscription use SIPS rather than SIP. > > 2) Along with this, some reference to RFC 5630 might be valuable, both > to indicate the limitations of SIPS and to indicate how it should be > implemented. Thanks for catching this. I propose adding the following text to the Security section as a final paragraph: Similarly, if the HTTP resource is encrypted or integrity protected in transit -- for example, by using HTTP over TLS [12] -- then the SIP means of subscribing to the HTTP resource MUST also have appropriate encryption or integrity protection applied. Examples of mechanisms for providing such protection include the use of the SIPS URI scheme [17], and the use of S/MIME bodies [13]. With the cited references: [12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [13] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [17] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009. /a --------------020405080302080203000001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/22/64 13:59, Jul 22, Tina TSOU wrote:
1) It is possible that the message/http NOTIFY message bodies may contain sensitive information. This is related to the statement at the end of the existing Security Considerations text that care should be taken to apply the same controls over access to entity information to SIP/SIPS subscribers as to users using other protocols. Additional text in the Security Considerations section should point out that if the NOTIFY requests may return sensitive information, that information should be protected in transit by, for example, requiring that the subscription use SIPS rather than SIP.

2) Along with this, some reference to RFC 5630 might be valuable, both to indicate the limitations of SIPS and to indicate how it should be implemented.

Thanks for catching this. I propose adding the following text to the Security section as a final paragraph:

   Similarly, if the HTTP resource is encrypted or integrity protected
   in transit -- for example, by using HTTP over TLS [12] -- then the
   SIP means of subscribing to the HTTP resource MUST also have
   appropriate encryption or integrity protection applied.  Examples of
   mechanisms for providing such protection include the use of the SIPS
   URI scheme [17], and the use of S/MIME bodies [13].

With the cited references:

   [12]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [13]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
         (S/MIME) Version 3.1 Message Specification", RFC 3851,
         July 2004.

   [17]  Audet, F., "The Use of the SIPS URI Scheme in the Session
         Initiation Protocol (SIP)", RFC 5630, October 2009.
/a
--------------020405080302080203000001-- From weiler+secdir@watson.org Thu Feb 4 19:47:58 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35CC3A6EA6 for ; Thu, 4 Feb 2010 19:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xIByoK4x+lk for ; Thu, 4 Feb 2010 19:47:57 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id B367B3A6EA2 for ; Thu, 4 Feb 2010 19:47:57 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o153mi9G051477 for ; Thu, 4 Feb 2010 22:48:45 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o153miiB051474 for ; Thu, 4 Feb 2010 22:48:44 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 4 Feb 2010 22:48:44 -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, 04 Feb 2010 22:48:45 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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, 05 Feb 2010 03:47:58 -0000 Dan Harkins is next in the rotation. Three of today's new assignments are already scheduled for the February 18th telechat. Documents on the telechat agenda typically have a last call end date before the date shown below; reviews by the end of last call are typically more appreciated by the doc editors. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2010-02-18 Reviewer Deadline Draft Stephen Farrell T 2010-02-16 draft-ietf-dhc-dhcpv4-vendor-message-01 Tobias Gondrom T 2010-02-16 draft-ietf-dhc-dhcpv6-vendor-message-01 Phillip Hallam-Baker T 2010-02-16 draft-ietf-tcpm-icmp-attacks-10 Hannes Tschofenig T 2010-02-16 draft-allbery-afs-srv-records-03 Nico Williams T 2010-02-16 draft-gould-rfc4310bis-03 Larry Zhu T 2010-02-16 draft-ietf-pce-p2mp-req-05 Last calls and special requests: Reviewer Deadline Draft Derek Atkins 2010-02-05 draft-ietf-ccamp-gmpls-dcsc-channel-ext-03 Rob Austein 2009-11-28 draft-ietf-pkix-attr-cert-mime-type-02 Rob Austein 2010-02-11 draft-ietf-ipsecme-esp-null-heuristics-05 Pat Cain 2010-02-08 draft-ietf-mpls-tp-nm-framework-04 Dave Cridland 2010-02-12 draft-ietf-rmt-flute-revised-10 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Alan DeKok 2010-02-19 draft-westerlund-mmusic-3gpp-sdp-rtsp-07 Shawn Emery R2010-02-11 draft-ietf-mediactrl-mixer-control-package-10 Shawn Emery 2010-02-16 draft-ietf-ccamp-gmpls-mln-extensions-11 Steve Hanna 2010-03-04 draft-rosen-urn-nena-01 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Love Hornquist-Astrand 2009-10-13 draft-ietf-idnabis-mappings-05 David McGrew None draft-ietf-dnsext-dnssec-gost-06 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Sandy Murphy R2009-11-18 draft-ietf-mpls-mpls-and-gmpls-security-framework-07 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Chris Newman 2010-01-07 draft-ietf-krb-wg-preauth-framework-15 Joe Salowey 2009-02-08 draft-ietf-geopriv-lis-discovery-13 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Brian Weis R2010-02-11 draft-ietf-mediactrl-sip-control-framework-11 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2009-05-09 draft-ietf-ecrit-location-hiding-req-02 Glen Zorn 2010-01-28 draft-ietf-pkix-tamp-05 From stephen.farrell@cs.tcd.ie Fri Feb 5 03:26:32 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFDA83A6D68; Fri, 5 Feb 2010 03:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rWxDt1mSPk2; Fri, 5 Feb 2010 03:26:32 -0800 (PST) Received: from TX2EHSOBE007.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by core3.amsl.com (Postfix) with ESMTP id 061353A6BDB; Fri, 5 Feb 2010 03:26:31 -0800 (PST) Received: from mail121-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 8.1.340.0; Fri, 5 Feb 2010 11:27:21 +0000 Received: from mail121-tx2 (localhost [127.0.0.1]) by mail121-tx2-R.bigfish.com (Postfix) with ESMTP id B5F5E4681F6; Fri, 5 Feb 2010 11:27:21 +0000 (UTC) X-SpamScore: 0 X-BigFish: VPS0(zzzz1202hzzz2dh6bh87h62h) X-Spam-TCS-SCL: 1:0 X-FB-DOMAIN-IP-MATCH: fail Received: from mail121-tx2 (localhost.localdomain [127.0.0.1]) by mail121-tx2 (MessageSwitch) id 1265369241291746_21862; Fri, 5 Feb 2010 11:27:21 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.242]) by mail121-tx2.bigfish.com (Postfix) with ESMTP id 4377F1090050; Fri, 5 Feb 2010 11:27:21 +0000 (UTC) Received: from imx2.tcd.ie (134.226.1.156) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server id 14.0.482.39; Fri, 5 Feb 2010 11:27:19 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id 22A4E68008; Fri, 5 Feb 2010 11:27:19 +0000 (GMT) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A03BEE1E211; Fri, 05 Feb 2010 11:27:19 +0000 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 0F42268008; Fri, 5 Feb 2010 11:27:19 +0000 (GMT) Message-ID: <4B6C0099.3080202@cs.tcd.ie> Date: Fri, 5 Feb 2010 11:27:21 +0000 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.23 (X11/20090812) MIME-Version: 1.0 To: draft-ietf-dhc-dhcpv4-vendor-message@tools.ietf.org, dhc-chairs@tools.ietf.org, secdir@ietf.org, IESG X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A13BEE1E211 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.5 VDF=10.119.38) X-Reverse-DNS: imx2.tcd.ie Subject: [secdir] secdir review of draft-ietf-dhc-dhcpv4-vendor-message X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 11:26:32 -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. The document defines a way to include vendor-specific messages in DHCPv4. I've only one relatively minor comment: Is this new message type likely to be used for passing sensitive information like user credentials? (E.g. username/password) If that's not the intent it might be worth stating that in the security considerations, just to discourage folks from doing that unless they provide their own confidentiality service. (I'm assuming there's no general confidentiality mechanism available.) Aside from that you may or may not want to capitalise the "should" in the last paragraph of the security considerations. (I don't care, but it might be an oversight.) On a non-security point: I didn't get the real need for this from reading the text and the references to the "Vendor-Identifying Vendor Options" I found confusing. So you could improve that a bit, but I assume that DHCP implementers would find it sufficiently clear. Stephen. From catherine.meadows@nrl.navy.mil Fri Feb 5 17:53:11 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D44953A6FCC; Fri, 5 Feb 2010 17:53:11 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8kSQpVzBE9B; Fri, 5 Feb 2010 17:53:11 -0800 (PST) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id CA30A3A6FCB; Fri, 5 Feb 2010 17:53:10 -0800 (PST) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.6/8.13.6) with ESMTP id o161rqFn013981; Fri, 5 Feb 2010 20:53:52 -0500 (EST) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.6/8.13.6) with SMTP id o161rkmD019140; Fri, 5 Feb 2010 20:53:46 -0500 (EST) Received: (from [IPv6:::1] [10.0.0.13]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010020520534522386 ; Fri, 05 Feb 2010 20:53:45 -0500 Message-Id: From: Catherine Meadows To: Sumanth Channabasappa In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CD37AFFA3@srvxchg> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 5 Feb 2010 20:53:45 -0500 References: <214A28E5-3DBD-4252-8EF6-7E18CEB441E5@nrl.navy.mil> <76AC5FEF83F1E64491446437EA81A61F7CD37AFFA3@srvxchg> X-Mailer: Apple Mail (2.936) Cc: "iesg@ietf.org" , "dan.ietf@sipez.com" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-sipping-config-framework-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2010 01:53:11 -0000 My apologies for not replying to this earlier. These changes look fine. Cathy On Jan 27, 2010, at 12:42 AM, Sumanth Channabasappa wrote: > Catherine, > > Thanks again for your keen observations, and the associated > comments. Dan and I discussed them offline, and I am summarizing our > responses inline, tagged with [D&S]. Please let us know if they > address your questions. > > - Dan & Sumanth > > > I think that this ID is in general in good shape with respect to > security, but I was a little confused about some of the discussion > of bootstrapping. It is the hardest to pin down, of course, but it > is also the most important to make clear, because it is the point, I > believe, at which the network is most vulnerable. Specific comments > follow: > > 1. The first sentence of Section 5.3.1, which reads > > When requesting a profile the device can provide an identity (i.e., a > user AoR), and contain associated credentials for authentication. To > do so, the device needs to obtain this information via bootstrapping. > > I wasn't quite sure what this means. Should that "can" be a > "must"? That is, the device needs the information, but can only get > it through bootstrapping. Or is the > "contain" be "obtain", and bootstrapping is how you get it? > > === [D&S] === > > You raise a good question. Dan suggested the following to solve the > confusion (and I concur with him): > > Replace the first sentence of 5.3.1: > "When requesting a profile the device can provide an identity (i.e., > a user AoR), and contain associated credentials for authentication." > > with: > > "When requesting a profile the profile delivery server will likely > require the device to provide an identity (i.e., a user AoR), and > associated credentials for authentication." > > Does that help? > ==== > > > > 2. Bootstrapping itself is never explicitly defined. I'd suggest > doing that at the beginning of 5.3.1. > > === [D&S] === > > You are correct. How about the following at the beginning of 5.3.1: > > "Bootstrapping is the process by which a new (or factory reset) > device, with no configuration or minimal "factory" pre- > configuration, enrolls with the PDS. The device may use a temporary > identity and credentials to authenticate itself to enroll and > receive profiles, which may provide more permanent identities and > credentials for future enrollments." > > Alternatively, we could add this definition in Section 2 > (Terminology). > > ==== > > > 3. The discussion of bootstrapping in 5.3.1 appears to only > consider the threat to the PDS. What about the other way around? > This is mentioned as a threat in the Security Considerations > section, but it's not clear to me whether 5.3.1 addresses this threat. > > === [D&S] === > This is addressed in Section 5.2.1, for normal profile enrollment. > Perhaps we should add a reference to these requirements in Section > 5.3.1 so that it is clear that the device authenticates the PDS even > in the bootstrapping scenario (e.g., during digest authentication)? > ==== > > > 4. The discussion of the security implications of bootstrapping > device profiles in Section 9.2 is valuable, and helps the reader > understand the rationale for the recommendations in 5.3.1 better, A > forward reference in the discussion of device profile on page 26 > would be helpful. > > === [D&S] === > Good suggestion, agree. > ==== > > 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 From christer.holmberg@ericsson.com Thu Feb 4 23:10:53 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD3A3A6D02; Thu, 4 Feb 2010 23:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.009 X-Spam-Level: X-Spam-Status: No, score=-3.009 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6NRkvBiAEx1; Thu, 4 Feb 2010 23:10:52 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 591393A6835; Thu, 4 Feb 2010 23:10:51 -0800 (PST) X-AuditID: c1b4fb3d-b7b85ae00000097d-62-4b6bc4ab797f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 6D.6E.02429.BA4CB6B4; Fri, 5 Feb 2010 08:11:39 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.147]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 5 Feb 2010 08:11:39 +0100 From: Christer Holmberg To: Samuel Weiler , "secdir@ietf.org" , "iesg@ietf.org" Date: Fri, 5 Feb 2010 08:11:37 +0100 Thread-Topic: secdir review of draft-ietf-sipcore-199-02 - Samuel's comments Thread-Index: AcqkF/sOYfNDsd6xRxuIMG9VeMtAugCGWnvw 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Sun, 07 Feb 2010 23:12:25 -0800 Cc: "draft-ietf-sipcore-199@tools.ietf.org" , "sipcore-chairs@tools.ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-sipcore-199-02 - Samuel's comments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 07:10:53 -0000 =20 Hi, Below are my replies to Samuel's comments. >This defines an intermediate "we're done" response, allowing=20 >parties to tear down some state, while still requiring a=20 >final response. >=20 >The obvious risk (forging these, just like forging a TCP=20 >reset) is documented. >=20 >Even though the point of the 199 response is to allow early=20 >resource release, I notice that some state is still being=20 >maintained for these sessions. It might be worth explicitly=20 >reminding readers of when they can timeout (is there a=20 >timeout specified somewhere?). The 199 response only tears down a specific early dialog within a session (= during the setup phase of a session there may be multiple early dialogs), b= ut the session itself, and all other early dialog within it, are unaffected= . For those normal RFC 3261 procedures apply. -------------- =20 >I'm also a little worried about the implications of one party=20 >or another trying to continue the dialog, perhaps=20 >maliciously, after sending or receiving one of these. What=20 >if one of these were used to disable a monitoring or billing=20 >system, but the parties continued to use the open session? =20 >(Compare to sending a weak C-tone on a wiretapped PSTN line.) That is of course possible, but in my opinion it is possible in SIP already= without this, using other responses and requests which tears down a dialog= or session. The protocol itself does not prevent users from continue to se= nd media using the parameters (IP address/port, codecs etc) that thay have = negotiated for the session. So, if one wants to prevent this from happening, some policy procedures nee= d to be applied in the network. -------------- >Editorial: >=20 >Please expand the acronyms in the abstract. (The id-nits=20 >checklist says the abstract "Should be meaningful to someone=20 >not versed in the technology; most abbreviations must be=20 >expanded on first use.") Sure, I'll fix that. Regards, Christer From rajiva@cisco.com Mon Feb 8 12:00:02 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCCF428C14D; Mon, 8 Feb 2010 12:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.392 X-Spam-Level: X-Spam-Status: No, score=-9.392 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnAlEp2HC5SJ; Mon, 8 Feb 2010 12:00:01 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 01C753A7103; Mon, 8 Feb 2010 12:00:01 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANb8b0urR7Ht/2dsb2JhbADBDJczhFQE X-IronPort-AV: E=Sophos;i="4.49,431,1262563200"; d="scan'208";a="297158250" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 08 Feb 2010 20:01:04 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o18K14T2014172; Mon, 8 Feb 2010 20:01:04 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Feb 2010 14:01:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Feb 2010 14:00:57 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577CD812B5@XMB-RCD-111.cisco.com> In-Reply-To: <12A2C4F2-7168-48B4-97AC-EC439E89FB1E@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-mpls-ldp-typed-wildcard-05 Thread-Index: AcqjuZ20Ftg0OjOPSPyUTkxDtQr/fgFDTDEQ References: <12A2C4F2-7168-48B4-97AC-EC439E89FB1E@bbn.com> From: "Rajiv Asati (rajiva)" To: "Richard L. Barnes" , "secdir" , "The IESG" , "The IETF" , "Rajiv Asati (rajiva)" X-OriginalArrivalTime: 08 Feb 2010 20:01:03.0892 (UTC) FILETIME=[718DC540:01CAA8F9] X-Mailman-Approved-At: Tue, 09 Feb 2010 03:02:00 -0800 Cc: draft-ietf-mpls-ldp-typed-wildcard@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-mpls-ldp-typed-wildcard-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2010 20:00:03 -0000 Hi Richard, Thank you so much for your review and critical feedback. This really helps to improve this specification. Please see inline, > specific constraints. Because this change is relatively minor, the > security considerations are mostly the same as the base protocol, as > noted by the Security Considerations section; however, I would prefer > if the authors explained a little better why this is the case. Please see my response below (to the last comment). > From an editorial perspective, this document is unclear on several > important points, especially with regard to the type-specific > constraints and how they are defined and managed. I think the document > would would benefit from another revision, focused on making the > meaning and management of all parameters clear to ensure > interoperability.=09 I am assuming that the unclarity you refer to is based on the specific comments you have provided below. Right?=20 > Specific comments: >=20 > Section 1, Para "As specified..." > With respect to the phrase "relative to an optional constraint": I > don't see anything in RFC 5036 that allows for such a constraint. The > Wildcard FEC type "is to be applied to all FECs associated with the > label within the following label TLV." Per RFC5036, the Label TLV is an optional parameter in Label release (section 3.5.10) and Label withdraw (section 3.5.10) messages. Hence, the text is section 1 is correct. > Section 1, Para "1. The Wildcard FEC Element is untyped" > It's not quite accurate to say that the element is untyped; it has type > 0x01. Suggest something like "The Wildcard FEC element only allows > very coarse selection of FECs by label." Type-length-value in TLV (encoding) has nothing to do with the 'typed' (vs. 'untyped') data, which is what that statement and the whole document refer to. Typed data is supplemented with the value, whereas the untyped data is not. The latter is what RFC5036 prescribed (note that there is no value in it). The former is what the current document is prescribing. Hence, the existing text in the para (and the whole document). I don't see any need for changing that para. Do you? > Section 1, General > Clearly you're really after here isn't to change the Wildcard FEC > Element (as the last sentence of the section says), but to have a new > element that is a typed Wildcard. It would be clearer and more > accurate to say this, e.g., in bullet (2), "There are situations where > it would be useful to have a wildcard-like FEC Element, with type > constraints, in Label Request messages." Agreed. Fixed. =20 > Section 2, TLV > s/Lenth/Length/ Agreed. Fixed. =20 > Section 3, Para "The Typed Wildcard FEC Element..." > The language about constraints here seems vague. (In what sense is the > constraint "optional"?) Suggest the following: > " > A Typed Wildcard FEC Element specifies a FEC Type and, optionally, a > constraint. An element of this type refers to all FECs of the > specified FEC Type that meet the constraint. The format of the > constraint field depends on the FEC Type specified. > " Agreed. Pls allow me to suggest a slightly changed replacement instead - ~~~~~~~~~ The Typed Wildcard FEC Element refers to all FECs of the specified type that meet the constraint. It specifies a 'FEC Element Type' and an optional constraint, which is intended to provide additional information. =20 ~~~~~~~~~ I have also put "Optional" in the figure 1, btw. =20 > Section 3, Para "Additional FEC Type-specific Information ..." et seq > It is unclear whose responsibility it is to define the structure of > this field (i.e., who is the "designer"?). Do you mean to say this: > "Additional constraints that the FEC must satisfy in order to be > selected. The format of the Additional FEC Type-specific Information > depends on the FEC type in question. This document defines the format > of this field for the Prefix FEC type." Agreed. Pls allow me to suggest a slightly changed replacement instead - ~~~~~~ It is important that any document specifying Typed wildcarding for any FEC Element Type also specifies the length and format of Additional FEC Type Specific Information, if included. ~~~~~~~~~~ > The text here and in the document suggest that there should perhaps be > a procedure for defining and registering formats for this field. > However, you may want to specify that any FEC Type may be specified > with a zero-length Additional FEC Type-specific Information field to > simply match all FECs of that FEC Type (in order to make it easy to use > without a whole lot of new RFCs). This is already implicit in the description of the 'Leng FEC Type Info'. I have made it explicit in the below update -=20 ~~~~~~~~~` Additional FEC Type-specific Information: (Optional) Additional information specific to the FEC Element Type required to fully specify the Typed Wildcard. If this field is absent, then all FECs of the specified FEC Type would be matched. ~~~~~~~~~~~~~ =09 =20 > Section 4, Para "It is the responsibility..." et seq > The authors of this document are the designers of the Typed Wildcard > FEC Element Type; who do you mean? It is meaningless to have a MUST > that is conditional on "making sense". What we mean is that the (future) specifications defining any new FEC Element Types should prescribe whether typed wildcarding is needed for that FEC Element Type. =20 Nonetheless, that para should be in the section 3, not section 4. I have moved it in the section 3. The 2nd para (When Typed Wildcarding....) has been removed, since it is redundant with the existing text. =20 > Section 4, Para "When a FEC TLV..." > This constraint made sense for the generic Wildcard type, since that > would overwhelm any other FEC Elements, but it's not clear why it's > necessary here. Couldn't I have a Label Withdraw message that > withdraws all CR-LSP FECs and a single Prefix FEC? Good question. The answer is - No. There must be two different messages. RFC5036 (section 3.4.1) does NOT allow multiple FEC elements in FEC TLV in any message except label mapping message. Frankly, it would bring whole set of complexity, if we removed this restriction, for minimal benefit.=20 =20 > Section 6, General > You need to specify the semantics of this field. Does it match all > FECs that are of the given address family? Also, this doesn't allow > any constraints on prefix length or the prefix itself; is that > intentional? Yes. That's intentional (since it is already covered by the Prefix FEC Element). Wrt semantics, not sure which particular field's semantics you are referring to, but the procedures are already specified in section 4, hence, there wasn't any benefit in replicating the text. =09 > Section 7, Para "In other words ..." > s/can not/MUST NOT/ Agreed. Fixed. =20 > Section 9, General > I would like to see a little more explanation of why this extension to > LDP does not create additional security considerations. It seems like > at the very least it increases the risk of misconfiguration by adding > much more flexible wildcard matching rules; that is, it seems more > likely that an LSR operator will accidentally match things he doesn't > intend to, or vice versa. Strictly speaking, the security exposure is reduced by this specification, since the wildcarding is now limited to FECs of a particular type (AFI, say), not all the FECs.=20 =09 Nonetheless, I agree to your suggestion about having some text to clarify a bit better and suggest adding the following (as 2nd para) to the security consideration section: ~~~~~~~~~~ One could deduce that the security exposure is reduced by this document, since an LDP speaker using Typed Wildcard FEC Element could use a single message to request, withdraw or release all the label mappings of a particular type (a particular AFI, for example), whereas an LDP speaker using Wildcard FEC Element, as defined in based LDP specification [RFC5036], could use a single message to request, withdraw or release all the label mappings of all types (all AFIs, for example). ~~~~~~~ Would this be sufficient?=20 Cheers, Rajiv > -----Original Message----- > From: Richard L. Barnes [mailto:rbarnes@bbn.com] > Sent: Monday, February 01, 2010 10:40 PM > To: secdir; The IESG; The IETF > Cc: draft-ietf-mpls-ldp-typed-wildcard@tools.ietf.org > Subject: secdir review of draft-ietf-mpls-ldp-typed-wildcard-05 >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 >=20 > This document extends the matching capabilities of the LDP Wildcard FEC > element, which matches all Forwarding Equivalence Classes bound to a > given label, by adding a second Typed Wildcard FEC element, which > matches all FECs of a given type, with optional additional type- > specific constraints. Because this change is relatively minor, the > security considerations are mostly the same as the base protocol, as > noted by the Security Considerations section; however, I would prefer > if the authors explained a little better why this is the case. >=20 >=20 > From an editorial perspective, this document is unclear on several > important points, especially with regard to the type-specific > constraints and how they are defined and managed. I think the document > would would benefit from another revision, focused on making the > meaning and management of all parameters clear to ensure > interoperability.=09 >=20 >=20 > Detailed comments follow. >=20 >=20 > --Richard >=20 >=20 >=20 > Specific comments: >=20 > Section 1, Para "As specified..." > With respect to the phrase "relative to an optional constraint": I > don't see anything in RFC 5036 that allows for such a constraint. The > Wildcard FEC type "is to be applied to all FECs associated with the > label within the following label TLV." >=20 > Section 1, Para "1. The Wildcard FEC Element is untyped" > It's not quite accurate to say that the element is untyped; it has type > 0x01. Suggest something like "The Wildcard FEC element only allows > very coarse selection of FECs by label." >=20 > Section 1, General > Clearly you're really after here isn't to change the Wildcard FEC > Element (as the last sentence of the section says), but to have a new > element that is a typed Wildcard. It would be clearer and more > accurate to say this, e.g., in bullet (2), "There are situations where > it would be useful to have a wildcard-like FEC Element, with type > constraints, in Label Request messages." >=20 > Section 2, TLV > s/Lenth/Length/ >=20 > Section 3, Para "The Typed Wildcard FEC Element..." > The language about constraints here seems vague. (In what sense is the > constraint "optional"?) Suggest the following: > " > A Typed Wildcard FEC Element specifies a FEC Type and, optionally, a > constraint. An element of this type refers to all FECs of the > specified FEC Type that meet the constraint. The format of the > constraint field depends on the FEC Type specified. > " >=20 > Section 3, Para "Additional FEC Type-specific Information ..." et seq > It is unclear whose responsibility it is to define the structure of > this field (i.e., who is the "designer"?). Do you mean to say this: > "Additional constraints that the FEC must satisfy in order to be > selected. The format of the Additional FEC Type-specific Information > depends on the FEC type in question. This document defines the format > of this field for the Prefix FEC type." > The text here and in the document suggest that there should perhaps be > a procedure for defining and registering formats for this field. > However, you may want to specify that any FEC Type may be specified > with a zero-length Additional FEC Type-specific Information field to > simply match all FECs of that FEC Type (in order to make it easy to use > without a whole lot of new RFCs). >=20 > Section 4, Para "It is the responsibility..." et seq > The authors of this document are the designers of the Typed Wildcard > FEC Element Type; who do you mean? It is meaningless to have a MUST > that is conditional on "making sense". >=20 > Section 4, Para "When a FEC TLV..." > This constraint made sense for the generic Wildcard type, since that > would overwhelm any other FEC Elements, but it's not clear why it's > necessary here. Couldn't I have a Label Withdraw message that > withdraws all CR-LSP FECs and a single Prefix FEC? >=20 > Section 6, General > You need to specify the semantics of this field. Does it match all > FECs that are of the given address family? Also, this doesn't allow > any constraints on prefix length or the prefix itself; is that > intentional? >=20 > Section 7, Para "In other words ..." > s/can not/MUST NOT/ >=20 > Section 9, General > I would like to see a little more explanation of why this extension to > LDP does not create additional security considerations. It seems like > at the very least it increases the risk of misconfiguration by adding > much more flexible wildcard matching rules; that is, it seems more > likely that an LSR operator will accidentally match things he doesn't > intend to, or vice versa. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From new-work-bounces@ietf.org Tue Feb 9 11:00:09 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DC73A75CE; Tue, 9 Feb 2010 11:00:09 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DB19C28C0D0; Tue, 9 Feb 2010 11:00:02 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100209190002.DB19C28C0D0@core3.amsl.com> Date: Tue, 9 Feb 2010 11:00:02 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 09 Feb 2010 11:28:10 -0800 Subject: [secdir] [New-work] WG Review: Recharter of Inter-Domain Routing (idr) 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: Tue, 09 Feb 2010 19:00:09 -0000 A modified charter has been submitted for the Inter-Domain Routing (idr) working group in the Routing 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 Tuesday, February 16, 2010. Inter-Domain Routing (idr) ----------------------------- Last Modified: 2010-02-04 Additional information is available at tools.ietf.org/wg/idr Chair(s): - Susan Hares - John Scudder Routing Area Director(s): - Ross Callon - Adrian Farrel Routing Area Advisor: - Ross Callon Mailing Lists: General Discussion: idr@ietf.org To Subscribe: idr-request@ietf.org In Body: subscribe idr-post Archive: http://www.ietf.org/mail-archive/web/idr/index.html Description of Working Group: The Inter-Domain Routing Working Group is chartered to standardize, develop, and support the Border Gateway Protocol Version 4 (BGP-4) [RFC 4271] capable of supporting policy based routing for TCP/IP internets. The main objective of the working group is to support the use of BGP-4 by IP version 4 and IP version 6 networks. The working group will also continue to work on improving the robustness and scalability of BGP. IDR will review extensions made to BGP in other working groups at least at WG document adoption and during working group last calls. The IDR working group will also provide advice and guidance on BGP to other working groups as requested. Work Items: The IDR working group will work on correctness, robustness and scalability of the BGP protocol, as well as clarity and accuracy of the BGP document set. The group will also work on extensions beyond these areas when specifically added to the charter. The current additional work items are: - Relax the definition of BGP identifiers to only require AS-wide uniqueness. This change must be made in a backward compatible way. - Specify a means to non-disruptively introduce new BGP Capabilities to an existing BGP session. - Upgrade of the base BGP specification to Full Standard - Define AS_PATH based Outbound Route Filtering. - MIB v2 for BGP-4 - Augment the BGP multiprotocol extensions to support the use of multiple concurrent sessions between a given pair of BGP speakers. Each session is used to transport routes related by some session- based attribute such as AFI/SAFI. This will provide an alternative to the MP-BGP approach of multiplexing all routes onto a single connection. - Support for four-octet AS Numbers in BGP. - Revisions to the BGP 'Minimum Route Advertisement Interval' deprecating the previously recommended values and allowing for withdrawals to be exempted from the MRAI. - Advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. Each path is identified by a path identifier in addition to the address prefix. - Revised error handling rules for optional transitive BGP attributes so that a BGP speaker is no longer required to reset the session over which a malformed attribute is received. Provide guidelines for authors of documents that define new optional transitive attributes, and re-assess procedures for existing optional transitive attributes - Specify Link Bandwidth Extended Community for use in unequal cost load balancing. - The definition of an "Accumulated IGP Metric" attribute for BGP to report the sum of the metric of each link along the path. This attribute is for use in a restricted environment where: - all ASes are subject to the administrative control - some form of tunneling is used to deliver a packet to its next BGP hop - where the path for a route leads outside the AS to which the BGP speaker adding the attribute belongs. - Advertisement of the best external route in BGP to assist with resolution of the next hop in the chosen data plane. Goals and Milestones: Done Submit to BGP Capability Advertisement to the IESG Done Submit BGP Security Vulnerabilities Analysis to IESG as an Informational Done Submit BGP4 MIB to IESG as a Proposed Standard Done Submit BGP4 document to IESG as a Draft Standard Done Submit Extended Communities draft to IESG as a Proposed Standard Done Submit BGP Graceful Restart to IESG as a Proposed Standard Done Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG as a Draft Standard Done Submit Subcodes for BGP Cease Notification Message to IESG as a Proposed Standard Done Submit 4-byte AS ID to IESG as a Proposed Standard Done Submit Outbound Route Filter and Prefix ORF draft to IESG as a Proposed Standard Done Prefix and ASpath ORF draft to IESG as a Proposed Standard Aug 2010 Submit AS-wide Unique BGP Identifier for BGP-4 as a Proposed Standard Aug 2010 Submit Dynamic Capability for BGP-4 to IESG as a Proposed Standard Aug 2010 ASpath ORF draft to IESG as a Proposed Standard Aug 2010 Submit MIB v2 for BGP-4 as a Proposed Standard Nov 2010 BGP Support for Four-octet AS Number Space (revised version) Nov 2010 Revisions to the BGP 'Minimum Route Advertisement Interval' Nov 2010 Advertisement of Multiple Paths in BGP Nov 2010 BGP Link Bandwidth Extended Community Nov 2010 Advertisement of the best external route in BGP Dec 2010 Submit Multisession BGP as a Proposed Standard Dec 2010 Error Handling for Optional Transitive BGP Attributes Dec 2010 ASpath ORF Dec 2010 Revise WG charter Mar 2011 The Accumulated IGP Metric Attribute for BGP Mar 2011 Base BGP specification (RFC 4271) as Full Standard _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Feb 9 11:00:13 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9275E28C241; Tue, 9 Feb 2010 11:00:13 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 025AE3A75BF; Tue, 9 Feb 2010 11:00:02 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100209190003.025AE3A75BF@core3.amsl.com> Date: Tue, 9 Feb 2010 11:00:02 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 09 Feb 2010 11:28:10 -0800 Subject: [secdir] [New-work] WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme) 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: Tue, 09 Feb 2010 19:00:13 -0000 A modified charter has been submitted for the IP Security Maintenance and Extensions (ipsecme) working group in the Security 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 Tuesday, February 16, 2010. IP Security Maintenance and Extensions (ipsecme) --------------------------------------------------- Current Status: Active Working Group Last Modified: 2010-01-21 Chair(s): * Paul Hoffman (paul.hoffman@vpnc.org) * Yaron Sheffer (yaronf@checkpoint.com) Security Area Director(s): * Tim Polk (tim.polk@nist.gov) * Pasi Eronen (pasi.eronen@nokia.com) Security Area Advisor: * Pasi Eronen (pasi.eronen@nokia.com) Mailing Lists: General Discussion: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Description of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 4306, RFC 4718, and associated RFCs), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The work items are: - A standards-track IKEv2 extension that allows an IKE peer to quickly and securely detect that its opposite peer, while currently reachable, has lost its IKEv2/IPsec state. Changes to how the peers recover from this situation are beyond the scope of this work item, as is improving the detection of an unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as starting points. - A standards-track IKEv2 extension to allow mutual EAP-based authentication in IKEv2, eliminating the need for the responder to present a certificate. The document will define the conditions that EAP methods need to fulfill in order to use this extension. The document will recommend, but will not require, the use of EAP methods that provide EAP channel binding. The proposed starting point for this work is draft-eronen-ipsec-ikev2-eap-auth-07.txt. - IKEv2 supports mutual authentication with a shared secret, but this mechanism is intended for "strong" shared secrets. User-chosen passwords are typically of low entropy and subject to off-line dictionary attacks when used with this mechanism. Thus, RFC 4306 recommends using EAP with public-key based authentication of the responder instead. This approach would be typically used in enterprise remote access VPN scenarios where the VPN gateway does not usually even have the actual passwords for all users, but instead typically communicates with a back-end RADIUS server. However, user-configured shared secrets are still useful for many other IPsec scenarios, such as authentication between two servers or routers. These scenarios are usually symmetric: both peers know the shared secret, no back-end authentication servers are involved, and either peer can initiate an IKEv2 SA. These features make using EAP (with its strict client-server separation) undesirable. The WG will develop a standards-track extension to IKEv2 to allow mutual authentication based on "weak" (low-entropy) shared secrets. The goal is to avoid off-line dictionary attacks without requiring the use of certificates or EAP. There are many already-developed algorithms that can be used, and the WG would need to pick one that both is believed to be secure and is believed to have acceptable intellectual property features. The WG would also need to develop the protocol to use the chosen algorithm in IKEv2 in a secure fashion. It is noted up front that this work item poses a higher chance of failing to be completed than other WG work items; this is balanced by the very high expected value of the extension if it is standardized and deployed. - IPsec gateways are often deployed in clusters that look like a single gateway to the peer (such as for high availability and load balancing reasons). However, correctly maintaining the appearance to the peer of a single gateway is complicated; one of the main challenges is the strict use of sequence numbers both in IKEv2 and ESP/AH. This work item will define a problem statement and requirements for potential IPsec/IKEv2 mechanism (or multiple mechanisms) to simplify cluster implementations. The result will be an informational document that, once completed, may lead to chartering one or more new work items to specify the actual mechanisms. The scope is restricted to mechanism(s) that are visible to the peer, and thus usually require interoperability between vendors. Mixed-vendor clusters, and protocols between the cluster members, are explicitly out of scope of this work item. The starting point will be draft-nir-ipsecme-ipsecha-00. In addition, the following items from the existing charter are expected to be completed soon: - A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. In some cases, the revision may include small technical corrections; however, impact on existing implementations must be considered. Major changes and adding new features is beyond the scope of this work item. One part of this work item, clarifying how AES counter mode is used for the IKEv2 encrypted payload, is in a separate document. - An IPsec document roadmap that describes the various RFC documents covering IPsec, including both the core RFC 240x and RFC 430x versions of IPsec, and extensions specified in other documents. This document will be informational. - A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. The scope of the WG is restricted to the work items listed above. The WG shall not consider adding new work items until there are four or fewer documents being actively worked on (not yet progressed to IETF Last Call). At that time, the WG can propose rechartering. Work on IPsec extensions that are not included in this charter can happen as usual in other WGs, or as individual submissions. This charter will expire in February 2012 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Goals and Milestones: Aug 2010 - WG last call on HA requirements Dec 2010 - WG last call on quick crash discovery Jan 2011 - WG last call on EAP-only authentication Mar 2011 - WG last call on password-based authentication _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Feb 9 11:15:15 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D81628C219; Tue, 9 Feb 2010 11:15:15 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A05F53A75BB; Tue, 9 Feb 2010 11:15:01 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100209191501.A05F53A75BB@core3.amsl.com> Date: Tue, 9 Feb 2010 11:15:01 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 09 Feb 2010 11:28:10 -0800 Subject: [secdir] [New-work] WG Review: Keying and Authentication for Routing Protocols (karp) 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: Tue, 09 Feb 2010 19:15:15 -0000 A new IETF working group has been proposed in the Routing Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, February 16, 2010. Keying and Authentication for Routing Protocols (karp) --------------------------------------------------- Current Status: Proposed Working Group Last Modified: 2010-02-05 Chair(s): - Joel Halpern - Brian Weis Routing Area Director(s): - Ross Callon - Adrian Farrell Routing Area Advisor: - Ross Callon Security Area Advisor: - Tim Polk Mailing Lists: karp@ietf.org Description of Working Group: The KARP working group is tasked to work with the routing protocol working groups in order to improve the communication security of the packets on the wire used by the routing protocols. This working group is concerned with message authentication, packet integrity, and denial of service (DoS) protection. At present, this charter explicitly excludes confidentiality and non-repudiation concerns. Authenticating the routing peer sending a message, and message integrity protection, will be provided through the use of per-packet cryptographic message authentication. Peer authentication will protect against unrecognized peers, imposter peers, and some DoS attacks aimed at routers. Protecting against misbehavior of an otherwise allowed peer router is outside the scope of this working group. Many routing protocols (or groups of protocols) already have some method for accomplishing cryptographic message authentication. In many or most cases existing methods are vulnerable to known attack, and some employ cryptographic algorithms that have been deprecated. While much work has been done to update authentication of routing protocols, current status is not consistently up to date. It is important to review and update those mechanisms to use modern security practices. Ensuring algorithm agility within routing protocols is of particular importance. A goal of the working group is to add incremental security to existing mechanisms rather than replacing them. Better deployable solutions to which vendors and operators can migrate is more important than getting a perfect security solution. Although there are many candidate routing protocols to evaluate, KARP must by necessity begin with a restricted focus. The initial set of routing protocols in scope include BGP, OSPFv2, OSPFv3, PCE, PIM, LDP, RSVP-TE, ISIS, BFD, LMP, and MSDP. The working group must coordinate very closely with other working groups, such as: - Routing protocol working groups for any routing protocol being evaluated. This coordination will include cooperatively determining the current or already planned state of the security work in the protocol. It will also include ensuring that any proposed mechanisms are consistent with the architecture and use of the protocol. Also, any specific proposal accepted as a KARP document will be developed in cooperation with the concerned protocol working group. - Security area working groups for cryptographic advice, and/or key management protocol support. Cryptographic protocol support may be required in order to support certain KARP WG milestones. Coordination with an appropriate working group in the security area would be necessary in order to get the appropriate expertise in completing a milestone. This charter provides for preliminary work in this space, although it is expected that detailed work items will be added to the charter when the problem has been better analyzed. For example, this may include a key management protocol by which routing protcols automatically negotiate keying material and policy. More about the use of a key management protocol will be captured in a framework document described below. - OPSEC working group for advice on best practices to create and use integrity keys used with routing protocol message authentication. Routing protocols use a range of transport mechanisms and communication relationships. There are also differences in details among the various protocols. The working group will attempt to describe the security relevant characteristics of routings protocols, such as the use or non-use of TCP, or the frequent use of group communication versus purely pairwise communication. Using these characteristics, the working group will then provide suitable common frameworks that can be applied, and tailored, to improve the communication security of the routing protocols. In later phases, it is expected that the working group will investigate the suitably of defining conceptual structures and APIs, so as to enable further work to be more effective. Work Items: - Determine current threats to the routing protocol operation, and define general requirements for cryptographic authentication of routing protocols. A primary source for this document should be draft-lebovitz-karp-roadmap, although RFC 4393 may also be useful. - Identify deficiencies of each routing protocol in scope, and specify mechanisms that bring them in line with the general requirements. These are referred to as protocol gap analysis documents. - Define one or more frameworks describing the common elements for modern authentication in routing protocols. - Publish guidance on how to create a gap analysis for routing protocols. - Publish guidance on guidance to operators on how to create and use integrity keys used with routing protocol message authentication. - Specify automated key management needs for routing protocols. Goals and Milestones: Nov 2010 - Submit General Framework, General Requirements, and Priorities/Work-Plan documents to the IESG to be considered as Informational RFC Nov 2010 - Submit a framework document describing protocol groups and the common techniques and interfaces that apply to them to the IESG to be considered as Informational RFC Dec 2010 - Submit a document describing best practices for creating and using protocol message authentication integrity keys as a BCP Apr 2011 - Submit specification document for OSPFv2 to the IESG to be considered as a Proposed Standard Apr 2011 - Submit specification document for BGP to the IESG to be considered as a Proposed Standard Jul 2011 - Submit specification document for OSPFv3 to the IESG to be considered as a Proposed Standard Jul 2011 - Submit specification document for LDP to the IESG to be considered as a Proposed Standard Oct 2011 - Submit specification document for PIM to the IESG to be considered as a Proposed Standard Oct 2011 - Submit specification document for RSVP-TE to the IESG to be considered as a Proposed Standard Nov 2011 - Specify automated key management needs for routing protocols using unicast techniques Jan 2012 - Submit specification document for ISIS to the IESG to be considered as a Proposed Standard Jan 2012 - Submit specification document for PCE to the IESG to be considered as a Proposed Standard Apr 2012 - Submit specification document for MSDP to the IESG to be considered as a Proposed Standard Apr 2012 - Specify automated key management needs for routing protocols using multicast techniques Apr 2012 - Submit specification document for BFD to the IESG to be considered as a Proposed Standard Jul 2012 - Submit specification document for LMP to the IESG to be considered 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 Tue Feb 9 11:15:31 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18AA28C10D; Tue, 9 Feb 2010 11:15:30 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B3CBF28C0E1; Tue, 9 Feb 2010 11:15:01 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100209191501.B3CBF28C0E1@core3.amsl.com> Date: Tue, 9 Feb 2010 11:15:01 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 09 Feb 2010 11:28:10 -0800 Subject: [secdir] [New-work] WG Review: Peer-to-Peer Streaming Protocol (PPSP) 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: Tue, 09 Feb 2010 19:15:31 -0000 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, February 16, 2010. Peer-to-Peer Streaming Protocol (PPSP) -------------------------------------------------- Current Status: Proposed Working Group Chair(s): TBD Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Lars Eggert Mailing Lists: ppsp@ietf.org Description of Working Group: The Peer-to-Peer Streaming Protocol (PPSP) working group develops two signaling and control protocols for a peer-to-peer (P2P) streaming system for transmitting live and pre-recorded media content with near real-time delivery requirements. Two kinds of nodes exist in the targeted P2P streaming system, i.e., "peers" and "trackers". Peers are nodes that are actively sending and receiving streamed media content, and include both statically connected hosts as well as mobile devices with connectivity and IP addresses that change over time. The set of peers that are participating in a streaming session will dynamically change over time. Trackers are well-known nodes with stable connectivity that maintain meta information about the streamed content and the dynamic peer set. The PPSP WG designs a protocol for signaling and control between trackers and peers (the PPSP "tracker protocol") and a signaling and control protocol for communication among the peers (the PPSP "peer protocol"). The two protocols enable peers to receive streaming data within the time constraints required by specific content items. The tracker protocol handles the initial and periodic exchange of meta information between trackers and peers, such as peer lists and content information. The peer protocol controls the advertising and exchange of media data availability between the peers. Existing IETF and other standards will be used for the encoding and transmission of the media content between peers. PPSP is not chartered to work on media transmission protocols, media encoding techniques or other components of a P2P streaming system such as playout scheduling and control, etc. The work items of the PPSP WG are: (1) A "problem statement" document that gives an overview of the proposed P2P streaming system, motivates the desire for standardized protocols, defines the envisioned scope of those standardized components and discusses common terminologies and concepts. (2) A "requirements" document that details the specific functional, operational and performance requirements of the two PPSP protocols. (3) An "architectural survey" document that summarizes current P2P streaming architectures, in particular tracker-based P2P streaming systems, and highlights best current practices. (4) A detailed specification of the PPSP peer protocol. (5) A detailed specification of the PPSP tracker protocol. (6) A "usage guide" that describes how the two PPSP protocols and existing IETF protocols, such as RELOAD, ALTO or RTSP, can be combined to create a deployable operational P2P streaming system. This document may also discuss variants of such a system that, for example, use layered media encoding and related media chunk descriptions in the peer protocol for more robust streaming. The work items of the PPSP WG interacts with the work performed in other IETF WGs, including P2PSIP, ALTO, LEDBAT and MMUSIC. Whenever extensions or modification to the protocols developed in other WGs are deemed necessary, PPSP shall communicate and discuss the requirements for such extensions with the relevant WGs. The design of such extensions is out of scope for PPSP. Goals and Milestones: Dec 2010 Submit problem statement to IESG as Informational Apr 2011 Submit architectural survey to IESG as Informational Apr 2011 Submit requirements document to IESG as Informational Aug 2011 Submit PPSP peer protocol to IESG as Proposed Standard Aug 2011 Submit PPSP tracker protocol to IESG as Proposed Standard Dec 2011 Submit usage guide to IESG to IESG as Informational _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From kent@bbn.com Tue Feb 9 13:11:00 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9B53A75FA for ; Tue, 9 Feb 2010 13:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OF6D1MX4cLex for ; Tue, 9 Feb 2010 13:10:56 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 809873A7270 for ; Tue, 9 Feb 2010 13:10:56 -0800 (PST) Received: from dhcp89-089-170.bbn.com ([128.89.89.170]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NexNJ-0002Rp-AY; Tue, 09 Feb 2010 16:12:01 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4B5D1F85.1070900@cryptocom.ru> References: <20100107222809.GA25747@shinkuro.com> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <4B5D1F85.1070900@cryptocom.ru> Date: Tue, 9 Feb 2010 16:11:56 -0500 To: Basil Dolmatov From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Andrew Sullivan , Ralph Droms , ogud@ogud.com, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 21:11:00 -0000 Basil, Sorry that I seem to have lost your message in my inbox for a while. Replies inline below. >>... >Yes, we do disagree in principles (see below). > >>The question for both DNSSEC and SIDR/RPKI is how many algorithms >>relying parties MUST/SHOULD be >> >I wondered why MUST and SHOULD are quoted together. I thought that >it is two _different_ modal verbs with _different_ meaning and >_different_ implementation demands. SHOULD is MUST with an allowance for "carefully weighed" exceptions. Both indicate that a compliant implementation ought to have code that supports the referenced feature. In this case, that would be code to support GOST algs. > >... >>I believe that the situation for DNESEC is equivalent, i.e., >>imposing a requirement (via MUST or SHOULD) to support more than a >>current and next set of algorithms is not justifiable. >> >The situation in DNSSec is entirely different from SIDR: > >>Comparing to DNS the IDR ideology is entirely different: DNS is >>wholistic and united service, but main IDR principle is the >>independence of routing decisions for any given AS. >> >The way that was chosen by SIDR developers is demanding to invent >some methods and technologies to prevent network from being split. >Thank you, Steve, you proposed one of the possible technologies >which makes that possible (at least makes a forthcoming split more >or less implicit). >That does not mean that this technology is the _good_ one. It means >that for the given set of circumstances this solution is >_the_only_possible_ one. The local TA management capability that I have described for SIDR is intended to deal with the general problem of an RP (or a sovereign entity) wanting to create and manage a local view of the RPKI. It is not primarily designed to accommodate national algorithms, although it can be used for that was well. >So, I quit the discussion in SIDR, not because of I was satisfied >with the technology and solutions, but because of I have understood >how I could maintain network interoperability even with this rigid >technology and have had more urgent tasks to perform. > >I kindly ask to all participating parties do not try to castrate >flexible protocol design of DNSSec to the SIDR/RPKI rigid approach. Oh, "castrate" seems like a pretty harsh term to use :-). Both the RPKI and DNSSEC are flexible protocols. We're debating the issue of how broad a set of algorithms MUST/SHOULD be supported by RPs, which is an architectural (and political) issue. >>It imposes unacceptable costs on resolvers (analogous to RPs in the >>RPKI context) >> >RPs - are not resolver analogues, but this is for another discussion. OK. >>and may have adverse secruity implications. Such externalization of >>costs is a fundamentally bad approach, one that the IETF tries to >>avoid in analogous contexts in all areas. >> >Here is another difference od DNSSec from SIDR - most of the >software is open-source in DNSSec, so costs have been already >distributed evenly. >As for proprietary realisations it seems to me the maintaining of >the cost/profit balance is the task of the management of the given >enterprise, and I am sure that they will do their work well. We disagree on the nature of how costs may accrue. >>It is fine for DNSEXT to allocate algorithm IDs to national >>algorithms like GOST, but it is not appropriate to mandate their >>support, for the reasons cited in my review. >> >I do agree that MUST set of algorithms should be very narrow and >limited generally speaking to those algorithms by which root zone is >signed. I'm glad we agree on this. Since SHOULD is only a slightly-diminished form of MUST, ... >As for the other algorithms, it seems to me that the main goal of >DNS system is the providing integral name service resolution. If one >have to perform some additional steps (install different resolver >software, include something and something) just to get access to the >network names on some part of the world, then the obvious next step >will be to point this different resolver to another root of the tree. Some might interpret this as a threat, even though I'm sure you didn't mean it that way. >Maybe this is the way the DNS system will develop, but now I think >that the some effort to keep the DNS system united is justified. Unified is a goal we both agree upon, but mandated support for national algorithms is NOT a unifying principle, it is a Balkanizing principle (if you'll pardon the term). Steve From Nicolas.Williams@sun.com Tue Feb 9 14:05:15 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46643A7623 for ; Tue, 9 Feb 2010 14:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APCVwjWu1ssq for ; Tue, 9 Feb 2010 14:05:15 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id D690B3A6E04 for ; Tue, 9 Feb 2010 14:05:01 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o19M5trn007882 for ; Tue, 9 Feb 2010 22:06:07 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id o19M5sEo036481 for ; Tue, 9 Feb 2010 15:05:54 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o19LZseP027068; Tue, 9 Feb 2010 15:35:54 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o19LZrL7027067; Tue, 9 Feb 2010 15:35:53 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 9 Feb 2010 15:35:52 -0600 From: Nicolas Williams To: Stephen Kent Message-ID: <20100209213552.GP1061@Sun.COM> References: <20100107222809.GA25747@shinkuro.com> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <4B5D1F85.1070900@cryptocom.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: Andrew Sullivan , secdir@ietf.org, Basil Dolmatov , ogud@ogud.com, Ralph Droms Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 22:05:16 -0000 On Tue, Feb 09, 2010 at 04:11:56PM -0500, Stephen Kent wrote: > >I do agree that MUST set of algorithms should be very narrow and > >limited generally speaking to those algorithms by which root zone is > >signed. > > I'm glad we agree on this. Since SHOULD is only a slightly-diminished > form of MUST, ... I'd add that if you "do agree that MUST set of algorithms should be very narrow" then it follows... ...that you can't allow any nation to dictate that some sub-set of algorithms must be added to the MUST set, because the moment you do all comers will demand their alg suite be added and you no longer have a "narrow" set of MUST-implement algorithms. (Yes, I'm merely re-stating what has already been said. But perhaps this formulation will make the point clearer.) Therefore the IETF policy seems quite right to me. GOST can only become a MUST- or SHOULD-implement algorithm only if we need one more algorithm _and_ GOST is the best candidate. That said... > >Maybe this is the way the DNS system will develop, but now I think > >that the some effort to keep the DNS system united is justified. > > Unified is a goal we both agree upon, but mandated support for > national algorithms is NOT a unifying principle, it is a Balkanizing > principle (if you'll pardon the term). +1 ...note too that I don't see why Russia couldn't make GOST support a requirement for resolvers and DNS servers distributed in Russia. They'd want to sign their zones (at least top level ones) with RSA in addition to GOST, but the burden of doing so would be minimal. Any nation could take the approach of legislating MUST-implement sets within their borders. Note that failure to sign all the way to leaf zones with MUST-implement algorithms is, effectively, a way of dividing the namespace, but at least that would apply only to DNSSEC and not plain DNS. Note too that having national algorithms in the MUST-implement set wouldn't guarantee that the root zone would be signed with them. The only way to do that would be through political agreements with, say, ICANN, or forking the roots. All of which leads me to this conclusion: adding national algorithms to the DNSSEC MUST-implement list cannot achieve a political goal that DNSSEC deployments use that algorithm. So what would we get in exchange for burdening implementors? As far as I can see: nothing. Nico -- From ajs@shinkuro.com Wed Feb 10 11:04:02 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511543A7040 for ; Wed, 10 Feb 2010 11:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hQFSE55NKsI for ; Wed, 10 Feb 2010 11:04:01 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 76E1B3A6C7F for ; Wed, 10 Feb 2010 11:04:01 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C6ADE1ECB4E8; Wed, 10 Feb 2010 19:05:11 +0000 (UTC) Date: Wed, 10 Feb 2010 14:05:09 -0500 From: Andrew Sullivan To: Basil Dolmatov Message-ID: <20100210190509.GQ5187@shinkuro.com> References: <20100107222809.GA25747@shinkuro.com> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <4B5D1F85.1070900@cryptocom.ru> <4B72F5A7.3050308@cryptocom.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B72F5A7.3050308@cryptocom.ru> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Ralph Droms , ogud@ogud.com, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 19:04:02 -0000 On Wed, Feb 10, 2010 at 09:06:31PM +0300, Basil Dolmatov wrote: >> I'm glad we agree on this. Since SHOULD is only a slightly-diminished >> form of MUST, ... > Either SHOULD is the synonym of MUST and then the question rises what it > is present for if there is no real difference between it and MUST (it > "should" be named as obsolete), or SHOULD has it's own meaning > and should not be treated in discussions as MUST equivalent. My view has generally been that for each SHOULD, one needs to state the cases under which one might not do the named thing. So it's like MUST EXCEPT. If you want something truly optional, it's MAY. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dol@cryptocom.ru Wed Feb 10 10:05:25 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2663A6F03 for ; Wed, 10 Feb 2010 10:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHCiX9kaNrnY for ; Wed, 10 Feb 2010 10:05:24 -0800 (PST) Received: from mx.cryptocom.ru (mx.cryptocom.ru [89.188.97.107]) by core3.amsl.com (Postfix) with ESMTP id 6073B3A777B for ; Wed, 10 Feb 2010 10:05:23 -0800 (PST) Received: from [192.168.63.201] (ppp91-76-231-25.pppoe.mtu-net.ru [91.76.231.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 5F51A46602; Wed, 10 Feb 2010 21:06:32 +0300 (MSK) Message-ID: <4B72F5A7.3050308@cryptocom.ru> Date: Wed, 10 Feb 2010 21:06:31 +0300 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Stephen Kent References: <20100107222809.GA25747@shinkuro.com> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <4B5D1F85.1070900@cryptocom.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 10 Feb 2010 11:13:07 -0800 Cc: Andrew Sullivan , Ralph Droms , ogud@ogud.com, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 18:05:25 -0000 Stephen Kent пишет: > Basil, > > Sorry that I seem to have lost your message in my inbox for a while. > Replies inline below. > >>> ... >> Yes, we do disagree in principles (see below). >> >>> The question for both DNSSEC and SIDR/RPKI is how many algorithms >>> relying parties MUST/SHOULD be >>> >> I wondered why MUST and SHOULD are quoted together. I thought that it >> is two _different_ modal verbs with _different_ meaning and >> _different_ implementation demands. > > SHOULD is MUST with an allowance for "carefully weighed" exceptions. > Both indicate that a compliant implementation ought to have code that > supports the referenced feature. In this case, that would be code to > support GOST algs. Good shift in modal verbs . I am fully agree that implementations "ought to have" but not "must have" a code. This is the difference between MUST and SHOULD as I understand it. If SHOULD is used then "it is advised to have a code", but you can omit it (after "careful weighting") and still be compliant. If MUST is used - then you must have a code, otherwise you are not compliant. No options. Period. >> Thank you, Steve, you proposed one of the possible technologies which >> makes that possible (at least makes a forthcoming split more or less >> implicit). >> That does not mean that this technology is the _good_ one. It means >> that for the given set of circumstances this solution is >> _the_only_possible_ one. > > The local TA management capability that I have described for SIDR is > intended to deal with the general problem of an RP (or a sovereign > entity) wanting to create and manage a local view of the RPKI. It is > not primarily designed to accommodate national algorithms, although it > can be used for that was well. That's right. I tried to find a way and found it in with capability which has been developed for somewhat different purpose. > >> So, I quit the discussion in SIDR, not because of I was satisfied >> with the technology and solutions, but because of I have understood >> how I could maintain network interoperability even with this rigid >> technology and have had more urgent tasks to perform. >> >> I kindly ask to all participating parties do not try to castrate >> flexible protocol design of DNSSec to the SIDR/RPKI rigid approach. > > Oh, "castrate" seems like a pretty harsh term to use :-). Both the > RPKI and DNSSEC are flexible protocols. > We're debating the issue of how broad a set of algorithms MUST/SHOULD > be supported by RPs, which is an architectural (and political) issue. Having no means to inform other side about algorithms used is the thing that differs SIDR from DNSSec. >>> >> I do agree that MUST set of algorithms should be very narrow and >> limited generally speaking to those algorithms by which root zone is >> signed. > It is fine for DNSEXT to allocate algorithm IDs to national algorithms > like GOST, but it is not appropriate to mandate their support, for the > reasons cited in my review. > > I'm glad we agree on this. Since SHOULD is only a slightly-diminished > form of MUST, ... Either SHOULD is the synonym of MUST and then the question rises what it is present for if there is no real difference between it and MUST (it "should" be named as obsolete), or SHOULD has it's own meaning and should not be treated in discussions as MUST equivalent. > >> As for the other algorithms, it seems to me that the main goal of DNS >> system is the providing integral name service resolution. If one have >> to perform some additional steps (install different resolver >> software, include something and something) just to get access to the >> network names on some part of the world, then the obvious next step >> will be to point this different resolver to another root of the tree. > > Some might interpret this as a threat, even though I'm sure you didn't > mean it that way. > I want to make a reservation that I am not native English speaking person, so sometimes I use only literal meaning of the words when writing (and reading). In order to clarify I will use an example from my profession (I am a physicist): Imagine that one astronomer will estimate the orbit of some comet and say that "It is likely to hit the Earth". Will it be the "threat" from the astronomer to the Earth? No, I think that it will be just a "warning note", because the astronomer have no influence on this process, he can only calculate the orbits of comets. Definitely, some people could say that "this astronomer threats us with this comet", but it seems obvious that it is not the case. ;) >> Maybe this is the way the DNS system will develop, but now I think >> that the some effort to keep the DNS system united is justified. > > Unified is a goal we both agree upon, but mandated support for > national algorithms is NOT a unifying principle, it is a Balkanizing > principle (if you'll pardon the term). I am not familiar with this term and once more I object against putting the equal sign between MUST and SHOULD modal verbs. I still think that there is a significant difference between them which is worth keeping both of these verbs in the list of instruments of IETF standards description. So, noone is talking about "mandated support" (which means MUST), the bottom line is "to encourage support". dol@ > > Steve > From kent@bbn.com Wed Feb 10 12:15:30 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD30C3A75D8 for ; Wed, 10 Feb 2010 12:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsxmquEUds7j for ; Wed, 10 Feb 2010 12:15:30 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id DBA4E3A7794 for ; Wed, 10 Feb 2010 12:15:22 -0800 (PST) Received: from dhcp89-089-170.bbn.com ([128.89.89.170]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NfIz8-0004Ep-C5; Wed, 10 Feb 2010 15:16:30 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20100210190509.GQ5187@shinkuro.com> References: <20100107222809.GA25747@shinkuro.com> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <4B5D1F85.1070900@cryptocom.ru> <4B72F5A7.3050308@cryptocom.ru> <20100210190509.GQ5187@shinkuro.com> Date: Wed, 10 Feb 2010 14:26:30 -0500 To: Andrew Sullivan From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Ralph Droms , Basil Dolmatov , ogud@ogud.com, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 20:15:30 -0000 At 2:05 PM -0500 2/10/10, Andrew Sullivan wrote: >On Wed, Feb 10, 2010 at 09:06:31PM +0300, Basil Dolmatov wrote: >>> I'm glad we agree on this. Since SHOULD is only a slightly-diminished >>> form of MUST, ... >> Either SHOULD is the synonym of MUST and then the question rises what it >> is present for if there is no real difference between it and MUST (it >> "should" be named as obsolete), or SHOULD has it's own meaning >> and should not be treated in discussions as MUST equivalent. > >My view has generally been that for each SHOULD, one needs to state >the cases under which one might not do the named thing. So it's like >MUST EXCEPT. If you want something truly optional, it's MAY. > >A Andrew, Thanks for a better characterization of SHOULD vs. MUST than what I provided. Steve From ajs@shinkuro.com Thu Feb 11 06:14:36 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AB573A74EB for ; Thu, 11 Feb 2010 06:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6Hmt2+Im8RX for ; Thu, 11 Feb 2010 06:14:35 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9C58B3A70CF for ; Thu, 11 Feb 2010 06:14:35 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 252C31ECB4E8; Thu, 11 Feb 2010 14:15:49 +0000 (UTC) Date: Thu, 11 Feb 2010 09:15:47 -0500 From: Andrew Sullivan To: Basil Dolmatov Message-ID: <20100211141547.GD9592@shinkuro.com> References: <20100107222809.GA25747@shinkuro.com> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <4B5D1F85.1070900@cryptocom.ru> <4B72F5A7.3050308@cryptocom.ru> <20100210190509.GQ5187@shinkuro.com> <4B732624.7040303@cryptocom.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B732624.7040303@cryptocom.ru> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Ralph Droms , ogud@ogud.com, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 14:14:36 -0000 On Thu, Feb 11, 2010 at 12:33:24AM +0300, Basil Dolmatov wrote: > Could you be so kind to point to a couple of examples of such usage of > SHOULD in IETF documents?
> Where SHOULD is used and exceptions  are clearly listed.
>
> That will help to understand the situation with this verb better.
> Thanks in advance,
[Note that it's much easier for me if you send your mail multipart, so I don't have to read plain HTML.] A good example of this style, I think, is in RFC 4308. For instance, look at these bits: Implementations that use UI suites SHOULD also provide a management interface for specifying values for individual cryptographic options. That is, it is unlikely that UI suites are a complete solution for matching the security policies of many IPsec users, and therefore an interface that gives a more complete set of options should be used as well. IPsec implementations that use these UI suites SHOULD use the suite names listed here. IPsec implementations SHOULD NOT use names different than those listed here for the suites that are described, and MUST NOT use the names listed here for suites that do not match these values. These requirements are necessary for interoperability. The first paragraph says you SHOULD provide a management interface, because it's unlikely the UI suite is a complete solution for matching the security policies. By implication, the case in which you need not provide the management interface is the case where the UI suite is _guaranteed_ to provide the complete solution. There could be such cases, though (I can imagine an organization that had tight rules about exactly what was allowed, and that could control the UI for everyone). The second paragraph says SHOULD and tells you what the requirements are needed for. By implication, if you don't care about interoperability, then you could violate this. (I like this example because it's a bizarre exception, since the whole point of an RFC is interoperability.) Clearer? (If not, trim the cc:s when following up: I doubt everyone else needs to be seeing all this.) A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dol@cryptocom.ru Wed Feb 10 13:32:25 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01CBF3A77A5 for ; Wed, 10 Feb 2010 13:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy2JvEgtUOne for ; Wed, 10 Feb 2010 13:32:21 -0800 (PST) Received: from mx.cryptocom.ru (mx.cryptocom.ru [89.188.97.107]) by core3.amsl.com (Postfix) with ESMTP id 9C6C03A7607 for ; Wed, 10 Feb 2010 13:32:20 -0800 (PST) Received: from [192.168.63.201] (ppp91-76-231-25.pppoe.mtu-net.ru [91.76.231.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id E04D646567; Thu, 11 Feb 2010 00:33:24 +0300 (MSK) Message-ID: <4B732624.7040303@cryptocom.ru> Date: Thu, 11 Feb 2010 00:33:24 +0300 From: Basil Dolmatov User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Andrew Sullivan References: <20100107222809.GA25747@shinkuro.com> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <4B5D1F85.1070900@cryptocom.ru> <4B72F5A7.3050308@cryptocom.ru> <20100210190509.GQ5187@shinkuro.com> In-Reply-To: <20100210190509.GQ5187@shinkuro.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 11 Feb 2010 08:21:48 -0800 Cc: Ralph Droms , ogud@ogud.com, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 21:32:25 -0000 Andrew Sullivan пишет: 
On Wed, Feb 10, 2010 at 09:06:31PM +0300, Basil Dolmatov wrote:
  
I'm glad we agree on this. Since SHOULD is only a slightly-diminished  
form of MUST, ...
      
Either SHOULD is the synonym of MUST and then the question rises what it  
is present for if there is no real difference between it and MUST (it  
"should" <grin> be named as obsolete), or SHOULD has it's own meaning  
and should not be treated in discussions as MUST equivalent.
    

My view has generally been that for each SHOULD, one needs to state
the cases under which one might not do the named thing.  So it's like
MUST EXCEPT.
Could you be so kind to point to a couple of examples of such usage of SHOULD in IETF documents?
Where SHOULD is used and exceptions  are clearly listed.

That will help to understand the situation with this verb better.
Thanks in advance,

dol@

From kent@bbn.com Thu Feb 11 08:28:52 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77D1C3A773D for ; Thu, 11 Feb 2010 08:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eT89lscXuKUs for ; Thu, 11 Feb 2010 08:28:51 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 84E483A773C for ; Thu, 11 Feb 2010 08:28:51 -0800 (PST) Received: from dhcp89-089-170.bbn.com ([128.89.89.170]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NfbvY-000Mdh-0i; Thu, 11 Feb 2010 11:30:04 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4B72F5A7.3050308@cryptocom.ru> References: <20100107222809.GA25747@shinkuro.com> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <4B5D1F85.1070900@cryptocom.ru> <4B72F5A7.3050308@cryptocom.ru> Date: Thu, 11 Feb 2010 11:29:55 -0500 To: Basil Dolmatov From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Andrew Sullivan , Ralph Droms , ogud@ogud.com, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 16:28:52 -0000 At 9:06 PM +0300 2/10/10, Basil Dolmatov wrote: >>... >Good shift in modal verbs . >I am fully agree that implementations "ought to have" but not "must >have" a code. >This is the difference between MUST and SHOULD as I understand it. >If SHOULD is used then "it is advised to have a code", but you can >omit it (after "careful weighting") and still be compliant. >If MUST is used - then you must have a code, otherwise you are not >compliant. No options. Period. I think Andrew's characterization is better than mine, and his follow-up message to you provied good examples. >... >>We're debating the issue of how broad a set of algorithms >>MUST/SHOULD be supported by RPs, which is an architectural (and >>political) issue. >Having no means to inform other side about algorithms used is the >thing that differs SIDR from DNSSec. I agree that there is a big difference between protocols where one can discover or negotiate protocol options and ones where this is not the case. But I believe that SIDR and DNESEC are pretty much the same in this respect. Both the RPKI and DNSSEC publish data that discloses what algs the publisher has chosen to employ. Relying parties either accommodate those choices or they do not make use of the signed data. >>... >> >>I'm glad we agree on this. Since SHOULD is only a >>slightly-diminished form of MUST, ... >Either SHOULD is the synonym of MUST and then the question rises >what it is present for if there is no real difference between it and >MUST (it "should" be named as obsolete), or SHOULD has it's >own meaning and should not be treated in discussions as MUST >equivalent. See Andrew's message, to which Im alluded above. >>... >I want to make a reservation that I am not native English speaking >person, so sometimes I use only literal meaning of the words when >writing (and reading). >In order to clarify I will use an example from my profession (I am a >physicist): > >Imagine that one astronomer will estimate the orbit of some comet >and say that "It is likely to hit the Earth". >Will it be the "threat" from the astronomer to the Earth? No, I >think that it will be just a "warning note", because the astronomer >have no influence on this process, he can only calculate the orbits >of comets. >Definitely, some people could say that "this astronomer threats us >with this comet", but it seems obvious that it is not the case. ;) OK. I'll interpret your comment as a comet warning :-). > >>>Maybe this is the way the DNS system will develop, but now I think >>>that the some effort to keep the DNS system united is justified. >> >>Unified is a goal we both agree upon, but mandated support for >>national algorithms is NOT a unifying principle, it is a >>Balkanizing principle (if you'll pardon the term). >I am not familiar with this term and once more I object against >putting the equal sign between MUST and SHOULD modal verbs. >I still think that there is a significant difference between them >which is worth keeping both of these verbs in the list of >instruments of IETF standards description. > >So, noone is talking about "mandated support" (which means MUST), >the bottom line is "to encourage support". MUST and SHOULD are not the same, but they are no so different as you seem to suggest. Steve From weiler+secdir@watson.org Thu Feb 11 09:49:59 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB1E3A7776 for ; Thu, 11 Feb 2010 09:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srOAkWxcwB2m for ; Thu, 11 Feb 2010 09:49:58 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 769FB3A7747 for ; Thu, 11 Feb 2010 09:49:54 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o1BHp82C040038 for ; Thu, 11 Feb 2010 12:51:08 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o1BHp8K3040035 for ; Thu, 11 Feb 2010 12:51:08 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 11 Feb 2010 12:51:08 -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, 11 Feb 2010 12:51:09 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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, 11 Feb 2010 17:49:59 -0000 Jeff Huztelman is next in the rotation. There are some new aliases available at tools.ietf.org that may make it easier to send reviews to everyone concerned. In particular, draftname.all@tools.ietf.org will reach document editors, WG chairs, and others who need to be notified about a given draft (e.g. a PROTO shepherd who isn't the AD). Feel free to use that, and please continue to send reviews to secdir@ietf.org and iesg@ietf.org as well. (Or to ietf@ietf.org, if you wish.) More info is available on the wiki. Documents on the telechat agenda typically have a last call end date before the date shown below; reviews by the end of last call are typically more appreciated by the doc editors. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2010-02-18 Reviewer Deadline Draft Derek Atkins T 2010-02-16 draft-ietf-ccamp-gmpls-dcsc-channel-ext-03 Pat Cain T 2010-02-16 draft-ietf-mpls-tp-nm-framework-04 Donald Eastlake TR2010-02-16 draft-zorn-radius-pkmv1-10 Shawn Emery TR2010-02-16 draft-ietf-avt-app-rtp-keepalive-07 Tobias Gondrom T 2010-02-16 draft-ietf-dhc-dhcpv6-vendor-message-01 Phillip Hallam-Baker T 2010-02-16 draft-ietf-tcpm-icmp-attacks-10 Joe Salowey T 2010-02-16 draft-ietf-geopriv-lis-discovery-13 Hannes Tschofenig T 2010-02-16 draft-allbery-afs-srv-records-03 Larry Zhu T 2010-02-16 draft-ietf-ecrit-location-hiding-req-02 Larry Zhu T 2010-02-16 draft-ietf-pce-p2mp-req-05 For telechat 2010-03-04 Reviewer Deadline Draft Shawn Emery TR2010-03-02 draft-ietf-mediactrl-mixer-control-package-10 Dan Harkins T 2010-03-02 draft-arkko-pana-iana-01 David McGrew T 2010-03-02 draft-ietf-dnsext-dnssec-gost-06 Brian Weis TR2010-03-02 draft-ietf-mediactrl-sip-control-framework-11 Nico Williams T 2010-03-02 draft-gould-rfc4310bis-04 Last calls and special requests: Reviewer Deadline Draft Rob Austein 2009-11-28 draft-ietf-pkix-attr-cert-mime-type-02 Rob Austein 2010-02-11 draft-ietf-ipsecme-esp-null-heuristics-05 Dave Cridland 2010-02-12 draft-ietf-rmt-flute-revised-10 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Alan DeKok 2010-02-19 draft-westerlund-mmusic-3gpp-sdp-rtsp-07 Shawn Emery 2010-02-16 draft-ietf-ccamp-gmpls-mln-extensions-11 Steve Hanna 2010-03-04 draft-rosen-urn-nena-01 David Harrington 2010-02-19 draft-ietf-avt-rtp-ipmr-12 Sam Hartman 2010-02-22 draft-ietf-ccamp-ethernet-traffic-parameters-10 Paul Hoffman 2010-02-22 draft-ietf-ccamp-gmpls-ether-svcs-04 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Love Hornquist-Astrand 2009-10-13 draft-ietf-idnabis-mappings-05 Love Hornquist-Astrand 2010-02-22 draft-ietf-ccamp-gmpls-mef-uni-03 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Sandy Murphy R2009-11-18 draft-ietf-mpls-mpls-and-gmpls-security-framework-07 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Chris Newman 2010-01-07 draft-ietf-krb-wg-preauth-framework-15 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Glen Zorn 2010-01-28 draft-ietf-pkix-tamp-05 From jhutz@cmu.edu Thu Feb 11 09:54:48 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28EF3A7760 for ; Thu, 11 Feb 2010 09:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBCZCGrlStF6 for ; Thu, 11 Feb 2010 09:54:47 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id E64013A73F1 for ; Thu, 11 Feb 2010 09:54:46 -0800 (PST) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o1BHthAY007203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 12:55:43 -0500 (EST) Date: Thu, 11 Feb 2010 12:55:43 -0500 From: Jeffrey Hutzelman To: Stephen Kent , Basil Dolmatov Message-ID: <9364B2468B4FBB516F5CEB46@lysithea.fac.cs.cmu.edu> In-Reply-To: <28397_1265905809_o1BGU87p018787_p0624080cc799df651250@[128.89.89.170]> References: <20100107222809.GA25747@shinkuro.com> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <4B5D1F85.1070900@cryptocom.ru> <4B72F5A7.3050308@cryptocom.ru> <28397_1265905809_o1BGU87p018787_p0624080cc799df651250@[128.89.89.170]> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: Andrew Sullivan , secdir@ietf.org, ogud@ogud.com, Ralph Droms Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 17:54:48 -0000 --On Thursday, February 11, 2010 11:29:55 AM -0500 Stephen Kent wrote: > At 9:06 PM +0300 2/10/10, Basil Dolmatov wrote: >>> ... >> Good shift in modal verbs . >> I am fully agree that implementations "ought to have" but not "must >> have" a code. >> This is the difference between MUST and SHOULD as I understand it. >> If SHOULD is used then "it is advised to have a code", but you can >> omit it (after "careful weighting") and still be compliant. >> If MUST is used - then you must have a code, otherwise you are not >> compliant. No options. Period. > > I think Andrew's characterization is better than mine, and his follow-up > message to you provied good examples. > >> ... >>> We're debating the issue of how broad a set of algorithms >>> MUST/SHOULD be supported by RPs, which is an architectural (and >>> political) issue. >> Having no means to inform other side about algorithms used is the >> thing that differs SIDR from DNSSec. > > I agree that there is a big difference between protocols where one can > discover or negotiate protocol options and ones where this is not the > case. But I believe that SIDR and DNESEC are pretty much the same in this > respect. Both the RPKI and DNSSEC publish data that discloses what algs > the publisher has chosen to employ. Relying parties either accommodate > those choices or they do not make use of the signed data. > >>> ... >>> >>> I'm glad we agree on this. Since SHOULD is only a >>> slightly-diminished form of MUST, ... >> Either SHOULD is the synonym of MUST and then the question rises >> what it is present for if there is no real difference between it and >> MUST (it "should" be named as obsolete), or SHOULD has it's >> own meaning and should not be treated in discussions as MUST >> equivalent. > > See Andrew's message, to which Im alluded above. >>> ... >> I want to make a reservation that I am not native English speaking >> person, so sometimes I use only literal meaning of the words when >> writing (and reading). >> In order to clarify I will use an example from my profession (I am a >> physicist): >> >> Imagine that one astronomer will estimate the orbit of some comet >> and say that "It is likely to hit the Earth". >> Will it be the "threat" from the astronomer to the Earth? No, I >> think that it will be just a "warning note", because the astronomer >> have no influence on this process, he can only calculate the orbits >> of comets. >> Definitely, some people could say that "this astronomer threats us >> with this comet", but it seems obvious that it is not the case. ;) > > OK. I'll interpret your comment as a comet warning :-). > >> >>>> Maybe this is the way the DNS system will develop, but now I think >>>> that the some effort to keep the DNS system united is justified. >>> >>> Unified is a goal we both agree upon, but mandated support for >>> national algorithms is NOT a unifying principle, it is a >>> Balkanizing principle (if you'll pardon the term). >> I am not familiar with this term and once more I object against >> putting the equal sign between MUST and SHOULD modal verbs. >> I still think that there is a significant difference between them >> which is worth keeping both of these verbs in the list of >> instruments of IETF standards description. >> >> So, noone is talking about "mandated support" (which means MUST), >> the bottom line is "to encourage support". > > MUST and SHOULD are not the same, but they are no so different as you > seem to suggest. It might be helpful for everyone to remember that while English has fairly loose definitions of "must" and "should", in this context MUST and SHOULD have precisely the meanings given them by RFC2119. In particular, SHOULD is not mere advice or encouragement; it is a requirement almost as strong as MUST. It doesn't mean "we think it's a good idea for you to do this"; it means "you absolutely have to do this unless...". -- Jeff From ajs@shinkuro.com Thu Feb 11 10:14:12 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A843228C15E for ; Thu, 11 Feb 2010 10:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0LKhuPMW-2r for ; Thu, 11 Feb 2010 10:14:11 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 2F8E63A753F for ; Thu, 11 Feb 2010 10:14:11 -0800 (PST) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 35C8A1ECB4E8; Thu, 11 Feb 2010 18:15:25 +0000 (UTC) Date: Thu, 11 Feb 2010 13:15:23 -0500 From: Andrew Sullivan To: Jeffrey Hutzelman Message-ID: <20100211181521.GG9592@shinkuro.com> References: <20100107222809.GA25747@shinkuro.com> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <4B5D1F85.1070900@cryptocom.ru> <4B72F5A7.3050308@cryptocom.ru> <28397_1265905809_o1BGU87p018787_p0624080cc799df651250@[128.89.89.170]> <9364B2468B4FBB516F5CEB46@lysithea.fac.cs.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9364B2468B4FBB516F5CEB46@lysithea.fac.cs.cmu.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: secdir@ietf.org, Basil Dolmatov , ogud@ogud.com, Ralph Droms Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 18:14:12 -0000 On Thu, Feb 11, 2010 at 12:55:43PM -0500, Jeffrey Hutzelman wrote: > SHOULD is not mere advice or encouragement; it is a requirement almost as > strong as MUST. It doesn't mean "we think it's a good idea for you to do > this"; it means "you absolutely have to do this unless...". To be fair to Basil, the actual text of 2119 is not as tight as you're claiming: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. That seems to me to say that, as long as you know what you're doing and have thought about it a lot, you can go ahead with your decision not to do the RECOMMENDED thing and still be considered conforming. The reason I prefer that authors and editors include the limiting conditions is because of that "full implications" condition. I think that if you leave the full implications undefined, you're inviting the reader to make their own determination. Interoperability is not best served thereby, so I think it better to state the counter-considerations (even indirectly). As Basil pointed out, there are plenty of SHOULDs in documents that don't actually say when you're allowed to violate them. In practice, this means that people will violate them when it's really really convenient, as opposed to the mere bar of convenient we get from MAY. (Note that by this argument and with the current text, resolver implementers could decide that they won't support GOST on the grounds that their user base doesn't really need GOST, and they don't care about interoperating with such an algorithm anyway. Since there's no limiting condition in the text, I'd be willing to make this argument were I playing protocol lawyer.) I also want to be clear that I'm not the DNSEXT shepherd for this document, and I offically have no opinion one way or the other about whether the language ought to be SHOULD or MAY. I think I've said that before, but I want to reiterate. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From jhutz@cmu.edu Thu Feb 11 10:27:43 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832233A786F for ; Thu, 11 Feb 2010 10:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwinBwUriDGt for ; Thu, 11 Feb 2010 10:27:42 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 5101C3A7871 for ; Thu, 11 Feb 2010 10:27:42 -0800 (PST) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o1BISkxm023600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 13:28:47 -0500 (EST) Date: Thu, 11 Feb 2010 13:28:46 -0500 From: Jeffrey Hutzelman To: Andrew Sullivan Message-ID: In-Reply-To: <20100211181521.GG9592@shinkuro.com> References: <20100107222809.GA25747@shinkuro.com> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <4B5D1F85.1070900@cryptocom.ru> <4B72F5A7.3050308@cryptocom.ru> <28397_1265905809_o1BGU87p018787_p0624080cc799df651250@[128.89.89.170]> <9364B2468B4FBB516F5CEB46@lysithea.fac.cs.cmu.edu> <20100211181521.GG9592@shinkuro.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: secdir@ietf.org, Basil Dolmatov , Ralph Droms , ogud@ogud.com Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 18:27:43 -0000 --On Thursday, February 11, 2010 01:15:23 PM -0500 Andrew Sullivan wrote: >> SHOULD is not mere advice or encouragement; it is a requirement almost >> as strong as MUST. It doesn't mean "we think it's a good idea for you >> to do this"; it means "you absolutely have to do this unless...". > > To be fair to Basil, the actual text of 2119 is not as tight as you're > claiming: > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. That's exactly as tight as I'm claiming; I simply omitted the details of the "unless..." part. > That seems to me to say that, as long as you know what you're doing > and have thought about it a lot, you can go ahead with your decision > not to do the RECOMMENDED thing and still be considered conforming. Yes. > The reason I prefer that authors and editors include the limiting > conditions is because of that "full implications" condition. I think > that if you leave the full implications undefined, you're inviting the > reader to make their own determination. Interoperability is not best > served thereby, so I think it better to state the > counter-considerations (even indirectly). When possible, yes. But sometimes you can't do any better than mentioning things to think about, and sometimes you can't even do that. SHOULD is really for those cases -- if it's possible to list the exceptions, then list them, and use MUST. > As Basil pointed out, there are plenty of SHOULDs in documents that > don't actually say when you're allowed to violate them. In practice, > this means that people will violate them when it's really really > convenient, as opposed to the mere bar of convenient we get from MAY. Certainly people do that. But that doesn't mean we should further dilute the meaning of SHOULD by assuming that it will always be interpreted more loosely than intended, or by saying that a particular algorithm SHOULD be implemented when what we really mean is that we would like people to implement it. > (Note that by this argument and with the current text, resolver > implementers could decide that they won't support GOST on the grounds > that their user base doesn't really need GOST, and they don't care > about interoperating with such an algorithm anyway. Since there's no > limiting condition in the text, I'd be willing to make this argument > were I playing protocol lawyer.) Generally, if we believe the argument "I don't care about interoperating with foo" is a reasonable one, then saying "SHOULD foo" is just as wrong as saying "MUST foo". SHOULD needs a good interop/security/stability reason just as much as MUST. -- Jeff From dave.cridland@isode.com Thu Feb 11 13:32:24 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C321E3A75F6; Thu, 11 Feb 2010 13:32:24 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyCmdhzcA--d; Thu, 11 Feb 2010 13:32:24 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id DF5003A75B5; Thu, 11 Feb 2010 13:32:23 -0800 (PST) Received: from puncture ((unknown) [217.155.137.60]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 11 Feb 2010 21:33:31 +0000 X-SMTP-Protocol-Errors: NORDNS Message-Id: <9010.1265924009.626613@puncture> Date: Thu, 11 Feb 2010 21:33:29 +0000 From: Dave Cridland To: , The IESG , Security Area Directorate MIME-Version: 1.0 Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: [secdir] Security Directorate review of draft-ietf-rmt-flute-revised-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Feb 2010 21:32:24 -0000 I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Looking at the extensive, and well structured, security considerations suggests to me that the general scope of attacks is well documented. Several options are provided in Section 7.2.2, and in particular file vs packet level protection seem not to be wholly described. (It seems to be suggested in other sections that both are needed). I also note that the document appears to advise that MIME types can be deduced from the filename - such deduction has been known to be susceptible to damage, and I would further note that in the case of many URIs, there is a provided type already available by (possibly partial) resolution of the URI. In general, it's better to discard and replace file extensions based on the known media type to avoid the "foo.jpg.pif" cases. Dave. From new-work-bounces@ietf.org Fri Feb 12 08:04:37 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663DD28C1A8; Fri, 12 Feb 2010 08:04:37 -0800 (PST) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16CD428C13E for ; Thu, 11 Feb 2010 12:18:45 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJgpewWZvNPt for ; Thu, 11 Feb 2010 12:18:44 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 2DD5E3A753F for ; Thu, 11 Feb 2010 12:18:44 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1NffW2-0004jc-79 for public-new-work-dist@listhub.w3.org; Thu, 11 Feb 2010 20:19:58 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NffW1-0004ij-8d for public-new-work@listhub.w3.org; Thu, 11 Feb 2010 20:19:57 +0000 Received: from jay.w3.org ([128.30.52.169]) by bart.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NffVz-0002FC-Uf; Thu, 11 Feb 2010 20:19:57 +0000 Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NffVz-0004FB-Nh; Thu, 11 Feb 2010 15:19:55 -0500 Message-Id: From: Ian Jacobs To: public-new-work@w3.org Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Feb 2010 14:19:55 -0600 X-Mailer: Apple Mail (2.936) X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1.8, BAYES_00=-2.599 X-W3C-Scan-Sig: bart.w3.org 1NffVz-0002FC-Uf bf9969d32061e9ad319f892003ab4976 X-Original-To: public-new-work@w3.org Archived-At: Resent-From: public-new-work@w3.org X-Mailing-List: archive/latest/53 X-Loop: public-new-work@w3.org Resent-Sender: public-new-work-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Thu, 11 Feb 2010 20:19:58 +0000 X-Mailman-Approved-At: Fri, 12 Feb 2010 08:04:36 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 12 Feb 2010 08:15:54 -0800 Subject: [secdir] [New-work] Proposed W3C Charter: Forms Working Group (until 2010-03-11) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 16:04:37 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the XForms Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Forms Working Group: http://www.w3.org/MarkUp/Forms/2009/charter2010 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 2010-03-11 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 Steven Pemberton, co-Chair . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/MarkUp/Forms/ [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 new-work-bounces@ietf.org Fri Feb 12 08:04:37 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C77F28C1B8; Fri, 12 Feb 2010 08:04:37 -0800 (PST) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3DB3A75CA for ; Thu, 11 Feb 2010 12:36:03 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdT4Qw-5pzWt for ; Thu, 11 Feb 2010 12:36:02 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 52CAA3A75C8 for ; Thu, 11 Feb 2010 12:36:02 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Nffmm-0002Ua-N1 for public-new-work-dist@listhub.w3.org; Thu, 11 Feb 2010 20:37:16 +0000 Received: from bart.w3.org ([128.30.52.63]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Nffmm-0002Tc-1L for public-new-work@listhub.w3.org; Thu, 11 Feb 2010 20:37:16 +0000 Received: from jay.w3.org ([128.30.52.169]) by bart.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Nffmk-0006vP-PK; Thu, 11 Feb 2010 20:37:16 +0000 Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Nffmk-00057L-Hp; Thu, 11 Feb 2010 15:37:14 -0500 Message-Id: <9FF4AB8C-11B1-4360-A5B6-78F2BA1F7A0D@w3.org> From: Ian Jacobs To: public-new-work@w3.org Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 11 Feb 2010 14:37:14 -0600 X-Mailer: Apple Mail (2.936) X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1.8, BAYES_00=-2.599 X-W3C-Scan-Sig: bart.w3.org 1Nffmk-0006vP-PK d9af3a99db7b17d556c2f61e6b3cc3db X-Original-To: public-new-work@w3.org Archived-At: Resent-From: public-new-work@w3.org X-Mailing-List: archive/latest/54 X-Loop: public-new-work@w3.org Resent-Sender: public-new-work-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Thu, 11 Feb 2010 20:37:16 +0000 X-Mailman-Approved-At: Fri, 12 Feb 2010 08:04:36 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 12 Feb 2010 08:15:55 -0800 Subject: [secdir] [New-work] Proposed W3C Charter: Web Fonts Working Group (until 2010-03-12) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2010 16:04:37 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to create a new Fonts Activity (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web Fonts Working Group: http://www.w3.org/2009/08/WebFonts/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 2010-03-12 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 Chris Lilley . Thank you, Ian Jacobs, Head of W3C Communications [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 pcain2@mail2.coopercain.com Fri Feb 12 16:26:18 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0623A7924; Fri, 12 Feb 2010 16:26:18 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2Bd84pgrlXR; Fri, 12 Feb 2010 16:26:17 -0800 (PST) Received: from server1.acmehacking.com (server1.acmehacking.com [72.51.39.79]) by core3.amsl.com (Postfix) with ESMTP id BA4A03A70D4; Fri, 12 Feb 2010 16:26:17 -0800 (PST) Received: from familyroom (c-76-118-182-57.hsd1.ma.comcast.net [76.118.182.57]) (authenticated bits=0) by server1.acmehacking.com (8.14.3/8.13.8) with ESMTP id o1D0RW8b004239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Feb 2010 18:27:36 -0600 Received: from familyroom by familyroom (PGP Universal service); Fri, 12 Feb 2010 19:27:33 -0500 X-PGP-Universal: processed; by familyroom on Fri, 12 Feb 2010 19:27:33 -0500 From: "pat cain" To: , Date: Fri, 12 Feb 2010 19:27:29 -0500 Message-ID: <02e701caac43$55881b50$009851f0$@coopercain.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqsQ0lXYQjh7jT0SbSDo/DvdLO3gw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] Security area review of draft-ietf-mpls-tp-nm-framework-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 00:26:18 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network. The Security Considerations section is the basis of my comment. I don't think the first two sentences are sentences. At least I think they need to be restated to clarify their meaning. The section states: " Provisions to any of the network mechanisms designed to satisfy the requirements described herein need to prevent their unauthorized use and provide a means for an operator to prevent denial of service attacks if those network mechanisms are used in such an attack. Solutions need to provide mechanisms to prevent private information from being accessed by unauthorized eavesdropping, or being directly obtained by an unauthenticated network element, system or user." Using terminology from the document, I think the paragraphs should really say something to the effect of: "Many of the EMF Interfaces (Section 2.3) are critical to proper NE operation and need to be protected from denial of service conditions or attack. The EMF Interfaces that use or access private information should be protected from eavesdropping or being accessed by unauthorized network elements, systems, or users. " Since the next part of the section points the reader to the ITU and other RFC documents, it should flow okay. Although I am by no means an MPLS expert, the rest of the document looked fine. [As a side note, normally the term 'unauthorized eavesdropping' is not used. Eavesdropping is always performed by an unauthorized party; if they are authorized it's called 'network monitoring'. ;) ] Pat Cain From hallam@gmail.com Fri Feb 12 18:26:32 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74E928C263; Fri, 12 Feb 2010 18:26:32 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4ug-1eXejsy; Fri, 12 Feb 2010 18:26:31 -0800 (PST) Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by core3.amsl.com (Postfix) with ESMTP id 3505E28C133; Fri, 12 Feb 2010 18:26:31 -0800 (PST) Received: by pzk5 with SMTP id 5so4689467pzk.29 for ; Fri, 12 Feb 2010 18:27:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=qQ6bEIjBci1YZ1sOYi8n+vkHY5qL/xkr9QV6t6Vp8Ig=; b=FMGSJBEeVKgbwEdLC4YaEkJivSu12QKM0o73DfewS0Vp7AblFuVyfRzLKJwKSk3Yqh KCBWGTWQFXDG11aE3AzFdJD/z0DIiTdsKGEkHMnPeHcK7mVM5K6h7dKpS7NWryNJ10/A wsdCZpTchVeB26rZa2Ne+A6BY5bq332b3lI0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TukWgUiZY/LQg9PKFD/rSnNEhVY96OHV6C46BSX2JSQS5guawqFjv0E7hHHtrtetLS bbyKTSer2ecgp5paS8Nq4AXP/sbaU5yVydzG27o6uCbnD3T0xzXjw9+fS11AUgX56S45 RHVCKv4gYvEPoVDMyUjs+xwAFMq2Y4QcudB0g= MIME-Version: 1.0 Received: by 10.115.2.20 with SMTP id e20mr1529649wai.50.1266028069451; Fri, 12 Feb 2010 18:27:49 -0800 (PST) Date: Fri, 12 Feb 2010 21:27:49 -0500 Message-ID: From: Phillip Hallam-Baker To: secdir@ietf.org, fernando@gont.com.ar, tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 02:26:33 -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. ICMP is one of those IP layer protocols that we all have some idea exist even if only the network level people understand what they do. This document is designed to describe security issues arising from the ICMP protocol and commonly implemented counter-measures. The principal security risks considered are service risks. ICMP may be used to perform certain denial of service and performance downgrade attacks. As such it probably needs rather more justification than 'we have always done this' when building critical infrastructures. Overall, Given that TCP streams will eventually time-out, I have something of a hard time seeing why we would be using a non-authenticated control protocol at all. Yes, I know the legacy reasons etc. etc. But this is not the way we would approach this problem today. This argument is almost made on page 15. Some statement giving the case for taking notice of ICMP messages at all is in order. It might well be that an appropriate control in certain cases would be to turn off ICMP hard errors and rely on timeouts, I am thinking here of critical infrastructure applications and communications between hosts running BGP functions. In particular I note that the draft says "It is interesting to note that, as ICMP error messages are transmitted unreliably, transport protocols should not depend on them for correct functioning." Given the extreme approach to security of starting from nothing and only adding systems that are essential, this would seem to suggest ICMP is not necessary and could be eliminated. There may be a case to the contrary but it needs to be made before page 15. Page 15/16 The following phrase repeats in a way that suggests an editing oversight: aborting the connection would be to ignore the valuable feature of the Internet that for many internal failures it reconstructs its function without any disruption of the end points Page 24-26 A more general way of describing the mitigation strategy would be to point out the general principle that error messages may be ignored whenever a packet indicating success is received within the timeout window. In other words no final processing decisions should be made on an unauthenticated ICMP packet until after the timeout window expires. -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From new-work-bounces@ietf.org Sun Feb 14 22:07:07 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150F83A7934; Sun, 14 Feb 2010 22:07:07 -0800 (PST) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D39928C1D4 for ; Fri, 12 Feb 2010 11:06:41 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu22TmxcebhC for ; Fri, 12 Feb 2010 11:06:38 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id 947D43A785D for ; Fri, 12 Feb 2010 11:06:36 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1Ng0rp-0002eV-VC for public-new-work-dist@listhub.w3.org; Fri, 12 Feb 2010 19:07:54 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Ng0rp-0002dc-HF for public-new-work@listhub.w3.org; Fri, 12 Feb 2010 19:07:53 +0000 Received: from jay.w3.org ([128.30.52.169]) by lisa.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Ng0ro-0002Vt-BF; Fri, 12 Feb 2010 19:07:53 +0000 Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Ng0ro-0005U5-3i; Fri, 12 Feb 2010 14:07:52 -0500 Message-Id: <727F5E1D-802A-45DB-8DA1-AFFD29928A2A@w3.org> From: Ian Jacobs To: public-new-work@w3.org Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 12 Feb 2010 13:07:51 -0600 X-Mailer: Apple Mail (2.936) X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1.8, BAYES_00=-2.599 X-W3C-Scan-Sig: lisa.w3.org 1Ng0ro-0002Vt-BF 76954727608c339b17196453fe190c46 X-Original-To: public-new-work@w3.org Archived-At: Resent-From: public-new-work@w3.org X-Mailing-List: archive/latest/55 X-Loop: public-new-work@w3.org Resent-Sender: public-new-work-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Fri, 12 Feb 2010 19:07:53 +0000 X-Mailman-Approved-At: Sun, 14 Feb 2010 22:07:05 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Sun, 14 Feb 2010 22:46:21 -0800 Subject: [secdir] [New-work] W3C Workshop: Future Standards for Model-Based User Interfaces 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, 15 Feb 2010 06:07:07 -0000 Dear Colleagues, I am pleased to announce an upcoming W3C Workshop: Future Standards for Model-Based User Interfaces 13-14 May 2001 Rome, Italy http://www.w3.org/2010/02/mbui/cfp Hosted by CNR-ISTI [1] Co-Chairs: Dave Raggett (W3C) and Fabio Patern=F2 (CNR-ISTI) Participants will examine the challenges facing Web developers due to variations in device capabilities, modes of interaction and software standards, the need to support assistive technologies for accessibility, and the demand for richer user interfaces. Discussion will focus on reviewing research on model-based design of context- sensitive user interfaces in relation to these challenges, and the opportunities for new open standards in the area of Model-Based User Interfaces. Important dates: Now: Notify us of your interest in participating in the workshop, see the requirements for participation [2]. 2 April: Deadline for submission of your statement of interest, see [2]. 16 April: Acceptance notifications and registration instructions sent. Program and accepted statements of interest posted on the = Workshop site. 30 April: Deadline for Registration 13-14 May: Workshop You should consider participating in this workshop if you are in one of the following communities: =95 Model-Based (or Model-Driven) UI technology vendors and developers, including open source projects. =95 Companies that own solutions for the development of multi-target, context-sensitive, adaptive User Interfaces. =95 Companies seeking to exploit Model-Based Approaches internally. =95 Software vendors or open source projects that currently offer XML- based languages for the description of user interfaces targeted to the desktop environment. =95 Government organizations seeking to the standardization of UI development. =95 Academic researchers with an interest in Model-Based UI Development. The Workshop is free of charge and open to anyone, subject to review of their statement of interest and space availability. If you have any questions, please contact Dave Raggett . More information is available in the Call for Participation: http://www.w3.org/2010/02/mbui/cfp Ian Jacobs, Head of W3C Communications [1] http://www.isti.cnr.it/ [2] http://www.w3.org/2010/02/mbui/cfp.html#requirements_for_participants -- 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 lars.eggert@nokia.com Mon Feb 15 00:18:56 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295A23A7AC4; Mon, 15 Feb 2010 00:18:56 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKbPBZIl-VNU; Mon, 15 Feb 2010 00:18:54 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id AACA43A7AC3; Mon, 15 Feb 2010 00:18:54 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o1F8Isvr003423; Mon, 15 Feb 2010 02:19:28 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Feb 2010 10:18:57 +0200 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Feb 2010 10:18:48 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o1F8IkJf002840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Feb 2010 10:18:47 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/signed; boundary=Apple-Mail-1-151906251; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Mon, 15 Feb 2010 10:18:34 +0200 Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1077) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Mon, 15 Feb 2010 10:18:36 +0200 (EET) X-OriginalArrivalTime: 15 Feb 2010 08:18:48.0662 (UTC) FILETIME=[7FE42760:01CAAE17] X-Nokia-AV: Clean Cc: "tcpm@ietf.org" , "fernando@gont.com.ar" , "secdir@ietf.org" Subject: Re: [secdir] [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 08:18:56 -0000 --Apple-Mail-1-151906251 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, authors/WG, please discuss the secdir review. I'll leave the document on the IESG = agenda for Thursday for now. Lars On 2010-2-13, at 4:27, Phillip Hallam-Baker wrote: > Hi, >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > ICMP is one of those IP layer protocols that we all have some idea > exist even if only the network level people understand what they do. > This document is designed to describe security issues arising from the > ICMP protocol and commonly implemented counter-measures. >=20 > The principal security risks considered are service risks. ICMP may be > used to perform certain denial of service and performance downgrade > attacks. As such it probably needs rather more justification than 'we > have always done this' when building critical infrastructures. >=20 >=20 > Overall, >=20 > Given that TCP streams will eventually time-out, I have something of a > hard time seeing why we would be using a non-authenticated control > protocol at all. Yes, I know the legacy reasons etc. etc. But this is > not the way we would approach this problem today. This argument is > almost made on page 15. Some statement giving the case for taking > notice of ICMP messages at all is in order. It might well be that an > appropriate control in certain cases would be to turn off ICMP hard > errors and rely on timeouts, I am thinking here of critical > infrastructure applications and communications between hosts running > BGP functions. >=20 > In particular I note that the draft says "It is interesting to note > that, as ICMP error messages are transmitted unreliably, transport > protocols should not depend on them for correct functioning." >=20 > Given the extreme approach to security of starting from nothing and > only adding systems that are essential, this would seem to suggest > ICMP is not necessary and could be eliminated. There may be a case to > the contrary but it needs to be made before page 15. >=20 >=20 > Page 15/16 >=20 > The following phrase repeats in a way that suggests an editing = oversight: > aborting the > connection would be to ignore the valuable feature of the Internet > that for many internal failures it reconstructs its function without > any disruption of the end points >=20 > Page 24-26 >=20 > A more general way of describing the mitigation strategy would be to > point out the general principle that error messages may be ignored > whenever a packet indicating success is received within the timeout > window. In other words no final processing decisions should be made on > an unauthenticated ICMP packet until after the timeout window expires. >=20 >=20 > --=20 > --=20 > New Website: http://hallambaker.com/ > View Quantum of Stupid podcasts, Tuesday and Thursday each week, > http://quantumofstupid.com/ > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-1-151906251 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTEwMDIxNTA4MTgzNVowIwYJKoZIhvcNAQkEMRYEFGRqfNZxsPXSd8R905aQjDbIQZoYMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDB29zWeJcgtYF9NqBvol5gBipICjaqcYJE5xGbSrPpw30T8ZFw2qjXXtNqlFbGH/j/lzHD Hzo4tR/PsRM+OQalt/+uHU4VAWkL76FoQA4etf4Y6sVlYujMKszQPyD4W+9+vFUT63OjXW9ieev7 O0vyofJbZiDqHVuH7F+G9JspvJtMq/aWjzEV0hDJ9ZQplsM8wMOmG+p1dWeJDT7ZHK/+Q3gMwCVy Y5nhddlElEGCc4KGc/Q4fCQzTHEEmxCx625GDADU8K3Qx5ziy75Vz3VqwBT3ffYyLhoDbdw1EPXx wL3ZTHWb6Lczz5eSK3kjdMTfu1yL1nUQrOD/E8yLzjDrAAAAAAAA --Apple-Mail-1-151906251-- From tobias.gondrom@gondrom.org Mon Feb 15 08:23:16 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6F9328C0F3 for ; Mon, 15 Feb 2010 08:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.639 X-Spam-Level: **** X-Spam-Status: No, score=4.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-JrHcNguiFD for ; Mon, 15 Feb 2010 08:23:16 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 7625028C0F9 for ; Mon, 15 Feb 2010 08:23:15 -0800 (PST) Received: (qmail 24267 invoked from network); 15 Feb 2010 17:24:16 +0100 Received: from 188-220-241-66.zone11.bethere.co.uk (HELO ?192.168.1.64?) (188.220.241.66) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Feb 2010 17:24:16 +0100 Message-ID: <4B797538.7020401@gondrom.org> Date: Mon, 15 Feb 2010 16:24:24 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.5) Gecko/20091130 SUSE/3.0.0-1.1.1 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: secdir@ietf.org, draft-ietf-dhc-dhcpv6-vendor-message.all@tools.ietf.org X-Enigmail-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090200090808080905030707" Cc: iesg@ietf.org Subject: [secdir] Secdir review of draft-ietf-dhc-dhcpv6-vendor-message-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 16:23:16 -0000 This is a multi-part message in MIME format. --------------090200090808080905030707 Content-Type: text/plain; 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 draft correctly states that the introduction basically allows each vendor to introduce its own security problems based on the functionality triggered by the vendor specific messages. The specification that "Relay agents SHOULD relay these messages ... unless the relay agent understands the specific message and knows that the message was directed at it." can worsen security risks by allowing quite far reaching/remote attacks as relays will forward any vendor message which they do not understand. Although this paradigm makes sense for network operation, this may result in unintended side effects regarding security and attack vectors. 1. COMMENT on section 3 on page 3: - msg-type VENDOR-SPECIFIC (TBD) What do you mean by TBD? (if you mean "to be defined", my opinion is that this is definitely not appropriate for a Standards Track document) 2. COMMENT on section 4 page 4: "Vendors using this new message should use the DHCPv6 security mechanisms..." => maybe a SHOULD would be more appropriate in this case. 3. Minor note: the draft has expired on Feb-2. 4. COMMENT: And last but not least a general personal comment: The document describes how to introduce vendor specific messages which will be solely in the control of the vendor. These message codes and their underlying functionality are unspecified and totally beyond IANA or IETF control. This can introduce basically any set of security and interoperability problems and I am not sure how this approach will support interoperability or would benefit the operation of the internet as a whole. But probably the DHC WG members knows better. Still, considering this question I wonder why this is in the status of "Standards Track" and not "Experimental". Best regards, Tobias Tobias Gondrom Sloan Fellowship 2009 London Business School email: tobias.gondrom@gondrom.org mobile: +447521003005 --------------090200090808080905030707 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 draft correctly states that the introduction basically allows each vendor to introduce its own security problems based on the functionality triggered by the vendor specific messages. The specification that "Relay agents SHOULD relay these messages ...  unless the relay agent understands the specific message and knows that the message was directed at it." can worsen security risks by allowing quite far reaching/remote attacks as relays will forward any vendor message which they do not understand. Although this paradigm makes sense for network operation, this may result in unintended side effects regarding security and attack vectors.

1. COMMENT on section 3 on page 3:
-  msg-type             VENDOR-SPECIFIC (TBD)
What do you mean by TBD? (if you mean "to be defined", my opinion is that this is definitely not appropriate for a Standards Track document)

2. COMMENT on section 4 page 4:
"Vendors using this new message should use the DHCPv6 security mechanisms..."
=> maybe a SHOULD would be more appropriate in this case.

3. Minor note: the draft has expired on Feb-2.

4. COMMENT:
And last but not least a general personal comment:
The document describes how to introduce vendor specific messages which will be solely in the control of the vendor. These message codes and their underlying functionality are unspecified and totally beyond IANA or IETF control.
This can introduce basically any set of security and interoperability problems and I am not sure how this approach will support interoperability or would benefit the operation of the internet as a whole. But probably the DHC WG members knows better. Still, considering this question I wonder why this is in the status of "Standards Track" and not "Experimental".

Best regards, Tobias


Tobias Gondrom
Sloan Fellowship 2009
London Business School
email: tobias.gondrom@gondrom.org
mobile: +447521003005


--------------090200090808080905030707-- From Shawn.Emery@Sun.COM Mon Feb 15 10:50:14 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C2063A7B6B; Mon, 15 Feb 2010 10:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+uZNroH0KrV; Mon, 15 Feb 2010 10:50:13 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 94C5B3A7BC2; Mon, 15 Feb 2010 10:50:12 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1FIphko021357; Mon, 15 Feb 2010 18:51:43 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KXW00M00C4ZF100@mail-amer.sun.com>; Mon, 15 Feb 2010 11:51:43 -0700 (MST) Received: from [10.0.0.5] ([unknown] [174.51.225.48]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KXW0015UCE7ZV10@mail-amer.sun.com>; Mon, 15 Feb 2010 11:51:43 -0700 (MST) Date: Mon, 15 Feb 2010 11:49:48 -0700 From: Shawn M Emery Sender: Shawn.Emery@Sun.COM To: secdir@ietf.org Message-id: <4B79974C.9030900@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Thunderbird/3.0 Cc: draft-ietf-mediactrl-mixer-control-package.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-mediactrl-mixer-control-package-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 18:50:14 -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 describes usage for managing mixers used in media conferences and connections. The security considerations section does exist and references the XML media RFC, 3023, with the possible implications of using XML for command and display purposes. In regards to media mixer usage this draft references the control framework draft, draft-ietf-mediactrl-sip-control-framework, for security issues regarding session establishment, transport protection, and control channel policy management. After reading the referenced drafts I believe that there are no additional threats that the draft-ietf-mediactrl-mixer-control-package draft does not already account for. General comment(s): None. Editorial comment(s): Security considerations: Section 11 of [I-D.ietf-mediactrl-sip-control-framework] is incorrectly referenced, should reference 12. This occurs 3 times. -- Shawn. From touch@ISI.EDU Mon Feb 15 12:09:03 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B20828C20F; Mon, 15 Feb 2010 12:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQmg6dXd-e1E; Mon, 15 Feb 2010 12:09:02 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 17A6928C203; Mon, 15 Feb 2010 12:09:02 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o1FK8Rwo005716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Feb 2010 12:08:29 -0800 (PST) Message-ID: <4B79A9BA.5050205@isi.edu> Date: Mon, 15 Feb 2010 12:08:26 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4B79A54C.7040107@gont.com.ar> In-Reply-To: <4B79A54C.7040107@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig104286DE59925E459E990848" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Phillip Hallam-Baker , secdir@ietf.org Subject: Re: [secdir] [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 20:09:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig104286DE59925E459E990848 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Hello, Phillip, >=20 > Thanks so much for your feedback! See my comments inline.... >=20 >=20 >> The principal security risks considered are service risks. ICMP may be= >> used to perform certain denial of service and performance downgrade >> attacks. As such it probably needs rather more justification than 'we >> have always done this' when building critical infrastructures. >=20 > I fully agree. This I-D has been debated in tcpm form... 6 years now. I= t > was originally meant for Std track, but somehow ended up heading for > Informational. That implies the decision was either accidental or unintentional, and neither is the case, FWIW. > What's in the I-D is what most implementation (all the > mainstream ones, at least) do. >=20 > So if *I* had to answer why we don't stress that ICMP should be > disregarded in many scenarios, etc., I can just say that this is what > the WG has converged to. This is what the WG *decided*. "Converged to" similarly implies lack of deliberate decision, which was not the case. >> Given that TCP streams will eventually time-out, I have something of a= >> hard time seeing why we would be using a non-authenticated control >> protocol at all. Yes, I know the legacy reasons etc. etc. But this is >> not the way we would approach this problem today.=20 >=20 > I fully agree. Not all TCP state times out. Connections that don't use keepalives will retain stale state until the state is explicitly flushed by a RST. If the other end never comes back up, the state *never* gets flushed if not for ICMPs. It'd be an interesting question to ask whether we could do without ICMPs altogether, but that is not addressed sufficiently in this doc to make such a conclusion, IMO. >> This argument is >> almost made on page 15. Some statement giving the case for taking >> notice of ICMP messages at all is in order.=20 >=20 > I guess the "statement" that you could get here (tcpm) is > "responsiveness". -- with which I'd disagree, for many of the reasons > stated in the draft, and because in many other cases it has been argued= > in this very wg that "tcp is supposed to be robust, it's not optimized > for any scenario, etc.". >=20 > Should I craft some text along the lines of "responsiveness"? This doc, by WG agreement, focuses on "what is". It is not intended to make broader recommendations or conclusions. >> It might well be that an >> appropriate control in certain cases would be to turn off ICMP hard >> errors and rely on timeouts, I am thinking here of critical >> infrastructure applications and communications between hosts running >> BGP functions. >=20 > Most (if not all) real-world implementations already do this. We have > lived with this behaviour that you describe for the last..mm.. 20 years= > (or so) with BSDs... and there's no way that BSDs, or Linux, or Cisco, > or whoever are going to change back their implementations to e.g. > "resetting connections in response to ICMP hard errors". For instance, > they have issued vulnerability advisories in this respect... KARP is addressing some of these issues. TCP-AO also addresses these issues in the context of BGP. It's difficult to argue for broader controls of ICMPs in the absence of authentication at the IP or TCP level, since RSTs have just as injurious an impact. >> In particular I note that the draft says "It is interesting to note >> that, as ICMP error messages are transmitted unreliably, transport >> protocols should not depend on them for correct functioning." >> >> Given the extreme approach to security of starting from nothing and >> only adding systems that are essential, this would seem to suggest >> ICMP is not necessary and could be eliminated.=20 >=20 > Yes...except for ICMP "frag needed but DF bit set", which is needed for= > PMTUD. Well, if we're going to pick, PMTUD based on ICMP should be replaced with PLPMTUD. However, again, this level of recommendation is out of scope for this doc, IMO. Joe --------------enig104286DE59925E459E990848 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkt5qbsACgkQE5f5cImnZrv78QCgqGvVd2B+ORo1Ln4JHUPA2T6Q QHkAoPaPoUKOk366SPiG2aVVVt/6RXFh =/Ojb -----END PGP SIGNATURE----- --------------enig104286DE59925E459E990848-- From touch@ISI.EDU Mon Feb 15 12:51:20 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EE823A79EF; Mon, 15 Feb 2010 12:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWioBgP1m3ws; Mon, 15 Feb 2010 12:51:19 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 7D2CD3A722A; Mon, 15 Feb 2010 12:51:19 -0800 (PST) Received: from [192.168.1.95] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o1FKja0m013907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Feb 2010 12:45:38 -0800 (PST) Message-ID: <4B79B270.5060804@isi.edu> Date: Mon, 15 Feb 2010 12:45:36 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4B79A54C.7040107@gont.com.ar> <4B79A9BA.5050205@isi.edu> <4B79AEC8.3030506@gont.com.ar> In-Reply-To: <4B79AEC8.3030506@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE223615851FE9C8280A451B4" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Phillip Hallam-Baker , secdir@ietf.org Subject: Re: [secdir] [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 20:51:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE223615851FE9C8280A451B4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: > Joe Touch wrote: >=20 >>>> The principal security risks considered are service risks. ICMP may = be >>>> used to perform certain denial of service and performance downgrade >>>> attacks. As such it probably needs rather more justification than 'w= e >>>> have always done this' when building critical infrastructures. >>> I fully agree. This I-D has been debated in tcpm form... 6 years now.= It >>> was originally meant for Std track, but somehow ended up heading for >>> Informational. >> That implies the decision was either accidental or unintentional, and >> neither is the case, FWIW. >=20 > Well, if you track the decision, you'll probably go back to an IETF > meeting in 2005 (Vancouver), in which, while we were heading for Std. > Track, somebody asked "Why not Informational?", and that's what we ende= d > up doing. So... That decision was discussed at length at multiple IETFs. It didn't happen as an accident or by the direct consequence of a single off-handed suggestion. =2E.. >>>> Given that TCP streams will eventually time-out, I have something of= a >>>> hard time seeing why we would be using a non-authenticated control >>>> protocol at all. Yes, I know the legacy reasons etc. etc. But this i= s >>>> not the way we would approach this problem today.=20 >>> I fully agree. >> >> Not all TCP state times out. Connections that don't use keepalives wil= l >> retain stale state until the state is explicitly flushed by a RST. If >> the other end never comes back up, the state *never* gets flushed if n= ot >> for ICMPs. >=20 > The TCP spec says that "ICMP hard errors should be processes as RSTs", > but never describe a case in which a TCP would send an ICMP hard error > instead of a RST. If frag is needed, you can't get a RST since the packet never gets there. If the port is blocked upstream of the end device, the same thing happens. Your next sentence appears to assert that the latter is the common case. > If you ever get an ICMP hard error, it's probably because of a firewall= =2E If it's after a connection is established, it's likely because of a change in path that has different firewall policy or MTU. > And many of these devices do not even check the TCP checksum. Nor should they. The ICMP packet isn't required to include the entire TCP segment, and when it doesn't it *can't* verify the checksum anyway. =2E.. > And, if you really depend on anything to flush stale connections, you'r= e > vulnerable to a bunch of other attacks (Sockstress, and the rest of the= > stuff that is already discussed in the CPNI TCP security paper). My point was simply that TCP doesn't always clean itself up via timeouts. That could be changed, but requires a change to the TCP spec to, e.g., require all TCP connections to default to "keepalive", and that hasn't been discussed. >>>> This argument is >>>> almost made on page 15. Some statement giving the case for taking >>>> notice of ICMP messages at all is in order.=20 >>> I guess the "statement" that you could get here (tcpm) is >>> "responsiveness". -- with which I'd disagree, for many of the reasons= >>> stated in the draft, and because in many other cases it has been argu= ed >>> in this very wg that "tcp is supposed to be robust, it's not optimize= d >>> for any scenario, etc.". >>> >>> Should I craft some text along the lines of "responsiveness"? >> This doc, by WG agreement, focuses on "what is". It is not intended to= >> make broader recommendations or conclusions. >=20 > This doc has probably been one of the best examples for the recent floo= d > of messages on the WG. >=20 >> KARP is addressing some of these issues. TCP-AO also addresses these >> issues in the context of BGP. >> >> It's difficult to argue for broader controls of ICMPs in the absence o= f >> authentication at the IP or TCP level, since RSTs have just as injurio= us >> an impact. >=20 > C'mon, Joe. ICMP must have an in-window TCP SEQ. ICMPs need not. We've > been here before. So the ICMP attack vector is the low hanging fruit. There are numerous ways to upset a TCP connection by injecting bad data, causing it to emit extra ACKs, etc. And the difference between in and not-in window has become much less relevant. (e.g., if "in window" was sufficient, then you should be arguing to stop work on TCP-SECURE). Joe --------------enigE223615851FE9C8280A451B4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkt5snAACgkQE5f5cImnZrvAPgCdH7TO1+bEqeguv644nVwYnUmt aN4AmwU0G2u3ccZy2BMciXQCN0wjVi38 =u802 -----END PGP SIGNATURE----- --------------enigE223615851FE9C8280A451B4-- From ananth@cisco.com Mon Feb 15 14:30:47 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF24B28C108; Mon, 15 Feb 2010 14:30:46 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6zOZzYd67EZ; Mon, 15 Feb 2010 14:30:46 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 14D2628C10B; Mon, 15 Feb 2010 14:30:46 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKdaeUurRN+K/2dsb2JhbACbFnSlMZcthFsEgxQ X-IronPort-AV: E=Sophos;i="4.49,480,1262563200"; d="scan'208";a="299480644" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 15 Feb 2010 22:32:18 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o1FMWGwK026772; Mon, 15 Feb 2010 22:32:16 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Feb 2010 14:32:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Feb 2010 14:32:17 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5808EB58FB@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4B79A54C.7040107@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt Thread-Index: AcqueB8CL+zCGYnVRrqOl12O9jscqwAEiDGA References: <4B79A54C.7040107@gont.com.ar> From: "Anantha Ramaiah (ananth)" To: "Fernando Gont" , "Phillip Hallam-Baker" X-OriginalArrivalTime: 15 Feb 2010 22:32:18.0218 (UTC) FILETIME=[BB2A48A0:01CAAE8E] Cc: tcpm@ietf.org, secdir@ietf.org Subject: Re: [secdir] [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 22:30:47 -0000 =20 Some general comments on this discussion inline... > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Fernando Gont > Sent: Monday, February 15, 2010 11:50 AM > To: Phillip Hallam-Baker > Cc: tcpm@ietf.org; secdir@ietf.org > Subject: Re: [tcpm] SECDIR REVIEW of=20 > draft-ietf-tcpm-icmp-attacks-10.txt >=20 > Hello, Phillip, >=20 > Thanks so much for your feedback! See my comments inline.... >=20 >=20 > > The principal security risks considered are service risks.=20 > ICMP may be=20 > > used to perform certain denial of service and performance downgrade=20 > > attacks. As such it probably needs rather more=20 > justification than 'we=20 > > have always done this' when building critical infrastructures. >=20 > I fully agree. This I-D has been debated in tcpm form... 6=20 > years now. It was originally meant for Std track, but somehow=20 > ended up heading for Informational. What's in the I-D is what=20 > most implementation (all the mainstream ones, at least) do. That is true. Many implementations already do what is being said in this ID.=20 >=20 > So if *I* had to answer why we don't stress that ICMP should=20 > be disregarded in many scenarios, etc., I can just say that=20 > this is what the WG has converged to. I think you should put some text to this effect. IMO, we don't have an overwhelming consensus on whether this document should be informational or standard. To me, I have no issues making this head towards the PS, one of the main reasons being it has been well adopted in the internet today. I also agree that "just being popular" doesn't imply that it needs to become a standard. In this case it is not only popular, these mitigations have more pros than cons. > > This argument is > > almost made on page 15. Some statement giving the case for taking=20 > > notice of ICMP messages at all is in order. >=20 > I guess the "statement" that you could get here (tcpm) is=20 > "responsiveness". -- with which I'd disagree, for many of the=20 > reasons stated in the draft, and because in many other cases=20 > it has been argued in this very wg that "tcp is supposed to=20 > be robust, it's not optimized for any scenario, etc.". >=20 > Should I craft some text along the lines of "responsiveness"? That may be a good idea. >=20 >=20 >=20 > > It might well be that an > > appropriate control in certain cases would be to turn off ICMP hard=20 > > errors and rely on timeouts, I am thinking here of critical=20 > > infrastructure applications and communications between=20 > hosts running=20 > > BGP functions. >=20 > Most (if not all) real-world implementations already do this.=20 > We have lived with this behaviour that you describe for the=20 > last..mm.. 20 years (or so) with BSDs... and there's no way=20 > that BSDs, or Linux, or Cisco, or whoever are going to change=20 > back their implementations to e.g. > "resetting connections in response to ICMP hard errors". For=20 > instance, they have issued vulnerability advisories in this respect... Correct. Thanks, -Anantha From d3e3e3@gmail.com Mon Feb 15 21:06:26 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EAED28C13E; Mon, 15 Feb 2010 21:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJO5wgzs+W7r; Mon, 15 Feb 2010 21:06:25 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id C233A28C0D0; Mon, 15 Feb 2010 21:06:24 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so807709eyd.5 for ; Mon, 15 Feb 2010 21:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=I0bS3dfuf7vt0Q4xmj3lC0Av8dKlMdPDTucCE4AbsMI=; b=ZiZeWIFUoky7IbeYSx1OEfr3XT1C8yymPu3vGDqKtQt8UKC0fuHfrhZ3Bm9/rMvX1f qEmUOa7keaFGFLYgj3GowScGe7UwYda7wxHEYsrplwQ/KM0MbG5juoK0oK7PZDtvMsMA PRxvpThnC/Pkwl7FymXFRz/JlpGbFBTbwcp9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=jrjyVUQ1Vg8BtSvS563uLcNT3aPsofCfdFson1dL32OphETAjggfXgO/8qhsxUG5od HdVzr48mnCP9iDABUcv+kgSqbYw3IDtgmN8wFaUQ9sH8wCvnsRkDHeiv4rrejy7WH7uJ 058Z0SYh2CFjJPN4Vq0V6pWb2aXVaCYQkJ75U= MIME-Version: 1.0 Received: by 10.216.87.208 with SMTP id y58mr1742340wee.30.1266296873649; Mon, 15 Feb 2010 21:07:53 -0800 (PST) Date: Tue, 16 Feb 2010 00:07:53 -0500 Message-ID: <1028365c1002152107p103a7cf1pac611ba5e4d2d0d3@mail.gmail.com> From: Donald Eastlake To: Glen Zorn , Dan Romascanu , iesg@ietf.org Content-Type: multipart/alternative; boundary=0016e6d7e352558a92047fb0b7ac Cc: secdir@ietf.org Subject: [secdir] SecDir review of draft-zorn-radius-pkmv1-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 05:06:26 -0000 --0016e6d7e352558a92047fb0b7ac 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. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines seven RADIUS Attributes to support the implementation of 802.16 (WiMax) PKMv1 (Privacy Key Management version 1). I previous reviewed version -05 of this draft. The Security Considerations section has been significantly improved since the -05 Draft. The only question I have is the "[SecEn]" reference. It is not common, in my experience, to reference a conference proceedings for the significant security properties of a protocol and I do not know how accessible this document is. But in this case, I think it is OK. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com --0016e6d7e352558a92047fb0b7ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the sec= urity directorate's
ongoing effort to review all IETF documents being processed by the
IESG. =A0Document editors and WG chairs should treat these comments just like any other last call comments.

This document defines seven RADIUS Attributes to support the
implementation of 802.16 (WiMax) PKMv1 (Privacy Key Management version
1). I previous reviewed version -05 of this draft.

The Security Considerations section has been significantly improved sin= ce the -05 Draft. The only question I have is the "[SecEn]" reference. It is = not common, in my experience, to reference a conference proceedings for the= significant security properties of a protocol and I do not know how access= ible this document is. But in this case, I think it is OK.

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 +1-508-634-2066 (home)
=A0155 Beaver Street
=A0Milford, MA 01757 USA
=A0d3e3e3@gmail.com

--0016e6d7e352558a92047fb0b7ac-- From jsalowey@cisco.com Mon Feb 15 23:01:01 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3816D3A74A6; Mon, 15 Feb 2010 23:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvWibeIH0TI3; Mon, 15 Feb 2010 23:01:00 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 782733A6F89; Mon, 15 Feb 2010 23:01:00 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC/SeUurR7H+/2dsb2JhbACbGXSnBZdTgkYBghQEgxSLPg X-IronPort-AV: E=Sophos;i="4.49,482,1262563200"; d="scan'208";a="483603808" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Feb 2010 07:02:34 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1G72Ytr023306; Tue, 16 Feb 2010 07:02:34 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Feb 2010 23:02:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Feb 2010 23:02:32 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-ietf-geopriv-lis-discovery-13 Thread-Index: Acqu1gJ/sSGaB+6SSd6V3dmQGYUzgA== From: "Joseph Salowey (jsalowey)" To: , , X-OriginalArrivalTime: 16 Feb 2010 07:02:34.0173 (UTC) FILETIME=[03B246D0:01CAAED6] Subject: [secdir] Secdir review of draft-ietf-geopriv-lis-discovery-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 07:01:01 -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. I have reviewed the document several times during its lifecycle and I think it is ready for publication. I believe the security considerations discuss the ways the discovery could be attacked and provide some means to mitigate them. The procedures in this document would benefit from a standardized way to identify the access network domain identity from the network authentication, but it does not seem to be there yet. From scott.mansfield@ericsson.com Mon Feb 15 09:23:26 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0763828C1EF; Mon, 15 Feb 2010 09:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=3.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkYyEnrl-j7V; Mon, 15 Feb 2010 09:23:25 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 1272928C1E1; Mon, 15 Feb 2010 09:23:24 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o1FHQbrD024087; Mon, 15 Feb 2010 11:26:37 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.106]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 15 Feb 2010 12:24:54 -0500 From: Scott Mansfield To: pat cain , "draft-ietf-mpls-tp-nm-framework@tools.ietf.org" , "draft-ietf-mpls-tp-nm-framework.chairs@tools.ietf.org" Date: Mon, 15 Feb 2010 12:24:07 -0500 Thread-Topic: Security area review of draft-ietf-mpls-tp-nm-framework-04 Thread-Index: AcqsQ0lXYQjh7jT0SbSDo/DvdLO3gwCICrLA Message-ID: References: <02e701caac43$55881b50$009851f0$@coopercain.com> In-Reply-To: <02e701caac43$55881b50$009851f0$@coopercain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 16 Feb 2010 00:19:44 -0800 Cc: Adrian Farrel , Loa Andersson , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Security area review of draft-ietf-mpls-tp-nm-framework-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 17:23:26 -0000 The editor's have reviewed the security directorate's comments and agree to= replace the first two paragraphs of Section 8 by the paragraph suggested b= y Pat (with a slight modification that adds a sentence about who is authori= zed to access the interfaces)...=20 Pat's original suggestion "Many of the EMF Interfaces (Section 2.3) are critical to proper NE operati= on and need to be protected from denial of service conditions or attack. Th= e EMF Interfaces that use or access private information should be protected= from eavesdropping or being accessed by unauthorized network elements, sys= tems, or users." The editors proposal... The ability for the authorized network operator to access EMF interfaces (s= ection 2.3) when needed is critical to proper operation. Therefore the EMF= interfaces need to be protected from denial of service conditions or attac= k. The EMF Interfaces that use or access private information should be prot= ected from eavesdropping or being accessed by unauthorized network elements= , systems, or users. Regards, -scott. -----Original Message----- From: pat cain [mailto:pcain2@mail2.coopercain.com]=20 Sent: Friday, February 12, 2010 7:27 PM To: draft-ietf-mpls-tp-nm-framework@tools.ietf.org; draft-ietf-mpls-tp-nm-f= ramework.chairs@tools.ietf.org Cc: iesg@ietf.org; secdir@ietf.org Subject: Security area review of draft-ietf-mpls-tp-nm-framework-04 Hi, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document provides the network management framework for the Transport P= rofile for Multi-Protocol Label Switching (MPLS-TP). This framework relies on the management terminology from the ITU-T to descr= ibe the management architecture that could be used for an MPLS-TP managemen= t network. The Security Considerations section is the basis of my comment. I don't thi= nk the first two sentences are sentences. At least I think they need to be = restated to clarify their meaning. The section states: "=20 Provisions to any of the network mechanisms designed to satisfy the requirements described herein need to prevent their unauthorized use and provide a means for an operator to prevent denial of service attacks if those network mechanisms are used in such an attack. Solutions need to provide mechanisms to prevent private information from being accessed by unauthorized eavesdropping, or being directly obtained by an unauthenticated network element, system or user." Using terminology from the document, I think the paragraphs should really s= ay something to the effect of: "Many of the EMF Interfaces (Section 2.3) are critical to proper NE operati= on and need to be protected from denial of service conditions or attack. Th= e EMF Interfaces that use or access private information should be protected= from eavesdropping or being accessed by unauthorized network elements, sys= tems, or users.=20 " Since the next part of the section points the reader to the ITU and other R= FC documents, it should flow okay. Although I am by no means an MPLS expert, the rest of the document looked f= ine. [As a side note, normally the term 'unauthorized eavesdropping' is not used= . Eavesdropping is always performed by an unauthorized party; if they are aut= horized it's called 'network monitoring'. ;) ] Pat Cain From fernando@gont.com.ar Mon Feb 15 11:48:12 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E4D3A7374; Mon, 15 Feb 2010 11:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.054 X-Spam-Level: X-Spam-Status: No, score=-3.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMtpGoegie-E; Mon, 15 Feb 2010 11:48:11 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 8FFC73A7372; Mon, 15 Feb 2010 11:48:08 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 5C6F26B6752; Mon, 15 Feb 2010 16:49:48 -0300 (ART) Received: from [192.168.0.100] (144-174-17-190.fibertel.com.ar [190.17.174.144]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1FJnX1Q014109; Mon, 15 Feb 2010 16:49:35 -0300 Message-ID: <4B79A54C.7040107@gont.com.ar> Date: Mon, 15 Feb 2010 16:49:32 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 15 Feb 2010 16:49:47 -0300 (ART) X-Mailman-Approved-At: Tue, 16 Feb 2010 00:19:43 -0800 Cc: tcpm@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 19:48:12 -0000 Hello, Phillip, Thanks so much for your feedback! See my comments inline.... > The principal security risks considered are service risks. ICMP may be > used to perform certain denial of service and performance downgrade > attacks. As such it probably needs rather more justification than 'we > have always done this' when building critical infrastructures. I fully agree. This I-D has been debated in tcpm form... 6 years now. It was originally meant for Std track, but somehow ended up heading for Informational. What's in the I-D is what most implementation (all the mainstream ones, at least) do. So if *I* had to answer why we don't stress that ICMP should be disregarded in many scenarios, etc., I can just say that this is what the WG has converged to. > Given that TCP streams will eventually time-out, I have something of a > hard time seeing why we would be using a non-authenticated control > protocol at all. Yes, I know the legacy reasons etc. etc. But this is > not the way we would approach this problem today. I fully agree. > This argument is > almost made on page 15. Some statement giving the case for taking > notice of ICMP messages at all is in order. I guess the "statement" that you could get here (tcpm) is "responsiveness". -- with which I'd disagree, for many of the reasons stated in the draft, and because in many other cases it has been argued in this very wg that "tcp is supposed to be robust, it's not optimized for any scenario, etc.". Should I craft some text along the lines of "responsiveness"? > It might well be that an > appropriate control in certain cases would be to turn off ICMP hard > errors and rely on timeouts, I am thinking here of critical > infrastructure applications and communications between hosts running > BGP functions. Most (if not all) real-world implementations already do this. We have lived with this behaviour that you describe for the last..mm.. 20 years (or so) with BSDs... and there's no way that BSDs, or Linux, or Cisco, or whoever are going to change back their implementations to e.g. "resetting connections in response to ICMP hard errors". For instance, they have issued vulnerability advisories in this respect... > In particular I note that the draft says "It is interesting to note > that, as ICMP error messages are transmitted unreliably, transport > protocols should not depend on them for correct functioning." > > Given the extreme approach to security of starting from nothing and > only adding systems that are essential, this would seem to suggest > ICMP is not necessary and could be eliminated. Yes...except for ICMP "frag needed but DF bit set", which is needed for PMTUD. > There may be a case to > the contrary but it needs to be made before page 15. My take is "responsiveness". But I'll let the wg chime in. :-) > Page 15/16 > > The following phrase repeats in a way that suggests an editing oversight: > aborting the > connection would be to ignore the valuable feature of the Internet > that for many internal failures it reconstructs its function without > any disruption of the end points Sorry... I wasn't able to catch the "oversight" you refer to... :-( > Page 24-26 > > A more general way of describing the mitigation strategy would be to > point out the general principle that error messages may be ignored > whenever a packet indicating success is received within the timeout > window. In other words no final processing decisions should be made on > an unauthenticated ICMP packet until after the timeout window expires. Section 7.2 already states: " The described mechanism basically disregards ICMP messages when a connection makes progress, without violating any of the requirements stated in [RFC1191] and [RFC1981]." Please let me know if this text addresses your comment, or whether you think I should craft another paragraph mentioning that of "ignore messages whenever a packet indicating progress is received". Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando@gont.com.ar Mon Feb 15 12:28:36 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4925328C27D; Mon, 15 Feb 2010 12:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.075 X-Spam-Level: X-Spam-Status: No, score=-3.075 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4tAgCKnMhTm; Mon, 15 Feb 2010 12:28:35 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id D340B28C27A; Mon, 15 Feb 2010 12:28:32 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 778356B6752; Mon, 15 Feb 2010 17:30:14 -0300 (ART) Received: from [192.168.0.100] (144-174-17-190.fibertel.com.ar [190.17.174.144]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1FKU0Su004009; Mon, 15 Feb 2010 17:30:01 -0300 Message-ID: <4B79AEC8.3030506@gont.com.ar> Date: Mon, 15 Feb 2010 17:30:00 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4B79A54C.7040107@gont.com.ar> <4B79A9BA.5050205@isi.edu> In-Reply-To: <4B79A9BA.5050205@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 15 Feb 2010 17:30:13 -0300 (ART) X-Mailman-Approved-At: Tue, 16 Feb 2010 00:19:43 -0800 Cc: tcpm@ietf.org, Phillip Hallam-Baker , secdir@ietf.org Subject: Re: [secdir] [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 20:28:36 -0000 Joe Touch wrote: >>> The principal security risks considered are service risks. ICMP may be >>> used to perform certain denial of service and performance downgrade >>> attacks. As such it probably needs rather more justification than 'we >>> have always done this' when building critical infrastructures. >> I fully agree. This I-D has been debated in tcpm form... 6 years now. It >> was originally meant for Std track, but somehow ended up heading for >> Informational. > > That implies the decision was either accidental or unintentional, and > neither is the case, FWIW. Well, if you track the decision, you'll probably go back to an IETF meeting in 2005 (Vancouver), in which, while we were heading for Std. Track, somebody asked "Why not Informational?", and that's what we ended up doing. So... >> So if *I* had to answer why we don't stress that ICMP should be >> disregarded in many scenarios, etc., I can just say that this is what >> the WG has converged to. > > This is what the WG *decided*. "Converged to" similarly implies lack of > deliberate decision, which was not the case. FWIW, this is what was decided (IIRC) at the IETF Vancouver in 2005. And as a result of what I already considered at the time an excessive expenditure of energy :-), didn't fight that much. >>> Given that TCP streams will eventually time-out, I have something of a >>> hard time seeing why we would be using a non-authenticated control >>> protocol at all. Yes, I know the legacy reasons etc. etc. But this is >>> not the way we would approach this problem today. >> I fully agree. > > Not all TCP state times out. Connections that don't use keepalives will > retain stale state until the state is explicitly flushed by a RST. If > the other end never comes back up, the state *never* gets flushed if not > for ICMPs. The TCP spec says that "ICMP hard errors should be processes as RSTs", but never describe a case in which a TCP would send an ICMP hard error instead of a RST. If you ever get an ICMP hard error, it's probably because of a firewall. And many of these devices do not even check the TCP checksum. So you may end up resetting a connection in response to an ICMP hard error elicited by a corrupted TCP segment. That is, honoring ICMPs makes TCP less robust. That said, at this point in time all this has already been discussed. So I just want to finish the I-D. So at this point in time, whatever addresses the raised issues would do for me. And, if you really depend on anything to flush stale connections, you're vulnerable to a bunch of other attacks (Sockstress, and the rest of the stuff that is already discussed in the CPNI TCP security paper). >>> This argument is >>> almost made on page 15. Some statement giving the case for taking >>> notice of ICMP messages at all is in order. >> I guess the "statement" that you could get here (tcpm) is >> "responsiveness". -- with which I'd disagree, for many of the reasons >> stated in the draft, and because in many other cases it has been argued >> in this very wg that "tcp is supposed to be robust, it's not optimized >> for any scenario, etc.". >> >> Should I craft some text along the lines of "responsiveness"? > > This doc, by WG agreement, focuses on "what is". It is not intended to > make broader recommendations or conclusions. This doc has probably been one of the best examples for the recent flood of messages on the WG. > KARP is addressing some of these issues. TCP-AO also addresses these > issues in the context of BGP. > > It's difficult to argue for broader controls of ICMPs in the absence of > authentication at the IP or TCP level, since RSTs have just as injurious > an impact. C'mon, Joe. ICMP must have an in-window TCP SEQ. ICMPs need not. We've been here before. So the ICMP attack vector is the low hanging fruit. >>> Given the extreme approach to security of starting from nothing and >>> only adding systems that are essential, this would seem to suggest >>> ICMP is not necessary and could be eliminated. >> Yes...except for ICMP "frag needed but DF bit set", which is needed for >> PMTUD. > > Well, if we're going to pick, PMTUD based on ICMP should be replaced > with PLPMTUD. However, again, this level of recommendation is out of > scope for this doc, IMO. I already tried this one, and e.g., Linux developers already refused to do so, as a result of "convergence time" reasons. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando@gont.com.ar Mon Feb 15 13:07:17 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF2743A6870; Mon, 15 Feb 2010 13:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.094 X-Spam-Level: X-Spam-Status: No, score=-3.094 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2C9ZGdezb-W; Mon, 15 Feb 2010 13:07:16 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 63BBC3A682A; Mon, 15 Feb 2010 13:07:14 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id DF2896B673D; Mon, 15 Feb 2010 18:08:55 -0300 (ART) Received: from [192.168.0.100] (144-174-17-190.fibertel.com.ar [190.17.174.144]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o1FL8fm1002804; Mon, 15 Feb 2010 18:08:42 -0300 Message-ID: <4B79B7D9.8080909@gont.com.ar> Date: Mon, 15 Feb 2010 18:08:41 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Touch References: <4B79A54C.7040107@gont.com.ar> <4B79A9BA.5050205@isi.edu> <4B79AEC8.3030506@gont.com.ar> <4B79B270.5060804@isi.edu> In-Reply-To: <4B79B270.5060804@isi.edu> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (venus.xmundo.net [201.216.232.56]); Mon, 15 Feb 2010 18:08:55 -0300 (ART) X-Mailman-Approved-At: Tue, 16 Feb 2010 00:19:44 -0800 Cc: tcpm@ietf.org, Phillip Hallam-Baker , secdir@ietf.org Subject: Re: [secdir] [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 21:07:17 -0000 Joe Touch wrote: >> Well, if you track the decision, you'll probably go back to an IETF >> meeting in 2005 (Vancouver), in which, while we were heading for Std. >> Track, somebody asked "Why not Informational?", and that's what we ended >> up doing. So... > > That decision was discussed at length at multiple IETFs. It didn't > happen as an accident or by the direct consequence of a single > off-handed suggestion. I disagree. But at this point in time, this is off-topic. >> The TCP spec says that "ICMP hard errors should be processes as RSTs", >> but never describe a case in which a TCP would send an ICMP hard error >> instead of a RST. I already argued that the only ICMPs that you really need are the "frag needed" ones. > If frag is needed, you can't get a RST since the packet never gets > there. If the port is blocked upstream of the end device, the same thing > happens. Your next sentence appears to assert that the latter is the > common case. If the packet had elicited an RST if it had been received at the intended destination, the connection will probably time-out (i.e., it was a data segment... unless you're implying that a simple ACK does not fit into the PMTU). >> If you ever get an ICMP hard error, it's probably because of a firewall. > > If it's after a connection is established, it's likely because of a > change in path that has different firewall policy or MTU. Exactly. In which case that should be a *soft* error (who said the path is not going to change back to the old one?). >> And many of these devices do not even check the TCP checksum. > > Nor should they. The ICMP packet isn't required to include the entire > TCP segment, and when it doesn't it *can't* verify the checksum anyway. Exactly. And this hurts the precious TCP robustness you have always been defending. >> And, if you really depend on anything to flush stale connections, you're >> vulnerable to a bunch of other attacks (Sockstress, and the rest of the >> stuff that is already discussed in the CPNI TCP security paper). > > My point was simply that TCP doesn't always clean itself up via > timeouts. That could be changed, but requires a change to the TCP spec > to, e.g., require all TCP connections to default to "keepalive", and > that hasn't been discussed. Keepalives are not even part of the spec. >>> It's difficult to argue for broader controls of ICMPs in the absence of >>> authentication at the IP or TCP level, since RSTs have just as injurious >>> an impact. >> C'mon, Joe. ICMP must have an in-window TCP SEQ. ICMPs need not. We've >> been here before. So the ICMP attack vector is the low hanging fruit. > > There are numerous ways to upset a TCP connection by injecting bad data, > causing it to emit extra ACKs, etc. And the difference between in and > not-in window has become much less relevant. ICMP's are one of the only two vectors that can reset connections without being required a matching SEQ. -- the other one being the ToS and Precedence level, as discussed in the CPNI document. IMO, in-window vs. oo-window does make a difference. For instance, the whole press that these issues got back in 2004 is because people had got the numbers wrong in their calculations of "number of packets needed". This is essentially the "new thing" that Paul Watson pointed out back in 2004. Anyway: For the most part I'm wondering if there's any additional text needed to address Phillip's comments. Thoughts? This should be our focus at this point in time. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From touch@ISI.EDU Tue Feb 16 08:44:06 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E619428C0D9; Tue, 16 Feb 2010 08:44:06 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxkuz9KxOEFZ; Tue, 16 Feb 2010 08:44:06 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 458603A6906; Tue, 16 Feb 2010 08:44:06 -0800 (PST) Received: from [75.215.203.205] (205.sub-75-215-203.myvzw.com [75.215.203.205]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o1GGiOpn025228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Feb 2010 08:44:26 -0800 (PST) Message-ID: <4B7ACB68.9020503@isi.edu> Date: Tue, 16 Feb 2010 08:44:24 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fernando Gont References: <4B79A54C.7040107@gont.com.ar> <4B79A9BA.5050205@isi.edu> <4B79AEC8.3030506@gont.com.ar> <4B79B270.5060804@isi.edu> <4B79B7D9.8080909@gont.com.ar> In-Reply-To: <4B79B7D9.8080909@gont.com.ar> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3AC637569631BEAA1B5B5101" X-MailScanner-ID: o1GGiOpn025228 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Phillip Hallam-Baker , secdir@ietf.org Subject: Re: [secdir] [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 16:44:07 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3AC637569631BEAA1B5B5101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Fernando Gont wrote: =2E.. > Anyway: For the most part I'm wondering if there's any additional text > needed to address Phillip's comments. Thoughts? This should be our focu= s > at this point in time. There were two separate points raised, IMO: - clarification of the role of this doc's recommendations The WG was aware of this issue, and there was a lot of effort in creating the existing text that already considered this perspective. No change needed. - addressing the larger issue of the role/need of ICMPs This is out of scope for this doc. No change needed. Overall, I think there isn't a need for a change. Joe --------------enig3AC637569631BEAA1B5B5101 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkt6y2gACgkQE5f5cImnZrtvegCg2UesmTQy7A6MAbYUWzWs/7V3 lv4AniuzFJkjbldUlYogdchUnixFj7UB =8+my -----END PGP SIGNATURE----- --------------enig3AC637569631BEAA1B5B5101-- From ananth@cisco.com Tue Feb 16 09:45:30 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64EE028C1B1; Tue, 16 Feb 2010 09:45:30 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RVHfUfx0MAT; Tue, 16 Feb 2010 09:45:29 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 72CFB28C0E9; Tue, 16 Feb 2010 09:45:29 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFppekurRN+J/2dsb2JhbACbGXSmCZdmhFsEgxSLEA X-IronPort-AV: E=Sophos;i="4.49,485,1262563200"; d="scan'208";a="299792539" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 16 Feb 2010 17:47:04 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o1GHl4hM002366; Tue, 16 Feb 2010 17:47:04 GMT Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Feb 2010 09:47:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Feb 2010 09:47:02 -0800 Message-ID: <0C53DCFB700D144284A584F54711EC5808EB5C32@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <4B7ACB68.9020503@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt Thread-Index: AcqvJ5gXsgopgP/BTROs15hmZLMgUwAAwdzQ References: <4B79A54C.7040107@gont.com.ar><4B79A9BA.5050205@isi.edu> <4B79AEC8.3030506@gont.com.ar><4B79B270.5060804@isi.edu> <4B79B7D9.8080909@gont.com.ar> <4B7ACB68.9020503@isi.edu> From: "Anantha Ramaiah (ananth)" To: "Joe Touch" , "Fernando Gont" X-OriginalArrivalTime: 16 Feb 2010 17:47:04.0670 (UTC) FILETIME=[0D1BD7E0:01CAAF30] Cc: tcpm@ietf.org, Phillip Hallam-Baker , secdir@ietf.org Subject: Re: [secdir] [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 17:45:30 -0000 =20 > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Joe Touch > Sent: Tuesday, February 16, 2010 8:44 AM > To: Fernando Gont > Cc: tcpm@ietf.org; Phillip Hallam-Baker; secdir@ietf.org > Subject: Re: [tcpm] SECDIR REVIEW of=20 > draft-ietf-tcpm-icmp-attacks-10.txt >=20 >=20 >=20 > Fernando Gont wrote: > ... > > Anyway: For the most part I'm wondering if there's any=20 > additional text=20 > > needed to address Phillip's comments. Thoughts? This should be our=20 > > focus at this point in time. >=20 > There were two separate points raised, IMO: >=20 > - clarification of the role of this doc's recommendations > The WG was aware of this issue, and there was > a lot of effort in creating the existing text that > already considered this perspective. No change needed. I would still think there is some text needed which explains (in a sentence or two) the role of this documents recommendations. Atleast explain why the target was chosen to be "informational" at this point of time. Would help a lot of readers/implementers down the line since this question would keep coming. But that's just me, if the consensus is to not add anything I am fine too. -Anantha From touch@ISI.EDU Tue Feb 16 09:52:04 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DF4728C17F; Tue, 16 Feb 2010 09:52:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAbH6B9mRI1t; Tue, 16 Feb 2010 09:52:03 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 67E7A28C100; Tue, 16 Feb 2010 09:52:02 -0800 (PST) Received: from [75.215.203.205] (205.sub-75-215-203.myvzw.com [75.215.203.205]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o1GHpw4i009428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Feb 2010 09:52:01 -0800 (PST) Message-ID: <4B7ADB3E.2060308@isi.edu> Date: Tue, 16 Feb 2010 09:51:58 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Anantha Ramaiah (ananth)" References: <4B79A54C.7040107@gont.com.ar><4B79A9BA.5050205@isi.edu> <4B79AEC8.3030506@gont.com.ar><4B79B270.5060804@isi.edu> <4B79B7D9.8080909@gont.com.ar> <4B7ACB68.9020503@isi.edu> <0C53DCFB700D144284A584F54711EC5808EB5C32@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <0C53DCFB700D144284A584F54711EC5808EB5C32@xmb-sjc-21c.amer.cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEDEC4ACB695A9B50B6227374" X-MailScanner-ID: o1GHpw4i009428 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Phillip Hallam-Baker , Fernando Gont , secdir@ietf.org Subject: Re: [secdir] [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 17:52:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEDEC4ACB695A9B50B6227374 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Anantha Ramaiah (ananth) wrote: > =20 >=20 >> -----Original Message----- >> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 >> Behalf Of Joe Touch >> Sent: Tuesday, February 16, 2010 8:44 AM >> To: Fernando Gont >> Cc: tcpm@ietf.org; Phillip Hallam-Baker; secdir@ietf.org >> Subject: Re: [tcpm] SECDIR REVIEW of=20 >> draft-ietf-tcpm-icmp-attacks-10.txt >> >> >> >> Fernando Gont wrote: >> ... >>> Anyway: For the most part I'm wondering if there's any=20 >> additional text=20 >>> needed to address Phillip's comments. Thoughts? This should be our=20 >>> focus at this point in time. >> There were two separate points raised, IMO: >> >> - clarification of the role of this doc's recommendations >> The WG was aware of this issue, and there was >> a lot of effort in creating the existing text that >> already considered this perspective. No change needed. >=20 > I would still think there is some text needed which explains (in a > sentence or two) the role of this documents recommendations. Atleast > explain why the target was chosen to be "informational" at this point o= f > time. Would help a lot of readers/implementers down the line since this= > question would keep coming. But that's just me, if the consensus is to > not add anything I am fine too. The role is basically limited to 'documenting what is deployed', which is summarized fairly directly in the abstract. The specific recommendation made towards the end of the intro reiterates that. I.e., this is not a new issue, and it's something for which there is specific text already. I think it answers the mail on that point. Joe --------------enigEDEC4ACB695A9B50B6227374 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkt62z4ACgkQE5f5cImnZrulAgCg5OyE5+fW8IMDSgtYsh8//cL6 sF4AoN6f9+vP2w9MUb9xNIFczq5Ln5Wj =mFVn -----END PGP SIGNATURE----- --------------enigEDEC4ACB695A9B50B6227374-- From paul.hoffman@vpnc.org Tue Feb 16 17:34:14 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9099F3A7BF8 for ; Tue, 16 Feb 2010 17:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vmg9ijEbxav8 for ; Tue, 16 Feb 2010 17:34:13 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id CD5723A79EF for ; Tue, 16 Feb 2010 17:34:13 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o1H1Zmn0032764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Feb 2010 18:35:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 16 Feb 2010 17:35:47 -0800 To: secdir@ietf.org, draft-ietf-ccamp-gmpls-ether-svcs.all@tools.ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [secdir] Secdir review of draft-ietf-ccamp-gmpls-ether-svcs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 01:34:14 -0000 Greetings again. This is a last-call review of draft-ietf-ccamp-gmpls-ether-svcs-04, focusing on security issues. This document does not introduce any new security concerns. The Security Considerations section says: This document introduces new message object formats for use in GMPLS signaling [RFC3473]. It does not introduce any new signaling messages, nor change the relationship between LSRs that are adjacent in the control plane. As such, this document introduces no additional security considerations. See [RFC3473] for relevant security considerations. RFC 3473 is GMPLS signalling with RSVP-TE. RSVP has hop-by-hop integrity protection that is often used in real-world deployments; no privacy is assumed in the signalling. However, RSVP-TE introduces non-hop-by-hop notifications that are adopted by draft-ietf-ccamp-gmpls-ether-svcs. Unlike the rest of RSVP-TE, those notifications have no integrity protection unless that operators run the protocol under a security service like IPsec, which they apparently rarely do in real-world deployments. To be clear, draft-ietf-ccamp-gmpls-ether-svcs doesn't make anything in RSVP-TE any worse, it just uses the existing completely-unprotected notifications. The lack of security is an operational issue, not a protocol issue. --Paul Hoffman, Director --VPN Consortium From Adrian.Farrel@huawei.com Wed Feb 17 04:05:06 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F40C3A795D for ; Wed, 17 Feb 2010 04:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRvc1KJUlKTc for ; Wed, 17 Feb 2010 04:05:04 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 5DDAB3A7654 for ; Wed, 17 Feb 2010 04:05:03 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXZ009Z0IZ5LH@usaga03-in.huawei.com> for secdir@ietf.org; Wed, 17 Feb 2010 06:06:41 -0600 (CST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXZ00EE6IZ3UN@usaga03-in.huawei.com> for secdir@ietf.org; Wed, 17 Feb 2010 06:06:41 -0600 (CST) Date: Wed, 17 Feb 2010 12:06:20 +0000 From: Adrian Farrel To: Paul Hoffman , secdir@ietf.org, draft-ietf-ccamp-gmpls-ether-svcs.all@tools.ietf.org Message-id: <3D3F33B1A4BB48FE84F8C39B90A29785@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [secdir] Secdir review of draft-ietf-ccamp-gmpls-ether-svcs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 12:05:06 -0000 Hi Paul, Thanks for the review. Off-topic of the draft, I think, you say... > RFC 3473 is GMPLS signalling with RSVP-TE. RSVP has hop-by-hop integrity > protection > that is often used in real-world deployments; no privacy is assumed in the > signalling. However, > RSVP-TE introduces non-hop-by-hop notifications that are adopted by > draft-ietf-ccamp- > gmpls-ether-svcs. Unlike the rest of RSVP-TE, those notifications have no > integrity protection > unless that operators run the protocol under a security service like IPsec I am not sure why you make this assertion. The GMPLS Notification message is open to all of the security features available in RSVP-TE. It is true that Notification messages can be sent using "non-adjacent signaling" which would require the existence of security peerings between non-adjacent nodes. This can be achieved by group keying, but peer keying need not be so arduous in most use cases. But an alternative mechanism for delivery of Notification messages is defined in RFC3473 where the messages are forwarded hop-by-hop within RSVP-TE. This enables the use of the normal RSVP-TE security model. Cheers, Adrian From phoffman@imc.org Wed Feb 17 08:49:57 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 304AC3A7D2E for ; Wed, 17 Feb 2010 08:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.746 X-Spam-Level: X-Spam-Status: No, score=-4.746 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwr88cQOYd3h for ; Wed, 17 Feb 2010 08:49:56 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 377B23A7B89 for ; Wed, 17 Feb 2010 08:49:56 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o1HGcSPj088804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Feb 2010 09:38:29 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <3D3F33B1A4BB48FE84F8C39B90A29785@your029b8cecfe> References: <3D3F33B1A4BB48FE84F8C39B90A29785@your029b8cecfe> Date: Wed, 17 Feb 2010 08:38:26 -0800 To: Adrian Farrel , Paul Hoffman , secdir@ietf.org, draft-ietf-ccamp-gmpls-ether-svcs.all@tools.ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [secdir] Secdir review of draft-ietf-ccamp-gmpls-ether-svcs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 16:49:57 -0000 At 12:06 PM +0000 2/17/10, Adrian Farrel wrote: >Hi Paul, > >Thanks for the review. > >Off-topic of the draft, I think, you say... > >>RFC 3473 is GMPLS signalling with RSVP-TE. RSVP has hop-by-hop integrity protection >>that is often used in real-world deployments; no privacy is assumed in the signalling. However, >>RSVP-TE introduces non-hop-by-hop notifications that are adopted by draft-ietf-ccamp- >>gmpls-ether-svcs. Unlike the rest of RSVP-TE, those notifications have no integrity protection >>unless that operators run the protocol under a security service like IPsec > >I am not sure why you make this assertion. >The GMPLS Notification message is open to all of the security features available in RSVP-TE. Right, I said that. >It is true that Notification messages can be sent using "non-adjacent signaling" which would require the existence of security peerings between non-adjacent nodes. This can be achieved by group keying, but peer keying need not be so arduous in most use cases. Having looked again, I don't see how group keying achieves non-hop-by-hop security. You would need to combine group keying with guarantees that every hop uses the same key. I don't see where that guarantee is specified, but I could have missed it. >But an alternative mechanism for delivery of Notification messages is defined in RFC3473 where the messages are forwarded hop-by-hop within RSVP-TE. This enables the use of the normal RSVP-TE security model. We agree there. What I am saying is that the "normal RSVP-TE security model" does not actually provide end-to-end notification integrity. If I'm wrong about that, I'm happy to correct my assertion. From dharkins@lounge.org Thu Feb 18 10:51:32 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25033A7ECA; Thu, 18 Feb 2010 10:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDil+aCn9Pkv; Thu, 18 Feb 2010 10:51:30 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 6C1293A7BBA; Thu, 18 Feb 2010 10:51:30 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D97AA1022404A; Thu, 18 Feb 2010 10:53:13 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 18 Feb 2010 10:53:13 -0800 (PST) Message-ID: <566430fae4cc2ff8eab69b2df47c3a0b.squirrel@www.trepanning.net> Date: Thu, 18 Feb 2010 10:53:13 -0800 (PST) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-arkko-pana-iana.all@tools.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [secdir] review of draft-arkko-pana-iana-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 18:51:32 -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. This draft changes the IANA rules for allocation of protocol fields to include "IESG approval". It really has no security considerations and this draft shouldn't warrant much attention from the ADs. That said, however, I did find the rationale for relaxing the rules a bit unconvincing. When RFC 5191 was approved the reasons in the rationale applied but "IESG approval" was not included. Perhaps it was an oversight and the WG didn't really want such rigid rules. Or maybe deployment experience has caused a change of heart. Why now? And why add "IESG review"? Why not "First Come First Served" or "Expert Review"? What is it about "IESG review" that makes it appropriate to add now? The rationale in section 2 could use a bit more explanation. And it seems strange, to me at least, that a non-WG draft is relaxing rules the WG set up intentionally for its protocol. "IESG approval" is supposed to be rare (according to RFC 5226) so maybe it would be possible to partition the ranges, leaving the lion's share the way it was-- "IETF review"-- and giving a reasonable chunk to "IESG approval" for the rare cases that this route is going to be used? If this was considered and rejected it might be good to mention that in section 2. regards, Dan. From new-work-bounces@ietf.org Fri Feb 19 08:19:14 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BFA13A7B4D; Fri, 19 Feb 2010 08:19:14 -0800 (PST) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA7928C2C1 for ; Fri, 19 Feb 2010 07:02: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rU27q3bja-r7 for ; Fri, 19 Feb 2010 07:02:35 -0800 (PST) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id DADCE28C263 for ; Fri, 19 Feb 2010 07:02:35 -0800 (PST) Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from ) id 1NiUOz-0008Tk-7s for public-new-work-dist@listhub.w3.org; Fri, 19 Feb 2010 15:04:21 +0000 Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NiUOy-0008Sr-L7 for public-new-work@listhub.w3.org; Fri, 19 Feb 2010 15:04:20 +0000 Received: from jay.w3.org ([128.30.52.169]) by lisa.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NiUOx-0007Js-JZ; Fri, 19 Feb 2010 15:04:20 +0000 Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1NiUOx-0006HK-DZ; Fri, 19 Feb 2010 10:04:19 -0500 Message-Id: From: Ian Jacobs To: public-new-work@w3.org Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 19 Feb 2010 09:04:19 -0600 X-Mailer: Apple Mail (2.936) X-W3C-Hub-Spam-Status: No, score=-4.4 X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1.8, BAYES_00=-2.599 X-W3C-Scan-Sig: lisa.w3.org 1NiUOx-0007Js-JZ 8a832d023534fe048f218e141453f889 X-Original-To: public-new-work@w3.org Archived-At: Resent-From: public-new-work@w3.org X-Mailing-List: archive/latest/56 X-Loop: public-new-work@w3.org Resent-Sender: public-new-work-request@w3.org Precedence: list Resent-Message-Id: Resent-Date: Fri, 19 Feb 2010 15:04:21 +0000 X-Mailman-Approved-At: Fri, 19 Feb 2010 08:19:12 -0800 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 19 Feb 2010 08:24:16 -0800 Subject: [secdir] [New-work] Proposed W3C Charter: Mobile Web for Social Development Interest Group (until 2010-03-24) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 16:19:14 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Mobile Web Initiative [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Mobile Web for Social Development = Interest Group: http://www.w3.org/2010/01/MW4Dcharter2.html As part of ensuring that the community is aware of proposed work at = W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2010-03-24 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 St=E9phane Boyera, Team Contact . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/Mobile/ [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 weiler+secdir@watson.org Sat Feb 20 08:30:48 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF933A7CD0 for ; Sat, 20 Feb 2010 08:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KX2Y2UBSTgja for ; Sat, 20 Feb 2010 08:30:47 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 63ED63A7B4D for ; Sat, 20 Feb 2010 08:30:47 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o1KGWbUv018994 for ; Sat, 20 Feb 2010 11:32:37 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o1KGWbXg018991 for ; Sat, 20 Feb 2010 11:32:37 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 20 Feb 2010 11:32:37 -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]); Sat, 20 Feb 2010 11:32:37 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 20 Feb 2010 16:30:48 -0000 Julien Laganier is next in the rotation. Documents on the telechat agenda typically have a last call end date before the date shown below; reviews by the end of last call are typically more appreciated by the doc editors. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2010-03-04 Reviewer Deadline Draft Rob Austein T 2010-03-02 draft-ietf-pkix-attr-cert-mime-type-02 Rob Austein T 2010-03-02 draft-ietf-ipsecme-esp-null-heuristics-05 Alan DeKok T 2010-03-02 draft-westerlund-mmusic-3gpp-sdp-rtsp-07 Charlie Kaufman T 2010-03-02 draft-ietf-tsvwg-port-randomization-06 David McGrew T 2010-03-02 draft-ietf-dnsext-dnssec-gost-06 Hilarie Orman TR2010-03-02 draft-lha-gssapi-delegate-policy-04 Brian Weis TR2010-03-02 draft-ietf-mediactrl-sip-control-framework-11 Nico Williams T 2010-03-02 draft-gould-rfc4310bis-05 Glen Zorn T 2010-03-02 draft-ietf-pkix-tamp-05 For telechat 2010-03-11 Jeffrey Hutzelman T 2010-03-09 draft-ietf-autoconf-adhoc-addr-model-02 Last calls and special requests: Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Shawn Emery 2010-02-16 draft-ietf-ccamp-gmpls-mln-extensions-11 Steve Hanna 2010-03-04 draft-rosen-urn-nena-01 David Harrington 2010-02-19 draft-ietf-avt-rtp-ipmr-12 Sam Hartman 2010-02-22 draft-ietf-ccamp-ethernet-traffic-parameters-10 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Love Hornquist-Astrand 2009-10-13 draft-ietf-idnabis-mappings-05 Love Hornquist-Astrand 2010-02-22 draft-ietf-ccamp-gmpls-mef-uni-03 Scott Kelly 2010-03-04 draft-ietf-l3vpn-mvpn-considerations-06 Stephen Kent 2010-03-05 draft-ietf-yam-rfc1652bis-03 Tero Kivinen 2010-03-06 draft-reschke-rfc2231-in-http-09 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Sandy Murphy R2009-11-18 draft-ietf-mpls-mpls-and-gmpls-security-framework-07 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Chris Newman 2010-01-07 draft-ietf-krb-wg-preauth-framework-15 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 From hartmans@mit.edu Tue Feb 23 08:28:15 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EA053A849F; Tue, 23 Feb 2010 08:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIg0Q9khBL5c; Tue, 23 Feb 2010 08:28:14 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id CEF1D3A77DE; Tue, 23 Feb 2010 08:28:14 -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 71B38201E2; Tue, 23 Feb 2010 11:30:15 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 76EFC48EF; Tue, 23 Feb 2010 11:30:10 -0500 (EST) From: Sam Hartman To: iesg@ietf.org,secdir@ietf.org Date: Tue, 23 Feb 2010 11:30:10 -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 Subject: [secdir] secdir review of draft-ietf-ccamp-ethernet-traffic-parameters X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 16:28:15 -0000 This document defines encodings for Metro Ethernet Forum traffic parameters to be used in the GMPLS path and resv messages. Basically, it provides a way of encoding MEF-compatible characterizations of traffic over a LSP that is being reserved within GMPLS. The security considerations section claims no new security issues are introduced. As far as I can determine, that claim is correct. --Sam From rajiva@cisco.com Tue Feb 23 09:25:22 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECCC928B56A; Tue, 23 Feb 2010 09:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.197 X-Spam-Level: X-Spam-Status: No, score=-10.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLnyRDTQLtL4; Tue, 23 Feb 2010 09:25:21 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C773D28C320; Tue, 23 Feb 2010 09:25:20 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO+eg0utJV2b/2dsb2JhbACbDHOkcphghGwEgxU X-IronPort-AV: E=Sophos;i="4.49,527,1262563200"; d="scan'208";a="88163057" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 23 Feb 2010 17:27:22 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o1NHRM6d023334; Tue, 23 Feb 2010 17:27:22 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Feb 2010 11:27:23 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Feb 2010 11:27:20 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577CF46844@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577CD812B5@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-mpls-ldp-typed-wildcard-05 Thread-Index: AcqjuZ20Ftg0OjOPSPyUTkxDtQr/fgFDTDEQAvingzA= References: <12A2C4F2-7168-48B4-97AC-EC439E89FB1E@bbn.com> <067E6CE33034954AAC05C9EC85E2577CD812B5@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Rajiv Asati (rajiva)" , "Richard L. Barnes" , "secdir" , "The IESG" , "The IETF" X-OriginalArrivalTime: 23 Feb 2010 17:27:23.0041 (UTC) FILETIME=[75B1D110:01CAB4AD] X-Mailman-Approved-At: Tue, 23 Feb 2010 12:32:03 -0800 Cc: draft-ietf-mpls-ldp-typed-wildcard@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-mpls-ldp-typed-wildcard-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 17:25:23 -0000 Hi Richard, Hope you received the below response on Feb 8th. Should I assume that you are in agreement to the changes I proposed? I would proceed with -06 version submission otherwise. Please let us know.=20 Thanks a lot. Cheers, Rajiv > -----Original Message----- > From: Rajiv Asati (rajiva) > Sent: Monday, February 08, 2010 3:01 PM > To: Richard L. Barnes; secdir; The IESG; The IETF; Rajiv Asati (rajiva) > Cc: draft-ietf-mpls-ldp-typed-wildcard@tools.ietf.org > Subject: RE: secdir review of draft-ietf-mpls-ldp-typed-wildcard-05 >=20 > Hi Richard, >=20 > Thank you so much for your review and critical feedback. This really > helps to improve this specification. Please see inline, >=20 > > specific constraints. Because this change is relatively minor, the > > security considerations are mostly the same as the base protocol, as > > noted by the Security Considerations section; however, I would prefer > > if the authors explained a little better why this is the case. >=20 > Please see my response below (to the last comment). >=20 > > From an editorial perspective, this document is unclear on several > > important points, especially with regard to the type-specific > > constraints and how they are defined and managed. I think the document > > would would benefit from another revision, focused on making the > > meaning and management of all parameters clear to ensure > > interoperability. >=20 > I am assuming that the unclarity you refer to is based on the specific > comments you have provided below. Right? >=20 >=20 > > Specific comments: > > > > Section 1, Para "As specified..." > > With respect to the phrase "relative to an optional constraint": I > > don't see anything in RFC 5036 that allows for such a constraint. The > > Wildcard FEC type "is to be applied to all FECs associated with the > > label within the following label TLV." >=20 > Per RFC5036, the Label TLV is an optional parameter in Label release > (section 3.5.10) and Label withdraw (section 3.5.10) messages. Hence, the > text is section 1 is correct. >=20 >=20 > > Section 1, Para "1. The Wildcard FEC Element is untyped" > > It's not quite accurate to say that the element is untyped; it has type > > 0x01. Suggest something like "The Wildcard FEC element only allows > > very coarse selection of FECs by label." >=20 >=20 > Type-length-value in TLV (encoding) has nothing to do with the 'typed' > (vs. 'untyped') data, which is what that statement and the whole document > refer to. >=20 > Typed data is supplemented with the value, whereas the untyped data is > not. The latter is what RFC5036 prescribed (note that there is no value > in it). The former is what the current document is prescribing. >=20 > Hence, the existing text in the para (and the whole document). >=20 > I don't see any need for changing that para. Do you? >=20 >=20 >=20 > > Section 1, General > > Clearly you're really after here isn't to change the Wildcard FEC > > Element (as the last sentence of the section says), but to have a new > > element that is a typed Wildcard. It would be clearer and more > > accurate to say this, e.g., in bullet (2), "There are situations where > > it would be useful to have a wildcard-like FEC Element, with type > > constraints, in Label Request messages." >=20 >=20 > Agreed. Fixed. >=20 >=20 > > Section 2, TLV > > s/Lenth/Length/ >=20 > Agreed. Fixed. >=20 >=20 > > Section 3, Para "The Typed Wildcard FEC Element..." > > The language about constraints here seems vague. (In what sense is the > > constraint "optional"?) Suggest the following: > > " > > A Typed Wildcard FEC Element specifies a FEC Type and, optionally, a > > constraint. An element of this type refers to all FECs of the > > specified FEC Type that meet the constraint. The format of the > > constraint field depends on the FEC Type specified. > > " >=20 >=20 > Agreed. Pls allow me to suggest a slightly changed replacement instead - >=20 > ~~~~~~~~~ > The Typed Wildcard FEC Element refers to all FECs of the specified type > that meet the constraint. It specifies a 'FEC Element Type' and an > optional constraint, which is intended to provide additional information. > ~~~~~~~~~ >=20 > I have also put "Optional" in the figure 1, btw. >=20 >=20 > > Section 3, Para "Additional FEC Type-specific Information ..." et seq > > It is unclear whose responsibility it is to define the structure of > > this field (i.e., who is the "designer"?). Do you mean to say this: > > "Additional constraints that the FEC must satisfy in order to be > > selected. The format of the Additional FEC Type-specific Information > > depends on the FEC type in question. This document defines the format > > of this field for the Prefix FEC type." >=20 >=20 > Agreed. Pls allow me to suggest a slightly changed replacement instead - >=20 > ~~~~~~ > It is important that any document specifying Typed wildcarding for any > FEC Element Type also specifies the length and format of Additional FEC > Type Specific Information, if included. > ~~~~~~~~~~ >=20 > > The text here and in the document suggest that there should perhaps be > > a procedure for defining and registering formats for this field. > > However, you may want to specify that any FEC Type may be specified > > with a zero-length Additional FEC Type-specific Information field to > > simply match all FECs of that FEC Type (in order to make it easy to use > > without a whole lot of new RFCs). >=20 > This is already implicit in the description of the 'Leng FEC Type Info'. > I have made it explicit in the below update - >=20 > ~~~~~~~~~` > Additional FEC Type-specific Information: (Optional) Additional > information specific to the FEC Element Type required to fully specify > the Typed Wildcard. If this field is absent, then all FECs of the > specified FEC Type would be matched. > ~~~~~~~~~~~~~ >=20 >=20 > > Section 4, Para "It is the responsibility..." et seq > > The authors of this document are the designers of the Typed Wildcard > > FEC Element Type; who do you mean? It is meaningless to have a MUST > > that is conditional on "making sense". >=20 >=20 > What we mean is that the (future) specifications defining any new FEC > Element Types should prescribe whether typed wildcarding is needed for > that FEC Element Type. >=20 > Nonetheless, that para should be in the section 3, not section 4. I have > moved it in the section 3. The 2nd para (When Typed Wildcarding....) has > been removed, since it is redundant with the existing text. >=20 >=20 > > Section 4, Para "When a FEC TLV..." > > This constraint made sense for the generic Wildcard type, since that > > would overwhelm any other FEC Elements, but it's not clear why it's > > necessary here. Couldn't I have a Label Withdraw message that > > withdraws all CR-LSP FECs and a single Prefix FEC? >=20 >=20 > Good question. The answer is - No. There must be two different messages. >=20 > RFC5036 (section 3.4.1) does NOT allow multiple FEC elements in FEC TLV > in any message except label mapping message. >=20 > Frankly, it would bring whole set of complexity, if we removed this > restriction, for minimal benefit. >=20 >=20 >=20 >=20 > > Section 6, General > > You need to specify the semantics of this field. Does it match all > > FECs that are of the given address family? Also, this doesn't allow > > any constraints on prefix length or the prefix itself; is that > > intentional? >=20 > Yes. That's intentional (since it is already covered by the Prefix FEC > Element). >=20 > Wrt semantics, not sure which particular field's semantics you are > referring to, but the procedures are already specified in section 4, > hence, there wasn't any benefit in replicating the text. >=20 >=20 > > Section 7, Para "In other words ..." > > s/can not/MUST NOT/ >=20 > Agreed. Fixed. >=20 > > Section 9, General > > I would like to see a little more explanation of why this extension to > > LDP does not create additional security considerations. It seems like > > at the very least it increases the risk of misconfiguration by adding > > much more flexible wildcard matching rules; that is, it seems more > > likely that an LSR operator will accidentally match things he doesn't > > intend to, or vice versa. >=20 > Strictly speaking, the security exposure is reduced by this > specification, since the wildcarding is now limited to FECs of a > particular type (AFI, say), not all the FECs. >=20 > Nonetheless, I agree to your suggestion about having some text to clarify > a bit better and suggest adding the following (as 2nd para) to the > security consideration section: >=20 > ~~~~~~~~~~ > One could deduce that the security exposure is reduced by this document, > since an LDP speaker using Typed Wildcard FEC Element could use a single > message to request, withdraw or release all the label mappings of a > particular type (a particular AFI, for example), whereas an LDP speaker > using Wildcard FEC Element, as defined in based LDP specification > [RFC5036], could use a single message to request, withdraw or release all > the label mappings of all types (all AFIs, for example). > ~~~~~~~ >=20 > Would this be sufficient? >=20 > Cheers, > Rajiv >=20 >=20 > > -----Original Message----- > > From: Richard L. Barnes [mailto:rbarnes@bbn.com] > > Sent: Monday, February 01, 2010 10:40 PM > > To: secdir; The IESG; The IETF > > Cc: draft-ietf-mpls-ldp-typed-wildcard@tools.ietf.org > > Subject: secdir review of draft-ietf-mpls-ldp-typed-wildcard-05 > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > > > This document extends the matching capabilities of the LDP Wildcard FEC > > element, which matches all Forwarding Equivalence Classes bound to a > > given label, by adding a second Typed Wildcard FEC element, which > > matches all FECs of a given type, with optional additional type- > > specific constraints. Because this change is relatively minor, the > > security considerations are mostly the same as the base protocol, as > > noted by the Security Considerations section; however, I would prefer > > if the authors explained a little better why this is the case. > > > > > > From an editorial perspective, this document is unclear on several > > important points, especially with regard to the type-specific > > constraints and how they are defined and managed. I think the document > > would would benefit from another revision, focused on making the > > meaning and management of all parameters clear to ensure > > interoperability. > > > > > > Detailed comments follow. > > > > > > --Richard > > > > > > > > Specific comments: > > > > Section 1, Para "As specified..." > > With respect to the phrase "relative to an optional constraint": I > > don't see anything in RFC 5036 that allows for such a constraint. The > > Wildcard FEC type "is to be applied to all FECs associated with the > > label within the following label TLV." > > > > Section 1, Para "1. The Wildcard FEC Element is untyped" > > It's not quite accurate to say that the element is untyped; it has type > > 0x01. Suggest something like "The Wildcard FEC element only allows > > very coarse selection of FECs by label." > > > > Section 1, General > > Clearly you're really after here isn't to change the Wildcard FEC > > Element (as the last sentence of the section says), but to have a new > > element that is a typed Wildcard. It would be clearer and more > > accurate to say this, e.g., in bullet (2), "There are situations where > > it would be useful to have a wildcard-like FEC Element, with type > > constraints, in Label Request messages." > > > > Section 2, TLV > > s/Lenth/Length/ > > > > Section 3, Para "The Typed Wildcard FEC Element..." > > The language about constraints here seems vague. (In what sense is the > > constraint "optional"?) Suggest the following: > > " > > A Typed Wildcard FEC Element specifies a FEC Type and, optionally, a > > constraint. An element of this type refers to all FECs of the > > specified FEC Type that meet the constraint. The format of the > > constraint field depends on the FEC Type specified. > > " > > > > Section 3, Para "Additional FEC Type-specific Information ..." et seq > > It is unclear whose responsibility it is to define the structure of > > this field (i.e., who is the "designer"?). Do you mean to say this: > > "Additional constraints that the FEC must satisfy in order to be > > selected. The format of the Additional FEC Type-specific Information > > depends on the FEC type in question. This document defines the format > > of this field for the Prefix FEC type." > > The text here and in the document suggest that there should perhaps be > > a procedure for defining and registering formats for this field. > > However, you may want to specify that any FEC Type may be specified > > with a zero-length Additional FEC Type-specific Information field to > > simply match all FECs of that FEC Type (in order to make it easy to use > > without a whole lot of new RFCs). > > > > Section 4, Para "It is the responsibility..." et seq > > The authors of this document are the designers of the Typed Wildcard > > FEC Element Type; who do you mean? It is meaningless to have a MUST > > that is conditional on "making sense". > > > > Section 4, Para "When a FEC TLV..." > > This constraint made sense for the generic Wildcard type, since that > > would overwhelm any other FEC Elements, but it's not clear why it's > > necessary here. Couldn't I have a Label Withdraw message that > > withdraws all CR-LSP FECs and a single Prefix FEC? > > > > Section 6, General > > You need to specify the semantics of this field. Does it match all > > FECs that are of the given address family? Also, this doesn't allow > > any constraints on prefix length or the prefix itself; is that > > intentional? > > > > Section 7, Para "In other words ..." > > s/can not/MUST NOT/ > > > > Section 9, General > > I would like to see a little more explanation of why this extension to > > LDP does not create additional security considerations. It seems like > > at the very least it increases the risk of misconfiguration by adding > > much more flexible wildcard matching rules; that is, it seems more > > likely that an LSR operator will accidentally match things he doesn't > > intend to, or vice versa. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From new-work-bounces@ietf.org Tue Feb 23 10:30:15 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37EE028C182; Tue, 23 Feb 2010 10:30:15 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 412BF3A84B6; Tue, 23 Feb 2010 10:30:04 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100223183006.412BF3A84B6@core3.amsl.com> Date: Tue, 23 Feb 2010 10:30:05 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 23 Feb 2010 12:32:03 -0800 Subject: [secdir] [New-work] WG Review: SIP Recording (SIPREC) 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: Tue, 23 Feb 2010 18:30:15 -0000 A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, March 2, 2010. SIP Recording (SIPREC) --------------------------------------------------- Current Status: Proposed Working Group Last Modified: 2010-02-18 Chair(s): * TBD Real-time Applications and Infrastructure Area Director(s): * Robert Sparks * Cullen Jennings Real-time Applications and Infrastructure Area Advisor: * Cullen Jennings Mailing Lists: * TBD Description of Working Group: The Session Recording Protocol (SRP) working group is chartered to define a SIP-based protocol for controlling a session (media) recorder. Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control, business analytics, or consumer protection. Recording is typically done by sending a copy of the media to the recording devices. The working group will determine requirements and produce a specification for a protocol that will manage delivery of media from an end-point that originates media, or that has access to it, to a recording device. PBX and recording vendors today implement proprietary, incompatible mechanisms to facilitate recording. A standard protocol will reduce the complexity and cost of providing such recording services. The Session Recording problem presents certain unique requirements that are not addressed in the current SIP protocol specification. These include requirements such as the need for a distinction between the session that is being recorded versus the session that has been established for recording. Privacy and security of conversations are significant concerns. The working group will make sure that any protocol specified addresses these concerns and includes mechanisms to alert users to the fact that a session they are participating in is being recorded. The working group must take care that the session recording requirements and protocol does not conflict with the IETF statement on wiretapping contained in RFC 2804. The SRP Working Group will thoroughly identify use cases, provide example system architectures and deployment scenarios, and define requirements. The scope of the activity includes: * Recorder Control * Session metadata content and format * Security mechanisms, including transport and media encryption * Privacy concerns, including end-user notification * Negotiation of recording media streams The group will define these issues and rationalize with IETF standards and practices. This includes encryption, NAT traversal, SIP-enabled firewalls, authorization, and security. The group will produce: * Updated Requirements, Use Cases, Architecture draft * Specification for Session Recording Protocol Goals and Milestones: Apr 2010 Use Cases and Requirements to IESG as Informational Draft Nov 2010 Architecture to IESG as Informational Draft Nov 2010 Submit protocol draft to IESG as standards track _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Feb 23 10:45:04 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E00E28C2EE; Tue, 23 Feb 2010 10:45:04 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C722728C178; Tue, 23 Feb 2010 10:45:01 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100223184501.C722728C178@core3.amsl.com> Date: Tue, 23 Feb 2010 10:45:01 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 23 Feb 2010 12:32:03 -0800 Subject: [secdir] [New-work] WG Review: Constrained RESTful Environments (CoRE) 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: Tue, 23 Feb 2010 18:45:04 -0000 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, March 2, 2010. Constrained RESTful Environments (CoRE) ------------------------------- Last Modified: 2010-02-12 Current Status: Proposed Working Group Chair(s): - TBD Applications Area Director(s): - Lisa Dusseault - Alexey Melnikov Applications Area Advisor: - Lisa Dusseault Mailing Lists: TBD Description of Working Group: CoRE is providing a framework for resource-oriented applications intended to run on constrained IP networks. A constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time. These networks and the nodes within them are characterized by severe limits on throughput, available power, and particularly on the complexity that can be supported with limited code size and limited RAM per node. More generally, we speak of constrained networks whenever at least some of the nodes and networks involved exhibit these characteristics. Low-Power Wireless Personal Area Networks (LoWPANs) are an example of this type of network. Constrained networks can occur as part of home and building automation, energy management, and the Internet of Things. The CoRE working group will define a framework for a limited class of applications: those that deal with the manipulation of simple resources on constrained networks. This includes applications to monitor simple sensors (e.g. temperature sensors, light switches, and power meters), to control actuators (e.g. light switches, heating controllers, and door locks), and to manage devices. The general architecture consists of nodes on the constrained network, called Devices, that are responsible for one or more Resources that may represent sensors, actuators, combinations of values or other information. Devices send messages to change and query resources on other Devices. Devices can send notifications about changed resource values to Devices that have subscribed to receive notification about changes. A Device can also publish or be queried about its resources. (Typically a single physical host on the network would have just one Device but a host might represent multiple logical Devices. The specific terminology to be used here is to be decided by the WG.) As part of the framework for building these applications, the WG will define a Constrained Application Protocol (CoAP) for the manipulation of Resources on a Device. CoAP will be designed for use between Devices on the same constrained network, between Devices and general nodes on the Internet, and between Devices on different constrained networks both joined by an internet. CoAP targets the type of operating environments defined in the ROLL and 6LOWPAN working groups which have additional constraints compared to normal IP networks, but the CoAP protocol will also operate over traditional IP networks. There also may be proxies that interconnect between other Internet protocols and the Devices using the CoAP protocol. The WG will define a mapping from CoAP to an HTTP REST API; this mapping will not depend on a specific application. It is worth noting that proxy does not have to occur at the boundary between the constrained network and the more general network, but can be deployed at various locations in the unconstrained network. CoAP will support various forms of "caching". For example, if a temperature sensor is normally asleep but wakes up every five minutes and sends the current temperature to a proxy that has subscribed, when the proxy receives a request over HTTP for that temperature resource, it can respond with the last seen value instead of trying to query the Device which is currently asleep. The initial work item of the WG is to define a protocol specification for CoAP that includes: 1) The ability to create, read, update and delete a Resource on a Device. 2) The ability to allow a Device to publish a value or event to another Device that has subscribed to be notified of changes, as well as the way for a Device to subscribe to receive publishes from another Device. 3) The ability to support a non-reliable multicast message to be sent to a group of Devices to manipulate a resource on all the Devices in the group. 4) The core CoAP functionality MUST operate well over UDP and UDP MUST be implemented on CoAP Devices. There may be OPTIONAL functions in CoAP (e.g. delivery of larger chunks of data) which if implemented are implemented over TCP. Applications which require the optional TCP features will limit themselves to a narrower subset of deployment cases. 5) A definition of how to use CoAP to advertise about or query for a Device's description. This description may include the device name and a list of its Resources, each with a URL, an interface description URI (pointing e.g. to a Web Application Description Language (WADL) document) and an optional name or identifier. The name taxonomy used for this description will be consistent with other IETF work, e.g. draft-cheshire-dnsext-dns-sd. 6) Specification for the HTTP REST based API and translation to communicate with Devices. Translation should make use of Device description information and should not need code updates to deal with new Devices. 7) Consider operational and manageability aspects of the protocol and at a minimum provide a way to tell if a Device is powered on or not. The working group will not develop a reliable multicast solution, and will not develop a general service discovery solution. There is a desire for discovery and configuration features, but the working group has not yet closed in on an specific approach. Thus, the WG may explore these topics and adopt drafts that define requirements or set problem statements, but will not adopt implementable specifications without a recharter. Security, particularly keying of new Devices, is very challenging for these applications. The WG will work to select approaches to security bootstrapping which are realistic given the constraints and requirements of the network. To ensure that any two nodes can join together, all nodes must implement at least one universal bootstrapping method. Security can be achieved using either session security or object security. For both object and session security, the WG will work with the security area to select appropriate security framework and protocol as well as selecting a minimal required to implement cipher suite. CoAP will initially look at CMS (RFC 5652), TLS/DTLS, and EAP. The WG will coordinate on requirements from many organizations including OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI, ASHRAE/BACnet; other SDOs and organizations. The WG will closely coordinate with other IETF WGs including ROLL, 6LoWPAN, and appropriate groups in the IETF OPS and Security areas. Milestones: Apr 2010 - Select WG document for basis of the CoAP protocol Dec 2010 - CoAP protocol specification with mapping to HTTP Rest API submitted to IESG as PS Dec 2010 - Constrained security bootstrapping specification submitted to IESG as PS Jan 2011 - Recharter to add things reduced out of initial scope _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Feb 23 11:00:07 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD61828C33E; Tue, 23 Feb 2010 11:00:07 -0800 (PST) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6E06228C33A; Tue, 23 Feb 2010 11:00:01 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100223190001.6E06228C33A@core3.amsl.com> Date: Tue, 23 Feb 2010 11:00:01 -0800 (PST) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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: Tue, 23 Feb 2010 12:32:03 -0800 Subject: [secdir] [New-work] WG Review: Recharter of ADSL MIB (adslmib) 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: Tue, 23 Feb 2010 19:00:07 -0000 A modified charter has been submitted for the ADSL MIB (adslmib) 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 Tuesday, March 2, 2010. ADSL MIB (adslmib) ------------------------------- Current Status: Active Working Group Last Modified: 2010-02-14 Additional information is available at tools.ietf.org/wg/adslmib Chair(s): * Menachem Dodge Operations and Management Area Director(s): * Dan Romascanu * Ronald Bonica Operations and Management Area Advisor: * Dan Romascanu Editor(s): * Scott Baillie * Moti Morgenstern * Umberto Bonollo * Edward Beili Mailing Lists: General Discussion: adslmib@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/adslmib Archive: http://www.ietf.org/mail-archive/web/adslmib/current/maillist.html Description of Working Group: The working group will define: 1. A set of managed objects to handle the bonding of xDSL lines according to the ITU-T Recommendations G.998.1 (ATM), G.998.2 (Ethernet) and G.998.3 (TDIM). A common MIB module will be developed to handle the common objects and three specific MIB modules will be developed to handle the three separate layer-2 technologies. Use will be made of the ifStack and ifInvStack Tables defined in RFC 2863 and RFC 2864 respectively. Use will also be made of the ifCapStack and ifInvCapStack tables as defined in RFC 5066. The Broadband forum TR-159 will be used in the definition of these MIBs. 2. The working group will develop a set of managed objects as an optional extension to RFC 5650 that shall provide an alternative approach, known as the "Vector of Profiles", for the configuration of DSL lines. The Vector of Profiles MIB will be based on the Broadband Forum TR-165 document. The ITU-T G.997.1 will also be considered in the definition of this extension. The MIB modules defined by this group will be generated using SMIv2, will be consistent with the SNMP management framework, and will describe the relationship of the objects defined to existing MIBs such as those described in other work products of this Working Group, the interfaces MIB, the Ethernet MIB modules and the AToM MIB. Goals and Milestones: Done Submit Internet-Draft to cover subscriber equipment Done Meet at Chicago IETF to review Internet-Drafts Done Submit Internet-Draft to IESG for consideration as Proposed Standard. Done Meet at Oslo IETF to review new Internet-Drafts and discuss implementation experience on initial MIB Done Submit supplementary Internet-Draft to IESG for consideration as Proposed Standard. Done Produce Internet-Draft covering HDSL2 management objects. Done Submit updated HDSL2/SHDSL Internet-Draft Done Complete WG last call for HDSL2/SHDSL management objects Done Collect implementation reports for ADSL MIB Done Submit HDSL2/SHDSL MIB to IESG for consideration as Proposed Standard Done Submit initial Internet-Draft VDSL MIB Done Complete WG last call on VDSL MIB Done Submit updated VDSL MIB Internet-Draft Done Submit final VDSL MIB Internet-Draft Done Submit VDSL MIB to IESG for consideration as Proposed Standard Done New WG I-Ds for the LCS MCM and SCM MIB modules Done Initial WG Internet-Draft covering ADSL2 management objects Done Integrate working group changes and produce revised draft Done Complete WG last call on ADSL2 MIB Done Submit ADSL2 MIB to IESG for consideration as Proposed Standard Done Re-charter or close down Done Initial WG Internet-Draft covering VDSL2 management objects Done Inform the ITU-T and DSL Forum that work on the VDSL2 MIB has begun Done Integrate working group changes and produce revised VDSL2 MIB draft Done Post Initial Drafts of all the xDsl Bonding MIB drafts Done Post Vdsl2 draft version 03 Done Post Vdsl2 draft version 04. Done Complete Thorough Working Group Reviews of the Vdsl2 draft and produce version 05. Done Working Group Last Call for the Vdsl2 document. Done Early MIB Doctor Reviews of the Vdsl2 draft. Done Make Correction to the draft following the review. Done Working Group Last Call for the Vdsl2 document following corrections. Done Present the Vdsl2 document to the IESG. Feb 2010 Submit updated ATM and Ethernet G.Bond MIB drafts. Mar 2010 Initial Vector of Profiles draft to be accepted by the Working Group. Apr 2010 Submit G.Bond MIB and TDIM MIB Drafts Apr 2010 Submit Vector of Profiles Draft version 01 May 2010 Working Group Last Call on all the G. Bond documents. Jun 2010 Submit G.Bond documents to IESG as Proposed Standard Jun 2010 Revise the draft and post vector of Profiles draft version 02. Jul 2010 Working Group Last Call for the Vector of Profiles draft. Aug 2010 Post Vector of Profiles Draft version 03. Sep 2010 Submit the Vector Of Profile document to the IESG as Proposed Standard. Oct 2010 Re-charter or close down. _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From jari.arkko@piuha.net Tue Feb 23 23:24:35 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9E628C214; Tue, 23 Feb 2010 23:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6g7S72DnMRQC; Tue, 23 Feb 2010 23:24:34 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id E2BBF28C0D6; Tue, 23 Feb 2010 23:24:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 05B862D292; Wed, 24 Feb 2010 09:26:39 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wonMWkG4e9h; Wed, 24 Feb 2010 09:26:38 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 744542D287; Wed, 24 Feb 2010 09:26:38 +0200 (EET) Message-ID: <4B84D4AC.7050603@piuha.net> Date: Wed, 24 Feb 2010 09:26:36 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Dan Harkins References: <566430fae4cc2ff8eab69b2df47c3a0b.squirrel@www.trepanning.net> In-Reply-To: <566430fae4cc2ff8eab69b2df47c3a0b.squirrel@www.trepanning.net> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-arkko-pana-iana.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review of draft-arkko-pana-iana-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 07:24:35 -0000 Dan, > This draft changes the IANA rules for allocation of protocol fields > to include "IESG approval". It really has no security considerations > and this draft shouldn't warrant much attention from the ADs. > OK. Thanks for your review. > That said, however, I did find the rationale for relaxing the rules a > bit unconvincing. When RFC 5191 was approved the reasons in the rationale > applied but "IESG approval" was not included. Perhaps it was an oversight > and the WG didn't really want such rigid rules. Or maybe deployment > experience has caused a change of heart. Why now? And why add "IESG > review"? Why not "First Come First Served" or "Expert Review"? What is > it about "IESG review" that makes it appropriate to add now? The > rationale in section 2 could use a bit more explanation. And it seems > strange, to me at least, that a non-WG draft is relaxing rules the WG > set up intentionally for its protocol. > > "IESG approval" is supposed to be rare (according to RFC 5226) so maybe > it would be possible to partition the ranges, leaving the lion's share > the way it was-- "IETF review"-- and giving a reasonable chunk to "IESG > approval" for the rare cases that this route is going to be used? If this > was considered and rejected it might be good to mention that in section 2. > Oversight: As far as I am concerned, not including IESG Approval *is* an oversight on all strict IANA allocation rules. If we are not ready to say FCFS for various reasons (and there are often good reasons) then at least we should provide an ability for someone to decide whether the strict rule is absolutely required in all cases. In the IETF the way to allow that judgment call to happen is to add "or IESG Approval" to the IANA rule. Why now? Because we have a document (pana-preauth) on IESG review, and it cannot be approved since it would need one of the flag bits that is Standards Action only per the existing PANA rules. But no one in the working or the IESG actually thinks we should block the document. Non-wg draft: We would have brought this through the working group, but I happened to close the working group a while ago, thinking that we were done. However, the document has been brought up for review on the PANA mailing list. I hope this helps shed some light on the background, or at least my thoughts on it. Jari From hallam@gmail.com Wed Feb 24 09:50:56 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF51F28C143; Wed, 24 Feb 2010 09:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb6UZJ+7dllk; Wed, 24 Feb 2010 09:50:55 -0800 (PST) Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by core3.amsl.com (Postfix) with ESMTP id 90F9C28C15F; Wed, 24 Feb 2010 09:50:55 -0800 (PST) Received: by iwn29 with SMTP id 29so3546105iwn.31 for ; Wed, 24 Feb 2010 09:52:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=z6JdkGChGB8IJEjQNF3Al98E7LMbV5bXcfQaC+XyoJ0=; b=OTUWQpd8HuP7k1OEvsnXneOmT2tLMe1rIZ3QMrOocDuBqV5Mx1yZ4jMJXt+vma6z/w s+lZG+Equ/6TwhX3VqBBTJlScSjzlfU7ePPkuBXDvAfbAV7B9mvlKebNs3OIeVd7/hPF alQJjqiEe87eonABJPzvggn3HhNF8Yb1PfRrM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=X39MbOVvKUWS04sEd9yh9mR0MyzaZobEcSs5OrrHcbRBGrTgpJOxtfN/38BCrmnvOt XfZ4pc/wCs1tktlioaKGteKX4aqGGMSVzTSMOqGrdaLeQ6dGawmbe/GBjIpJU+fk2vyg 4neZlJCZ6O8o0cpD3WYb1H4yxzUETESCwC7cU= MIME-Version: 1.0 Received: by 10.231.167.204 with SMTP id r12mr305328iby.31.1267033979492; Wed, 24 Feb 2010 09:52:59 -0800 (PST) In-Reply-To: <4B7ACB68.9020503@isi.edu> References: <4B79A54C.7040107@gont.com.ar> <4B79A9BA.5050205@isi.edu> <4B79AEC8.3030506@gont.com.ar> <4B79B270.5060804@isi.edu> <4B79B7D9.8080909@gont.com.ar> <4B7ACB68.9020503@isi.edu> Date: Wed, 24 Feb 2010 12:52:59 -0500 Message-ID: From: Phillip Hallam-Baker To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tcpm@ietf.org, Fernando Gont , secdir@ietf.org Subject: Re: [secdir] [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 17:50:56 -0000 When a document becomes an RFC it is read as a stand alone document and not in the context of the working group discussions that may have ended years ago. If a particular security issue has not been discussed because it was out of scope, that should be given as the reason that it is not discussed. On Tue, Feb 16, 2010 at 11:44 AM, Joe Touch wrote: > > > Fernando Gont wrote: > ... >> Anyway: For the most part I'm wondering if there's any additional text >> needed to address Phillip's comments. Thoughts? This should be our focus >> at this point in time. > > There were two separate points raised, IMO: > > - clarification of the role of this doc's recommendations > =A0 =A0 =A0 =A0The WG was aware of this issue, and there was > =A0 =A0 =A0 =A0a lot of effort in creating the existing text that > =A0 =A0 =A0 =A0already considered this perspective. No change needed. > > - addressing the larger issue of the role/need of ICMPs > =A0 =A0 =A0 =A0This is out of scope for this doc. No change needed. > > Overall, I think there isn't a need for a change. > > Joe > > --=20 --=20 New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ From touch@ISI.EDU Wed Feb 24 10:00:08 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF95D28C245; Wed, 24 Feb 2010 10:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZPzTypD3Acg; Wed, 24 Feb 2010 10:00:08 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 0908528C14B; Wed, 24 Feb 2010 10:00:08 -0800 (PST) Received: from [75.214.31.137] (137.sub-75-214-31.myvzw.com [75.214.31.137]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o1OHxgPs014029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Feb 2010 09:59:44 -0800 (PST) Message-ID: <4B85690D.4050707@isi.edu> Date: Wed, 24 Feb 2010 09:59:41 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4B79A54C.7040107@gont.com.ar> <4B79A9BA.5050205@isi.edu> <4B79AEC8.3030506@gont.com.ar> <4B79B270.5060804@isi.edu> <4B79B7D9.8080909@gont.com.ar> <4B7ACB68.9020503@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB939625BC76FE1BD4643B39E" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tcpm@ietf.org, Fernando Gont , secdir@ietf.org Subject: Re: [secdir] [tcpm] SECDIR REVIEW of draft-ietf-tcpm-icmp-attacks-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 18:00:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB939625BC76FE1BD4643B39E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Phillip Hallam-Baker wrote: > When a document becomes an RFC it is read as a stand alone document > and not in the context of the working group discussions that may have > ended years ago. >=20 > If a particular security issue has not been discussed because it was > out of scope, that should be given as the reason that it is not > discussed. That seems worthwhile to include IMO, esp. as a response to SECDIR review= =2E Joe >=20 >=20 > On Tue, Feb 16, 2010 at 11:44 AM, Joe Touch wrote: >> >> Fernando Gont wrote: >> ... >>> Anyway: For the most part I'm wondering if there's any additional tex= t >>> needed to address Phillip's comments. Thoughts? This should be our fo= cus >>> at this point in time. >> There were two separate points raised, IMO: >> >> - clarification of the role of this doc's recommendations >> The WG was aware of this issue, and there was >> a lot of effort in creating the existing text that >> already considered this perspective. No change needed. >> >> - addressing the larger issue of the role/need of ICMPs >> This is out of scope for this doc. No change needed. >> >> Overall, I think there isn't a need for a change. >> >> Joe >> >> >=20 >=20 >=20 --------------enigB939625BC76FE1BD4643B39E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAkuFaQ0ACgkQE5f5cImnZrv/WACgvI2D+I/7gR3TDFKOr904/7+3 2JcAoLC44MjIyLOWYyu9/lFyb0S9TvNc =xJxb -----END PGP SIGNATURE----- --------------enigB939625BC76FE1BD4643B39E-- From kivinen@iki.fi Fri Feb 26 03:30:54 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D982328C15D; Fri, 26 Feb 2010 03:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r47Lm+QdX6ZI; Fri, 26 Feb 2010 03:30:53 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 68F4D28C159; Fri, 26 Feb 2010 03:30:50 -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 o1QBWv6r009112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Feb 2010 13:32:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o1QBWume015791; Fri, 26 Feb 2010 13:32:56 +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: <19335.45416.521059.570426@fireball.kivinen.iki.fi> Date: Fri, 26 Feb 2010 13:32:56 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 98 min Cc: httpbis-chairs@tools.ietf.org, julian.reschke@greenbytes.de Subject: [secdir] Review of draft-reschke-rfc2231-in-http-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 11:30:55 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines how http-header field parameters can use characters outside the ISO-8859-1 character set. The security considerations section says: ---------------------------------------------------------------------- 5. Security Considerations This document does not discuss security issues and is not believed to raise any security issues not already endemic in HTTP. ---------------------------------------------------------------------- but already the appendix D, Open issues section lists: ---------------------------------------------------------------------- D.5. i18n-spoofing In Section 5: Type: change GK@ninebynine.org (2010-02-20): I note that the security considerations section says nothing about possible character "spoofing" - i.e. making a displayed prompt or value appear to be something other than it is. E.g. Non-ASCII characters have been used to set up exploits involving dodgy URIs that may appear to a user to be legitimate. ---------------------------------------------------------------------- I agree on this comment, and the security consideration section should include text about the ability to character spoofing. Also as the parameters can include different texts for different languages that also offers another form of spoofing, for example the example the title parameter used in the headers could include different titles for different languages which could affect the way the user interprets it. As this document does not define any specific parameters, the actual documents defining parameters using this format specified here should include text about whether those spoofing attacks are possible and/or meaningful. Having some generic text in this document explaining the possible attacks, would make sure those documents include the text needed. -- kivinen@iki.fi From weiler+secdir@watson.org Fri Feb 26 03:57:41 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85FDE3A8351 for ; Fri, 26 Feb 2010 03:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVMgcqtzW2uF for ; Fri, 26 Feb 2010 03:57:40 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 943B728C191 for ; Fri, 26 Feb 2010 03:57:40 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o1QBxsqO012431 for ; Fri, 26 Feb 2010 06:59:54 -0500 (EST) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o1QBxsXo012428 for ; Fri, 26 Feb 2010 06:59:54 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 26 Feb 2010 06:59:54 -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, 26 Feb 2010 06:59:54 -0500 (EST) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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, 26 Feb 2010 11:57:41 -0000 Many of today's new assignments are scheduled for telechat on March 11th, two weeks from today!! Documents on the telechat agenda typically have a last call end date before the date shown below; reviews by the end of last call are typically more appreciated by the doc editors. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2010-03-04 Reviewer Deadline Draft Rob Austein T 2010-03-02 draft-ietf-pkix-attr-cert-mime-type-03 Rob Austein T 2010-03-02 draft-ietf-ipsecme-esp-null-heuristics-05 Richard Barnes TR2010-03-02 draft-ietf-mpls-ldp-typed-wildcard-06 Alan DeKok T 2010-03-02 draft-westerlund-mmusic-3gpp-sdp-rtsp-07 Shawn Emery T 2010-03-02 draft-ietf-ccamp-gmpls-mln-extensions-12 Charlie Kaufman T 2010-03-02 draft-ietf-tsvwg-port-randomization-06 David McGrew T 2010-03-02 draft-ietf-dnsext-dnssec-gost-06 Hilarie Orman TR2010-03-02 draft-lha-gssapi-delegate-policy-04 Hilarie Orman T 2010-03-02 draft-singh-geopriv-pidf-lo-dynamic-07 Brian Weis TR2010-03-02 draft-ietf-mediactrl-sip-control-framework-11 Nico Williams T 2010-03-02 draft-gould-rfc4310bis-05 Glen Zorn T 2010-03-02 draft-ietf-pkix-tamp-05 For telechat 2010-03-11 Love Hornquist-Astrand T 2010-03-09 draft-ietf-ccamp-gmpls-mef-uni-03 Jeffrey Hutzelman T 2010-03-09 draft-ietf-autoconf-adhoc-addr-model-02 Julien Laganier T 2010-03-09 draft-ietf-csi-hash-threat-07 Barry Leiba T 2010-03-09 draft-ietf-dnsext-dnssec-alg-allocation-02 Chris Lonvick T 2010-03-09 draft-ietf-dnsext-axfr-clarify-13 Catherine Meadows T 2010-03-09 draft-ietf-ecrit-specifying-holes-01 Russ Mundy T 2010-03-09 draft-ietf-geopriv-loc-filters-09 Sandy Murphy T 2010-03-09 draft-ietf-geopriv-prefix-00 Chris Newman T 2010-03-09 draft-ietf-krb-wg-preauth-framework-15 Chris Newman T 2010-03-09 draft-ietf-pce-pcep-svec-list-04 Magnus Nystrom T 2010-03-09 draft-ietf-tcpm-tcp-ao-crypto-02 Radia Perlman T 2010-03-09 draft-ietf-tcpm-tcp-auth-opt-10 Last calls and special requests: Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Steve Hanna 2010-03-04 draft-rosen-urn-nena-01 David Harrington 2010-02-19 draft-ietf-avt-rtp-ipmr-12 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05 Love Hornquist-Astrand 2009-10-13 draft-ietf-idnabis-mappings-05 Scott Kelly 2010-03-04 draft-ietf-l3vpn-mvpn-considerations-06 Stephen Kent 2010-03-05 draft-ietf-yam-rfc1652bis-03 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Sandy Murphy R2009-11-18 draft-ietf-mpls-mpls-and-gmpls-security-framework-07 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 From julian.reschke@greenbytes.de Fri Feb 26 05:46:03 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51B063A87A6; Fri, 26 Feb 2010 05:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2lQqiIa-BLe; Fri, 26 Feb 2010 05:46:02 -0800 (PST) Received: from donbot.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by core3.amsl.com (Postfix) with ESMTP id 0702C3A87A4; Fri, 26 Feb 2010 05:46:01 -0800 (PST) Received: from [192.168.1.105] (unknown [192.168.1.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by donbot.greenbytes.de (Postfix) with ESMTPSA id E4F60C4CA98; Fri, 26 Feb 2010 14:48:14 +0100 (CET) Message-ID: <4B87D118.1090408@greenbytes.de> Date: Fri, 26 Feb 2010 14:48:08 +0100 From: Julian Reschke Organization: greenbytes GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Tero Kivinen References: <19335.45416.521059.570426@fireball.kivinen.iki.fi> In-Reply-To: <19335.45416.521059.570426@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: httpbis-chairs@tools.ietf.org, Graham Klyne , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-reschke-rfc2231-in-http-10.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 13:46:03 -0000 Hi Tero, On 26.02.2010 12:32, Tero Kivinen wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document defines how http-header field parameters can use > characters outside the ISO-8859-1 character set. The security > considerations section says: > > ---------------------------------------------------------------------- > 5. Security Considerations > > This document does not discuss security issues and is not believed to > raise any security issues not already endemic in HTTP. > ---------------------------------------------------------------------- > > but already the appendix D, Open issues section lists: Indeed; that was due to unfortunate timing; the issue was raised before LC, but as LC was already requested I didn't have time to resolve it. Thus, I noted it as open issue. > ---------------------------------------------------------------------- > D.5. i18n-spoofing > > In Section 5: > > Type: change > > msg01329.html> > > GK@ninebynine.org (2010-02-20): I note that the security > considerations section says nothing about possible character > "spoofing" - i.e. making a displayed prompt or value appear to be > something other than it is. E.g. Non-ASCII characters have been > used to set up exploits involving dodgy URIs that may appear to a > user to be legitimate. > ---------------------------------------------------------------------- In the meantime I replied in , posting this proposal: -- snip -- 5. Security Considerations The format described in this document makes it possible to transport non-ASCII characters, and thus enables character "spoofing" scenarios, in which a displayed value appears to be something other than it is. Furthermore, there are known attack scenarios relating to decoding UTF-8. See Section 10 of [RFC3629] for more information on both topics. -- snip -- > I agree on this comment, and the security consideration section should > include text about the ability to character spoofing. Also as the > parameters can include different texts for different languages that > also offers another form of spoofing, for example the example the > title parameter used in the headers could include different titles for > different languages which could affect the way the user interprets it. > > As this document does not define any specific parameters, the actual > documents defining parameters using this format specified here should > include text about whether those spoofing attacks are possible and/or > meaningful. Having some generic text in this document explaining the > possible attacks, would make sure those documents include the text > needed. I'm a bit reluctant to add more than I already have. After all, this applies to *any* IETF spec that has proper I18N, so, in theory, *everything* the IETF does that allows natural language text. It would be really great if we had a document that summarized common security considerations, so that "higher-level" specs could just point to individual parts of these. For the spoofing issue I'm now pointing to RFC 3629 -- do you feel we need more? Best regards, Julian -- bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht Münster: HRB5782 From catherine.meadows@nrl.navy.mil Fri Feb 26 06:57:50 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059C728C128; Fri, 26 Feb 2010 06:57:50 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH8ByQjRrDIX; Fri, 26 Feb 2010 06:57:39 -0800 (PST) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 197FA3A87B7; Fri, 26 Feb 2010 06:57:38 -0800 (PST) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.6/8.13.6) with ESMTP id o1QExnfI010018; Fri, 26 Feb 2010 09:59:49 -0500 (EST) Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.6/8.13.6) with SMTP id o1QExk17014214; Fri, 26 Feb 2010 09:59:48 -0500 (EST) Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010022609594515258 ; Fri, 26 Feb 2010 09:59:45 -0500 From: Catherine Meadows Content-Type: multipart/alternative; boundary=Apple-Mail-4--1020872955 Date: Fri, 26 Feb 2010 10:03:39 -0500 Message-Id: To: iesg@ietf.org, secdir@ietf.org, james.winterbottom@andrew.com, martin.thomson@andrew.com, ecrit-chairs@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [secdir] secdir review of draft-ietf-ecrit-specifying-holes-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 14:57:50 -0000 --Apple-Mail-4--1020872955 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document describes the holes SHOULD be specified in geodetic = service boundaries for use by the LoST protocol. It also describes one possible method for searching for holes using the = information stored in a service database. The only security considerations that I think would arise here would be = in relation to the way in which the information is conveyed the LoST protocol, or how holes = are handled by the protocol. Both of these are beyond the scope of this document, which is = only concerned with defining what a hole is. Thus I agree with the authors that this document = introduces no new security considerations. 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-4--1020872955 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = have reviewed this document as part of the security = directorate's 
ongoing effort to review all IETF documents being = processed by the 
IESG.  These comments were written = primarily for the benefit of the 
security area directors. =  Document editors and WG chairs should treat 
these = comments just like any other last call comments.

This = document describes the holes SHOULD be specified in geodetic service = boundaries for use
by the LoST protocol.
It also = describes one possible method for searching for holes using the = information stored in a service database.

The = only security considerations that I think would arise here would be in = relation to the
way in which the information is conveyed the = LoST protocol, or how holes are handled by the
protocol. =  Both of these are beyond the scope of this document, which is only = concerned with defining
what a hole is.  Thus I agree = with the authors that this document introduces no new security = considerations.


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-4--1020872955-- From kent@bbn.com Fri Feb 26 12:03:50 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354543A8844 for ; Fri, 26 Feb 2010 12:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkCH13ZJ2yX5 for ; Fri, 26 Feb 2010 12:03:48 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 906C628C331 for ; Fri, 26 Feb 2010 12:03:01 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nl6R1-000B2H-WC for secdir@ietf.org; Fri, 26 Feb 2010 15:05:16 -0500 Mime-Version: 1.0 Message-Id: Date: Fri, 26 Feb 2010 15:05:14 -0500 To: secdir@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-944907780==_ma============" Subject: [secdir] secdir review of draft-ietf-yam-rfc1652bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 20:03:50 -0000 --============_-944907780==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a very, very brief document that is targeted to obsolete RFC 1652. It addresses transport of 8-bit (vs. ASCII) data via SMTP, consistent with carriage of MIME 8BIT content encoding. This document is part of the YAM effort, updating the series of Internet email standards. The security considerations section consists of only one sentence: "This RFC does not discuss security issues and is not believed to raise any security issues not already endemic in electronic mail and present in fully conforming implementations of [RFC5321]." RFC 5321 (the updated SMTP spec) has an extensive security considerations section, so this is a reasonable reference. I could imagine security issues that might be associated with this document vs. 5321, since the security section of the latter document does not address any security concerns related to transfer of 8-bit data. For example, the handshake used to determine whether an SMTP sever support receipt/relay of 8-bit data might be used to target servers based on the lack of such support. One might even cite the use of this transport capability as facilitating malware transmission in e-mail attachments :. --============_-944907780==_ma============ Content-Type: text/html; charset="us-ascii" secdir review of draft-ietf-yam-rfc1652bis-03
I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This is a very, very brief document that is targeted to obsolete RFC 1652. It addresses transport of 8-bit (vs. ASCII) data via SMTP, consistent with carriage of MIME 8BIT content encoding. This document is part of the YAM effort, updating the series of Internet email standards.

The security considerations section consists of only one sentence: "This RFC does not discuss security issues and is not believed to raise any security issues not already endemic in electronic mail and present in fully conforming implementations of [RFC5321]." RFC 5321 (the updated SMTP spec) has an extensive security considerations section, so this is a reasonable reference. I could imagine security issues that might be associated with this document vs. 5321, since the security section of the latter document does not address any security concerns related to transfer of 8-bit data. For example, the handshake used to determine whether an SMTP sever support receipt/relay of 8-bit data might be used to target servers based on the lack of such support. One might even cite the use of this transport capability as facilitating malware transmission in e-mail attachments :.
--============_-944907780==_ma============-- From charliek@microsoft.com Fri Feb 26 18:03:41 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64A128C217; Fri, 26 Feb 2010 18:03:41 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CU+64hMMZsLN; Fri, 26 Feb 2010 18:03:40 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id C6C8C28C1FD; Fri, 26 Feb 2010 18:03:40 -0800 (PST) Received: from TK5EX14CASC130.redmond.corp.microsoft.com (157.54.52.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 26 Feb 2010 18:05:57 -0800 Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.20]) by TK5EX14CASC130.redmond.corp.microsoft.com ([157.54.52.9]) with mapi; Fri, 26 Feb 2010 18:05:40 -0800 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "micheal.larsen@tietoenator.com" , "fernando@gont.com.ar" , "jmpolk@cisco.com" , "gorry@erg.abdn.ac.uk" , "lars.eggert@nokia.com" Thread-Topic: Secdir review of draft-ietf-tsvwg-port-randomization-06.txt Thread-Index: Acq3UVrFxdRHn0hzRWysE0Ue9YIZzA== Date: Sat, 27 Feb 2010 02:05:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-tsvwg-port-randomization-06.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 02:03:42 -0000 I am reviewing this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG. These com= ments 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. Feel free to forward to any appropriate forum. This document (targeting BCP status) describes an obscure but important pra= ctice regarding the selection of ephemeral port IDs when creating TCP conne= ctions. If an attacker can guess the ephemeral port used by a TCP connectio= n between some pair of nodes, it greatly increases the chances he can corru= pt the data being passed over that connection or cause the connection to br= eak. To make such an attack harder, the originators of TCP connections shou= ld pick the ephemeral port number randomly (or at least unpredictably) from= a large set of available ports. For some arcane reasons, picking ports strictly randomly is not the best yo= u can do, because some choices don't work out. If you pick a port number th= at has used for a recently closed TCP connection to the same IP address, th= e other end might become confused, think that the old connection is continu= ing, and generally mess things up. (Most applications will eventually sort = themselves out after some timeouts and retries, but it is not guaranteed). = Another possible problem is that if someone starts listening on the port yo= u selected and the timing is "just wrong", you connection could become conf= used with one of his. These problems can be almost certainly avoided by picking ports from a part= icular narrow range and picking them in sequence so that no port number is = reused until all have been used once. Unfortunately, doing that increases t= he chance that an attacker can predict the port some new connection will ch= oose. This document describes how various implementations trade-off these two con= flicting goals, and makes recommendations as to how a new implementation mi= ght pick an algorithm. Unfortunately, this algorithm is a cryptographers dream with lots of opport= unities to make micro-optimizations. I could not resist the temptation to d= o so myself when reading the document, but I *can* resist the temptation to= tell anyone about the resulting algorithm. There are only 64K ports, so no= thing anyone can do is going to make a cryptographically significant improv= ement over the proposals made here, and spending time debating whether my a= lgorithm beats your algorithm is a waste of everyone's time. Detailed security-relevant comments: p13 para 2: says random must return integers in the range 0 - (2^n-1) where= n>15. Larger values of n (e.g. n=3D31) are preferred, since otherwise dist= ribution when reduced mod num_ephemeral will not be uniform. p16 para 2: suggests use of MD5, which is fine from the point of view of do= cumenting current practice, and in fact is cryptographically just fine in t= his context. Nevertheless, crypto weenies the world over will pounce on you= if it looks like you're suggesting that people use it. It's probably bette= r to just suggest "some cryptographic hash function", or if you have to sug= gest something specific, perhaps SHA-256. The appendix at the end should sp= ecify the hash algorithm used by existing implementations. Your sample code in many cases, but in particular on page 17 figure 5 ignor= es the possibility of integer overflow when incrementing things (e.g. table= [index]++). The results of modular arithmetic when one of the operands is n= egative is language dependent, and in ANSI C is not defined, so this code c= ould corrupt memory (unless the values being incremented are unsigned). p20 para 2: suggests use of a 32 bit key, which has exploitable security pr= oblems even though MD5 is fine. 64 bits is a bare minimum, and since bits a= re cheap someone should really use 128. p20 last 2 lines: use of pseudo-random data is never harmful and might help= , so "should not be done" seems a little strong. p24 para 3: Since the local offset function is a cryptographic hash reduced= to a small number of bits, there will be identical offsets for different i= nputs and they are generally harmless. If they occurred at greater frequenc= y than would be expected by chance, the port-offset mechanism proposed in t= his document would have a reduced effect. p24 para 4: Similarly, seeding the random number generator with a good sou= rce of randomness will make an implementation more secure, but "must" is a = bit strong. Detailed non-security relevant comments: The document is titled "Transport Protocol Port Randomization Recommendatio= ns", but it doesn't really make recommendations. It enumerates current prac= tice and calls out the pros and cons, but it doesn't really recommend what = an implementer should do. That's probably OK, but it seemed a bit odd. p6 last para section 1: Given that this document never uses SHOULD, MUST, .= .. outside of this paragraph, does it really need this paragraph and the re= ference to RFC 2119? p7 end of section 2.1 says ports in the range 49152-65535 are meant for the= selection of ephemeral ports p12 1st para says: "ephemeral port selection algorithms should use the who= le range 1024-49151". Is this saying you should use port numbers not intend= ed for this use? Do you mean should use the whole range 1024-65535? Typos: p12 line 2: "is not affected is not affected" -> "is not affected" p13 para 2 line 2: "interger" -> "integer" p16 para 3: "chosen as random as possible" -> "chosen to be as random as po= ssible" p20 para 3: "reasonable" -> "reasonably" --Charlie From alexey.melnikov@isode.com Sat Feb 27 11:46:30 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FE833A8994 for ; Sat, 27 Feb 2010 11:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUJeyK0VSPan for ; Sat, 27 Feb 2010 11:46:29 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 42C533A8993 for ; Sat, 27 Feb 2010 11:46:29 -0800 (PST) Received: from [172.16.2.163] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 27 Feb 2010 19:48:48 +0000 Message-ID: <4B897708.8040501@isode.com> Date: Sat, 27 Feb 2010 19:48:24 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Stephen Kent References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-yam-rfc1652bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 19:46:30 -0000 Hi Stephen, Stephen Kent wrote: [...] > The security considerations section consists of only one sentence: > "This RFC does not discuss security issues and is not believed to > raise any security issues not already endemic in electronic mail and > present in fully conforming implementations of [RFC5321]." RFC 5321 > (the updated SMTP spec) has an extensive security considerations > section, so this is a reasonable reference. I could imagine security > issues that might be associated with this document vs. 5321, since the > security section of the latter document does not address any security > concerns related to transfer of 8-bit data. For example, the handshake > used to determine whether an SMTP sever support receipt/relay of 8-bit > data might be used to target servers based on the lack of such support. Can you elaborate of your concern hear? If you can suggest some text, that would be perfect. > One might even cite the use of this transport capability as > facilitating malware transmission in e-mail attachments. Does it? From hilarie@purplestreak.com Sat Feb 27 15:55:23 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F823A76C6; Sat, 27 Feb 2010 15:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Qj1uE+rsD0B; Sat, 27 Feb 2010 15:55:22 -0800 (PST) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by core3.amsl.com (Postfix) with ESMTP id 142E63A7655; Sat, 27 Feb 2010 15:55:22 -0800 (PST) Received: from mx02.mta.xmission.com ([166.70.13.212]) by out02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NlWVE-00025k-P5; Sat, 27 Feb 2010 16:55:20 -0700 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=fermat.rhmr.com) by mx02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NlWVC-0002W1-IA; Sat, 27 Feb 2010 16:55:20 -0700 Received: from fermat.rhmr.com (localhost [127.0.0.1]) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9ubuntu1) with ESMTP id o1RNs4RS021730; Sat, 27 Feb 2010 16:54:04 -0700 Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id o1RNs3J9021727; Sat, 27 Feb 2010 16:54:03 -0700 Date: Sat, 27 Feb 2010 16:54:03 -0700 Message-Id: <201002272354.o1RNs3J9021727@fermat.rhmr.com> X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f 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=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=error X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa05 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 Thu, 25 Oct 2007 00:26:12 +0000) X-SA-Exim-Scanned: Yes (on mx02.mta.xmission.com) Cc: hartmans-ietf@mit.edu, lha@apple.com Subject: [secdir] Re-review of draft-lha-gssapi-delegate-policy-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 27 Feb 2010 23:55:23 -0000 The draft, including typos, is unchanged since my review 3 months ago. Hilarie ------------ 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 document describes an augmentation of the semantics of the GSSAPI service delegation policy. It allows a client to ask a central server if there is a policy allowing delegation of the service. This is a something of a policy band-aid. The API currently supports only unconditional delegation. This change allows a client to learn if the local policy supports it. The decision might involve a tier of Kerberos inter-realm servers, and the API is charged with enforcing the policy of assuring that all tickets agree that delegation is permitted. The change is minimal, involving no over-the-wire changes, but I imagine it is only part of the tip of a policy iceberg. If clients are to make policy decisions about something as complex as delegation, ultimately they will need more specific information, I would imagine. The security of the mechanism depends on how wise the administrators are when configuring the delegation policy, but the clients have no insight into how the decision was reached. I recommend that the security considerations section make some comment about why a client would or would not make use of this new mechanism. Perhaps it should be avoided for security-critical services ("don't delegate, even if it is allowed")? Or should it always be used? Section 2. Typo --- "to allow and administrator" should be "to allow an administrator" Section 4. Grammar --- "If the initiator set both ... " should be "sets". Last paragraph "the the" should be "to the". "There state" should be "their state". Section 5. Grammar. When the initiator uses deleg_policy_req_flag, the GSS-API Kerberos mechanism, in addition to the service tickets' OK-AS- DELEGATE flag, the MUST examine all cross realm tickets in the traversal from the user's initial ticket-granting-ticket (TGT) to the service ticket. Suggested rewording If the initiator sets the deleg_policy_req_flag, the GSS-API Kerberos mechanism MUST examine the OK-AS-DELEGATE flag in the service ticket, and it MUST examine all cross realm tickets in the traversal from the user's initial ticket-granting-ticket (TGT) to the service ticket. Section 7. Failure to specify deleg_policy_req_flag on the part of the client can at worst result in NOT delegating credentials -- fails closed, a desirable security property. Suggested rewording. A client's failure to specify deleg_policy_req_flag can at worst result in NOT delegating credentials. This means that the client does not expand its trust, which is generally safer than the alternative. From hilarie@purplestreak.com Sun Feb 28 17:17:10 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E99813A85B2; Sun, 28 Feb 2010 17:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6SqAFPwsxJt; Sun, 28 Feb 2010 17:17:10 -0800 (PST) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by core3.amsl.com (Postfix) with ESMTP id 140423A833D; Sun, 28 Feb 2010 17:17:10 -0800 (PST) Received: from mx02.mta.xmission.com ([166.70.13.212]) by out02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NluFv-0001ja-Pn; Sun, 28 Feb 2010 18:17:08 -0700 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=fermat.rhmr.com) by mx02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NluFt-0000zs-5A; Sun, 28 Feb 2010 18:17:07 -0700 Received: from fermat.rhmr.com (localhost [127.0.0.1]) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9ubuntu1) with ESMTP id o211FgRi014725; Sun, 28 Feb 2010 18:15:42 -0700 Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id o211Ffd0014707; Sun, 28 Feb 2010 18:15:41 -0700 Date: Sun, 28 Feb 2010 18:15:41 -0700 Message-Id: <201003010115.o211Ffd0014707@fermat.rhmr.com> X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f 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=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=error X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa02 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 Thu, 25 Oct 2007 00:26:12 +0000) X-SA-Exim-Scanned: Yes (on mx02.mta.xmission.com) Cc: vs2140@cs.columbia.edu, Hannes.Tschofenig@gmx.net, martin.thomson@andrew.com, hgs@cs.columbia.edu Subject: [secdir] Review of draft-singh-geopriv-pidf-lo-dynamic-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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: Mon, 01 Mar 2010 01:17:11 -0000 draft-singh-geopriv-pidf-lo-dynamic-07 Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO) 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 introduces data elements associated with velocity and acceleration. There are no new security considerations. I wonder when the system will encompass a set of simultaneous differential equations. Presentities of complex shapes, non-rigid, ... Hilarie