From kivinen@iki.fi Mon Mar 1 04:53: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 3E78728C2EB; Mon, 1 Mar 2010 04:53:10 -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 wsNVY3tVNqEh; Mon, 1 Mar 2010 04:53:06 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id F226928C2EC; Mon, 1 Mar 2010 04:53:05 -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 o21Cqwuq023516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Mar 2010 14:52:58 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o21CqutG004784; Mon, 1 Mar 2010 14:52: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: <19339.47272.515270.37133@fireball.kivinen.iki.fi> Date: Mon, 1 Mar 2010 14:52:56 +0200 From: Tero Kivinen To: Julian Reschke In-Reply-To: <4B87D118.1090408@greenbytes.de> References: <19335.45416.521059.570426@fireball.kivinen.iki.fi> <4B87D118.1090408@greenbytes.de> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min 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: Mon, 01 Mar 2010 12:53:10 -0000 Julian Reschke writes: > -- 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 think that text adequately covers non-ASCII characters issues. > > 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. Yes, but the impact of them is different. For example it does not really matter if the filename parameters having different languages differ, but there might be parameters where this really matters. As this document does not define any exact parameters, it might be enough to comment something like that "This document specifies way to transport multiple language variants for parameters, and such use might allow spoofing attacks, where different language versions of the same parameters do not match. Whether this attack is useful as an attack depends on the parameter specified." This way the one writing documents specifying parameters allowing multiple languages and specifying some kind processing on them will think whether this attack affects them or not. > 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. Such document would probably be so long that it would not be that useful. I think listing exact security considerations specific for this document in the security considerations section is better, altough for background information pointing to another document (like RFC 3629) is enough. > For the spoofing issue I'm now pointing to RFC 3629 -- do you feel we > need more? I am not really sure for what kind of parameters the different language versions are used, so I cannot really comment whether there can be security issues because of them. If you are sure there cannot be any security issues because of them, then you should say so. If you do do not know, then it is better to mention here to make those who use them to think about the security issues they might raise. -- kivinen@iki.fi From Pasi.Eronen@nokia.com Mon Mar 1 04:56: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 658A93A8400; Mon, 1 Mar 2010 04:56:04 -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 29u0FxKVZwm6; Mon, 1 Mar 2010 04:56:03 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0C3683A8760; Mon, 1 Mar 2010 04:56:02 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o21Ctn2e005903; Mon, 1 Mar 2010 14:56:00 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 14:55:47 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Mar 2010 14:55:39 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Mon, 1 Mar 2010 13:55:38 +0100 From: To: , Date: Mon, 1 Mar 2010 13:55:37 +0100 Thread-Topic: Pasi's AD Notes for February 2010 Thread-Index: Acq5Pn0maQCiiLvrR6GlQzWfyOR3nA== Message-ID: <808FD6E27AD4884E94820BC333B2DB775848146A84@NOK-EUMSG-01.mgdnok.nokia.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-OriginalArrivalTime: 01 Mar 2010 12:55:39.0276 (UTC) FILETIME=[7E5F34C0:01CAB93E] X-Nokia-AV: Clean Subject: [secdir] Pasi's AD Notes for February 2010 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 Mar 2010 12:56:04 -0000 Here's again a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES - Planning AD transition with Tim/Sean - IETF 77 planning with Tim/Sean: SAAG meeting, SecDir=20 lunch, overall agenda - (not wearing AD hat) draft-krawczyk-hkdf went through IETF last call; on the agenda of 2010-03-04 IESG telechat. - (not wearing AD hat) Waiting for Dan Romascanu to process=20 errata 1955/1956 for RFC 4072 [since 2009-12-09] - Waiting for IETF Trust's reply on how to contribute pre-5378 rights to the trust [since 2009-11-03] - Lot of tools work (code I want to get in decent state before my AD term ends) WORKING GROUPS DKIM - draft-ietf-dkim-deployment: discussion ongoing to resolve Tim's DISCUSS; currently waiting for Tim to reply [since 2010-02-25] - Processed errata 1385. - I still need to review what to do about errata 1532, 1596, and 1942. - Waiting for Stephen and Barry for new charter text. EMU - The WG chairs have the token for doing something about ITU-T=20 X.1034 liaison statement. IPSECME - draft-ietf-ipsecme-ikev2-ipv6-config (not wearing AD hat):=20 published as RFC 5739. - draft-ietf-ipsecme-esp-null-heuristics: went through IETF last call; placed on the agenda of 2010-03-04 IESG telechat. - draft-ietf-ipsecme-roadmap: sent by AD review comments; waiting for reply/revised ID [since 2010-02-26] - draft-ietf-ipsecme-aes-ctr-ikev2: sent my AD review comments; waiting for reply/revised ID [since 2010-01-27] - draft-ietf-ipsecme-traffic-visibility: in RFC editor queue. - I need to look at errata 1937 (for RFC 4307) [since 2009-11-02] ISMS - draft-ietf-isms-dtls-tm: sent my AD review comments; waiting for reply/revised ID [since 2010-02-25] KEYPROV - draft-ietf-keyprov-pskc: waiting for me to do my AD=20 review [since 2010-02-28] - draft-ietf-keyprov-symmetrickeyformat: waiting for me to=20 do my AD review [since 2010-02-28] PKIX - Processed errata 1909/2048 (for RFC 3279), 2013 (for RFC 5758),=20 and 2021 (for RFC 5756) SASL - draft-ietf-sasl-gs2: in RFC editor queue/AUTH48 - draft-ietf-sasl-scram: in RFC editor queue/AUTH48 - (not WG item) draft-melnikov-sasl-scram-ldap: in=20 RFC editor queue/AUTH48 - (not WG item) draft-altman-tls-channel-bindings: waiting for the=20 authors to propose wording that is both aligned with the=20 implementations, and considers the renegotiation problem and=20 solution [pinged again 2010-02-26] SYSLOG - draft-ietf-syslog-sign: in RFC editor queue. Waiting for the authors to reply about SHA-256 issue [since 2010-03-01] TLS - draft-ietf-tls-renegotiation: published as RFC 5746. - draft-ietf-tls-extractor: in RFC editor queue, waiting for Eric to reply. - draft-ietf-tls-rfc4366-bis: it seems we need more text about server_name (and perhaps renegotiation); waiting for WG=20 chairs/editor to drive discussion/propose text. - (not WG item) see SASL WG for draft-altman-tls-channel-bindings - (not WG item) lot of emails about draft-hoffman-tls-* I=20 need to read, but haven't yet... OTHER DOCUMENTS DISCUSSES (active -- something happened within last month) - draft-ietf-dhc-dhcpv4-vendor-message: it seems bigger issues concerning this draft need to be resolved before it makes sense to address my relatively minor concern; waiting for that dust to settle [as of 2010-03-01] - draft-ietf-geopriv-lis-discovery: discussion ongoing; currently waiting for more information from WG chair/authors [since 2010-02-25] - draft-zorn-radius-pkmv1: discussion ongoing; currently waiting=20 for the author to reply to my comments [since 2010-03-01] DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-ietf-bmwg-ipsec-meth: waiting for authors to submit a revised ID [since 2010-01-29] - draft-ietf-bmwg-ipsec-term: waiting for authors to reply to my comments or submit a revised ID [since 2010-01-29] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] (pinged again on 2009-04-30, 2009-06-09, 2009-10-29, 2009-12-28, 2010-02-18) - draft-ietf-sip-certs: waiting for the authors to reply=20 [since 2009-10-26] (pinged 2010-01-22) - draft-ietf-sipping-policy-package: waiting for draft-ietf-sipping- media-policy-dataset to progress (or more information from Robert) [since 2008-10-28] --end-- From aland@deployingradius.com Mon Mar 1 05:30:55 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 4D21A28C5EF; Mon, 1 Mar 2010 05:30:55 -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 byb5a0g8e4gg; Mon, 1 Mar 2010 05:30:54 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 163B128CA2F; Mon, 1 Mar 2010 05:15:38 -0800 (PST) Message-ID: <4B8BBDF9.7000505@deployingradius.com> Date: Mon, 01 Mar 2010 14:15:37 +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-westerlund-mmusic-3gpp-sdp-rtsp@tools.ietf.org, IESG IESG Subject: [secdir] Secdir review of draft-westerlund-mmusic-3gpp-sdp-rtsp-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: Mon, 01 Mar 2010 13: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 a number of attributes for 3GPP SDP and RTSP protocols. The attributes are already in wide-spread use. The document is simply requesting IANA allocation for the attributes. There appear to be no security considerations associated with the document. Alan DeKok From gwz@net-zen.net Mon Mar 1 06:09: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 4172728C32C for ; Mon, 1 Mar 2010 06:09:47 -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.434, 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 7Eu9zwUGuJMM for ; Mon, 1 Mar 2010 06:09:46 -0800 (PST) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by core3.amsl.com (Postfix) with SMTP id 7898328C336 for ; Mon, 1 Mar 2010 06:09:46 -0800 (PST) Received: (qmail 12378 invoked from network); 1 Mar 2010 13:43:07 -0000 Received: from unknown (124.120.216.211) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 01 Mar 2010 13:43:06 -0000 From: "Glen Zorn" To: , , , , , Date: Mon, 1 Mar 2010 20:42:49 +0700 Organization: Network Zen Message-ID: <00c101cab945$18bf9090$4a3eb1b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq5RRVibn8mZ1OlS8ShoPDUlMwmoA== Content-Language: en-us Subject: [secdir] secdir review of draft-ietf-pkix-tamp-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, 01 Mar 2010 14:09:47 -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. EDITORIAL COMMENTS Section 1.2.2 says: Management trust anchors are used in the management of cryptographic modules. For example, the TAMP messages specified in this document are validated to a management trust anchor. Likewise, a signed firmware package as specified in [RFC4108] is validated to a management trust anchor. This might be better put as Management trust anchors are used in the management of cryptographic modules. For example, the TAMP messages specified in this document are validated by a management trust anchor. Likewise, a signed firmware package as specified in [RFC4108] is validated by a management trust anchor. In Section 1.3.4, s/The application-specific protocol processing MUST be provided the/The application-specific protocol processing MUST provide the/ Section 3, paragraph 3 says "Certificates include a signature, which removes the ability for relying parties to". Just a question: should "relying" in the sentence actually be "relaying"? In any case, "ability for" should probably be changed to "ability of". Suggestion: Section 4.4 says in two places "The status codes appear in the same order as the TrustAnchorUpdate structures to which they apply"; maybe "The status codes MUST appear in the same order as the TrustAnchorUpdate structures to which they apply" would be clearer. In Section 7, s/if the signer is not representated/if the signer is not represented/. The Security Considerations section is remarkably clear and comprehensive. From housley@vigilsec.com Mon Mar 1 07: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 BE83B28C3D5; Mon, 1 Mar 2010 07:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 PHb+MsQPC0Px; Mon, 1 Mar 2010 07:47:57 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id C1DD328C3C1; Mon, 1 Mar 2010 07:47:57 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id D35E79A4726; Mon, 1 Mar 2010 10:48:11 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id qtZJxkRjKwJW; Mon, 1 Mar 2010 10:47:54 -0500 (EST) Received: from [192.168.2.106] (pool-96-255-37-236.washdc.fios.verizon.net [96.255.37.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 16EBC9A471B; Mon, 1 Mar 2010 10:48:11 -0500 (EST) Message-ID: <4B8BE1B3.2010601@vigilsec.com> Date: Mon, 01 Mar 2010 10:48:03 -0500 From: Russ Housley User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Glen Zorn References: <00c101cab945$18bf9090$4a3eb1b0$@net> In-Reply-To: <00c101cab945$18bf9090$4a3eb1b0$@net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: cwallace@cygnacom.com, secdir@ietf.org, srashmo@radium.ncsc.mil, iesg@ietf.org, pkix-chairs@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-pkix-tamp-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, 01 Mar 2010 15:47:58 -0000 Glen: > 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. > > > EDITORIAL COMMENTS > > Section 1.2.2 says: > Management trust anchors are used in the management of cryptographic > modules. For example, the TAMP messages specified in this document > are validated to a management trust anchor. Likewise, a signed > firmware package as specified in [RFC4108] is validated to a > management trust anchor. > This might be better put as > Management trust anchors are used in the management of cryptographic > modules. For example, the TAMP messages specified in this document > are validated by a management trust anchor. Likewise, a signed > firmware package as specified in [RFC4108] is validated by a > management trust anchor. The point is that the certification path must terminate at the management trust anchor. This is accomplished when the signature can be validated directly with the management trust anchor public key, but it is also accomplished when the top-level certificate in a valid certification path is the management trust anchor. The phrase "validated to" is intended to reflect this situation. > In Section 1.3.4, s/The application-specific protocol processing MUST be > provided the/The application-specific protocol processing MUST provide the/ Thanks for catching that mistake. > Section 3, paragraph 3 says "Certificates include a signature, which removes > the ability for relying parties to". Just a question: should "relying" in > the sentence actually be "relaying"? In any case, "ability for" should > probably be changed to "ability of". No, this is correct. Parties that validate certificates and then depend upon the stuff in the certificate are called "relying parties." > Suggestion: Section 4.4 says in two places "The status codes appear in the > same order as the TrustAnchorUpdate structures to which they apply"; maybe > "The status codes MUST appear in the same order as the TrustAnchorUpdate > structures to which they apply" would be clearer. That is a good improvement. > In Section 7, s/if the signer is not representated/if the signer is not > represented/. Thanks for catching that mistake. > The Security Considerations section is remarkably clear and comprehensive. Thanks. Russ From julian.reschke@greenbytes.de Mon Mar 1 09:33:55 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 2531228C3CB; Mon, 1 Mar 2010 09:33:55 -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 O2aV2PUj9ErQ; Mon, 1 Mar 2010 09:33:53 -0800 (PST) Received: from donbot.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by core3.amsl.com (Postfix) with ESMTP id 384E528C159; Mon, 1 Mar 2010 09:33:52 -0800 (PST) Received: from [192.168.1.119] (unknown [192.168.1.119]) (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 7A461C4CA91; Mon, 1 Mar 2010 18:33:51 +0100 (CET) Message-ID: <4B8BFA7D.5010603@greenbytes.de> Date: Mon, 01 Mar 2010 18:33:49 +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> <4B87D118.1090408@greenbytes.de> <19339.47272.515270.37133@fireball.kivinen.iki.fi> In-Reply-To: <19339.47272.515270.37133@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: Mon, 01 Mar 2010 17:33:55 -0000 On 01.03.2010 13:52, Tero Kivinen wrote: > ... > Yes, but the impact of them is different. For example it does not > really matter if the filename parameters having different languages > differ, but there might be parameters where this really matters. > > As this document does not define any exact parameters, it might be > enough to comment something like that "This document specifies way to > transport multiple language variants for parameters, and such use > might allow spoofing attacks, where different language versions of the > same parameters do not match. Whether this attack is useful as an > attack depends on the parameter specified." > > This way the one writing documents specifying parameters allowing > multiple languages and specifying some kind processing on them will > think whether this attack affects them or not. > ... Ack. I'm tracking this at . For now I have modified the Sec Considerations to: -- 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. In addition, this document specifies a way to transport multiple language variants for a single parameter, and such use might allow spoofing attacks, where different language versions of the same parameter are not equivalent. Whether this attack is useful as an attack depends on the parameter specified. -- snip -- Please let me know whether this works for you (and thanks for the concrete proposal). >> 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. > > Such document would probably be so long that it would not be that > useful. I think listing exact security considerations specific for > this document in the security considerations section is better, > altough for background information pointing to another document (like > RFC 3629) is enough. Of course it would be long :-). But by giving it the right granularity other specs could just refer to the proper part. For instance, do we really want all HTTP related specs have *different* security considerations about DNS spoofing, poisoning, XSS, etc? Maybe something to be discussed in Anaheim (Alexey?). > ... Best regards, Julian -- bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht Münster: HRB5782 From bew@cisco.com Mon Mar 1 11:06:31 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 29F583A8AEA; Mon, 1 Mar 2010 11:06:31 -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 uSCxC-eVSRMA; Mon, 1 Mar 2010 11:06:30 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3A4AC3A8152; Mon, 1 Mar 2010 11:06:30 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI6ei0urRN+J/2dsb2JhbACbB3Oid5dahHsEgxc X-IronPort-AV: E=Sophos;i="4.49,561,1262563200"; d="scan'208";a="89784631" Received: from sj-core-3.cisco.com ([171.68.223.137]) by rtp-iport-2.cisco.com with ESMTP; 01 Mar 2010 19:06:29 +0000 Received: from dhcp-128-107-163-86.cisco.com (dhcp-128-107-163-86.cisco.com [128.107.163.86]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o21J6SE1029658; Mon, 1 Mar 2010 19:06:28 GMT Message-Id: <594F9574-438D-47A1-BD01-ED5A80621EE4@cisco.com> 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 Mar 2010 11:06:25 -0800 X-Mailer: Apple Mail (2.936) Cc: draft-ietf-mediactrl-sip-control-framework@tools.ietf.org, mediactrl-chairs@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-mediactrl-sip-control-framework-11 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 Mar 2010 19:06:31 -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 review comments. I previously reviewed -04 of this I-D and made a number of suggestions. The current version has those suggestions incorporated, and I see no concerns with text added between versions. Brian From new-work-bounces@ietf.org Mon Mar 1 12:30: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 531BC28C596; Mon, 1 Mar 2010 12:30: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 45ED528C58C; Mon, 1 Mar 2010 12:30:01 -0800 (PST) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100301203002.45ED528C58C@core3.amsl.com> Date: Mon, 1 Mar 2010 12:30: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: Mon, 01 Mar 2010 12:35:31 -0800 Subject: [secdir] [New-work] IETF Workshop on Broadband Home Gateways 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, 01 Mar 2010 20:30:04 -0000 During the 76th IETF meeting, the Transport Area sponsored a Broadband Home Gateway BoF, called HOMEGATE. Since that time, interested IETF participants have been working to narrow the scope of the draft charter and to reach out to other Standards Development Organizations (SDOs) to ensure that the planned work is complimentary and not overlapping with their respective work. To further that goal, the IETF's Transport and Internet Areas intend to co-sponsor a two-day workshop on HOMEGATE between IETF-77 and IETF-78. This workshop is slated to take place on April 20-21, 2010 in London, England. In order to reserve a properly sized meeting facility, it is important for interested people to indicate their interest in attending AS SOON AS POSSIBLE. Please do so at http://event.pingg.com/HomeGateLondonMtg NOTE: Due to potential venue limitations and the desire to allow participants from different stakeholder groups to be represented, physical attendance may need to be limited. Attendance will be confirmed at a later time (and certainly early enough for people to book reasonably priced travel accommodations). Remote listening or participation facilities of some sort will be available to all. PLEASE INDICATE YOUR INTEREST NOW if you wish to attend this interim meeting in person: http://event.pingg.com/HomeGateLondonMtg In addition: - You can find the HOMEGATE wiki at http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE - You should join the HOMEGATE mailing list at https://www.ietf.org/mailman/listinfo/homegate Thank you in advance for your interest and participation! Regards, Lars Eggert & Magnus Westerlund, Transport Area Directors Jari Arkko & Ralph Droms, Internet Area Directors _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From GK@ninebynine.org Mon Mar 1 12:54: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 3EA3F28C5A6; Mon, 1 Mar 2010 12:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5Bj2TBrZRKg; Mon, 1 Mar 2010 12:54:40 -0800 (PST) Received: from relay5.mail.ox.ac.uk (relay5.mail.ox.ac.uk [163.1.2.163]) by core3.amsl.com (Postfix) with ESMTP id 22C8728C5A2; Mon, 1 Mar 2010 12:54:40 -0800 (PST) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay5.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1NmCdR-0008Oq-HC; Mon, 01 Mar 2010 20:54:37 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1NmCdQ-0001pM-2z; Mon, 01 Mar 2010 20:54:37 +0000 Message-ID: <4B8C16DC.5030703@ninebynine.org> Date: Mon, 01 Mar 2010 19:34:52 +0000 From: Graham Klyne User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Tero Kivinen References: <19335.45416.521059.570426@fireball.kivinen.iki.fi> <4B87D118.1090408@greenbytes.de> <19339.47272.515270.37133@fireball.kivinen.iki.fi> In-Reply-To: <19339.47272.515270.37133@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 X-Mailman-Approved-At: Mon, 01 Mar 2010 13:05:36 -0800 Cc: httpbis-chairs@tools.ietf.org, secdir@ietf.org, iesg@ietf.org, Julian Reschke 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: Mon, 01 Mar 2010 20:54:41 -0000 For information: Larry Masinter recently suggested replacing some similar text in the IRI specification with a reference to a Unicode report: http://lists.w3.org/Archives/Public/www-tag/2010Feb/0175.html #g -- Tero Kivinen wrote: > Julian Reschke writes: >> -- 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 think that text adequately covers non-ASCII characters issues. > >>> 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. > > Yes, but the impact of them is different. For example it does not > really matter if the filename parameters having different languages > differ, but there might be parameters where this really matters. > > As this document does not define any exact parameters, it might be > enough to comment something like that "This document specifies way to > transport multiple language variants for parameters, and such use > might allow spoofing attacks, where different language versions of the > same parameters do not match. Whether this attack is useful as an > attack depends on the parameter specified." > > This way the one writing documents specifying parameters allowing > multiple languages and specifying some kind processing on them will > think whether this attack affects them or not. > >> 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. > > Such document would probably be so long that it would not be that > useful. I think listing exact security considerations specific for > this document in the security considerations section is better, > altough for background information pointing to another document (like > RFC 3629) is enough. > >> For the spoofing issue I'm now pointing to RFC 3629 -- do you feel we >> need more? > > I am not really sure for what kind of parameters the different > language versions are used, so I cannot really comment whether there > can be security issues because of them. > > If you are sure there cannot be any security issues because of them, > then you should say so. If you do do not know, then it is better to > mention here to make those who use them to think about the security > issues they might raise. From clonvick@cisco.com Mon Mar 1 13:24: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 C0EB928C16D; Mon, 1 Mar 2010 13:24:13 -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 AmZ5O+9EQz+D; Mon, 1 Mar 2010 13:24:13 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 096173A743D; Mon, 1 Mar 2010 13:24:13 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAO/i0urRN+J/2dsb2JhbACPUQGLNXOlWJdqhHsEgxc X-IronPort-AV: E=Sophos;i="4.49,562,1262563200"; d="scan'208";a="94144560" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 01 Mar 2010 21:24:13 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o21LODIQ010968; Mon, 1 Mar 2010 21:24:13 GMT Date: Mon, 1 Mar 2010 13:24:13 -0800 (PST) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dnsext-axfr-clarify.all@tools.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [secdir] secdir review of draft-ietf-dnsext-axfr-clarify-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: Mon, 01 Mar 2010 21:24:13 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall, I found no problems with the document. It is well written and very explanatory. The following notes and suggestions are editorial. It would be nice to reference the security considerations of RFCs 1034 and 1035 just to say that this specification doesn't add any new considerations, however those documents don't have any security considerations sections. Would the authors then consider something like the following (which would be the first paragraph in Section 8): This document is a clarification of a mechanism outlined in RFCs 1034 and 1035 and as such does not add any new security considerations. The security considerations relevent to the deployment of this specification are noted in RFC 4033. In my first reading of the document, I was unfamiliar with the term "mbz". I'd suggest expanding the acronym in one place. Thanks, Chris From fernando@gont.com.ar Mon Mar 1 23:31:33 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 AEE6B28C219; Mon, 1 Mar 2010 23:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 uaXFkB4hTUch; Mon, 1 Mar 2010 23:31:32 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id BA36828C112; Mon, 1 Mar 2010 23:31:29 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id 9BD0E6B6876; Tue, 2 Mar 2010 04:31:28 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o227VBpM031025; Tue, 2 Mar 2010 04:31:19 -0300 Message-ID: <4B8CBEC1.1080203@gont.com.ar> Date: Tue, 02 Mar 2010 04:31:13 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Charlie Kaufman 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]); Tue, 02 Mar 2010 04:31:24 -0300 (ART) Cc: "gorry@erg.abdn.ac.uk" , "secdir@ietf.org" , "micheal.larsen@tietoenator.com" , "lars.eggert@nokia.com" , "jmpolk@cisco.com" , "iesg@ietf.org" Subject: Re: [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: Tue, 02 Mar 2010 07:31:33 -0000 Hello, Charlie, Thanks so much for your feedback! Comments in-line.... > 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=31) are preferred, since > otherwise distribution when reduced mod num_ephemeral will not be > uniform. Would requiring random() to return 32-bit random values address this comment? > p16 para 2: suggests use of MD5, which is fine from the point of view > of documenting current practice, and in fact is cryptographically > just fine in this 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 better to just suggest "some > cryptographic hash function", or if you have to suggest something > specific, perhaps SHA-256. My take on this is that as we're just obfuscating port numbers, MD5 is good enough. But please let me know if you argue that we should s/MD5/SHA-256/..... > The appendix at the end should specify the > hash algorithm used by existing implementations. You mean Appendix A? If so, we could probably just indicate that Linux uses MD5 for the hash-based port randomization algorithm. > Your sample code in many cases, but in particular on page 17 figure 5 > ignores the possibility of integer overflow when incrementing things > (e.g. table[index]++). The results of modular arithmetic when one of > the operands is negative is language dependent, and in ANSI C is not > defined, so this code could corrupt memory (unless the values being > incremented are unsigned). All operands are assumed to be unsigned. Please let me know if I should clarify this. > p20 para 2: suggests use of a 32 bit key, which has exploitable > security problems even though MD5 is fine. 64 bits is a bare minimum, > and since bits are cheap someone should really use 128. Ok, I'll s/32/128/ > 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 inputs and they are generally harmless. If they > occurred at greater frequency than would be expected by chance, the > port-offset mechanism proposed in this document would have a reduced > effect. Ok. I'll tweak the text. > p24 para 4: Similarly, seeding the random number generator with a > good source of randomness will make an implementation more secure, > but "must" is a bit strong. Not sure what you mean. This para just refers to the quality of random numbers. i.e., that if your going to use only random numbers for the secret key, they should be "good enough" (with "good enough" being RFC4086) > Detailed non-security relevant comments: > > The document is titled "Transport Protocol Port Randomization > Recommendations", but it doesn't really make recommendations. It > enumerates current practice 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. How about "Transport Protocol Port Randomization", instead? > 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 reference to RFC 2119? It does. See Section 3.2 and Section 3.3. > 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 whole range 1024-49151". Is > this saying you should use port numbers not intended for this use? Do > you mean should use the whole range 1024-65535? The later: the text should say "...port selection algorithms should use the whole range 1024-49151" (I screwed up the text in my last rev.... will fix this). > > Typos: > > p12 line 2: "is not affected is not affected" -> "is not affected" Fixed. > p13 para 2 line 2: "interger" -> "integer" p16 para 3: "chosen as > random as possible" -> "chosen to be as random as possible" p20 para > 3: "reasonable" -> "reasonably" 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 kivinen@iki.fi Tue Mar 2 01:18: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 D33F828C107; Tue, 2 Mar 2010 01:18:58 -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 Sw6v2QtAYltf; Tue, 2 Mar 2010 01:18:57 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6C11628C0F4; Tue, 2 Mar 2010 01:18:57 -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 o229IoCd025277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 11:18:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o229Io61013610; Tue, 2 Mar 2010 11:18:50 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19340.55290.30153.415562@fireball.kivinen.iki.fi> Date: Tue, 2 Mar 2010 11:18:50 +0200 From: Tero Kivinen To: Julian Reschke In-Reply-To: <4B8BFA7D.5010603@greenbytes.de> References: <19335.45416.521059.570426@fireball.kivinen.iki.fi> <4B87D118.1090408@greenbytes.de> <19339.47272.515270.37133@fireball.kivinen.iki.fi> <4B8BFA7D.5010603@greenbytes.de> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min 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: Tue, 02 Mar 2010 09:18:58 -0000 Julian Reschke writes: > I'm tracking this at > . > > For now I have modified the Sec Considerations to: > > -- 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. > > In addition, this document specifies a way to transport multiple > language variants for a single parameter, and such use might allow > spoofing attacks, where different language versions of the same > parameter are not equivalent. Whether this attack is useful as an > attack depends on the parameter specified. > -- snip -- > > Please let me know whether this works for you (and thanks for the > concrete proposal). Yes, that text works for me. -- kivinen@iki.fi From lars.eggert@nokia.com Tue Mar 2 06:30: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 21AAA3A8A86; Tue, 2 Mar 2010 06:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.291, 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 qM0PEvfFF+bA; Tue, 2 Mar 2010 06:30:05 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 4A8A43A8A85; Tue, 2 Mar 2010 06:30:05 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o22ESqmB016958; Tue, 2 Mar 2010 08:29:00 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 16:28:25 +0200 Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 16:28:25 +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 o22ESM2V024469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 16:28:23 +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-40--677400384; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4B8CBEC1.1080203@gont.com.ar> Date: Tue, 2 Mar 2010 06:28:11 -0800 Message-Id: <7E759E79-2154-476C-BD31-F8E0F1483D76@nokia.com> References: <4B8CBEC1.1080203@gont.com.ar> To: Fernando Gont 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]); Tue, 02 Mar 2010 16:28:16 +0200 (EET) X-OriginalArrivalTime: 02 Mar 2010 14:28:25.0583 (UTC) FILETIME=[9E8FFFF0:01CABA14] X-Nokia-AV: Clean Cc: "gorry@erg.abdn.ac.uk" , "secdir@ietf.org" , "micheal.larsen@tietoenator.com" , "jmpolk@cisco.com" , "iesg@ietf.org" Subject: Re: [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: Tue, 02 Mar 2010 14:30:06 -0000 --Apple-Mail-40--677400384 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, when you make some of the text changes that Charlie suggested, please = make them in a way that doesn't break what the document says about = [Allman]. (Mark Allman ran some tests with some of the algorithms in = this document, and if we change their description retroactively, it may = affect what we can say about his effort.) On 2010-3-1, at 23:31, Fernando Gont wrote: >> Detailed non-security relevant comments: >>=20 >> The document is titled "Transport Protocol Port Randomization >> Recommendations", but it doesn't really make recommendations. It >> enumerates current practice 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. this came up during the WG discussion. If I remember correctly, the = document is the way it is because the WG felt that multiple schemes work = well, and because this is not something that requires interoperability, = there was no strong need to pick a "winner". Lars= --Apple-Mail-40--677400384 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 MQ8XDTEwMDMwMjE0MjgxMlowIwYJKoZIhvcNAQkEMRYEFIxJW555Msxhh/EwEPcRvAxayunoMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCL9ARwnJfkByTeKMCh3ozyffOEaLue/o0CbLjnQQVvNUIOAxvhQ9rd0nMZw2JNOGOowQzF 5WebORw1MM3eA2J1EwCPUqn9K8Ic/PcRqd6LXNqGaTKTY9lWZ+QMiqcTVhGXDmRjewLhPnZgz5QB G6h5RwDjGV0fmm9WU0f/WvdSdDLJLmsVgYuKgYvy+uKR+P7Ph6h+Lpe54Ps9VGCniNdRLhm3hPDE e3Bf15TQ7HWLQQwriwR2HGsRj4APwLj+6BPplwymXjbsJWFsIA8xt96xjlGJRpDWHLcCktS0KVGt pkgLtGXoqPMP1aXmoYKeg6t373iQe1ANZfcvT5SErcB5AAAAAAAA --Apple-Mail-40--677400384-- From clonvick@cisco.com Tue Mar 2 07:06: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 DB1353A8AF4; Tue, 2 Mar 2010 07:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 ncaqaLofmxOJ; Tue, 2 Mar 2010 07:06:57 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0044D3A8ABD; Tue, 2 Mar 2010 07:06:56 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ+4jEurRN+J/2dsb2JhbACbBXOmcphShHsEgxc X-IronPort-AV: E=Sophos;i="4.49,567,1262563200"; d="scan'208";a="94617120" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2010 15:06:58 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o22F6v1M014172; Tue, 2 Mar 2010 15:06:57 GMT Date: Tue, 2 Mar 2010 07:06:57 -0800 (PST) From: Chris Lonvick To: Alfred =?hp-roman8?B?SM5uZXM=?= In-Reply-To: <201003021445.PAA16394@TR-Sys.de> Message-ID: References: <201003021445.PAA16394@TR-Sys.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-341603450-1267542417=:7331" Cc: draft-ietf-dnsext-axfr-clarify.all@gamay.tools.IETF.ORG, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dnsext-axfr-clarify-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, 02 Mar 2010 15:06:58 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-341603450-1267542417=:7331 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Alfred, On Tue, 2 Mar 2010, Alfred H=CEnes wrote: > Chris, > thanks for your detailed review. See detailed responses inline. > >> Hi, >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> Overall, I found no problems with the document. It is well written and >> very explanatory. The following notes and suggestions are editorial. > > Thanks for this former judgement in particular. > It deemed specifically important for a topic that some years ago > had caused controversies to be as clear and logically consistent > as possible and to explain therein the reasons to write that > document -- the very cursory text in STD 13 that essentially had > laid the grounds for diverging exegesis. > >> >> It would be nice to reference the security considerations of RFCs 1034 >> and 1035 just to say that this specification doesn't add any new >> considerations, however those documents don't have any security >> considerations sections. Would the authors then consider something >> like the following (which would be the first paragraph in Section 8): > >> This document is a clarification of a mechanism outlined in RFCs 103= 4 >> and 1035 and as such does not add any new security considerations. >> The security considerations relevent to the deployment of this >> specification are noted in RFC 4033. > > Unless someone opposes, such text can be added, sure. > But in that case, wouldn't RFC 3833 be a better choice than RFC 4033? > RFC 4033 indeed contains considerations that go beyond DNSSEC, but > the more generic security considerations for the DNS in general are > in RFC 3833. I suggest to add the following text: > > | This document is a clarification of a mechanism outlined in RFCs 1034 > | and 1035 and as such does not add any new security considerations. > | RFC 3833 [RFC3833] is devoted entirely to security considerations for > | the DNS; its Section 4.3 delineates zone transfer security aspects > | from the security threats addressed by DNSSEC. > > [ + add an entry [RFC3833] to Section 12.2 (Informative References). ] > > Does that make sense to you? That does address my concern very well. (Not being familiar with the=20 DNSSEC RFCs I chose 4033 from your list of references as it was close=20 enough from my quick scans. :) > > >> In my first reading of the document, I was unfamiliar with the term >> "mbz". I'd suggest expanding the acronym in one place. > > The first appearance of "mbz" is in Section 2.1.1, enclosed in (single) > quotes, and tagged with "-- see Note c)", where Note c) (at the bottom > of page 9) contains the explanation: > > c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore > it. > > 'mbz' is used more as a user-friendly symbol -- at first glance similar > to "MUST be 0", but actually quite different -- for the classification > of fields than a literal acronym (and hence also written on lowercase), > and the common expansion "must be zero" deliberately has been omitted > because of anecdotal evidence that implementors have understood that as > an encouragement, or even requirement, to check for value 0 on receipt, > which is contrary to what we want. Ahh, now I see; that is your definition. OK, I was looking for an acronym= =20 expansion. I'm not going to object if you leave it as is. > > Note: Similar considerations apply to 'n/a' ( same section, Note b) ). Yup, but that one I could figure out without a definition. :-) Best regards, Chris ---559023410-341603450-1267542417=:7331-- From sra@hactrn.net Tue Mar 2 10:04: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 713D028C214; Tue, 2 Mar 2010 10:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 mRA5dZKJv2+V; Tue, 2 Mar 2010 10:04:12 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 0293628C1E6; Tue, 2 Mar 2010 10:04:12 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 3462628440; Tue, 2 Mar 2010 18:04:11 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id E996822807; Tue, 2 Mar 2010 13:04:10 -0500 (EST) Date: Tue, 02 Mar 2010 13:04:10 -0500 From: Rob Austein To: iesg@ietf.org, secdir@ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100302180410.E996822807@thrintun.hactrn.net> Cc: pkix-chairs@tools.ietf.org, draft-ietf-pkix-attr-cert-mime-type-03@tools.ietf.org Subject: [secdir] Review of draft-ietf-pkix-attr-cert-mime-type-03.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, 02 Mar 2010 18:04:13 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is a 4 page draft targeted at informational status in support of a MIME media type registration for RFC 3281 attribute certificates. I have no security concerns with this document. From A.Hoenes@TR-Sys.de Tue Mar 2 06:46: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 4481B28C119; Tue, 2 Mar 2010 06:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.001 X-Spam-Level: ** X-Spam-Status: No, score=2.001 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, 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 X8Ef7fhNeVa9; Tue, 2 Mar 2010 06:46:16 -0800 (PST) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id F11BC3A8AA0; Tue, 2 Mar 2010 06:46:14 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA216001137; Tue, 2 Mar 2010 15:45:37 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id PAA16394; Tue, 2 Mar 2010 15:45:36 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201003021445.PAA16394@TR-Sys.de> To: clonvick@cisco.com Date: Tue, 2 Mar 2010 15:45:35 +0100 (MEZ) In-Reply-To: from Chris Lonvick at Mar "1, " 2010 "01:24:13" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Mar 2010 10:52:33 -0800 Cc: draft-ietf-dnsext-axfr-clarify.all@gamay.tools.IETF.ORG, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dnsext-axfr-clarify-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, 02 Mar 2010 14:46:17 -0000 Chris, thanks for your detailed review. See detailed responses inline. > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Overall, I found no problems with the document. It is well written and > very explanatory. The following notes and suggestions are editorial. Thanks for this former judgement in particular. It deemed specifically important for a topic that some years ago had caused controversies to be as clear and logically consistent as possible and to explain therein the reasons to write that document -- the very cursory text in STD 13 that essentially had laid the grounds for diverging exegesis. > > It would be nice to reference the security considerations of RFCs 1034 > and 1035 just to say that this specification doesn't add any new > considerations, however those documents don't have any security > considerations sections. Would the authors then consider something > like the following (which would be the first paragraph in Section 8): > This document is a clarification of a mechanism outlined in RFCs 1034 > and 1035 and as such does not add any new security considerations. > The security considerations relevent to the deployment of this > specification are noted in RFC 4033. Unless someone opposes, such text can be added, sure. But in that case, wouldn't RFC 3833 be a better choice than RFC 4033? RFC 4033 indeed contains considerations that go beyond DNSSEC, but the more generic security considerations for the DNS in general are in RFC 3833. I suggest to add the following text: | This document is a clarification of a mechanism outlined in RFCs 1034 | and 1035 and as such does not add any new security considerations. | RFC 3833 [RFC3833] is devoted entirely to security considerations for | the DNS; its Section 4.3 delineates zone transfer security aspects | from the security threats addressed by DNSSEC. [ + add an entry [RFC3833] to Section 12.2 (Informative References). ] Does that make sense to you? > In my first reading of the document, I was unfamiliar with the term > "mbz". I'd suggest expanding the acronym in one place. The first appearance of "mbz" is in Section 2.1.1, enclosed in (single) quotes, and tagged with "-- see Note c)", where Note c) (at the bottom of page 9) contains the explanation: c) 'mbz' -- The client MUST set this bit to 0, the server MUST ignore it. 'mbz' is used more as a user-friendly symbol -- at first glance similar to "MUST be 0", but actually quite different -- for the classification of fields than a literal acronym (and hence also written on lowercase), and the common expansion "must be zero" deliberately has been omitted because of anecdotal evidence that implementors have understood that as an encouragement, or even requirement, to check for value 0 on receipt, which is contrary to what we want. Note: Similar considerations apply to 'n/a' ( same section, Note b) ). > Thanks, > Chris > Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From barryleiba@gmail.com Tue Mar 2 11:43: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 7305C3A8AF6; Tue, 2 Mar 2010 11:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 TijhO+m0elLA; Tue, 2 Mar 2010 11:43:11 -0800 (PST) Received: from mail-pz0-f171.google.com (mail-pz0-f171.google.com [209.85.222.171]) by core3.amsl.com (Postfix) with ESMTP id 4678D3A8AEA; Tue, 2 Mar 2010 11:43:11 -0800 (PST) Received: by pzk1 with SMTP id 1so525342pzk.17 for ; Tue, 02 Mar 2010 11:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tIpl7oHLKxs/DZmqBsuFGpfgzczp3zQePdcVgfDs2Us=; b=DlZR14+yVXZ+ViU36al1LAx5Gcy9kI92rdf43MU9Bv2IMYHjgm+CqSLRwAM58/ST76 tDnrn9c5hv6pLzuz/wn9wuojH7Y5YpA0w2ckBTf3Rux0x0K9ctnrR9ngrSLBtNpuJ0Gm lt3fTIobTv/6SXGMDp61igPMwfa8GO0bO8U0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=bT18woPzJyY0Dp7V5WzGB3+9MEkDbMZWFvVjSv1Kc1dlP+nfdoz881GnSGhQdnl8Pb iQ/iI34skR4wuH4YBsGdAY0c8DajNQO6G4BbBGwIvRInfwFR5xFCcsNwH0lq+7tB2/56 8OS17atuM62++PSE6AKstrOF5CF89g6ZTT4mQ= MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.142.249.25 with SMTP id w25mr3760894wfh.15.1267558987819; Tue, 02 Mar 2010 11:43:07 -0800 (PST) Date: Tue, 2 Mar 2010 14:43:07 -0500 X-Google-Sender-Auth: 2edecadf990bae95 Message-ID: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com> From: Barry Leiba To: secdir@ietf.org, draft-ietf-dnsext-dnssec-alg-allocation.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: iesg@ietf.org Subject: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-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 Mar 2010 19:43:12 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document relaxes the requirement for registration of a crypto algorithm for DNSSEC, allowing algorithms documented in informational RFCs (including individual and independent submissions) to be registered. Until now, an algorithm had to be on standards track for registration. I have mixed feelings about this. Since I haven't participated in any conversations about this until now, please forgive me if I'm repeating things that have (undoubtedly) been discussed already, and take this with the appropriate condiments. I understand the reasoning for allowing non-standards-track algorithms, but I don't understand the reason not to use "Expert Review", specifying that the documentation required is an RFC, and giving at least *some* criteria for the expert to consider. Otherwise, I wonder whether registration of poorly designed algorithms will happen, and those algorithms may present an attractive nuisance, getting widely implemented by virtue of being registered, despite what this document says about that. Given that this registry is part of the basis for the security of DNS, I'd rather see at least some oversight (noting that "oversee" and "overlook" mean very different things). Even with expert review, we could allow weak or otherwise poor algorithms to be registered, if we want to do that, with the addition of a field in the registry that indicates the expert's assessment: perhaps it could say "not recommended" as a sufficient warning. That would also allow updates later, giving erstwhile-good algorithms a status of "compromised", "deprecated", or the like (and would be a better place to note the deprecation of RSA/MD5 than in the algorithm description, where it is now). Going to the bullet at the bottom of page 2, what I'd like to ensure is that an algorithm that "might not have been evaluated thoroughly enough to be able to be put on the Standards Track" has nonetheless been evaluated thoroughly enough to be in an "official list" of likely candidates for implementation. An "assessment" column would provide that. I'd like to see the text of the last paragraph of section 3 change: OLD It should be noted that the order of algorithms in the IANA registry does not signify or imply cryptographic strength or preference. NEW It should be noted that the presence of or order of algorithms in the IANA registry does not signify or imply cryptographic strength or preference. I think this should have an informative reference to RFC 5226 section 4.1, which defines the IANA registration policies (and gives the specific meaning of "RFC Required"). Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ From sra@hactrn.net Tue Mar 2 11:48: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 B78ED3A8C86; Tue, 2 Mar 2010 11:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 tZ7MdQnNBhd9; Tue, 2 Mar 2010 11:48:25 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 84BD03A8C84; Tue, 2 Mar 2010 11:48:24 -0800 (PST) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 3E1A128473; Tue, 2 Mar 2010 19:48:23 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id EA82A22807; Tue, 2 Mar 2010 14:48:22 -0500 (EST) Date: Tue, 02 Mar 2010 14:48:22 -0500 From: Rob Austein To: iesg@ietf.org, secdir@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20100302194822.EA82A22807@thrintun.hactrn.net> Cc: ipsecme-chairs@tools.ietf.org, draft-ietf-ipsecme-esp-null-heuristics@tools.ietf.org Subject: [secdir] Review of draft-ietf-ipsecme-esp-null-heuristics-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: Tue, 02 Mar 2010 19:48:25 -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 documents a set of heuristics to allow a packet inspection engine (stateful firewall, protocol analyzer, ...) to spot IPsec ESP streams that use NULL encryption as efficiently as possible, without modifications to the IPsec protocols. While I have reservations about some of the scenarios in which such a mechanism might be useful, this is clearly a chartered work item for the IPSECME WG, this is happening at a deep enough level that any a priori correlation between role and hat color is quite weak, it seems likely to be deployed whether I like it or not, and, in any case, as this draft makes no changes to IPsec itself (thus placing the workload on the packet inspection engine), this draft is less troubling than other approaches in this space. The Security Considerations section is OK as far as it goes, but could benefit from some additional text or references to other parts of the document. Specifically: - The discussion of failure modes for the heuristics is in section 3, with no reference from the Security Considerations section. - The discussion of failure modes for the heuristics in section 3 is also incomplete: while it (correctly, I think) concludes that misclassifying traffic as ESP-NULL is no worse than a DoS attack which an attacker could have launched anyway, it does not discuss the other failure mode: what happens if a stream is misclassified as non-NULL ESP, thus (depending on policy) allowing it through without inspection, or dropping it on the floor? The above suggestions notwithstanding, I have no serious security concerns with this document. It doesn't modify IPsec, so from the IPsec point of view this is at worst a public analysis of some techniques for detecting a set of configuration choices that an IPsec user presumably made intentionally. From the packet inspection point of view, the heuristics are probably both harmless and useful, subject to the caveats above and in the document; packet inspection is an error-prone activity in any case, and following the advice in this document (which is targeted for Informational status) seems unlikely to make things worse. I did not attempt to review the pseudo-code in Appendix A. From ajs@shinkuro.com Tue Mar 2 12:31: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 EA0F828C16F; Tue, 2 Mar 2010 12:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[AWL=1.500, 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 LaxbNDdv3xe7; Tue, 2 Mar 2010 12:31:05 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id B281528C180; Tue, 2 Mar 2010 12:31:05 -0800 (PST) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6C43C1ECBC22; Tue, 2 Mar 2010 20:31:05 +0000 (UTC) Date: Tue, 2 Mar 2010 15:31:03 -0500 From: Andrew Sullivan To: Barry Leiba Message-ID: <20100302203103.GJ2901@shinkuro.com> References: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: draft-ietf-dnsext-dnssec-alg-allocation.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-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 Mar 2010 20:31:08 -0000 Hi, Thanks for the review of this document. On Tue, Mar 02, 2010 at 02:43:07PM -0500, Barry Leiba wrote: > I understand the reasoning for allowing non-standards-track > algorithms, but I don't understand the reason not to use "Expert > Review", specifying that the documentation required is an RFC, and > giving at least *some* criteria for the expert to consider. > Otherwise, I wonder whether registration of poorly designed algorithms > will happen, and those algorithms may present an attractive nuisance, > getting widely implemented by virtue of being registered, despite what > this document says about that. I have a certain amount of sympathy for this comment, but the plain fact is that the DNS community does not actually have the expertise to evaluate cryptographic algorithms anyway. The upshot therefore of your suggestion is that the expert review required in this area would probably require an expert panel in each case, with one member from the DNS community and another from the security community. More importantly, I'm not sure there's actually a problem to solve here. Do we have a problem in other protocols where poor crypto algorithms have won out over better-designed algorithms? > Even with expert review, we could allow weak or otherwise poor > algorithms to be registered, if we want to do that, with the addition > of a field in the registry that indicates the expert's assessment: > perhaps it could say "not recommended" as a sufficient warning. That > would also allow updates later, giving erstwhile-good algorithms a > status of "compromised", "deprecated", or the like (and would be a > better place to note the deprecation of RSA/MD5 than in the algorithm > description, where it is now). We do in fact have a completely separate effort underway to update the registry in order to allow certain kinds of indicators like this. The WG seemed to agree that these were separate problems and didn't want to conflate them. Does that other effort address your concern? > I'd like to see the text of the last paragraph of section 3 change: > OLD > It should be noted that the order of algorithms in the IANA registry > does not signify or imply cryptographic strength or preference. > NEW > It should be noted that the presence of or order of algorithms in the > IANA registry does not signify or imply cryptographic strength or > preference. I see no objection to that alteration. > I think this should have an informative reference to RFC 5226 section > 4.1, which defines the IANA registration policies (and gives the > specific meaning of "RFC Required"). I have no objection to this reference. Thanks again for the review, Andrew (doc shepherd) -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From barryleiba.mailing.lists@gmail.com Tue Mar 2 12:42:28 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 E925E28C144; Tue, 2 Mar 2010 12:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 pGQDzr+DmGq8; Tue, 2 Mar 2010 12:42:28 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id B100B28C0CF; Tue, 2 Mar 2010 12:42:27 -0800 (PST) Received: by fxm5 with SMTP id 5so757089fxm.29 for ; Tue, 02 Mar 2010 12:42:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=JRdR4QFA9z7fTUvqhaT1UYCF+4s3AUkJ9wNRE28xtr8=; b=ConQN71v9QXsxkezb55/z/BrYUdGlpfzIIllWk0Oy0SZc4GcLIsDfgzwKoSlrK4pTu kJVZNtvg5ftPTGtlrxv0wY544BN2m3PM1zqZaZw4yBkNysLRNJL4QsfA7rH2vQ+gA34M BqcpIumKuQHdg5xkgfmRzIY3cp+hNDkICnMx4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=wZtIuys0zidorfMCw+Yxaa+2wc/JdkpXkS5nL7ZChQF+d4RBKQ3drOSqb7jszaSpTq SAciJGS5frqbMSS4a/Jvpa6WmnMs/UNRVdVQ++o535EMKulJY1n8B/fPKgPElN6y8hMB YH21+ifDSBkeXb3VDdseucZkkZ9kAS6aMsNzw= MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.223.14.15 with SMTP id e15mr7270850faa.57.1267562545046; Tue, 02 Mar 2010 12:42:25 -0800 (PST) In-Reply-To: <20100302203103.GJ2901@shinkuro.com> References: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com> <20100302203103.GJ2901@shinkuro.com> Date: Tue, 2 Mar 2010 15:42:24 -0500 X-Google-Sender-Auth: 02d3c9e5e7c2eaf0 Message-ID: <6c9fcc2a1003021242p16379b6ai6d87f6cf497b37cb@mail.gmail.com> From: Barry Leiba To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-dnsext-dnssec-alg-allocation.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-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 Mar 2010 20:42:29 -0000 > The upshot therefore of your suggestion is that the expert review > required in this area would probably require an expert panel in each > case, with one member from the DNS community and another from the > security community. I understand. > More importantly, I'm not sure there's actually a problem to solve > here. =A0Do we have a problem in other protocols where poor crypto > algorithms have won out over better-designed algorithms? Actually, we do -- not with "won out", so much as "got implemented", which then leaves a hole in the algorithm negotiation process. HTTP clients and servers, for instance, often support long-broken versions of SSL, weak encryption algorithms, and too-short key lengths. The result is that both clients and servers can be steered, in the negotiation process, toward use of weak crypto, which can then undermine the security of the transactions. > We do in fact have a completely separate effort underway to update the > registry in order to allow certain kinds of indicators like this. =A0The > WG seemed to agree that these were separate problems and didn't want > to conflate them. =A0Does that other effort address your concern? Partially. It depends upon how that work resolves the question of who gets to decide what values those indicators take. If I can register the BBC algorithm (Barry's Broken Crypto), and give it soi-disant "highly recommended" status, then nothing's solved. If someone *else* is responsible for controlling that field, then we're back to asking who the expert (or panel of) is. Anyway, repeating: my lone opinion on this doesn't override a bunch of people who spent a lot of time going over this and came to consensus. I'm just a bit concerned, is all. Barry From ajs@shinkuro.com Tue Mar 2 15:12: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 E905F28C2A7; Tue, 2 Mar 2010 15:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=1.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 1Ir74c8ugzR4; Tue, 2 Mar 2010 15:12:16 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id A6FED28C25C; Tue, 2 Mar 2010 15:12:12 -0800 (PST) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EE1ED1ECBC22; Tue, 2 Mar 2010 23:12:10 +0000 (UTC) Date: Tue, 2 Mar 2010 18:12:04 -0500 From: Andrew Sullivan To: Barry Leiba Message-ID: <20100302231204.GM2901@shinkuro.com> References: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com> <20100302203103.GJ2901@shinkuro.com> <6c9fcc2a1003021242p16379b6ai6d87f6cf497b37cb@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6c9fcc2a1003021242p16379b6ai6d87f6cf497b37cb@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: draft-ietf-dnsext-dnssec-alg-allocation.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-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 Mar 2010 23:12:23 -0000 On Tue, Mar 02, 2010 at 03:42:24PM -0500, Barry Leiba wrote: > > More importantly, I'm not sure there's actually a problem to solve > > here.  Do we have a problem in other protocols where poor crypto > > algorithms have won out over better-designed algorithms? > > Actually, we do -- not with "won out", so much as "got implemented", > which then leaves a hole in the algorithm negotiation process. HTTP > clients and servers, for instance, often support long-broken versions > of SSL, weak encryption algorithms, and too-short key lengths. The > result is that both clients and servers can be steered, in the > negotiation process, toward use of weak crypto, which can then > undermine the security of the transactions. Hrm. Well, in DNSSEC, there _is_ no algorithm negotiation process. The client validates using the signatures that are published, or it doesn't validate at all. And remember that in the case of DNSSEC, we have no reason (so far) to suppose that we'll get to the state where validation is required. Under the protocol, if you don't understand the algorithm on the signature available to you (which could actually be a subset of the signatures in the zone, due to the effects of caches), you just treat the response as not secured. So it's just like the zone isn't signed. There's the additional factor that adding algorithms increases response size, which increases transit cost for the zone operator. Because there's no way to negotiate the algorithm and there's an incentive to keep the number of algorithms in use small, we've had the idea that validators are likely to converge on one or two good ones, and tend to stay there. > > We do in fact have a completely separate effort underway to update the > > registry in order to allow certain kinds of indicators like this.  The > > WG seemed to agree that these were separate problems and didn't want > > to conflate them.  Does that other effort address your concern? > > Partially. It depends upon how that work resolves the question of who > gets to decide what values those indicators take. If I can register > the BBC algorithm (Barry's Broken Crypto), and give it soi-disant > "highly recommended" status, then nothing's solved. If someone *else* > is responsible for controlling that field, then we're back to asking > who the expert (or panel of) is. The text of this draft currently explicitly notes that it doesn't change the rules for making an algorithm mandatory to implement. Since making an algorithm mandatory to implement would update 4034, I therefore think that it would still require standards action, which punts the whole business right back to the same process in place today. Does that make you less uneasy? Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From barryleiba.mailing.lists@gmail.com Tue Mar 2 15:21:49 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 284423A6884; Tue, 2 Mar 2010 15:21:48 -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 VtBFZ86-sXEY; Tue, 2 Mar 2010 15:21:36 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 7DB353A7870; Tue, 2 Mar 2010 15:21:31 -0800 (PST) Received: by fxm5 with SMTP id 5so923180fxm.29 for ; Tue, 02 Mar 2010 15:21:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+SNJ2n8d8EJ0atGuHUco6a58olHhQfY1dYqIRIdcuyc=; b=ncXGhsoDga9UYs30R4A0XCLDu4j8KxIVJykECFoTFXslCsgojT2whNc3kZgR+YiLpX oRFCeC7c3whFORDy3AejOqx2ib+CRMxFtjI8x2kXJAooXoKkg37ligJDdX3KzfmxaFEC tpgdgsN0NP4Z0qsvgNz6brAUkDDZ1aqbhFi2w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=x5qi02XOuYkRS9sYmLixKJJ7duy3m69O8m8w0GDPPCh2hZk8UOEWhVXJ4Q/wbSlF0m f9SCGviB7n4CGFeMEaekZmqaLdlfyyDp1Vm/MHAswk0BJXfn95DyaG2oIGq/SAIlGrH2 5cHGo4ixF6Uukexn8HarekVs1GlSa4IZWHDiM= MIME-Version: 1.0 Received: by 10.223.6.88 with SMTP id 24mr7491866fay.2.1267572088522; Tue, 02 Mar 2010 15:21:28 -0800 (PST) In-Reply-To: <20100302231204.GM2901@shinkuro.com> References: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com> <20100302203103.GJ2901@shinkuro.com> <6c9fcc2a1003021242p16379b6ai6d87f6cf497b37cb@mail.gmail.com> <20100302231204.GM2901@shinkuro.com> Date: Tue, 2 Mar 2010 18:21:28 -0500 Message-ID: <6c9fcc2a1003021521i2f2e90afm62e392e9fe0dfd65@mail.gmail.com> From: Barry Leiba To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-dnsext-dnssec-alg-allocation.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 23:21:49 -0000 > Because there's no way to negotiate the algorithm and there's an > incentive to keep the number of algorithms in use small, we've had the > idea that validators are likely to converge on one or two good ones, > and tend to stay there. ... > Since making an algorithm mandatory to implement would update 4034, I > therefore think that it would still require standards action, which > punts the whole business right back to the same process in place > today. =A0Does that make you less uneasy? Yes, this whole discussion makes me much happier -- as I said, I hadn't been involved with this before, so I was coming out of left field anyway. Thanks for the discussion, Andrew. I hope this has been helpful for the ADs, as well. Barry From weiler@watson.org Tue Mar 2 15:46: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 4B1B73A89A4; Tue, 2 Mar 2010 15:46: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 AsyXJsN5bi7p; Tue, 2 Mar 2010 15:46:07 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 5E7A83A85A1; Tue, 2 Mar 2010 15:46:07 -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 o22Nk5F6051698; Tue, 2 Mar 2010 18:46:05 -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 o22Nk3OU051692; Tue, 2 Mar 2010 18:46:03 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 2 Mar 2010 18:46:03 -0500 (EST) From: Samuel Weiler To: Andrew Sullivan In-Reply-To: <20100302231204.GM2901@shinkuro.com> Message-ID: References: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com> <20100302203103.GJ2901@shinkuro.com> <6c9fcc2a1003021242p16379b6ai6d87f6cf497b37cb@mail.gmail.com> <20100302231204.GM2901@shinkuro.com> 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 Mar 2010 18:46:05 -0500 (EST) Cc: draft-ietf-dnsext-dnssec-alg-allocation.all@tools.ietf.org, Barry Leiba , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-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 Mar 2010 23:46:08 -0000 On Tue, 2 Mar 2010, Andrew Sullivan wrote: > The text of this draft currently explicitly notes that it doesn't > change the rules for making an algorithm mandatory to implement. > Since making an algorithm mandatory to implement would update 4034, I > therefore think that it would still require standards action, which > punts the whole business right back to the same process in place > today. Does that make you less uneasy? It still leaves me uneasy. As a casual reader of this doc (and casual author of an algorithm definition doc), I'd be inclinded to assume that an algorithm definition doc, even if not standards track, could at least specify the requirement status for the algorithm it's defining. As I pointed out when reviewing draft-ietf-dnsext-dnssec-registry-fixes, I'm worried about the possibility of an independent submission (=RFC Editor stream document) creating a new "MANDATORY" algorithm or of changing the requirement status of other new algorithms, even if those were defined on the standards track. I proposed some text for the registry-fixes doc to resolve that, and I suggest repeating it here: "Unless specified in a Standards Track RFC, new algorithms will have a requirements status of OPTIONAL. Only a Standards Track RFC may set or change a requirements status of ENCOURAGED or MANDATORY." There may be some additional issues around the particular keywords in that text, but that's the general idea. At the very least, rather than say "This document does not change the requirements for when an algorithm because (sic) mandatory to implement. Such requirements should come in a separate, focused document.", actually tell people what the mechanism/threshhold for setting a requirement level is. I don't think it's currently obvious. -- Sam From ajs@shinkuro.com Tue Mar 2 16:05: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 193353A8B6B; Tue, 2 Mar 2010 16:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.631, 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 5uWKjuCILNvg; Tue, 2 Mar 2010 16:05:12 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 53FC73A6D3F; Tue, 2 Mar 2010 16:05:12 -0800 (PST) Received: from crankycanuck.ca (external.shinkuro.com [66.92.164.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 5CF801ECBC22; Wed, 3 Mar 2010 00:05:11 +0000 (UTC) Date: Tue, 2 Mar 2010 19:05:09 -0500 From: Andrew Sullivan To: Samuel Weiler Message-ID: <20100303000509.GR2901@shinkuro.com> References: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com> <20100302203103.GJ2901@shinkuro.com> <6c9fcc2a1003021242p16379b6ai6d87f6cf497b37cb@mail.gmail.com> <20100302231204.GM2901@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: draft-ietf-dnsext-dnssec-alg-allocation.all@tools.ietf.org, Barry Leiba , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-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, 03 Mar 2010 00:05:13 -0000 On Tue, Mar 02, 2010 at 06:46:03PM -0500, Samuel Weiler wrote: > were defined on the standards track. I proposed some text for the > registry-fixes doc to resolve that, and I suggest repeating it here: > > "Unless specified in a Standards Track RFC, new algorithms will have a > requirements status of OPTIONAL. Only a Standards Track RFC may set or > change a requirements status of ENCOURAGED or MANDATORY." The -02 version of registry-fixes says The requirement status for all new algorithms will be DISCRETIONARY unless a Standards Track document changes that (possibly including the Standards Track document defining the algorithm). Only a Standards Track document may make an algorithm ENCOURAGED or MANDATORY or remove the MANDATORY or ENCOURAGED designation (to DISCOURAGED or OBSOLETE for example). There is no reference from the current (alg-allocation) document to the registry-fixes doc because we were trying, very hard, to keep each document specific and focussed. Does that help? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From weiler@watson.org Tue Mar 2 17:00: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 CC2F93A8863; Tue, 2 Mar 2010 17:00: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 Vr84Ec4RCfjb; Tue, 2 Mar 2010 17:00:11 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 08B2D3A870E; Tue, 2 Mar 2010 17:00:10 -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 o2310Af9063070; Tue, 2 Mar 2010 20:00:10 -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 o23109Zn063065; Tue, 2 Mar 2010 20:00:09 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 2 Mar 2010 20:00:09 -0500 (EST) From: Samuel Weiler To: Andrew Sullivan In-Reply-To: <20100303000509.GR2901@shinkuro.com> Message-ID: References: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com> <20100302203103.GJ2901@shinkuro.com> <6c9fcc2a1003021242p16379b6ai6d87f6cf497b37cb@mail.gmail.com> <20100302231204.GM2901@shinkuro.com> <20100303000509.GR2901@shinkuro.com> 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 Mar 2010 20:00:10 -0500 (EST) Cc: draft-ietf-dnsext-dnssec-alg-allocation.all@tools.ietf.org, Barry Leiba , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-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, 03 Mar 2010 01:00:11 -0000 > The -02 version of registry-fixes says > > The requirement status for all new algorithms will be DISCRETIONARY > unless a Standards Track document changes that (possibly including > the Standards Track document defining the algorithm). Only a > Standards Track document may make an algorithm ENCOURAGED or > MANDATORY or remove the MANDATORY or ENCOURAGED designation (to > DISCOURAGED or OBSOLETE for example). > > There is no reference from the current (alg-allocation) document to > the registry-fixes doc because we were trying, very hard, to keep each > document specific and focussed. > > Does that help? No. alg-allocation, read by itself, is still confusing. Rather than cite the new metric for changing requirement status (as being defined/changed in registry-fixes), alg-allocation could instead cite the current metric. Earlier in this thread you said that was to update 4034 (=standards action). No matter what the metric is, I want alg-allocation to be explicit about the metric. -- Sam From ajs@shinkuro.com Tue Mar 2 18:53: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 774A03A8836; Tue, 2 Mar 2010 18:53:26 -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 P5PybulrOKNg; Tue, 2 Mar 2010 18:53:25 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9BE2B3A859E; Tue, 2 Mar 2010 18:53:25 -0800 (PST) Received: from crankycanuck.ca (3.e54f41.client.atlantech.net [65.79.229.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EB56E1ECBC22; Wed, 3 Mar 2010 02:53:18 +0000 (UTC) Date: Tue, 2 Mar 2010 21:53:14 -0500 From: Andrew Sullivan To: Samuel Weiler Message-ID: <20100303025314.GA4711@shinkuro.com> References: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com> <20100302203103.GJ2901@shinkuro.com> <6c9fcc2a1003021242p16379b6ai6d87f6cf497b37cb@mail.gmail.com> <20100302231204.GM2901@shinkuro.com> <20100303000509.GR2901@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: draft-ietf-dnsext-dnssec-alg-allocation.all@tools.ietf.org, Barry Leiba , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-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, 03 Mar 2010 02:53:26 -0000 On Tue, Mar 02, 2010 at 08:00:09PM -0500, Samuel Weiler wrote: > No. alg-allocation, read by itself, is still confusing. Rather than > cite the new metric for changing requirement status (as being > defined/changed in registry-fixes), alg-allocation could instead cite > the current metric. Earlier in this thread you said that was to update > 4034 (=standards action). > > No matter what the metric is, I want alg-allocation to be explicit about > the metric. It appears, however, that the approach you're suggesting could actually make things more confusing in the near term. DNSEXT is currently trying to do two, strictly separate things: 1. Alter the mechanism to get an algorithm assignment in the IANA registry. That's what the document we're discussing does. 2. Clean up the registry to make it easier to find, in one place, data like what is mandatory to implement or not. That's what registry-fixes does. What you are suggesting is that the present document be made to say not only that it does not alter how you get a "mandatory" flag, but what the current procedure is. The problem with that is that we're actually trying to _change_ what the procedure is, because at the moment it's "update 4034" or maybe "update 3755" or maybe "update 2536". In any case, it's certainly standards action; but what that action is, we'd have to work out when we did it. It is in fact this very confusion that regstry-fixes is supposed to help: on its publication, what you'd have to do is update the registry with the required flad, and registry-fixes makes clear that such an update requires standards action. If we change the current document to say precisely how you get a mandatory flag today, however, we're out of luck: there's actually no mandatory flag in the registry as it stands, so there's nowhere to track this. This therefore would require a lengthy explanation in the current document about how there is in fact no such thing as a mandatory flag in the registry, and that therefore you can't have a restriction on setting the mandatory flag, but that anyway you can't have a mandatory-to-implement algorithm without a standards action. All of that to be obsoleted immediately on publication of whatever ends up coming out of registry-fixes (since even if one doesn't like the current words in that document, _something_ needs to be done about the registry in question). I'm therefore not actually sure how to make the text clearer for the immediate circumstance without also making it more confusing in the hopefully-near future. If you have suggested text to do this, however, I'd be interested in seeing it. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From Shawn.Emery@Sun.COM Tue Mar 2 22:59:38 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 B52F128C238; Tue, 2 Mar 2010 22:59:38 -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 NwuGERGoeCWG; Tue, 2 Mar 2010 22:59:38 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id C522228C101; Tue, 2 Mar 2010 22:59:37 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o236xaWV004451; Wed, 3 Mar 2010 06:59:39 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 <0KYP00K001Y0RE00@mail-amer.sun.com>; Tue, 02 Mar 2010 23:59:36 -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 <0KYP00AEW23C8M40@mail-amer.sun.com>; Tue, 02 Mar 2010 23:59:36 -0700 (MST) Date: Tue, 02 Mar 2010 23:57:30 -0700 From: Shawn M Emery Sender: Shawn.Emery@Sun.COM To: secdir@ietf.org Message-id: <4B8E085A.2060500@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 Cc: draft-ietf-ccamp-gmpls-mln-extensions.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-ccamp-gmpls-mln-extensions-11 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 Mar 2010 06:59:38 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes protocol extensions for interfacing with Generalized Multi Protocol Label Switching (GMPLS) Multi-Layer/Multi-Region Networks. The security considerations section does exist and references draft-ietf-mpls-mpls-and-gmpls-security-framework for the various attacks and their possible solutions regarding MPLS/GMPLS. The section then discloses that a call controller should not be reachable from an external Traffic Engineering domain. Then discusses that in order to prevent MITM attacks that IKE MUST be used between edge nodes and terminating calls. After reading this draft and the security-framework draft it seems that they cover the threat models sufficiently. General comments: None. Editorial comments: Introduction: PSC and L2SC are expanded, therefore: s/TDM/Time-Division Multiplexing (TDM)/ - - Shawn. From Pasi.Eronen@nokia.com Wed Mar 3 02:10: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 614723A8D50 for ; Wed, 3 Mar 2010 02:10:35 -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 DJyTCKst9GF6 for ; Wed, 3 Mar 2010 02:10:33 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 2111F3A8B24 for ; Wed, 3 Mar 2010 02:10:33 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o23AAPmU002870 for ; Wed, 3 Mar 2010 04:10:33 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 12:10:26 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 12:10:21 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 3 Mar 2010 11:10:21 +0100 From: To: Date: Wed, 3 Mar 2010 11:10:19 +0100 Thread-Topic: Security Directorate lunch in IETF77 Thread-Index: Acq6ubquOa5h8s4oQE27vjXmyGyVFg== Message-ID: <808FD6E27AD4884E94820BC333B2DB775848240A2F@NOK-EUMSG-01.mgdnok.nokia.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-OriginalArrivalTime: 03 Mar 2010 10:10:21.0956 (UTC) FILETIME=[BC03C440:01CABAB9] X-Nokia-AV: Clean Subject: [secdir] Security Directorate lunch in IETF77 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 Mar 2010 10:10:35 -0000 As usual, we're planning to have the Security Directorate=20 lunch on Tuesday. The room will be Pacific B. If there's anything special you'd like to discuss, please drop an email to Tim, Sean, and me. Best regards, Pasi & Tim & Sean From kivinen@iki.fi Wed Mar 3 03:46:05 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 0EFAB3A8D93; Wed, 3 Mar 2010 03:46:05 -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] 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 DkCZh9mi-pIw; Wed, 3 Mar 2010 03:46:04 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id AB5413A8D92; Wed, 3 Mar 2010 03:46:00 -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 o23BjteP002364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Mar 2010 13:45:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o23Bjs2N019086; Wed, 3 Mar 2010 13:45:54 +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: <19342.19442.798794.603092@fireball.kivinen.iki.fi> Date: Wed, 3 Mar 2010 13:45:54 +0200 From: Tero Kivinen To: Rob Austein In-Reply-To: <20100302194822.EA82A22807@thrintun.hactrn.net> References: <20100302194822.EA82A22807@thrintun.hactrn.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 12 min Cc: ipsecme-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-ipsecme-esp-null-heuristics@tools.ietf.org, secdir@ietf.org Subject: [secdir] Review of draft-ietf-ipsecme-esp-null-heuristics-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: Wed, 03 Mar 2010 11:46:05 -0000 Rob Austein writes: > The Security Considerations section is OK as far as it goes, but could > benefit from some additional text or references to other parts of the > document. Specifically: > > - The discussion of failure modes for the heuristics is in section 3, > with no reference from the Security Considerations section. Do you have any concrete proposal what text to add to security considerations section? > - The discussion of failure modes for the heuristics in section 3 is > also incomplete: while it (correctly, I think) concludes that > misclassifying traffic as ESP-NULL is no worse than a DoS attack > which an attacker could have launched anyway, it does not discuss > the other failure mode: what happens if a stream is misclassified as > non-NULL ESP, thus (depending on policy) allowing it through without > inspection, or dropping it on the floor? It does say that valid ESP-NULL stream cannot be misclassified as non-ESP-NULL stream. The only way for valid ESP-NULL stream to be classified as non-ESP-NULL is that the packet does not look valid ESP-NULL packet (i.e. for example has garbage in the ESP padding), but then it is not valid ESP-NULL packet anymore. I.e. valid EPS-NULL packets cannot be misclassified, but of course attacker can easily send packets which cause those packets to be misclassified as encrypted ESP, but on the other hand attacker can most likely also use encrypted ESP instead (as is listed in the security considerations section) if encrypted ESP packets are to be allowed to that host. All of those depends very much about what kind of the policy is used in the intermediate devices. If the policy says drop all packets which cannot be inspected, then attacker does not gain anything by getting flow misclassified. If policy is allow those through, then attacker can use encrypted ESP to bypass the deep inspection device anyways, which means the other end should have its own ways of inspecting the packets anyways, as middle box cannot inspect them. -- kivinen@iki.fi From weiler+secdir@watson.org Wed Mar 3 05:40: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 318553A8913 for ; Wed, 3 Mar 2010 05:40:47 -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 pog7pTHrP5Jm for ; Wed, 3 Mar 2010 05:40:46 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 0B0713A84F0 for ; Wed, 3 Mar 2010 05:40:45 -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 o23DekCB068646 for ; Wed, 3 Mar 2010 08:40:46 -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 o23DejWD068643 for ; Wed, 3 Mar 2010 08:40:45 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 3 Mar 2010 08:40:45 -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]); Wed, 03 Mar 2010 08:40:46 -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: Wed, 03 Mar 2010 13:40:47 -0000 I'm taking the unusual step of sending assignments on Wednesday, largely because there are so many new assignments, some of them of docs that are scheduled for next week's telechat. Yes, there's a telechat tomorrow, too: the IESG is working overtime before the changing of the guard. There may be another assignment note on Friday once the telechat agenda is final. Nico Williams 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 Lastly, thanks to everyone who's already gotten their review in for tomorrow's telechat. There were twelve documents on the list Friday; nine of the reviews are in. I'm sure the ADs are delighted. -- Sam For telechat 2010-03-04 Reviewer Deadline Draft Richard Barnes TR2010-03-02 draft-ietf-mpls-ldp-typed-wildcard-06 David McGrew T 2010-03-02 draft-ietf-dnsext-dnssec-gost-06 For telechat 2010-03-11 Reviewer Deadline Draft 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 Russ Mundy T 2010-03-09 draft-ietf-geopriv-loc-filters-09 Sandy Murphy TR2010-03-09 draft-ietf-mpls-mpls-and-gmpls-security-framework-08 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 Eric Rescorla T 2010-03-09 draft-ietf-6man-ipv6-subnet-model-07 Joe Salowey T 2010-03-09 draft-ietf-mext-binary-ts-04 Stefan Santesson T 2010-03-09 draft-ietf-mip4-rfc3344bis-09 Nico Williams T 2010-03-09 draft-gould-rfc4310bis-06 Last calls and special requests: Reviewer Deadline Draft Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Steve Hanna 2010-03-04 draft-rosen-urn-nena-01 Love Hornquist-Astrand 2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-06 Love Hornquist-Astrand 2009-10-13 draft-ietf-idnabis-mappings-05 Scott Kelly 2010-03-04 draft-ietf-l3vpn-mvpn-considerations-06 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Juergen Schoenwaelder 2010-02-19 draft-ietf-avt-rtp-ipmr-12 Yaron Sheffer 2010-03-15 draft-ietf-ipfix-mediators-problem-statement-08 Tina TSOU 2010-03-15 draft-ietf-ippm-twamp-session-cntrl-04 Carl Wallace 2010-03-12 draft-ietf-morg-sortdisplay-03 Sam Weiler 2010-03-12 draft-ietf-nsis-ntlp-statemachine-09 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Brian Weis 2010-03-15 draft-ietf-nsis-rmd-16 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 From Adrian.Farrel@huawei.com Wed Mar 3 05:50: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 C2BA128C37F; Wed, 3 Mar 2010 05:50:00 -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] 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 s8fXyw3EfCz5; Wed, 3 Mar 2010 05:50:00 -0800 (PST) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 126C53A8DD4; Wed, 3 Mar 2010 05:50:00 -0800 (PST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYP00CMDL3DS0@usaga01-in.huawei.com>; Wed, 03 Mar 2010 05:50:01 -0800 (PST) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYP00M2NL39Q6@usaga01-in.huawei.com>; Wed, 03 Mar 2010 05:50:00 -0800 (PST) Date: Wed, 03 Mar 2010 13:45:16 +0000 From: Adrian Farrel To: Shawn M Emery , secdir@ietf.org Message-id: <9108E055D0054EAB87380398B99442D4@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=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4B8E085A.2060500@sun.com> Cc: draft-ietf-ccamp-gmpls-mln-extensions.all@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] Review of draft-ietf-ccamp-gmpls-mln-extensions-11 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, 03 Mar 2010 13:50:00 -0000 Thanks Shawn! Nit entered as RFC Editor note. Cheers, Adrian ----- Original Message ----- From: "Shawn M Emery" To: Cc: ; Sent: Wednesday, March 03, 2010 6:57 AM Subject: Review of draft-ietf-ccamp-gmpls-mln-extensions-11 > > 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 protocol extensions for interfacing with Generalized > Multi Protocol Label Switching (GMPLS) Multi-Layer/Multi-Region Networks. > > The security considerations section does exist and references > draft-ietf-mpls-mpls-and-gmpls-security-framework for the various attacks > and their possible solutions regarding MPLS/GMPLS. The section then > discloses that a call controller should not be reachable from an external > Traffic Engineering domain. Then discusses that in order to prevent MITM > attacks that IKE MUST be used between edge nodes and terminating calls. > After reading this draft and the security-framework draft it seems that > they cover the threat models sufficiently. > > General comments: > > None. > > Editorial comments: > > Introduction: > > PSC and L2SC are expanded, therefore: > s/TDM/Time-Division Multiplexing (TDM)/ > > - - > Shawn. > From danmcd@sun.com Wed Mar 3 07:42: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 69FED28C117; Wed, 3 Mar 2010 07:42:26 -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 LJeCwAf628aO; Wed, 3 Mar 2010 07:42:25 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 79ED83A8ABD; Wed, 3 Mar 2010 07:42:24 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o23FgPlr004119; Wed, 3 Mar 2010 15:42:25 GMT Received: from kebe.East.Sun.COM (kebe.East.Sun.COM [129.148.174.48]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o23FgOtV007783; Wed, 3 Mar 2010 10:42:24 -0500 (EST) Received: from kebe.East.Sun.COM (localhost [127.0.0.1]) by kebe.East.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o23FT9b7003774; Wed, 3 Mar 2010 10:29:09 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o23FT8up003773; Wed, 3 Mar 2010 10:29:08 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Wed, 3 Mar 2010 10:29:08 -0500 From: Dan McDonald To: Tero Kivinen Message-ID: <20100303152908.GC23551@kebe.East.Sun.COM> References: <20100302194822.EA82A22807@thrintun.hactrn.net> <19342.19442.798794.603092@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19342.19442.798794.603092@fireball.kivinen.iki.fi> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Wed, 03 Mar 2010 08:38:38 -0800 Cc: ipsecme-chairs@tools.ietf.org, secdir@ietf.org, draft-ietf-ipsecme-esp-null-heuristics@tools.ietf.org, iesg@ietf.org Subject: Re: [secdir] Review of draft-ietf-ipsecme-esp-null-heuristics-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: Wed, 03 Mar 2010 15:42:26 -0000 On Wed, Mar 03, 2010 at 01:45:54PM +0200, Tero Kivinen wrote: > > - The discussion of failure modes for the heuristics is in section 3, > > with no reference from the Security Considerations section. > > Do you have any concrete proposal what text to add to security > considerations section? Tero -- I will add some of your text below to both Section 3 and the Security Considerations. > > - The discussion of failure modes for the heuristics in section 3 is > > also incomplete: while it (correctly, I think) concludes that > > misclassifying traffic as ESP-NULL is no worse than a DoS attack > > which an attacker could have launched anyway, it does not discuss > > the other failure mode: what happens if a stream is misclassified as > > non-NULL ESP, thus (depending on policy) allowing it through without > > inspection, or dropping it on the floor? > > It does say that valid ESP-NULL stream cannot be misclassified as > non-ESP-NULL stream. The only way for valid ESP-NULL stream to be > classified as non-ESP-NULL is that the packet does not look valid > ESP-NULL packet (i.e. for example has garbage in the ESP padding), but > then it is not valid ESP-NULL packet anymore. Actually, it's possible that using an authentication algorithm of which the inspector is not aware can cause ESP-NULL to be misclassified. Other than that, we catch everything else. > I.e. valid EPS-NULL packets cannot be misclassified, but of course > attacker can easily send packets which cause those packets to be > misclassified as encrypted ESP, but on the other hand attacker can > most likely also use encrypted ESP instead (as is listed in the > security considerations section) if encrypted ESP packets are to be > allowed to that host. Rob -- are you also worried about flow-poisoning? If an attacker manages (by chance?) to trick an inspecting node into considering a flow encrypted, and then the inspecting node *caches* that flow as poison (a bad implementation choice, to be sure, but possible given how much crap is out there), then legitimate ESP-NULL packets could be dropped. > All of those depends very much about what kind of the policy is used > in the intermediate devices. If the policy says drop all packets which > cannot be inspected, then attacker does not gain anything by getting > flow misclassified. The attacker gains denial-of-service, which may be all he/she wants. Dan From phoffman@imc.org Wed Mar 3 09:07:37 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 F173C28C153; Wed, 3 Mar 2010 09:07:36 -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 pVMX9CytWULj; Wed, 3 Mar 2010 09:07:36 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0638F28C12C; Wed, 3 Mar 2010 09:07:35 -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 o23H7WZV018274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Mar 2010 10:07:33 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com> <20100302203103.GJ2901@shinkuro.com> <6c9fcc2a1003021242p16379b6ai6d87f6cf497b37cb@mail.gmail.com> <20100302231204.GM2901@shinkuro.com> Date: Wed, 3 Mar 2010 09:05:24 -0800 To: Samuel Weiler , Andrew Sullivan From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: draft-ietf-dnsext-dnssec-alg-allocation.all@tools.ietf.org, Barry Leiba , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-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, 03 Mar 2010 17:07:37 -0000 At 6:46 PM -0500 3/2/10, Samuel Weiler wrote: >On Tue, 2 Mar 2010, Andrew Sullivan wrote: > >>The text of this draft currently explicitly notes that it doesn't >>change the rules for making an algorithm mandatory to implement. >>Since making an algorithm mandatory to implement would update 4034, I >>therefore think that it would still require standards action, which >>punts the whole business right back to the same process in place >>today. Does that make you less uneasy? > >It still leaves me uneasy. As a casual reader of this doc (and casual author of an algorithm definition doc), I'd be inclinded to assume that an algorithm definition doc, even if not standards track, could at least specify the requirement status for the algorithm it's defining. That line of logic would mean that any Informational RFC on any topic can "specify the requirement status". The IETF has never worked that way, and never will. >As I pointed out when reviewing draft-ietf-dnsext-dnssec-registry-fixes, I'm worried about the possibility of an independent submission (=RFC Editor stream document) creating a new "MANDATORY" algorithm or of changing the requirement status of other new algorithms, even if those were defined on the standards track. I proposed some text for the registry-fixes doc to resolve that, and I suggest repeating it here: > >"Unless specified in a Standards Track RFC, new algorithms will have a requirements status of OPTIONAL. Only a Standards Track RFC may set or change a requirements status of ENCOURAGED or MANDATORY." Mixing the contents of these two documents is a terrible idea. It puts the rules for the registry in two documents instead of one. >At the very least, rather than say "This document does not change the requirements for when an algorithm because (sic) mandatory to implement. Such requirements should come in a separate, focused document.", actually tell people what the mechanism/threshhold for setting a requirement level is. I don't think it's currently obvious. It is not because that mechanism is in a different document, as it should be. From kent@bbn.com Wed Mar 3 17:59: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 677AD28C2BE; Wed, 3 Mar 2010 17:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEesQgeHnQjf; Wed, 3 Mar 2010 17:59:01 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 4373F3A89EF; Wed, 3 Mar 2010 17:58:58 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[169.223.34.205]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Nn0L4-00041k-JP; Wed, 03 Mar 2010 20:58:59 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.5.6.2.20100303103218.0ba092a0@resistor.net> References: <4B8E515A.6060608@isode.com> <6.2.5.6.2.20100303103218.0ba092a0@resistor.net> Date: Wed, 3 Mar 2010 20:55:44 -0500 To: S Moonesamy From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-944454558==_ma============" Cc: yam@ietf.org, 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: Thu, 04 Mar 2010 01:59:02 -0000 --============_-944454558==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 11:14 AM -0800 3/3/10, S Moonesamy wrote: >... >This part of the effort is to move 8BITMIME to Full Standard. This >document does not change the 8BITMIME specification as defined in >RFC 1652. There was a pre-evaluation and a Sec-dir review prior to >this document ( >http://www.ietf.org/mail-archive/web/secdir/current/msg01064.html ). >It would have been helpful if the YAM WG got a review of RFC 1652 at >that time but that did not happen probably due to miscommunication >about the process. Please note that there hasn't been any reports >of security issues with this 16 year old specification. OK >>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 > >I don't understand your concern in regards to the 8-bit data >transfer. If you mean that support for this SMTP extension could be >used to identify SMTP servers which do not support it, that is >correct. There is some text about 8-bit message content >transmission in Section 2.4 of RFC 5321. First, this is a minor issue, so we ought not devote to much time to it. I mentioned it because the tone of the security considerations sentence is somewhat dismissive, suggesting that the authors did not want to bother with this section :-). Nonetheless, it would be preferable to explicitly note this side-effect of security considerations section, since it is not called out in the 5321 security considerations and the text in 2.4 does not have a secruity focus. >This transport capability does not facilitate malware transmission >as email attachments can still be sent even if the SMTP client or >server does not support the 8BITMIME extension. It is only a matter >of using MIME for the 5322 message. Presumably you mean to say that binary attachments that are ideal for delivering malware are supported irrespective of the use of this feature, right? If so, that then that might also be a suitable comment to make in the SC section. Steve --============_-944454558==_ma============ Content-Type: text/html; charset="us-ascii" Re:[secdir] secdir review of draft-ietf-yam-rfc1652bis-03
At 11:14 AM -0800 3/3/10, S Moonesamy wrote:
...
This part of the effort is to move 8BITMIME to Full Standard.  This document does not change the 8BITMIME specification as defined in RFC 1652.  There was a pre-evaluation and a Sec-dir review prior to this document ( http://www.ietf.org/mail-archive/web/secdir/current/msg01064.html ).  It would have been helpful if the YAM WG got a review of RFC 1652 at that time but that did not happen probably due to miscommunication about the process.  Please note that there hasn't been any reports of security issues with this 16 year old specification.

OK

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

I don't understand your concern in regards to the 8-bit data transfer.  If you mean that support for this SMTP extension could be used to identify SMTP servers which do not support it, that is correct.  There is some text about 8-bit message content transmission in Section 2.4 of RFC 5321.

First, this is a minor issue, so we ought not devote to much time to it. I mentioned it because the tone of the security considerations sentence is somewhat dismissive, suggesting that the authors did not want to bother with this section :-). Nonetheless, it would be preferable  to explicitly note this side-effect of security considerations section, since it is not called out in the 5321 security considerations and the text in 2.4 does not have a secruity focus.

This transport capability does not facilitate malware transmission as email attachments can still be sent even if the SMTP client or server does not support the 8BITMIME extension.  It is only a matter of using MIME for the 5322 message.

Presumably you mean to say that binary attachments that are ideal for delivering malware are supported irrespective of the use of this feature, right?  If so, that then that might also be a suitable comment to make in the SC section.

Steve
--============_-944454558==_ma============-- From fernando@gont.com.ar Wed Mar 3 20:09:21 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 8867A28C4F5; Wed, 3 Mar 2010 20:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.118, 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 TLu5m-HaGZ7G; Wed, 3 Mar 2010 20:09:20 -0800 (PST) Received: from smtp1.xmundo.net (smtp1.xmundo.net [201.216.232.80]) by core3.amsl.com (Postfix) with ESMTP id 5A71928C235; Wed, 3 Mar 2010 20:09:18 -0800 (PST) Received: from venus.xmundo.net (venus.xmundo.net [201.216.232.56]) by smtp1.xmundo.net (Postfix) with ESMTP id A5D766B6BB7; Thu, 4 Mar 2010 01:09:25 -0300 (ART) Received: from [192.168.0.100] (129-130-17-190.fibertel.com.ar [190.17.130.129]) (authenticated bits=0) by venus.xmundo.net (8.13.8/8.13.8) with ESMTP id o2449FBb009462; Thu, 4 Mar 2010 01:09:16 -0300 Message-ID: <4B8F326C.4090804@gont.com.ar> Date: Thu, 04 Mar 2010 01:09:16 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <4B8CBEC1.1080203@gont.com.ar> <7E759E79-2154-476C-BD31-F8E0F1483D76@nokia.com> In-Reply-To: <7E759E79-2154-476C-BD31-F8E0F1483D76@nokia.com> 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]); Thu, 04 Mar 2010 01:09:25 -0300 (ART) Cc: "gorry@erg.abdn.ac.uk" , "secdir@ietf.org" , "micheal.larsen@tietoenator.com" , "jmpolk@cisco.com" , "iesg@ietf.org" Subject: Re: [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: Thu, 04 Mar 2010 04:09:21 -0000 Hi, Lars, > when you make some of the text changes that Charlie suggested, please > make them in a way that doesn't break what the document says about > [Allman]. (Mark Allman ran some tests with some of the algorithms in > this document, and if we change their description retroactively, it > may affect what we can say about his effort.) I don't think the resulting changes would affect the results in [Allman]. For instance, I'd bet the random() function he used provided 32-bit pseudo-random numbers (rathern than 16-bit numbers, as previously suggested in the I-D). >>> The document is titled "Transport Protocol Port Randomization >>> Recommendations", but it doesn't really make recommendations. It >>> enumerates current practice 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. > > this came up during the WG discussion. If I remember correctly, the > document is the way it is because the WG felt that multiple schemes > work well, and because this is not something that requires > interoperability, there was no strong need to pick a "winner". I didn't apply any change in response to this. (Just for the record, *I* would have been happier with the document recommending a particular algorithm... but I do see the point of why the wg didn't think so). 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 sm@elandsys.com Wed Mar 3 11:14: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 BBBBC28B797; Wed, 3 Mar 2010 11:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=0.934, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 r6XBGDZlCZqB; Wed, 3 Mar 2010 11:14:42 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id E8FE93A8C07; Wed, 3 Mar 2010 11:14:41 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.239.138]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id o23JEWP7001778; Wed, 3 Mar 2010 11:14:38 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=elandsys.com; s=mail; t=1267643681; x=1267730081; bh=xx4AY9R59sCPOJlQ/koqxakGb8A=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=gQMR+tDRFtgx/2rMpaMmSvQA5xS2xtoMKhZUaJa02yuxPX1aEETUGt7UBcbS5Vxcl fjPgv8q2b5gLvCIPVzHEsuzG1+Y9XSrPBXKgqZ0XW1UlOhG+dUpCCKZthvRj5Tbdfx r9AKG68IdShgVLKHmzmjsLaNLk/VVF7LPDyhZsIc= Message-Id: <6.2.5.6.2.20100303103218.0ba092a0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 Mar 2010 11:14:13 -0800 To: Stephen Kent From: S Moonesamy In-Reply-To: <4B8E515A.6060608@isode.com> References: <4B8E515A.6060608@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Wed, 03 Mar 2010 23:17:34 -0800 Cc: yam@ietf.org, 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: Wed, 03 Mar 2010 19:14:44 -0000 Hi Stephen, Thank you for your review. At 04:08 03-03-10, Alexey Melnikov forwarded: >From: Stephen Kent >Subject: [secdir] secdir review of draft-ietf-yam-rfc1652bis-03 [snip] >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. This part of the effort is to move 8BITMIME to Full Standard. This document does not change the 8BITMIME specification as defined in RFC 1652. There was a pre-evaluation and a Sec-dir review prior to this document ( http://www.ietf.org/mail-archive/web/secdir/current/msg01064.html ). It would have been helpful if the YAM WG got a review of RFC 1652 at that time but that did not happen probably due to miscommunication about the process. Please note that there hasn't been any reports of security issues with this 16 year old specification. >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 I don't understand your concern in regards to the 8-bit data transfer. If you mean that support for this SMTP extension could be used to identify SMTP servers which do not support it, that is correct. There is some text about 8-bit message content transmission in Section 2.4 of RFC 5321. This transport capability does not facilitate malware transmission as email attachments can still be sent even if the SMTP client or server does not support the 8BITMIME extension. It is only a matter of using MIME for the 5322 message. Could you please clarify the security issues you have in mind so that I can bring them to the attention of the authors of this document? Regards, S. Moonesamy From lars.eggert@nokia.com Thu Mar 4 01:51: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 53A8A3A8746; Thu, 4 Mar 2010 01:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 E8oS13skyst5; Thu, 4 Mar 2010 01:51:58 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C59EA3A845C; Thu, 4 Mar 2010 01:51:57 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o249ocGk022620; Thu, 4 Mar 2010 11:50:58 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 11:50:56 +0200 Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 11:50:55 +0200 Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o249ostU023194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Mar 2010 11:50:54 +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-5--521251048; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4B8F326C.4090804@gont.com.ar> Date: Thu, 4 Mar 2010 10:50:41 +0100 Message-Id: <7BE92F3B-A1EC-43A9-9D3F-10D273D67678@nokia.com> References: <4B8CBEC1.1080203@gont.com.ar> <7E759E79-2154-476C-BD31-F8E0F1483D76@nokia.com> <4B8F326C.4090804@gont.com.ar> To: Fernando Gont 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]); Thu, 04 Mar 2010 11:50:47 +0200 (EET) X-OriginalArrivalTime: 04 Mar 2010 09:50:55.0587 (UTC) FILETIME=[2F37BB30:01CABB80] X-Nokia-AV: Clean Cc: "gorry@erg.abdn.ac.uk" , "secdir@ietf.org" , "micheal.larsen@tietoenator.com" , "jmpolk@cisco.com" , "iesg@ietf.org" Subject: Re: [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: Thu, 04 Mar 2010 09:51:59 -0000 --Apple-Mail-5--521251048 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-3-4, at 5:09, Fernando Gont wrote: >> when you make some of the text changes that Charlie suggested, please >> make them in a way that doesn't break what the document says about >> [Allman]. (Mark Allman ran some tests with some of the algorithms in >> this document, and if we change their description retroactively, it >> may affect what we can say about his effort.) >=20 > I don't think the resulting changes would affect the results in > [Allman]. For instance, I'd bet the random() function he used provided > 32-bit pseudo-random numbers (rathern than 16-bit numbers, as = previously > suggested in the I-D). please check with Mark on this. I believe you are right, but it's better = to be sure than to bet. >>>> The document is titled "Transport Protocol Port Randomization=20 >>>> Recommendations", but it doesn't really make recommendations. It=20 >>>> enumerates current practice 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. >>=20 >> this came up during the WG discussion. If I remember correctly, the >> document is the way it is because the WG felt that multiple schemes >> work well, and because this is not something that requires >> interoperability, there was no strong need to pick a "winner". >=20 > I didn't apply any change in response to this. (Just for the record, = *I* > would have been happier with the document recommending a particular > algorithm... but I do see the point of why the wg didn't think so). I would have been happier, too, but I think the argument was that we = didn't want to needlessly say that some existing implementations don't = comply to the recommendations in the RFC when it doesn't matter because = their algorithm is good enough. Lars= --Apple-Mail-5--521251048 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 MQ8XDTEwMDMwNDA5NTA0MVowIwYJKoZIhvcNAQkEMRYEFLUASmsnHuWgoddhFZEperYZvBcJMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQBpjMi/b96fevF9ZGGYx3QFG7sFfqK4QF922HEZNt8icFNivUUS4er0Zdegu4FZPH6Kk4dI xGBaoggWhtFY7CATLwDztrxRNtZF6cjYTnmHrj51O3BxbykT6T3cPgVvyLlm5EzZmpVaLnfUJzv2 cRIMUiYxtPyi4A7mq/GFQDx8ZKU9HjgWKV3qL5V15a7DDC08Q0mEyMxH+nL7YRdtvuhOs0XrpaGW 2bkmouo0sgJ+8GZhpHF+SiZwZs0FMXaqUSvxJ/PdlqN2XPaDn/L9yb2S+M8eC6VFIOf9dniyjKLm QcIoL0Yahv4Sv8bpNa8qPduiF5/2vHshZ0GhLUIveWKJAAAAAAAA --Apple-Mail-5--521251048-- From alexey.melnikov@isode.com Thu Mar 4 03:18:28 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 774363A8972; Thu, 4 Mar 2010 03:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.091, 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 hd5e4JOOpsUT; Thu, 4 Mar 2010 03:18:23 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 42BE03A7A97; Thu, 4 Mar 2010 03:18:21 -0800 (PST) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 4 Mar 2010 11:18:22 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4B8F96E8.7020805@isode.com> Date: Thu, 04 Mar 2010 11:18:00 +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: <4B8E515A.6060608@isode.com> <6.2.5.6.2.20100303103218.0ba092a0@resistor.net> 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, S Moonesamy , yam@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: Thu, 04 Mar 2010 11:18:28 -0000 Hi Stephen, Stephen Kent wrote: > At 11:14 AM -0800 3/3/10, S Moonesamy 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. One might even cite the use of this >>> transport capability as facilitating malware transmission in e-mail >>> attachments >> >> I don't understand your concern in regards to the 8-bit data >> transfer. If you mean that support for this SMTP extension could be >> used to identify SMTP servers which do not support it, that is correct. > Right. ESMTP capability negotiation is a basic feature of ESMTP as described in RFC 5321, this is not specific to 8BITMIME. >> There is some text about 8-bit message content transmission in >> Section 2.4 of RFC 5321. > > First, this is a minor issue, so we ought not devote to much time to > it. I mentioned it because the tone of the security considerations > sentence is somewhat dismissive, suggesting that the authors did not > want to bother with this section :-). Nonetheless, it would be > preferable to explicitly note this side-effect of security > considerations section, since it is not called out in the 5321 > security considerations and the text in 2.4 does not have a secruity > focus. RFC 5321 is also being revised by the YAM WG, so I would prefer any such text to go there. >> This transport capability does not facilitate malware transmission as >> email attachments can still be sent even if the SMTP client or server >> does not support the 8BITMIME extension. It is only a matter of >> using MIME for the 5322 message. > > Presumably you mean to say that binary attachments that are ideal for > delivering malware are supported irrespective of the use of this > feature, right? Firstly, 8BITMIME is not suitable for transferring unencoded binary data, it is only suitable for transfering 8bit text (e.g. textual documents encoded in UTF-8). BINARYMIME (a separate SMTP extension) is used to transfer unencoded binary data. Secondly, the only thing that 8BITMIME changes is how certain email messages or message attachments are transferred. So if there is a malware that can take advantage of 8BITMIME, messages containing such malware would take less bandwidth to transfer. > If so, that then that might also be a suitable comment to make in the > SC section. From charliek@microsoft.com Thu Mar 4 10:50: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 2D8BD3A8E14; Thu, 4 Mar 2010 10:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_29=0.6, J_CHICKENPOX_31=0.6, 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 M9T6FnTWS-33; Thu, 4 Mar 2010 10:50:13 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id DCD9D3A8E25; Thu, 4 Mar 2010 10:50:13 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 4 Mar 2010 10:50:15 -0800 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.89]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi; Thu, 4 Mar 2010 10:50:08 -0800 From: Charlie Kaufman To: Fernando Gont Thread-Topic: Secdir review of draft-ietf-tsvwg-port-randomization-06.txt Thread-Index: Acq3UVrFxdRHn0hzRWysE0Ue9YIZzACzAlaAAGhSi/A= Date: Thu, 4 Mar 2010 18:50:05 +0000 Message-ID: References: <4B8CBEC1.1080203@gont.com.ar> In-Reply-To: <4B8CBEC1.1080203@gont.com.ar> 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 Cc: "gorry@erg.abdn.ac.uk" , "secdir@ietf.org" , "micheal.larsen@tietoenator.com" , "lars.eggert@nokia.com" , "jmpolk@cisco.com" , "iesg@ietf.org" Subject: Re: [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: Thu, 04 Mar 2010 18:50:15 -0000 > > 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 distribution when reduced mod num_ephemeral will not be > > uniform. >=20 > Would requiring random() to return 32-bit random values address this > comment? >=20 In most (all?) C implementations, rand() returns int, and so would return v= alues between 0 and 2^15-1, 2^31-1, or 2^63-1. I would change the wording t= o something like: Note: "random()" is a function that returns a pseudo-random non-negative integer number in the range 0 to at least 65535 (it is preferable if it = returns values in a range larger than 65535, as is the case with the "random()" C-language function). >=20 >=20 > > p16 para 2: suggests use of MD5, which is fine from the point of view > > of documenting current practice, and in fact is cryptographically just > > fine in this 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 better > > to just suggest "some cryptographic hash function", or if you have to > > suggest something specific, perhaps SHA-256. >=20 > My take on this is that as we're just obfuscating port numbers, MD5 is go= od > enough. But please let me know if you argue that we should s/MD5/SHA- > 256/..... >=20 I agree. In this context, MD5 is more than good enough. But I have lost eno= ugh battles with crypto weenies when trying to use MD5 in a context where c= ryptographic strength is not an issue that I'd reluctantly recommend that y= ou say SHA-256 instead in this paragraph. In the paragraph that follows, wh= ere it is explaining that using a weak cryptographic function is OK, the re= ference to MD5 is the best one to use. In both cases, the algorithms are me= ntioned as examples, which is also the right thing to do. >=20 >=20 > > The appendix at the end should specify the hash algorithm used by > > existing implementations. >=20 > You mean Appendix A? If so, we could probably just indicate that Linux us= es > MD5 for the hash-based port randomization algorithm. >=20 Yes. >=20 > > Your sample code in many cases, but in particular on page 17 figure 5 > > ignores the possibility of integer overflow when incrementing things > > (e.g. table[index]++). The results of modular arithmetic when one of > > the operands is negative is language dependent, and in ANSI C is not > > defined, so this code could corrupt memory (unless the values being > > incremented are unsigned). >=20 > All operands are assumed to be unsigned. Please let me know if I should > clarify this. >=20 That would technically be OK. The current text says it's an array of short = integers, which if someone implemented as: short int table[TABLE_LENGTH]; would do bad things on implementations where short is 16 bits signed. If this code is copied from a real implementation, it's probably better to = just add the declaration. Otherwise, it would be better to avoid the overfl= ows altogether with code like: /* Initialization at system boot time */ num_ephemeral =3D max_ephemeral - min_ephemeral + 1; for(i =3D 0; i < TABLE_LENGTH; i++) table[i] =3D random() % TABLE_LENGTH; /* Ephemeral port selection function */ offset =3D F(local_IP, remote_IP, remote_port, secret_key1) % num_ephe= meral; index =3D G(local_IP, remote_IP, remote_port, secret_key2) % TABLE_LEN= GTH; count =3D num_ephemeral; do { port =3D min_ephemeral + (offset + table[index]) % num_ephemeral; table[index] =3D (table[index]+1) % num_ephemeral; if(resulting five-tuple is unique) return port; count--; } while (count > 0); return ERROR; By adding the mod functions to F() and G() in the code, you avoid the need = to say that F and G are hash functions that return integers in a particular= range. The other place where there is a problem with overflow is in figure 4, wher= e after the line: next_ephemeral++; I would add: if (next_ephemeral =3D=3D num_ephemeral) next_ephemeral =3D 0; =20 While in theory these changes could invalidate the citing of [Allman], none= have an affect bigger than seeding the random number generate with differe= nt values, so I would claim that to the extent his results are useful they = apply to the slightly modified algorithms that avoid integer overflows. >=20 >=20 > > p20 para 2: suggests use of a 32 bit key, which has exploitable > > security problems even though MD5 is fine. 64 bits is a bare minimum, > > and since bits are cheap someone should really use 128. >=20 > Ok, I'll s/32/128/ >=20 That works (except in reality, the wording change is a little bigger than t= hat). >=20 >=20 > > 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 inputs and they are generally harmless. If they occurred at > > greater frequency than would be expected by chance, the port-offset > > mechanism proposed in this document would have a reduced effect. >=20 > Ok. I'll tweak the text. >=20 >=20 >=20 > > p24 para 4: Similarly, seeding the random number generator with a good > > source of randomness will make an implementation more secure, but > > "must" is a bit strong. >=20 > Not sure what you mean. This para just refers to the quality of random > numbers. i.e., that if your going to use only random numbers for the secr= et > key, they should be "good enough" (with "good enough" being RFC4086) >=20 I guess I would change the word "must" to "should". If an implementation do= es not follow this recommendation, it will probably be just fine. I hesitate to mention that the standard C language implementation of rand()= does not satisfy this requirement, but getting random values from rand() (= following some variation of randomize() or srand(time)) is a lot better tha= n nothing and arguably adequate for this application. I would hate to guide= people away from using rand() because it might discourage them from doing = this at all. On the other hand, I would never want to guide anyone towards = rand() because (at least the last time I looked at it) it was a horrible ra= ndom number generator not even suitable for statistical randomness unless u= sed very carefully. >=20 >=20 > > Detailed non-security relevant comments: > > > > The document is titled "Transport Protocol Port Randomization > > Recommendations", but it doesn't really make recommendations. It > > enumerates current practice 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. >=20 > How about "Transport Protocol Port Randomization", instead? >=20 Works for me, but I suspect someone had a good reason for naming it what th= ey did. >=20 >=20 > > 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 reference to RFC 2119? >=20 > It does. See Section 3.2 and Section 3.3. >=20 My mistake. I searched the document, but somehow missed the two MUSTs. >=20 >=20 >=20 > > 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 whole range 1024-49151". Is > > this saying you should use port numbers not intended for this use? Do > > you mean should use the whole range 1024-65535? >=20 > The later: the text should say "...port selection algorithms should use t= he > whole range 1024-49151" (I screwed up the text in my last rev.... > will fix this). >=20 >=20 > > > > Typos: > > > > p12 line 2: "is not affected is not affected" -> "is not affected" >=20 > Fixed. >=20 >=20 > > p13 para 2 line 2: "interger" -> "integer" p16 para 3: "chosen as > > random as possible" -> "chosen to be as random as possible" p20 para > > 3: "reasonable" -> "reasonably" >=20 > Thanks! >=20 > 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 >=20 >=20 >=20 >=20 From Nicolas.Williams@sun.com Thu Mar 4 12:49:19 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 4D2603A8E4B for ; Thu, 4 Mar 2010 12:49:19 -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 1VOhi9u2Ok4f for ; Thu, 4 Mar 2010 12:49:18 -0800 (PST) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id A0A173A8C7E for ; Thu, 4 Mar 2010 12:49:18 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o24KnKST000097 for ; Thu, 4 Mar 2010 20:49:20 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id o24KnKLe002371 for ; Thu, 4 Mar 2010 13:49:20 -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 o24Kfode015225; Thu, 4 Mar 2010 14:41:50 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o24KfoYe015224; Thu, 4 Mar 2010 14:41:50 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 4 Mar 2010 14:41:50 -0600 From: Nicolas Williams To: secdir@ietf.org Message-ID: <20100304204149.GV1072@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i Cc: shollenbeck@verisign.com, jgould@verisign.com Subject: [secdir] secdir review of draft-gould-rfc4310bis-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, 04 Mar 2010 20:49:19 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document presents no new security considerations over the RFC it seeks to update. For a provisioning protocol the primary security considerations relate to authentication, which does not belong here, and authorization, which does belong here. The security considerations section of this I-D appears to be complete. Nico -- From j.schoenwaelder@jacobs-university.de Fri Mar 5 05:56: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 CF8D03A8B5C; Fri, 5 Mar 2010 05:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.038, 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 SGGgqRclwBxo; Fri, 5 Mar 2010 05:56:05 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CE5843A8B7B; Fri, 5 Mar 2010 05:56:04 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F2608C000D; Fri, 5 Mar 2010 14:56:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id W52C-vmZKK+2; Fri, 5 Mar 2010 14:56:04 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA483C0011; Fri, 5 Mar 2010 14:55:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7979410B9991; Fri, 5 Mar 2010 14:55:54 +0100 (CET) Date: Fri, 5 Mar 2010 14:55:54 +0100 From: Juergen Schoenwaelder To: info@spiritdsp.com Message-ID: <20100305135554.GA20432@elstar.local> Mail-Followup-To: info@spiritdsp.com, iesg@ietf.org, secdir@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-avt-rtp-ipmr-12.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 13:56:06 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. The document defines how SPIRIT IP-MR encoded speech signals can be transported over RTP. The security considerations seem to be adequate. However, I am concerned about the C code in the appendix extracting frame information. The code does not seem to do proper bound checking, which I think is a problem that needs to be fixed. I understand that the frame size is an out parameter - still the size of the buffer passed via pCoded should be available so that proper bound checking can be performed. Other than that, I noticed a number of editorial issues, mostly due to missing articles etc. I am attaching a unified context diff correcting some of the issues (but note that I stopped making changes at the end of section 3 - so there is likely more to fix). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="gaga.txt" --- draft-ietf-avt-rtp-ipmr-12.txt 2010-03-05 14:34:16.000000000 +0100 +++ draft-ietf-avt-rtp-ipmr-12-js.txt 2010-03-05 14:51:08.000000000 +0100 @@ -124,7 +124,7 @@ 2. IP-MR Codec Description -The IP-MR codec is scalable adaptive multi-rate wideband speech codec +The IP-MR codec is a scalable adaptive multi-rate wideband speech codec designed by SPIRIT for use in IP based networks. These codec is suitable for real time communications such as telephony and videoconferencing. @@ -141,12 +141,12 @@ layer and several enhancement layers which are coded independently. Only the core layer is mandatory to decode understandable speech and upper layers provide quality enhancement. These enhancement layers -may be omitted and remaining base layer can be meaningfully decoded +may be omitted and the remaining base layer can be meaningfully decoded without artifacts. This makes the bit stream scalable and allows to reduce bit rate during transmission without re-encoding. This memo specifies an optional form of redundancy coding within RTP -for protection against packet loss. It is based on commonly known +for protection against packet loss. It is based on a commonly known scheme when previously transmitted frames are aggregated together with new ones. Each frame is retransmitted once in the following RTP payload packet. f(n-2)...f(n+4) denotes a sequence of speech @@ -242,7 +242,7 @@ 3.2. Payload Format Structure The IP-MR payload format consists of a payload header with general -information about packet, a speech table of contents (TOC), and speech +information about a packet, a speech table of contents (TOC), and speech data. An optional redundancy section follows after speech data. The redundancy section consists of redundancy header, redundancy TOC and redundancy data payload. @@ -307,7 +307,7 @@ o D (1 bit): reserved. Must be always set to 1. Previously, this bit indicated DTX mode availability, but in fact - payload dublicates this information. + payload duplicates this information. o A (1 bit): reserved. Must be always set to 1. Previously, this bit indicated aligned mode, but this mode has @@ -322,7 +322,7 @@ 3.4. Speech Table of Contents -The speech TOC contains entries for each frame in packet (grouping size +The speech TOC contains entries for each frame in a packet (grouping size in total). Each entry contains a single field: 0 @@ -341,7 +341,7 @@ lost frame itself or by empty frames generated by the encoder during silence intervals in DTX mode. -Note that if CR flag from payload header is 7 (NO_DATA) then speech TOC +Note that if the CR flag from the payload header is 7 (NO_DATA) then the speech TOC is empty. 3.5. Speech Data @@ -350,30 +350,30 @@ noise frames, as specified in the speech TOC of the payload. Each speech frame represents 20 ms of speech encoded with the rate -indicated in the CR and base rate indicated in BR field of the payload +indicated in the CR field and the base rate indicated in the BR field of the payload header. -The size of coded speech frame is variable due to the nature of codec. -The Encoder's algorithm decides what size of each frame is and returns +The size of the coded speech frame is variable due to the nature of codec. +The Encoder's algorithm decides the size of each frame and returns it after encoding. In order to save bandwidth the size is not placed -into payload obviously. The frame size can be determined by frame's +into the payload. The frame size can be determined by frame's content using a special service function specified in Appendix A. -This function provides complete information about coded frame including -size, number of layers, size of each layer and size of perceptual +This function provides complete information about the coded frame including +its size, the number of layers, the size of each layer and the size of perceptual sensitive classes. 3.6. Redundancy Header If a packet contains redundancy (R field of payload header is 1) the -speech data is followed by redundancy header: +speech data is followed by the redundancy header: 0 1 2 3 4 5 +-+-+-+-+-+-+ | CL1 | CL2 | +-+-+-+-+-+-+ -Redundancy header consists of two fields. Each field contains class -specifier for amount of redundancy partly taken from the preceding +The redundancy header consists of two fields. Each field contains class +specifier for the amount of redundancy partly taken from the preceding packet (CL1) and pre-preceding packet (CL2), e.g. distant from the current packet by 1 and 2 packets accordingly. The values are listed in the table below: @@ -409,20 +409,20 @@ Each specifier takes 3 bits, thus the total redundancy header size is 6 bits. -These classes indicate subjective importance of bits from core layer. -Class A contains the bits most sensitive to errors and lost of these +These classes indicate the subjective importance of bits from the core layer. +Class A contains the bits most sensitive to errors and loss of these bits results in a corrupted speech frame which should not be decoded -without applying packet loss concealment (PLC) procedure. Class B is +without applying a packet loss concealment (PLC) procedure. Class B is less sensitive than class A and so on to F. Sum of all bit classes from A to F composes core layer. -Putting some part (classes of bits) from previous frame into current -packet makes possible to partially decode previous frame in case of -it's lost. Than more information is delivered than less speech quality -degradation will be. Flags CL1 and CL2 specify how many classes from -previous frames current packet contain. E.g. CL1=3 (class C), it means -that packet contains bits from classes A, B and C of previous frame. -If CL1=6 (class F) then whole core layer is included. +Putting some part (classes of bits) from a previous frame into the current +packet makes it possible to partially decode a previous frame in case it +got lost. Since more information is delivered, less speech quality +degradation will be observed. The flags CL1 and CL2 specify how many classes from +previous frames the current packet contain. For example, CL1=3 (class C) means +that the packet contains bits from classes A, B and C of the previous frame. +If CL1=6 (class F) then the whole core layer is included. 3.7. Redundancy Table of Contents @@ -432,7 +432,7 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The redundancy TOC contains entries for redundancy frames from preceding -and pre-preceding packets. Each entry takes 1 bit like speech TOC entry +and pre-preceding packets. Each entry takes 1 bit like the speech TOC entry (3.3): 0 @@ -453,21 +453,21 @@ is equal to the grouping size of the current packet. E.g. maximum number of entries is 4*2 = 8. - o If class specifier in the redundancy header is CL=0 (NO_DATA) - then there is no entries for corresponding packet redundancy. + o If the class specifier in the redundancy header is CL=0 (NO_DATA) + then there are no entries for corresponding packet redundancy. 3.8. Redundancy Data -Redundancy data of a payload contains redundancy information for one or +The redundancy data of the payload contains redundancy information for one or more speech frames or comfort noise frames that may be lost during transition, as specified in the redundancy TOC of the payload. Actually redundancy is the most important part of preceding frames representing 20 ms of speech. This data MAY be used for partial reconstruction of -lost frames. The amount of available redundancy is specified by CL flag -in redundancy header section (3.5). This flag SHOULD be passed to +lost frames. The amount of available redundancy is specified by the CL flag +in the redundancy header section (3.5). This flag SHOULD be passed to the decoder. The size of redundancy frame is variable and can be obtained -using service function specified in Appendix A. +using the service function specified in Appendix A. 4. Payload Examples --sdtB3X0nJg68CQEu-- From weiler+secdir@watson.org Fri Mar 5 16:42: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 A7C7A3A904D for ; Fri, 5 Mar 2010 16:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hTsE+yERB4J for ; Fri, 5 Mar 2010 16:42:35 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id A07F63A904C for ; Fri, 5 Mar 2010 16:42:35 -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 o260gb6O026234 for ; Fri, 5 Mar 2010 19:42: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 o260gbIh026231 for ; Fri, 5 Mar 2010 19:42:37 -0500 (EST) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 5 Mar 2010 19:42:37 -0500 (EST) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 05 Mar 2010 19:42: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, 06 Mar 2010 00:42:36 -0000 Six more new assignments, in addition the stack from Wednesday. Rob Austein 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-11 Reviewer Deadline Draft Love Hornquist-Astrand T 2010-03-09 draft-ietf-idnabis-mappings-05 Jeffrey Hutzelman T 2010-03-09 draft-ietf-autoconf-adhoc-addr-model-02 Scott Kelly T 2010-03-09 draft-ietf-l3vpn-mvpn-considerations-06 Julien Laganier T 2010-03-09 draft-ietf-csi-hash-threat-07 Russ Mundy T 2010-03-09 draft-ietf-geopriv-loc-filters-09 Sandy Murphy TR2010-03-09 draft-ietf-mpls-mpls-and-gmpls-security-framework-08 Sandy Murphy T 2010-03-09 draft-ietf-geopriv-prefix-00 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 Eric Rescorla T 2010-03-09 draft-ietf-6man-ipv6-subnet-model-08 Joe Salowey T 2010-03-09 draft-ietf-mext-binary-ts-04 Stefan Santesson T 2010-03-09 draft-ietf-mip4-rfc3344bis-09 For telechat 2010-04-08 Reviewer Deadline Draft Love Hornquist-Astrand T 2010-04-06 draft-ietf-ccamp-gmpls-mef-uni-03 Chris Newman T 2010-04-06 draft-ietf-krb-wg-preauth-framework-15 Chris Newman T 2010-04-06 draft-ietf-pce-pcep-svec-list-04 For telechat 2010-04-22 Reviewer Deadline Draft Love Hornquist-Astrand T 2010-04-20 draft-ietf-opsawg-smi-datatypes-in-xsd-06 Last calls and special requests: Reviewer Deadline Draft Derek Atkins 2010-03-19 draft-turner-asymmetrickeyformat-03 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Shawn Emery R2010-03-19 draft-ietf-manet-nhdp-11 Steve Hanna 2010-03-04 draft-rosen-urn-nena-01 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-06 Yaron Sheffer 2010-03-15 draft-ietf-ipfix-mediators-problem-statement-08 Tina TSOU 2010-03-15 draft-ietf-ippm-twamp-session-cntrl-04 Carl Wallace 2010-03-12 draft-ietf-morg-sortdisplay-03 Sam Weiler 2010-03-12 draft-ietf-nsis-ntlp-statemachine-09 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Brian Weis 2010-03-15 draft-ietf-nsis-rmd-16 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Nico Williams 2010-03-20 draft-haberman-rpsl-reachable-test-03 Tom Yu 2010-03-18 draft-ietf-ipsecme-ikev2bis-08 Kurt Zeilenga 2010-03-18 draft-ietf-mmusic-rfc4756bis-06 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-05 Glen Zorn 2010-03-20 draft-ietf-sip-ipv6-abnf-fix-04 From shanna@juniper.net Fri Mar 5 18:30: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 A7EC33A89E4; Fri, 5 Mar 2010 18:30:00 -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 fORwogKkcpRH; Fri, 5 Mar 2010 18:29:59 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id ECE713A89AF; Fri, 5 Mar 2010 18:29:57 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKS5G+KE3GAu8ZHYxU8erh5z+ME2qmLo0n@postini.com; Fri, 05 Mar 2010 18:30:02 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 5 Mar 2010 18:26:19 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 5 Mar 2010 21:26:18 -0500 From: Stephen Hanna To: "br@brianrosen.net" Date: Fri, 5 Mar 2010 21:26:15 -0500 Thread-Topic: secdir review for draft-rosen-urn-nena-01 Thread-Index: Acq81GWjk8ZNKlT9TYCK72AfCxOyTQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "iesg@ietf.org" , "secdir@ietf.org" Subject: [secdir] secdir review for draft-rosen-urn-nena-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: Sat, 06 Mar 2010 02:30:00 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These 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 does not raise any particular security issues so the security considerations section of the document is adequate. Subsequent documents that define values and sub-registries within the nena namespace may need more detailed discussions of security considerations. I did notice one non-security issue. In the Declaration of syntactic structure in section 2, the structure the structure is given as {NENAclass}:ClassSpecificString}. I don't know why curly braces are being used here but I suppose they are intended to indicate that NENAclass and ClassSpecificString are variable strings. If so, there should be an opening curly brace before ClassSpecificString. Thanks, Steve From magnusn@gmail.com Fri Mar 5 21:43: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 2717428C15A; Fri, 5 Mar 2010 21:43: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 5lRfkETsvzvU; Fri, 5 Mar 2010 21:43:00 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 2B58E28C126; Fri, 5 Mar 2010 21:43:00 -0800 (PST) Received: by gwb10 with SMTP id 10so2387401gwb.31 for ; Fri, 05 Mar 2010 21:42:59 -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=lHs1gUxbVk9/lxzSe7OyTSOJIm7Qm4qT2qvauwG9cGg=; b=C/d20H9D099i5Z5DITJq2IrDQznOPBvOM84KMWseBe9SCcLm4c75ThvEkkJQxJmRDK XKk9d11UDBdWDV0NNxFXfi9gTsLnYv4vIQq7o5GPVf2p+dp/FjMSTKBYmRHTHkgoKTGV 60wvJ+K1U1gng2+G/5vYBbPHMQvtJRzSW5Dn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MWKd3sx04K4T4CHtvVa+HvnnAqMM1XfY8nMhfTrpjYrxn3IEJ+D9XkYldsy2AXMgcE 821naSb+9/v5gCBxLxxCV06QG2obn1YyvnIWIEwhqnIIeTe7y/nCwTiNMp2LP0nyDo/U knZ6hKEZf0mziQqhaaGljc/BRsQxkuthLW5kY= MIME-Version: 1.0 Received: by 10.100.30.29 with SMTP id d29mr3755340and.247.1267854179703; Fri, 05 Mar 2010 21:42:59 -0800 (PST) Date: Fri, 5 Mar 2010 21:42:59 -0800 Message-ID: <2f57b9e61003052142s36ec86baj3aa54ddac604ef6e@mail.gmail.com> From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: iesg@ietf.org, secdir@ietf.org, gregory.ietf@gmail.com, ekr@rtfm.com, magnus.westerlund@ericsson.com, lars.eggert@nokia.com Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] Secdir review of draft-ietf-tcpm-tcp-ao-crypto-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: Sat, 06 Mar 2010 05:43:01 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments This document specifies requirements on cryptographic algorithms to be used in the TCP Authentication Option (TCP APO). It also specifies some mandatory algorithms. Comments: Abstract: - The abstract does not mention that the document also specifies requirements on future algorithms. IMO, it should. Section 1: (- Last paragraph is what prompted my comment on the abstract.) Section 2.2: - Suggest moving the note explaining the need to mandate two MAC algorithms to the Security Considerations section as it does not contain normative text but does contain security considerations. - Section 3.1.1.3: - It is a little surprising to see that the SHA-1-based MAC algorithm is selected as the default one, given that this is a new specification and the industry is moving away from SHA-1. C.f. the work on XML Encryption 1.1 and XML Signature 1.1 that specificallly recommends against use of SHA-1 in new applications. - Section 6 (Security Considerations): In the fourth paragraph, there is a discussion around the fact that the document does not force use of a 16 octet key. I think it would be useful to at least clearly state a recommended minimum key size. Editorial: Section 1: - "between to endpoints" - "between two endpoints"? Section 3.1.1: - "fixed-length output lengths" -> "fixed-length output"? Section 3.2.1: - "will be that has" -> "will be that"? -- Magnus From radiaperlman@gmail.com Sat Mar 6 21:30:42 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 6893E3A9118; Sat, 6 Mar 2010 21:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPMozcCips9y; Sat, 6 Mar 2010 21:30:41 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 0D6E93A9073; Sat, 6 Mar 2010 21:30:41 -0800 (PST) Received: by pwi3 with SMTP id 3so3497827pwi.31 for ; Sat, 06 Mar 2010 21:30:41 -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=RKM1KaQk5xVNFHPHL2xt4yTIit9qMZez1aSSaMbR2dU=; b=r69758dYwnZIHrhswbVg7dv01Hi5zBdsnm2ZUAYpkU9l2w+RDLZji5M6ytl6HPHsC5 K76sN9ohFquKMR08ZoYfraT2LcUrSFg+1HW3epfSF7hJqdNFq6lwunbu9HtMUE5/M/zg bK0biNVxjJuO3xgbnzTHfsAkX0oKfhl7HSd9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YyRfRhIDWNSv5QGq9Ckhhi3o1YvdMVU5Fz+fB6bHGGdP5SHV3mMtORxhba7tLSdHsQ huIJyeFucW8LQdVMQwzsLnMgWSpPEPiTtjfvXEF0r2UmKh30SaH6uGVXgWfVsXBJEX7Z gyFZoYuRvtp5CzxIqqObvyY235tkYjLX0y97g= MIME-Version: 1.0 Received: by 10.142.152.6 with SMTP id z6mr2069926wfd.214.1267939841820; Sat, 06 Mar 2010 21:30:41 -0800 (PST) Date: Sat, 6 Mar 2010 21:30:41 -0800 Message-ID: From: Radia Perlman To: iesg@ietf.org, secdir@ietf.org, touch@isi.edu, mankin@psg.com, rbonica@juniper.net Content-Type: multipart/alternative; boundary=000e0cd154aade4a1604812f3f41 X-Mailman-Approved-At: Sun, 07 Mar 2010 08:14:11 -0800 Subject: [secdir] review of draft-ietf-tcpm-tcp-auth-opt-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: Sun, 07 Mar 2010 05:30:42 -0000 --000e0cd154aade4a1604812f3f41 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This protocol is essentially a lightweight special purpose version of the Authentication Header (AH) protocol (RFC 4302). It is intended as a generalization, improvement, and replacement of the TCP-MD5 protocol documented in RFC2385. RFC2385 only proposed using TCP-MD5 for BGP, which had certain unique requirements (like keeping a TCP connection up through crashes of one or both endpoints). The proposal does not explicitly limit the applicability. One question that leaps to mind is why there is both this and AH (not to mention ESP). The primary differences between TCP-AO and AH are: TCP-AO can only be used to protect TCP connections (because the integrity checksum is included in a TCP extension header). TCP-AO only increases the packet length by 16 bytes with default crypto (AH adds 24 bytes with default crypto). While both are technically independent of any particular keying mechanism, AH was designed to be keyed using IKE (RFC 4306) while TCP-AO was designed for manual keying. In particular, TCP-AO includes an in-band protocol for signally when a new key is available so that when new keys are configured at the two ends of a connection, both ends will start using the new key only when it is available at both ends. Review of the document: Section 4.2 under KeyID (and repeated in section 5.1 under IDs), the document says that KeyID values are arbitrary. This is not quite true. The same KeyID value cannot be used for two different valid keys. (So an implementation must assure that all nodes have deconfigured or expired keys with a particular KeyID value before assigning that KeyID value to a new key. Section 4.2 also implies that the KeyID for the same master key used to generate different encryption keys for the two different directions of TCP can have different KeyIDs in the two different directions. That seems like a useless generality. Section 8.1 specifies how to choose the key to use in a next packet based on the RNextKeyID in the last received packet. It does not specify how to choose the key when starting a new connection (i.e. sending a SYN). I would assume that there is some non-connection state saved on the node (and preserved across crashes) that remembers the last RNextKeyID received on any connection, and this is used to open new connections. The first time a connection is opened to a node that has never successfully been connected to, the sender would cycle through all valid keys until finding one the other end will accept. In any case, the spec should say. Section 8.2 paragraph 5 says the implementation of SNEs (extended sequence numbers) is not specified in this document. This seems entirely unacceptable, since the two ends must implement them identically for the protocol to work and they aren't specified anywhere else. Further, it appears that they *are* specified in the paragraphs that follow (though stated as an example rather than a spec). Sections 9.3-9.5 appear to be dealing with the case where one end of the connection has been configured to use TCP-AO but the other has not. This should probably be modeled as having a special "no authentication" key configured as a valid key for the connection. The initiator would not use that key when sending a SYN, but would switch to that key if he got an unsigned ACK from the other end or he got an unsigned SYN from the other end. There is an implication that existing implementations will ignore the TCP-AO extension if they don't support TCP-AO. Is that true? (When in this mode, there is no security, but it is a way to add initial keys to the two endpoints without breaking connectivity during the period when one end has been keyed and the other has not. Once both ends have received a correctly signed message from the other end, they should stop accepting unsigned ones. Section 10 says "TCP implementations MUST support TCP-AO". What does this mean? Implementations of this spec MUST implement this spec. It is not reasonable to expect *all* TCP implementations to support TCP-AO. Section 11.2 suggests use of IPsec NAT traversal instead of TCP-AO if NATs are present, but does not suggest how that would be negotiated. Or is this saying that IPsec NAT traversal is preferred in any scenario where NAT traversal *might* be needed? Typos: Page 4 2nd to last paragraph: There is a badly structured sentence that could be fixed in multiple ways. One way would be: "This document obsoletes the TCP MD5 option with a more general TCP Authentication Option (TCP-AO). The new design supports the use of other (stronger) hash functions, provides replay protection for long-lived connections and across repeated instances of a single connection, coordinates key changes between endpoints, and provides a more structured recommendation for external key management." Section 3 paragraph 3: "proceeding -> preceding" Page 13 3rd to last line: "match at exactly" -> "match exactly" Page 21 3rd to last line: "when is" -> "when it is" --000e0cd154aade4a1604812f3f41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate'= s
ongoing effort to review all IETF documents being processed by the IESG.=A0 These comments were written primarily for the benefit of the security area directors.=A0 Document editors and WG chairs should treat these comments just like any other last call comments.
This protocol is essentially a lightweight special purpose version of = the Authentication Header (AH) protocol (RFC 4302). It is intended as a gen= eralization, improvement, and replacement of the TCP-MD5 protocol documente= d in RFC2385. RFC2385 only proposed using TCP-MD5 for BGP, which had certai= n unique requirements (like keeping a TCP connection up through crashes of = one or both endpoints). The proposal does not explicitly limit the applicab= ility.
=A0
One question that leaps to mind is why there is both this and AH (not = to mention ESP).

The primary differences between TCP-AO and AH are:

TCP-AO can only be used to protect TCP connections (because the integrit= y checksum is included in a TCP extension header).

TCP-AO only increases the packet length by 16 bytes with default crypto = (AH adds 24 bytes with default crypto).

While both are technically independent of any particular keying mechanis= m, AH was designed to be keyed using IKE (RFC 4306) while TCP-AO was design= ed for manual keying. In particular, TCP-AO includes an in-band protocol fo= r signally when a new key is available so that when new keys are configured= at the two ends of a connection, both ends will start using the new key on= ly when it is available at both ends.

Review of the document:

Section 4.2 under KeyID (and repeated in section 5.1 under IDs), the doc= ument says that KeyID values are arbitrary. This is not quite true. The sam= e KeyID value cannot be used for two different valid keys. (So an implement= ation must assure that all nodes have deconfigured or expired keys with a p= articular KeyID value before assigning that KeyID value to a new key.

Section 4.2 also implies that the KeyID for the same master key used to = generate different encryption keys for the two different directions of TCP = can have different KeyIDs in the two different directions. That seems like = a useless generality.

Section 8.1 specifies how to choose the key to use in a next packet base= d on the RNextKeyID in the last received packet. It does not specify how to= choose the key when starting a new connection (i.e. sending a SYN). I woul= d assume that there is some non-connection state saved on the node (and pre= served across crashes) that remembers the last RNextKeyID received on any c= onnection, and this is used to open new connections. The first time a conne= ction is opened to a node that has never successfully been connected to, th= e sender would cycle through all valid keys until finding one the other end= will accept. In any case, the spec should say.

Section 8.2 paragraph 5 says the implementation of SNEs (extended sequen= ce numbers) is not specified in this document. This seems entirely unaccept= able, since the two ends must implement them identically for the protocol t= o work and they aren't specified anywhere else. Further, it appears tha= t they *are* specified in the paragraphs that follow (though stated as an e= xample rather than a spec).

Sections 9.3-9.5 appear to be dealing with the case where one end of the= connection has been configured to use TCP-AO but the other has not. This s= hould probably be modeled as having a special "no authentication"= key configured as a valid key for the connection. The initiator would not = use that key when sending a SYN, but would switch to that key if he got an = unsigned ACK from the other end or he got an unsigned SYN from the other en= d. There is an implication that existing implementations will ignore the TC= P-AO extension if they don't support TCP-AO. Is that true? (When in thi= s mode, there is no security, but it is a way to add initial keys to the tw= o endpoints without breaking connectivity during the period when one end ha= s been keyed and the other has not. Once both ends have received a correctl= y signed message from the other end, they should stop accepting unsigned on= es.

Section 10 says "TCP implementations MUST support TCP-AO". Wha= t does this mean? Implementations of this spec MUST implement this spec. It= is not reasonable to expect *all* TCP implementations to support TCP-AO.

Section 11.2 suggests use of IPsec NAT traversal instead of TCP-AO if NA= Ts are present, but does not suggest how that would be negotiated. Or is th= is saying that IPsec NAT traversal is preferred in any scenario where NAT t= raversal *might* be needed?

Typos:

Page 4 2nd to last paragraph: There is a badly structured sentence that = could be fixed in multiple ways. One way would be: "This document obso= letes the TCP MD5 option with a more general TCP Authentication Option (TCP= -AO). The new design supports the use of other (stronger) hash functions, p= rovides replay protection for long-lived connections and across repeated in= stances of a single connection, coordinates key changes between endpoints, = and provides a more structured recommendation for external key management.&= quot;

Section 3 paragraph 3: "proceeding -> preceding"

Page 13 3rd to last line: "match at exactly" -> "match= exactly"

Page 21 3rd to last line: "when is" -> "when it is&quo= t;

--000e0cd154aade4a1604812f3f41-- From touch@ISI.EDU Sun Mar 7 11:08:44 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 272743A8B90; Sun, 7 Mar 2010 11:08:44 -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] 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 1qgkl2LVS1tK; Sun, 7 Mar 2010 11:08:42 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id BD25D3A8612; Sun, 7 Mar 2010 11:08:42 -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 o27J71vD022138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 7 Mar 2010 11:07:03 -0800 (PST) Message-ID: <4B93F955.3000002@isi.edu> Date: Sun, 07 Mar 2010 11:07:01 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Radia Perlman References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig314BEFDF6CDEA990F6A084E4" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbonica@juniper.net, mankin@psg.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-tcpm-tcp-auth-opt-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: Sun, 07 Mar 2010 19:08:44 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig314BEFDF6CDEA990F6A084E4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Radia, Thanks for your comments. Some clarifications below. It would be useful to determine how to proceed on these issues. Joe Radia Perlman wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > This protocol is essentially a lightweight special purpose version of > the Authentication Header (AH) protocol (RFC 4302). It is intended as a= > generalization, improvement, and replacement of the TCP-MD5 protocol > documented in RFC2385. RFC2385 only proposed using TCP-MD5 for BGP, > which had certain unique requirements (like keeping a TCP connection up= > through crashes of one or both endpoints). The proposal does not > explicitly limit the applicability. > =20 > One question that leaps to mind is why there is both this and AH (not t= o > mention ESP). >=20 > The primary differences between TCP-AO and AH are: >=20 > TCP-AO can only be used to protect TCP connections (because the > integrity checksum is included in a TCP extension header). >=20 > TCP-AO only increases the packet length by 16 bytes with default crypto= > (AH adds 24 bytes with default crypto). The document contains a list of the differences. One other notable difference is that TCP-AO rekeys on each new TCP connection even when used with manual master keys, without requiring an in-band or out-of-band key negotation protocol. > While both are technically independent of any particular keying > mechanism, AH was designed to be keyed using IKE (RFC 4306) while TCP-A= O > was designed for manual keying. In particular, TCP-AO includes an > in-band protocol for signally when a new key is available so that when > new keys are configured at the two ends of a connection, both ends will= > start using the new key only when it is available at both ends. >=20 > Review of the document: >=20 > Section 4.2 under KeyID (and repeated in section 5.1 under IDs), the > document says that KeyID values are arbitrary. This is not quite true. > The same KeyID value cannot be used for two different valid keys. (So a= n > implementation must assure that all nodes have deconfigured or expired > keys with a particular KeyID value before assigning that KeyID value to= > a new key. The same keyID can be used for different valid (master) keys, so long as they otherwise do not apply to the same TCP socket pair (connection), as noted in the following requirement in 5.1: >> The IDs of MKTs MUST NOT overlap where their TCP connection identifiers overlap. The primary reason for calling them "arbitrary" is to note that the values are not monotonically increasing, have no reserved values, and are otherwise not meaningful. Would it help to clarify that in the doc? > Section 4.2 also implies that the KeyID for the same master key used to= > generate different encryption keys for the two different directions of > TCP can have different KeyIDs in the two different directions. That > seems like a useless generality. It specifically allows for at least two capabilities: 1) master keys can be installed on a set of devices without coordinating their keyIDs in advance=09 2) master keys can be installed on a set of devices, and new devices added to the set of keys later without requiring renumbering of keyIDs These two capabilities are particularly important when used with wildcards in the TCP socket pair of the master key tuple, i.e., when a key is used among a set of devices specified by a pattern. Would it be useful to add as motivation in the doc? > Section 8.1 specifies how to choose the key to use in a next packet > based on the RNextKeyID in the last received packet. It does not specif= y > how to choose the key when starting a new connection (i.e. sending a > SYN).=20 8.1 talks about how to use new keys in established connections. 9.4 addresses how to start a connection as follows: 1. Find the per-connection parameters for the segment: a. If the segment is a SYN, then this is the first segment of a new connection. Find the matching MKT for this segment based on the segment's socket pair. i. If there is no matching MKT, omit the TCP-AO option. Proceed with transmitting the segment. ii. If there is a matching MKT, then set the per-connection parameters as needed (see Section 6). Proceed with the step 2. This is enabled by the requirement that: >> An outgoing TCP segment MUST match at most one desired MKT, indicated by the segment's socket pair. The segment MAY match multiple MKTs, provided that exactly one MKT is indicated as desired. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Other information in the segment MAY be used to determine the desired MKT when multiple MKTs match; such information MUST NOT include values in any TCP option fields. > I would assume that there is some non-connection state saved on > the node (and preserved across crashes) that remembers the last > RNextKeyID received on any connection, and this is used to open new > connections. There is no such state. New connections are opened by using the "desired" MKT for a socket pair (this is like setting one of the MKTs for a set of overlapping MKTs as "use first"). >The first time a connection is opened to a node that has > never successfully been connected to, the sender would cycle through al= l > valid keys until finding one the other end will accept. In any case, th= e > spec should say. Would it be useful, given the above already in the doc, to be more clear about the idea of "desired" MKTs, and how MKTs are selected when a connection is opened? > Section 8.2 paragraph 5 says the implementation of SNEs (extended > sequence numbers) is not specified in this document. This seems entirel= y > unacceptable, since the two ends must implement them identically for th= e > protocol to work and they aren't specified anywhere else. Further, it > appears that they *are* specified in the paragraphs that follow (though= > stated as an example rather than a spec). The implementation is not specified. The code is one way to implement them, but not the only way. SNE properties are described throughout that section. We meant that to say more like "the requirements are specified in this section, but the implementation is up to the user". Does that address your concerns, or would it be useful to either update the text to require the algorithm indicated, or to be more clear about what is being required and what is offered as an example? > Sections 9.3-9.5 appear to be dealing with the case where one end of th= e > connection has been configured to use TCP-AO but the other has not.=20 Section 9 as a whole describes how TCP-AO interacts with RFC 793. It deals with sent and received segments separately, because they are specified separately in 793, and typically implemented separately. None of this is specific to asymmetric use. > This > should probably be modeled as having a special "no authentication" key > configured as a valid key for the connection. In TCP-AO, the default is that all packets are allowed as having no authentication unless there is a key required. This differs from IPsec, in which all packets would be blocked until a "default pass" rule were installed. > The initiator would not > use that key when sending a SYN, but would switch to that key if he got= > an unsigned ACK from the other end or he got an unsigned SYN from the > other end. There is an implication that existing implementations will > ignore the TCP-AO extension if they don't support TCP-AO. Is that true?= Yes. This is consistent with RFC 793. > (When in this mode, there is no security, but it is a way to add initia= l > keys to the two endpoints without breaking connectivity during the > period when one end has been keyed and the other has not. Once both end= s > have received a correctly signed message from the other end, they shoul= d > stop accepting unsigned ones. TCP-AO is not intended to 'startup' mid-connection. That would make the use of SNE impossible, among other things. > Section 10 says "TCP implementations MUST support TCP-AO". What does > this mean? Implementations of this spec MUST implement this spec. It is= > not reasonable to expect *all* TCP implementations to support TCP-AO. I'll let the TSV ADs speak to this issue. I had thought we were intending this to be a MUST for all TCP implementations, to encourage its use. This would be in the spirit of IPsec being a MUST for IPv6 - even though there are IPv6 implementations that don't support IPsec. > Section 11.2 suggests use of IPsec NAT traversal instead of TCP-AO if > NATs are present, but does not suggest how that would be negotiated. Or= > is this saying that IPsec NAT traversal is preferred in any scenario > where NAT traversal *might* be needed? We're trying to offer a path for NAT traversal; another path is the TCP-AO-nat extension, currently under ongoing discussion in the WG. The point is more "do NAT traversal *like* IPsec", not to use "IPsec NAT traversal" - i.e., traversal by UDP encapsulation. We can update the doc to make that more clear. The updates below would be useful to include, and the ADs can indicate when they should be done (e.g., now, or during AUTH48). > Typos: >=20 > Page 4 2nd to last paragraph: There is a badly structured sentence that= > could be fixed in multiple ways. One way would be: "This document > obsoletes the TCP MD5 option with a more general TCP Authentication > Option (TCP-AO). The new design supports the use of other (stronger) > hash functions, provides replay protection for long-lived connections > and across repeated instances of a single connection, coordinates key > changes between endpoints, and provides a more structured recommendatio= n > for external key management." >=20 > Section 3 paragraph 3: "proceeding -> preceding" >=20 > Page 13 3rd to last line: "match at exactly" -> "match exactly" >=20 > Page 21 3rd to last line: "when is" -> "when it is" >=20 --------------enig314BEFDF6CDEA990F6A084E4 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) iEYEARECAAYFAkuT+VUACgkQE5f5cImnZrtRlwCfWwVhJt3uhrSIZikt7ov+Q60K 3PIAoKIW8iaMfsMqo1PXgxGZTSOBsfxe =gXvJ -----END PGP SIGNATURE----- --------------enig314BEFDF6CDEA990F6A084E4-- From radiaperlman@gmail.com Sun Mar 7 11:28: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 098C228C1CD; Sun, 7 Mar 2010 11:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynRXhKB-FxCC; Sun, 7 Mar 2010 11:28:54 -0800 (PST) Received: from mail-pz0-f195.google.com (mail-pz0-f195.google.com [209.85.222.195]) by core3.amsl.com (Postfix) with ESMTP id D17593A8312; Sun, 7 Mar 2010 11:28:54 -0800 (PST) Received: by pzk33 with SMTP id 33so392753pzk.5 for ; Sun, 07 Mar 2010 11:28:55 -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; bh=wjHSQ3Q0l8T597RkwSsWXF1+IpY3jMWihU98Nl9XFSU=; b=BGmr/LzZtUlldjycUIZ3diakCZSVvtb7XiJ1/mOmFkdVj7U5dJNW/KEuCGAIBM/ufv nipo3jUNZS4pjbk2rcFkJ++4HX/NgAXToT34Pk1Ggwi0y0jI1Bb6j2er9An28Zr9z9W1 7zkxQ+EryD2sGqO81mQ6eutr2WprNvm9tDet0= 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; b=gQ9X4n9Z/L2gFUQzta/80mrc36fKqBQLmEdVISoMIKA/lW7ZsY1X9m8GLRjy/enT41 STZ+4ymLWaHoaf3MerBNWprTGByyrlveh8ufOcvMcsHXMIsJ6XaBHdhxqhjh8ObPbuUd a5XvkA+GWNdR7OTWWOVIRfTyUIYbfHgEU4Ulo= MIME-Version: 1.0 Received: by 10.142.6.19 with SMTP id 19mr2562584wff.131.1267990135647; Sun, 07 Mar 2010 11:28:55 -0800 (PST) In-Reply-To: <4B93F955.3000002@isi.edu> References: <4B93F955.3000002@isi.edu> Date: Sun, 7 Mar 2010 11:28:55 -0800 Message-ID: From: Radia Perlman To: Joe Touch Content-Type: multipart/alternative; boundary=00504502bc1f9d2f3304813af515 X-Mailman-Approved-At: Sun, 07 Mar 2010 11:39:13 -0800 Cc: rbonica@juniper.net, mankin@psg.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-tcpm-tcp-auth-opt-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: Sun, 07 Mar 2010 19:28:57 -0000 --00504502bc1f9d2f3304813af515 Content-Type: text/plain; charset=ISO-8859-1 re: all the opportunities for clarification: I certainly like documenting clarifications and motivations, whether it be in the base document, or a companion "tutorial/motivation" document. Radia On Sun, Mar 7, 2010 at 11:07 AM, Joe Touch wrote: > Hi, Radia, > > Thanks for your comments. Some clarifications below. > > It would be useful to determine how to proceed on these issues. > > Joe > > Radia Perlman wrote: > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > This protocol is essentially a lightweight special purpose version of > > the Authentication Header (AH) protocol (RFC 4302). It is intended as a > > generalization, improvement, and replacement of the TCP-MD5 protocol > > documented in RFC2385. RFC2385 only proposed using TCP-MD5 for BGP, > > which had certain unique requirements (like keeping a TCP connection up > > through crashes of one or both endpoints). The proposal does not > > explicitly limit the applicability. > > > > One question that leaps to mind is why there is both this and AH (not to > > mention ESP). > > > > The primary differences between TCP-AO and AH are: > > > > TCP-AO can only be used to protect TCP connections (because the > > integrity checksum is included in a TCP extension header). > > > > TCP-AO only increases the packet length by 16 bytes with default crypto > > (AH adds 24 bytes with default crypto). > > The document contains a list of the differences. One other notable > difference is that TCP-AO rekeys on each new TCP connection even when > used with manual master keys, without requiring an in-band or > out-of-band key negotation protocol. > > > While both are technically independent of any particular keying > > mechanism, AH was designed to be keyed using IKE (RFC 4306) while TCP-AO > > was designed for manual keying. In particular, TCP-AO includes an > > in-band protocol for signally when a new key is available so that when > > new keys are configured at the two ends of a connection, both ends will > > start using the new key only when it is available at both ends. > > > > Review of the document: > > > > Section 4.2 under KeyID (and repeated in section 5.1 under IDs), the > > document says that KeyID values are arbitrary. This is not quite true. > > The same KeyID value cannot be used for two different valid keys. (So an > > implementation must assure that all nodes have deconfigured or expired > > keys with a particular KeyID value before assigning that KeyID value to > > a new key. > > The same keyID can be used for different valid (master) keys, so long as > they otherwise do not apply to the same TCP socket pair (connection), as > noted in the following requirement in 5.1: > > >> The IDs of MKTs MUST NOT overlap where their TCP connection > identifiers overlap. > > The primary reason for calling them "arbitrary" is to note that the > values are not monotonically increasing, have no reserved values, and > are otherwise not meaningful. > > Would it help to clarify that in the doc? > > > Section 4.2 also implies that the KeyID for the same master key used to > > generate different encryption keys for the two different directions of > > TCP can have different KeyIDs in the two different directions. That > > seems like a useless generality. > > It specifically allows for at least two capabilities: > > 1) master keys can be installed on a set of devices without coordinating > their keyIDs in advance > > 2) master keys can be installed on a set of devices, and new devices > added to the set of keys later without requiring renumbering of keyIDs > > These two capabilities are particularly important when used with > wildcards in the TCP socket pair of the master key tuple, i.e., when a > key is used among a set of devices specified by a pattern. > > Would it be useful to add as motivation in the doc? > > > Section 8.1 specifies how to choose the key to use in a next packet > > based on the RNextKeyID in the last received packet. It does not specify > > how to choose the key when starting a new connection (i.e. sending a > > SYN). > > 8.1 talks about how to use new keys in established connections. > > 9.4 addresses how to start a connection as follows: > > 1. Find the per-connection parameters for the segment: > > a. If the segment is a SYN, then this is the first segment of a > new connection. Find the matching MKT for this segment based > on the segment's socket pair. > > i. If there is no matching MKT, omit the TCP-AO option. > Proceed with transmitting the segment. > > ii. If there is a matching MKT, then set the per-connection > parameters as needed (see Section 6). Proceed with the > step 2. > > This is enabled by the requirement that: > > >> An outgoing TCP segment MUST match at most one desired MKT, > indicated by the segment's socket pair. The segment MAY match > multiple MKTs, provided that exactly one MKT is indicated as desired. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Other information in the segment MAY be used to determine the desired > MKT when multiple MKTs match; such information MUST NOT include > values in any TCP option fields. > > > > I would assume that there is some non-connection state saved on > > the node (and preserved across crashes) that remembers the last > > RNextKeyID received on any connection, and this is used to open new > > connections. > > There is no such state. New connections are opened by using the > "desired" MKT for a socket pair (this is like setting one of the MKTs > for a set of overlapping MKTs as "use first"). > > >The first time a connection is opened to a node that has > > never successfully been connected to, the sender would cycle through all > > valid keys until finding one the other end will accept. In any case, the > > spec should say. > > Would it be useful, given the above already in the doc, to be more clear > about the idea of "desired" MKTs, and how MKTs are selected when a > connection is opened? > > > Section 8.2 paragraph 5 says the implementation of SNEs (extended > > sequence numbers) is not specified in this document. This seems entirely > > unacceptable, since the two ends must implement them identically for the > > protocol to work and they aren't specified anywhere else. Further, it > > appears that they *are* specified in the paragraphs that follow (though > > stated as an example rather than a spec). > > The implementation is not specified. The code is one way to implement > them, but not the only way. SNE properties are described throughout that > section. > > We meant that to say more like "the requirements are specified in this > section, but the implementation is up to the user". > > Does that address your concerns, or would it be useful to either update > the text to require the algorithm indicated, or to be more clear about > what is being required and what is offered as an example? > > > Sections 9.3-9.5 appear to be dealing with the case where one end of the > > connection has been configured to use TCP-AO but the other has not. > > Section 9 as a whole describes how TCP-AO interacts with RFC 793. It > deals with sent and received segments separately, because they are > specified separately in 793, and typically implemented separately. > > None of this is specific to asymmetric use. > > > This > > should probably be modeled as having a special "no authentication" key > > configured as a valid key for the connection. > > In TCP-AO, the default is that all packets are allowed as having no > authentication unless there is a key required. This differs from IPsec, > in which all packets would be blocked until a "default pass" rule were > installed. > > > The initiator would not > > use that key when sending a SYN, but would switch to that key if he got > > an unsigned ACK from the other end or he got an unsigned SYN from the > > other end. There is an implication that existing implementations will > > ignore the TCP-AO extension if they don't support TCP-AO. Is that true? > > Yes. This is consistent with RFC 793. > > > (When in this mode, there is no security, but it is a way to add initial > > keys to the two endpoints without breaking connectivity during the > > period when one end has been keyed and the other has not. Once both ends > > have received a correctly signed message from the other end, they should > > stop accepting unsigned ones. > > TCP-AO is not intended to 'startup' mid-connection. That would make the > use of SNE impossible, among other things. > > > Section 10 says "TCP implementations MUST support TCP-AO". What does > > this mean? Implementations of this spec MUST implement this spec. It is > > not reasonable to expect *all* TCP implementations to support TCP-AO. > > I'll let the TSV ADs speak to this issue. I had thought we were > intending this to be a MUST for all TCP implementations, to encourage > its use. This would be in the spirit of IPsec being a MUST for IPv6 - > even though there are IPv6 implementations that don't support IPsec. > > > Section 11.2 suggests use of IPsec NAT traversal instead of TCP-AO if > > NATs are present, but does not suggest how that would be negotiated. Or > > is this saying that IPsec NAT traversal is preferred in any scenario > > where NAT traversal *might* be needed? > > We're trying to offer a path for NAT traversal; another path is the > TCP-AO-nat extension, currently under ongoing discussion in the WG. The > point is more "do NAT traversal *like* IPsec", not to use "IPsec NAT > traversal" - i.e., traversal by UDP encapsulation. > > We can update the doc to make that more clear. > > The updates below would be useful to include, and the ADs can indicate > when they should be done (e.g., now, or during AUTH48). > > > > Typos: > > > > Page 4 2nd to last paragraph: There is a badly structured sentence that > > could be fixed in multiple ways. One way would be: "This document > > obsoletes the TCP MD5 option with a more general TCP Authentication > > Option (TCP-AO). The new design supports the use of other (stronger) > > hash functions, provides replay protection for long-lived connections > > and across repeated instances of a single connection, coordinates key > > changes between endpoints, and provides a more structured recommendation > > for external key management." > > > > Section 3 paragraph 3: "proceeding -> preceding" > > > > Page 13 3rd to last line: "match at exactly" -> "match exactly" > > > > Page 21 3rd to last line: "when is" -> "when it is" > > > > --00504502bc1f9d2f3304813af515 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
re: all the opportunities for clarification: I certainly like document= ing clarifications and motivations, whether it be in the base document, or = a companion "tutorial/motivation" document.
=A0
Radia

On Sun, Mar 7, 2010 at 11:07 AM, Joe Touch <touch@isi.edu> wrote:
Hi, Radia,

Thanks for you= r comments. Some clarifications below.

It would be useful to determi= ne how to proceed on these issues.

Joe

Radia Perlman wrote:
> I have reviewed this doc= ument as part of the security directorate's
> ongoing effort to r= eview all IETF documents being processed by the
> IESG. =A0These comm= ents were written primarily for the benefit of the
> security area directors. =A0Document editors and WG chairs should trea= t
> these comments just like any other last call comments.
> Th= is protocol is essentially a lightweight special purpose version of
>= the Authentication Header (AH) protocol (RFC 4302). It is intended as a > generalization, improvement, and replacement of the TCP-MD5 protocol> documented in RFC2385. RFC2385 only proposed using TCP-MD5 for BGP,<= br>> which had certain unique requirements (like keeping a TCP connectio= n up
> through crashes of one or both endpoints). The proposal does not
&g= t; explicitly limit the applicability.
>
> One question that le= aps to mind is why there is both this and AH (not to
> mention ESP).<= br> >
> The primary differences between TCP-AO and AH are:
>
= > TCP-AO can only be used to protect TCP connections (because the
>= ; integrity checksum is included in a TCP extension header).
>
> TCP-AO only increases the packet length by 16 bytes with default crypt= o
> (AH adds 24 bytes with default crypto).

The document= contains a list of the differences. One other notable
difference is tha= t TCP-AO rekeys on each new TCP connection even when
used with manual master keys, without requiring an in-band or
out-of-ban= d key negotation protocol.

> While both are technically independent of any pa= rticular keying
> mechanism, AH was designed to be keyed using IKE (R= FC 4306) while TCP-AO
> was designed for manual keying. In particular= , TCP-AO includes an
> in-band protocol for signally when a new key is available so that when=
> new keys are configured at the two ends of a connection, both ends= will
> start using the new key only when it is available at both end= s.
>
> Review of the document:
>
> Section 4.2 under KeyI= D (and repeated in section 5.1 under IDs), the
> document says that K= eyID values are arbitrary. This is not quite true.
> The same KeyID v= alue cannot be used for two different valid keys. (So an
> implementation must assure that all nodes have deconfigured or expired=
> keys with a particular KeyID value before assigning that KeyID val= ue to
> a new key.

The same keyID can be used for differ= ent valid (master) keys, so long as
they otherwise do not apply to the same TCP socket pair (connection), asnoted in the following requirement in 5.1:

=A0 >> The IDs of = MKTs MUST NOT overlap where their TCP connection
=A0 identifiers overlap= .

The primary reason for calling them "arbitrary" is to note th= at the
values are not monotonically increasing, have no reserved values,= and
are otherwise not meaningful.

Would it help to clarify that = in the doc?

> Section 4.2 also implies that the KeyID for the = same master key used to
> generate different encryption keys for the = two different directions of
> TCP can have different KeyIDs in the tw= o different directions. That
> seems like a useless generality.

It specifically allows f= or at least two capabilities:

1) master keys can be installed on a s= et of devices without coordinating
their keyIDs in advance

2) mas= ter keys can be installed on a set of devices, and new devices
added to the set of keys later without requiring renumbering of keyIDs
<= br>These two capabilities are particularly important when used with
wild= cards in the TCP socket pair of the master key tuple, i.e., when a
key i= s used among a set of devices specified by a pattern.

Would it be useful to add as motivation in the doc?

> Section 8.1 specifies how to choose the key to u= se in a next packet
> based on the RNextKeyID in the last received pa= cket. It does not specify
> how to choose the key when starting a new= connection (i.e. sending a
> SYN).

8.1 talks about how to use new keys in established = connections.

9.4 addresses how to start a connection as follows:
=
=A0 1. Find the per-connection parameters for the segment:

=A0 = =A0 =A0 a. If the segment is a SYN, then this is the first segment of a
=A0 =A0 =A0 =A0 =A0new connection. Find the matching MKT for this segment b= ased
=A0 =A0 =A0 =A0 =A0on the segment's socket pair.

=A0 =A0= =A0 =A0 =A0 i. If there is no matching MKT, omit the TCP-AO option.
=A0= =A0 =A0 =A0 =A0 =A0 =A0 Proceed with transmitting the segment.

=A0 =A0 =A0 =A0 =A0ii. If there is a matching MKT, then set the per-con= nection
=A0 =A0 =A0 =A0 =A0 =A0 =A0 parameters as needed (see Section 6)= . Proceed with the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 step 2.

This is en= abled by the requirement that:

=A0 >> An outgoing TCP segment MUST match at most one desired MKT= ,
=A0 indicated by the segment's socket pair. The segment MAY match<= br>=A0 multiple MKTs, provided that exactly one MKT is indicated as desired= .
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^
=A0 Other information in the segment MAY be used to determ= ine the desired
=A0 MKT when multiple MKTs match; such information MUST = NOT include
=A0 values in any TCP option fields.


> I would assume that there is some non-connec= tion state saved on
> the node (and preserved across crashes) that re= members the last
> RNextKeyID received on any connection, and this is= used to open new
> connections.

There is no such state. New connections are = opened by using the
"desired" MKT for a socket pair (this is l= ike setting one of the MKTs
for a set of overlapping MKTs as "use f= irst").

=A0>The first time a connection is opened to a nod= e that has
> never successfully been connected to, the sender would c= ycle through all
> valid keys until finding one the other end will ac= cept. In any case, the
> spec should say.

Would it be useful, given the above alre= ady in the doc, to be more clear
about the idea of "desired" M= KTs, and how MKTs are selected when a
connection is opened?

> Section 8.2 paragraph 5 says the implementation = of SNEs (extended
> sequence numbers) is not specified in this docume= nt. This seems entirely
> unacceptable, since the two ends must imple= ment them identically for the
> protocol to work and they aren't specified anywhere else. Further,= it
> appears that they *are* specified in the paragraphs that follow= (though
> stated as an example rather than a spec).

The implementation is not specified. The code is one way to implement
th= em, but not the only way. SNE properties are described throughout that
s= ection.

We meant that to say more like "the requirements are sp= ecified in this
section, but the implementation is up to the user".

Does that a= ddress your concerns, or would it be useful to either update
the text to= require the algorithm indicated, or to be more clear about
what is bein= g required and what is offered as an example?

> Sections 9.3-9.5 appear to be dealing with the c= ase where one end of the
> connection has been configured to use TCP-= AO but the other has not.

Section 9 as a whole describes how T= CP-AO interacts with RFC 793. It
deals with sent and received segments separately, because they are
speci= fied separately in 793, and typically implemented separately.

None o= f this is specific to asymmetric use.

> This
> should probably be modeled as havin= g a special "no authentication" key
> configured as a valid= key for the connection.

In TCP-AO, the default is that all pa= ckets are allowed as having no
authentication unless there is a key required. This differs from IPsec,
= in which all packets would be blocked until a "default pass" rule= were
installed.

> The initiator would not
> use that key whe= n sending a SYN, but would switch to that key if he got
> an unsigned= ACK from the other end or he got an unsigned SYN from the
> other en= d. There is an implication that existing implementations will
> ignore the TCP-AO extension if they don't support TCP-AO. Is that = true?

Yes. This is consistent with RFC 793.

> (When in this mode, there is no security, but it= is a way to add initial
> keys to the two endpoints without breaking= connectivity during the
> period when one end has been keyed and the= other has not. Once both ends
> have received a correctly signed message from the other end, they shou= ld
> stop accepting unsigned ones.

TCP-AO is not intende= d to 'startup' mid-connection. That would make the
use of SNE im= possible, among other things.

> Section 10 says "TCP implementations MUST s= upport TCP-AO". What does
> this mean? Implementations of this s= pec MUST implement this spec. It is
> not reasonable to expect *all* = TCP implementations to support TCP-AO.

I'll let the TSV ADs speak to this issue. I had thought we we= re
intending this to be a MUST for all TCP implementations, to encourage=
its use. This would be in the spirit of IPsec being a MUST for IPv6 - even though there are IPv6 implementations that don't support IPsec.

> Section 11.2 suggests use of IPsec NAT traversal= instead of TCP-AO if
> NATs are present, but does not suggest how th= at would be negotiated. Or
> is this saying that IPsec NAT traversal = is preferred in any scenario
> where NAT traversal *might* be needed?

We're trying t= o offer a path for NAT traversal; another path is the
TCP-AO-nat extensi= on, currently under ongoing discussion in the WG. The
point is more &quo= t;do NAT traversal *like* IPsec", not to use "IPsec NAT
traversal" - i.e., traversal by UDP encapsulation.

We can updat= e the doc to make that more clear.

The updates below would be useful= to include, and the ADs can indicate
when they should be done (e.g., no= w, or during AUTH48).


> Typos:
>
> Page 4 2nd to last pa= ragraph: There is a badly structured sentence that
> could be fixed i= n multiple ways. One way would be: "This document
> obsoletes th= e TCP MD5 option with a more general TCP Authentication
> Option (TCP-AO). The new design supports the use of other (stronger)> hash functions, provides replay protection for long-lived connection= s
> and across repeated instances of a single connection, coordinates= key
> changes between endpoints, and provides a more structured recommendati= on
> for external key management."
>
> Section 3 par= agraph 3: "proceeding -> preceding"
>
> Page 13 3r= d to last line: "match at exactly" -> "match exactly"= ;
>
> Page 21 3rd to last line: "when is" -> "when= it is"
>


--00504502bc1f9d2f3304813af515-- From touch@ISI.EDU Sun Mar 7 11:46: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 F0A1228C1E9; Sun, 7 Mar 2010 11:46:57 -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 39Tos+2Ie7xD; Sun, 7 Mar 2010 11:46:56 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 87C1628C17E; Sun, 7 Mar 2010 11:46:56 -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 o27JiDOI029107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 7 Mar 2010 11:44:15 -0800 (PST) Message-ID: <4B94020D.8090209@isi.edu> Date: Sun, 07 Mar 2010 11:44:13 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Radia Perlman References: <4B93F955.3000002@isi.edu> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD6E40A591AF966B3039D9FDC" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: rbonica@juniper.net, mankin@psg.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review of draft-ietf-tcpm-tcp-auth-opt-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: Sun, 07 Mar 2010 19:46:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD6E40A591AF966B3039D9FDC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Radia (et al.), I expect that this will be 'documented' not only as an RFC, but as a published paper elsewhere; that paper might provide the context, but it won't be citable in the RFC (not ready yet). I don't see the need for that as an RFC per se - it's more useful as advertisement to the community at large, IMO, so I'd like to seek a wider venue for that. Joe Radia Perlman wrote: > re: all the opportunities for clarification: I certainly like > documenting clarifications and motivations, whether it be in the base > document, or a companion "tutorial/motivation" document. > =20 > Radia >=20 > On Sun, Mar 7, 2010 at 11:07 AM, Joe Touch > wrote: >=20 > Hi, Radia, >=20 > Thanks for your comments. Some clarifications below. >=20 > It would be useful to determine how to proceed on these issues. >=20 > Joe >=20 > Radia Perlman wrote: > > I have reviewed this document as part of the security directorate= 's > > ongoing effort to review all IETF documents being processed by th= e > > IESG. These comments were written primarily for the benefit of t= he > > security area directors. Document editors and WG chairs should t= reat > > these comments just like any other last call comments. > > This protocol is essentially a lightweight special purpose versio= n of > > the Authentication Header (AH) protocol (RFC 4302). It is intende= d > as a > > generalization, improvement, and replacement of the TCP-MD5 proto= col > > documented in RFC2385. RFC2385 only proposed using TCP-MD5 for BG= P, > > which had certain unique requirements (like keeping a TCP > connection up > > through crashes of one or both endpoints). The proposal does not > > explicitly limit the applicability. > > > > One question that leaps to mind is why there is both this and AH > (not to > > mention ESP). > > > > The primary differences between TCP-AO and AH are: > > > > TCP-AO can only be used to protect TCP connections (because the > > integrity checksum is included in a TCP extension header). > > > > TCP-AO only increases the packet length by 16 bytes with default > crypto > > (AH adds 24 bytes with default crypto). >=20 > The document contains a list of the differences. One other notable > difference is that TCP-AO rekeys on each new TCP connection even wh= en > used with manual master keys, without requiring an in-band or > out-of-band key negotation protocol. >=20 > > While both are technically independent of any particular keying > > mechanism, AH was designed to be keyed using IKE (RFC 4306) while= > TCP-AO > > was designed for manual keying. In particular, TCP-AO includes an= > > in-band protocol for signally when a new key is available so that= when > > new keys are configured at the two ends of a connection, both end= s > will > > start using the new key only when it is available at both ends. > > > > Review of the document: > > > > Section 4.2 under KeyID (and repeated in section 5.1 under IDs), = the > > document says that KeyID values are arbitrary. This is not quite = true. > > The same KeyID value cannot be used for two different valid keys.= > (So an > > implementation must assure that all nodes have deconfigured or ex= pired > > keys with a particular KeyID value before assigning that KeyID > value to > > a new key. >=20 > The same keyID can be used for different valid (master) keys, so lo= ng as > they otherwise do not apply to the same TCP socket pair (connection= ), as > noted in the following requirement in 5.1: >=20 > >> The IDs of MKTs MUST NOT overlap where their TCP connection > identifiers overlap. >=20 > The primary reason for calling them "arbitrary" is to note that the= > values are not monotonically increasing, have no reserved values, a= nd > are otherwise not meaningful. >=20 > Would it help to clarify that in the doc? >=20 > > Section 4.2 also implies that the KeyID for the same master key > used to > > generate different encryption keys for the two different directio= ns of > > TCP can have different KeyIDs in the two different directions. Th= at > > seems like a useless generality. >=20 > It specifically allows for at least two capabilities: >=20 > 1) master keys can be installed on a set of devices without coordin= ating > their keyIDs in advance >=20 > 2) master keys can be installed on a set of devices, and new device= s > added to the set of keys later without requiring renumbering of key= IDs >=20 > These two capabilities are particularly important when used with > wildcards in the TCP socket pair of the master key tuple, i.e., whe= n a > key is used among a set of devices specified by a pattern. >=20 > Would it be useful to add as motivation in the doc? >=20 > > Section 8.1 specifies how to choose the key to use in a next pack= et > > based on the RNextKeyID in the last received packet. It does not > specify > > how to choose the key when starting a new connection (i.e. sendin= g a > > SYN). >=20 > 8.1 talks about how to use new keys in established connections. >=20 > 9.4 addresses how to start a connection as follows: >=20 > 1. Find the per-connection parameters for the segment: >=20 > a. If the segment is a SYN, then this is the first segment of= a > new connection. Find the matching MKT for this segment bas= ed > on the segment's socket pair. >=20 > i. If there is no matching MKT, omit the TCP-AO option. > Proceed with transmitting the segment. >=20 > ii. If there is a matching MKT, then set the per-connectio= n > parameters as needed (see Section 6). Proceed with th= e > step 2. >=20 > This is enabled by the requirement that: >=20 > >> An outgoing TCP segment MUST match at most one desired MKT, > indicated by the segment's socket pair. The segment MAY match > multiple MKTs, provided that exactly one MKT is indicated as desi= red. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^ > Other information in the segment MAY be used to determine the des= ired > MKT when multiple MKTs match; such information MUST NOT include > values in any TCP option fields. >=20 >=20 > > I would assume that there is some non-connection state saved on > > the node (and preserved across crashes) that remembers the last > > RNextKeyID received on any connection, and this is used to open n= ew > > connections. >=20 > There is no such state. New connections are opened by using the > "desired" MKT for a socket pair (this is like setting one of the MK= Ts > for a set of overlapping MKTs as "use first"). >=20 > >The first time a connection is opened to a node that has > > never successfully been connected to, the sender would cycle > through all > > valid keys until finding one the other end will accept. In any > case, the > > spec should say. >=20 > Would it be useful, given the above already in the doc, to be more = clear > about the idea of "desired" MKTs, and how MKTs are selected when a > connection is opened? >=20 > > Section 8.2 paragraph 5 says the implementation of SNEs (extended= > > sequence numbers) is not specified in this document. This seems > entirely > > unacceptable, since the two ends must implement them identically > for the > > protocol to work and they aren't specified anywhere else. Further= , it > > appears that they *are* specified in the paragraphs that follow > (though > > stated as an example rather than a spec). >=20 > The implementation is not specified. The code is one way to impleme= nt > them, but not the only way. SNE properties are described throughout= that > section. >=20 > We meant that to say more like "the requirements are specified in t= his > section, but the implementation is up to the user". >=20 > Does that address your concerns, or would it be useful to either up= date > the text to require the algorithm indicated, or to be more clear ab= out > what is being required and what is offered as an example? >=20 > > Sections 9.3-9.5 appear to be dealing with the case where one end= > of the > > connection has been configured to use TCP-AO but the other has no= t. >=20 > Section 9 as a whole describes how TCP-AO interacts with RFC 793. I= t > deals with sent and received segments separately, because they are > specified separately in 793, and typically implemented separately. >=20 > None of this is specific to asymmetric use. >=20 > > This > > should probably be modeled as having a special "no authentication= " key > > configured as a valid key for the connection. >=20 > In TCP-AO, the default is that all packets are allowed as having no= > authentication unless there is a key required. This differs from IP= sec, > in which all packets would be blocked until a "default pass" rule w= ere > installed. >=20 > > The initiator would not > > use that key when sending a SYN, but would switch to that key if > he got > > an unsigned ACK from the other end or he got an unsigned SYN from= the > > other end. There is an implication that existing implementations = will > > ignore the TCP-AO extension if they don't support TCP-AO. Is that= > true? >=20 > Yes. This is consistent with RFC 793. >=20 > > (When in this mode, there is no security, but it is a way to add > initial > > keys to the two endpoints without breaking connectivity during th= e > > period when one end has been keyed and the other has not. Once > both ends > > have received a correctly signed message from the other end, they= > should > > stop accepting unsigned ones. >=20 > TCP-AO is not intended to 'startup' mid-connection. That would make= the > use of SNE impossible, among other things. >=20 > > Section 10 says "TCP implementations MUST support TCP-AO". What d= oes > > this mean? Implementations of this spec MUST implement this spec.= > It is > > not reasonable to expect *all* TCP implementations to support TCP= -AO. >=20 > I'll let the TSV ADs speak to this issue. I had thought we were > intending this to be a MUST for all TCP implementations, to encoura= ge > its use. This would be in the spirit of IPsec being a MUST for IPv6= - > even though there are IPv6 implementations that don't support IPsec= =2E >=20 > > Section 11.2 suggests use of IPsec NAT traversal instead of TCP-A= O if > > NATs are present, but does not suggest how that would be > negotiated. Or > > is this saying that IPsec NAT traversal is preferred in any scena= rio > > where NAT traversal *might* be needed? >=20 > We're trying to offer a path for NAT traversal; another path is the= > TCP-AO-nat extension, currently under ongoing discussion in the WG.= The > point is more "do NAT traversal *like* IPsec", not to use "IPsec NA= T > traversal" - i.e., traversal by UDP encapsulation. >=20 > We can update the doc to make that more clear. >=20 > The updates below would be useful to include, and the ADs can indic= ate > when they should be done (e.g., now, or during AUTH48). >=20 >=20 > > Typos: > > > > Page 4 2nd to last paragraph: There is a badly structured sentenc= e > that > > could be fixed in multiple ways. One way would be: "This document= > > obsoletes the TCP MD5 option with a more general TCP Authenticati= on > > Option (TCP-AO). The new design supports the use of other (strong= er) > > hash functions, provides replay protection for long-lived connect= ions > > and across repeated instances of a single connection, coordinates= key > > changes between endpoints, and provides a more structured > recommendation > > for external key management." > > > > Section 3 paragraph 3: "proceeding -> preceding" > > > > Page 13 3rd to last line: "match at exactly" -> "match exactly" > > > > Page 21 3rd to last line: "when is" -> "when it is" > > >=20 >=20 --------------enigD6E40A591AF966B3039D9FDC 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) iEYEARECAAYFAkuUAg0ACgkQE5f5cImnZrvdTwCgha92Vgi0aufVjpRTaQ57Tto/ 4SMAoNiVDGuh/2q8WFROaGlKXsrZrDEj =pFoB -----END PGP SIGNATURE----- --------------enigD6E40A591AF966B3039D9FDC-- From jsalowey@cisco.com Sun Mar 7 16:46: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 0878F3A67E7; Sun, 7 Mar 2010 16:46:17 -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 Ry0FIcmBu5hK; Sun, 7 Mar 2010 16:46:16 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 04FBC3A676A; Sun, 7 Mar 2010 16:46:15 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFrXk0urR7H+/2dsb2JhbACbI3OfYJdHhHgEgxc X-IronPort-AV: E=Sophos;i="4.49,599,1262563200"; d="scan'208";a="91153238" Received: from sj-core-2.cisco.com ([171.71.177.254]) by rtp-iport-2.cisco.com with ESMTP; 08 Mar 2010 00:46:19 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o280kJim009166; Mon, 8 Mar 2010 00:46:19 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 7 Mar 2010 16:46:19 -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: Sun, 7 Mar 2010 16:46:16 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-mext-binary-ts-04 Thread-Index: Acq+WMKoAdFLpEHYSLas24Gy8TOzvQ== From: "Joseph Salowey (jsalowey)" To: , , X-OriginalArrivalTime: 08 Mar 2010 00:46:19.0056 (UTC) FILETIME=[C423CB00:01CABE58] Subject: [secdir] secdir review of draft-ietf-mext-binary-ts-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, 08 Mar 2010 00:46:17 -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 didn't find any security issues in the draft. The security considerations section points to draft-ietf-mext-flow-binding-05. The referenced section is a bit thin and doesn't really say what bad things could happen if the binding is falsified. If unprotected bindings are not an option, this may be OK. If they are an option it would be good to have a better understanding of what the risks are with the various levels of protection. If this is done it might be possible that there are specific considerations around some of the data types defined in the draft-ietf-mext-binary-ts-04, but I don't think that would be the case.=20 Joe From duerst@it.aoyama.ac.jp Mon Mar 8 00:39: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 4E1153A635F for ; Mon, 8 Mar 2010 00:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 CBEfpklIMTTe for ; Mon, 8 Mar 2010 00:39:57 -0800 (PST) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id 96BF93A67A3 for ; Mon, 8 Mar 2010 00:39:56 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id o288dxfZ029161 for ; Mon, 8 Mar 2010 17:39:59 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 7807_0878_2e1fcaa8_2a8e_11df_bbe3_001d096c5782; Mon, 08 Mar 2010 17:39:59 +0900 Received: from [IPv6:::1] ([133.2.210.1]:60432) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 8 Mar 2010 17:39:57 +0900 Message-ID: <4B94B7CB.3050303@it.aoyama.ac.jp> Date: Mon, 08 Mar 2010 17:39:39 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Dan Harkins References: <825be751fdcdc5da34213d44f5ef0b67.squirrel@www.trepanning.net> In-Reply-To: <825be751fdcdc5da34213d44f5ef0b67.squirrel@www.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: jwz@jwz.org, LMM@acm.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] review of draft-duerst-mailto-bis-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: Mon, 08 Mar 2010 08:39:59 -0000 Hello Dan, Many thanks for your comments. Sorry to be late with my reply. On 2009/12/09 3:02, Dan Harkins wrote: > > 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 should treat these comments > just like any other last call comments. > > This document adds support for internationalization (and internation- > alized resource identifiers) to the previously defined syntax of a > "mailto" URI. It will obsolete RFC 2368. > > This document does not introduce any new security issues. The Security > Considerations describe some of the dangers inherent to using a "mailto" > URI and recommend some guidelines in their use. They are illustrative and > seem fine. > > There is some requirements language that I think could be cleaned up > a little. For instance, in section 4 it says: > > "The user agent interpreting a 'mailto' URI SHOULD choose not to > create a message if any of the header fields are considered > dangerous; it may also choose to create a message with only a subset > of the header fields given in the URI. > > "SHOULD choose not to" made me stop and read that a couple times to try > to understand what behavior is being specified. I eventually decided that > "SHOULD NOT" is equivalent. Is that correct? If so I suggest changing it. Done, in response to somebody else who also pointed this out. > And should that "may also choose" become a "MAY also choose"? Done. > Section 7 has a couple of cases of "SHOULD never", such as: > > "A mail client SHOULD never send anything without complete disclosure > to the user...." > > Never is pretty absolute. But then it's qualified with SHOULD. Should it > be "SHOULD NOT"? Done. > I like the example in section 6 that illustrates how to provide a link > in a browsable archive that will do a reply and preserve threading > information. Very cool! That's actually in use in the W3C mailing list archives. See e.g. the Respond link at the top of http://lists.w3.org/Archives/Public/public-iri/2010Mar/0000.html. Maybe you can suggest implementing something similar to the IETF mailing list archives? Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From gwz@net-zen.net Mon Mar 8 02:25:44 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 D0F8A3A67D4 for ; Mon, 8 Mar 2010 02:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 9xCYTqMPnx1f for ; Mon, 8 Mar 2010 02:25:44 -0800 (PST) Received: from smtpout08.prod.mesa1.secureserver.net (smtpout08-01.prod.mesa1.secureserver.net [64.202.165.119]) by core3.amsl.com (Postfix) with SMTP id 77AC23A67F9 for ; Mon, 8 Mar 2010 02:25:44 -0800 (PST) Received: (qmail 5561 invoked from network); 8 Mar 2010 10:25:46 -0000 Received: from unknown (124.122.164.217) by smtpout08.prod.mesa1.secureserver.net (64.202.165.119) with ESMTP; 08 Mar 2010 10:25:46 -0000 From: "Glen Zorn" To: , , , , , , , Date: Mon, 8 Mar 2010 17:25:31 +0700 Organization: Network Zen Message-ID: <017f01cabea9$b0c56f40$12504dc0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq+qZ92NP+59aU3S9Ctm+KsbtV2GA== Content-Language: en-us x-cr-hashedpuzzle: GWBW J7Mv LF64 cZYQ mPYM sjpI AAbBVQ== AAfPxA== AAsghA== ADa+5A== AD3S3g== AEBG9A== AEWhOw== AGqUuw== AHslag== AIHb7A==; 8; YgByAGUAdAB0AEAAYgByAG8AYQBkAHMAbwBmAHQALgBjAG8AbQA7AGIAcgBpAGEAbgAuAGUALgBjAGEAcgBwAGUAbgB0AGUAcgBAAGcAbQBhAGkAbAAuAGMAbwBtADsAZgBsAHUAZgBmAHkAQABjAGkAcwBjAG8ALgBjAG8AbQA7AGkAZQBzAGcAQABpAGUAdABmAC4AbwByAGcAOwByAGoAcwBwAGEAcgBrAHMAQABuAG8AcwB0AHIAdQBtAC4AYwBvAG0AOwBzAGUAYwBkAGkAcgBAAGkAZQB0AGYALgBvAHIAZwA7AHMAaQBwAC0AYwBoAGEAaQByAHMAQAB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcAOwB2AGsAZwBAAGIAZQBsAGwALQBsAGEAYgBzAC4AYwBvAG0A; Sosha1_v1; 7; {094FBBD8-0349-4679-9E5E-ACEAE0A6FF1E}; ZwB3AHoAQABuAGUAdAAtAHoAZQBuAC4AbgBlAHQA; Mon, 08 Mar 2010 10:25:06 GMT; cwBlAGMAZABpAHIAIAByAGUAdgBpAGUAdwAgAG8AZgAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBzAGkAcAAtAGkAcAB2ADYALQBhAGIAbgBmAC0AZgBpAHgALQAwADQA x-cr-puzzleid: {094FBBD8-0349-4679-9E5E-ACEAE0A6FF1E} Subject: [secdir] secdir review of draft-ietf-sip-ipv6-abnf-fix-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, 08 Mar 2010 10:25:44 -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. In Section 3.2, second paragraph, s/19.1.4 of RFC3216 MUST/19.1.4 of RFC3261 MUST/. From CWallace@cygnacom.com Mon Mar 8 05:42: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 688ED3A6957; Mon, 8 Mar 2010 05:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 weCFYaSWxrBe; Mon, 8 Mar 2010 05:42:08 -0800 (PST) Received: from mail166.messagelabs.com (mail166.messagelabs.com [216.82.253.163]) by core3.amsl.com (Postfix) with SMTP id 842483A6904; Mon, 8 Mar 2010 05:42:08 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-15.tower-166.messagelabs.com!1268055731!26949027!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.13] Received: (qmail 28049 invoked from network); 8 Mar 2010 13:42:11 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.13) by server-15.tower-166.messagelabs.com with SMTP; 8 Mar 2010 13:42:11 -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, 8 Mar 2010 08:42:10 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review for draft-ietf-morg-sortdisplay-03 Thread-Index: Acq+xScjWnQdc4P/Rfydi9Wtpu6UoA== From: "Carl Wallace" To: , Cc: dkarp@zimbra.com Subject: [secdir] secdir review for draft-ietf-morg-sortdisplay-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: Mon, 08 Mar 2010 13:42:09 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes an IMAP protocol extension enabling server-side message sorting on the commonly-displayed portion of the From and To header fields. The security considerations section states that this document does not introduce any security considerations beyond those in the base IMAP spec. This seems OK to me. From tsirtsis@qualcomm.com Mon Mar 8 07:38: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 70C253A69D9; Mon, 8 Mar 2010 07:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2qkqU+8M2kd; Mon, 8 Mar 2010 07:38:03 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D058A3A69BA; Mon, 8 Mar 2010 07:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=tsirtsis@qualcomm.com; q=dns/txt; s=qcdkim; t=1268062688; x=1299598688; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Tsirtsis,=20George"=20 |To:=20"Joseph=20Salowey=20(jsalowey)"=20,=20"iesg@ietf.org"=0D=0A=09,=20"secdi r@ietf.org"=20,=0D=0A=09"draft-ietf-mext -binary-ts.all@tools.ietf.org"=0D=0A=09|Date:=20Mon,=208=20Mar=20201 0=2007:38:04=20-0800|Subject:=20RE:=20secdir=20review=20o f=20draft-ietf-mext-binary-ts-04|Thread-Topic:=20secdir =20review=20of=20draft-ietf-mext-binary-ts-04 |Thread-Index:=20Acq+WMKoAdFLpEHYSLas24Gy8TOzvQAfAchA |Message-ID:=20|References:=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=qQmyBNAwC/+lfArae/9jAABTUKGM8kXWY5/SdLI2I2s=; b=p/i2REfhFQEOWQ9b2UebY7CLVChc+f6Wkk7ZKj42lhRdNG4WN1gN2pPC TE84rN+Z4UAkSGEaNppI2+A9k/p/DMWMK8Ns3mk3NhglOa8yOPZa5WDWl 0+K+2wGHr/9TQ7dOt3yfkX6wuQvtI5xWW5BsBpiawQPyTu6iUoCSl7VNQ E=; X-IronPort-AV: E=McAfee;i="5400,1158,5914"; a="35808326" Received: from ironstorm.qualcomm.com ([172.30.39.153]) by wolverine02.qualcomm.com with ESMTP; 08 Mar 2010 07:38:07 -0800 X-IronPort-AV: E=Sophos;i="4.49,600,1262592000"; d="scan'208";a="50654666" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 08 Mar 2010 07:38:07 -0800 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.234.1; Mon, 8 Mar 2010 07:37:51 -0800 Received: from NALASEXMB09.na.qualcomm.com ([10.47.16.15]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Mon, 8 Mar 2010 07:37:51 -0800 From: "Tsirtsis, George" To: "Joseph Salowey (jsalowey)" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-mext-binary-ts.all@tools.ietf.org" Date: Mon, 8 Mar 2010 07:38:04 -0800 Thread-Topic: secdir review of draft-ietf-mext-binary-ts-04 Thread-Index: Acq+WMKoAdFLpEHYSLas24Gy8TOzvQAfAchA 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-Mailman-Approved-At: Mon, 08 Mar 2010 07:41:44 -0800 Subject: Re: [secdir] secdir review of draft-ietf-mext-binary-ts-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, 08 Mar 2010 15:38:06 -0000 Thanks Joseph, some comments inline... -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Monday, March 08, 2010 12:46 AM To: iesg@ietf.org; secdir@ietf.org; draft-ietf-mext-binary-ts.all@tools.iet= f.org Subject: secdir review of draft-ietf-mext-binary-ts-04 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 didn't find any security issues in the draft. =20 GT> That's good news, thanks. The security considerations section points to draft-ietf-mext-flow-binding-05. The referenced section is a bit thin and doesn't really say what bad things could happen if the binding is falsified. If unprotected bindings are not an option, this may be OK. =20 GT> Unprotected bindings are NOT an option since all bindings (including th= e extensions defined in draft-ietf-mext-flow-binding-05 and in draft-ietf-m= ext-binary-ts-04) are authenticated as per base RFC3775 MIPv6 specification= . If they are an option it would be good to have a better understanding of what the risks are with the various levels of protection. If this is done it might be possible that there are specific considerations around some of the data types defined in the draft-ietf-mext-binary-ts-04, but I don't think that would be the case.=20 Joe From scott@hyperthought.com Mon Mar 8 11:25: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 AA5743A6B50 for ; Mon, 8 Mar 2010 11:25:43 -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 Z1s8tm6UjEOk for ; Mon, 8 Mar 2010 11:25:42 -0800 (PST) Received: from smtp222.iad.emailsrvr.com (smtp222.iad.emailsrvr.com [207.97.245.222]) by core3.amsl.com (Postfix) with ESMTP id C5C473A69EA for ; Mon, 8 Mar 2010 11:25:42 -0800 (PST) Received: from relay12.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay12.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 8295E20D39C; Mon, 8 Mar 2010 14:25:46 -0500 (EST) Received: from dynamic1.wm-web.iad.mlsrvr.com (dynamic1.wm-web.iad.mlsrvr.com [192.168.2.150]) by relay12.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 66D7520D05A; Mon, 8 Mar 2010 14:25:46 -0500 (EST) Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic1.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 3FAFDC98070; Mon, 8 Mar 2010 14:25:46 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Mon, 8 Mar 2010 11:25:46 -0800 (PST) Date: Mon, 8 Mar 2010 11:25:46 -0800 (PST) From: scott@hyperthought.com To: draft-ietf-l3vpn-mvpn-considerations-06.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1268076346.258521810@192.168.2.227> X-Mailer: webmail7.0 Subject: [secdir] secdir review of draft-ietf-l3vpn-mvpn-considerations-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, 08 Mar 2010 19:25: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 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.=0A=0AThis document defines a set of mandatory-t= o-implement features for L3 mcast BGP/MPLS VPN implementations, with the un= derlying motivation being that due to the current lack of a minimal necessa= ry and sufficient set of mandatory features, currently deployed implementat= ions may be compliant, yet not interoperate. =0A=0AI think the security ADs= will want to pay attention to this document. The security considerations s= ection is very brief:=0A=0A "This document does not by itself raise any pa= rticular security=0A considerations."=0A=0AAfter reading this, I was surp= rised to find a page-and-a-half discussion earlier in the document entitled= "3.3.5 Security and robustness". This section seems to indicate that ther= e *are* security considerations, although the section could really use some= editorial attention. =0A=0AI would suggest a couple of things: first, thor= oughly review 3.3.5 to ensure that it is complete. Second, try to make this= section more intelligible. For example, here is the first paragraph:=0A=0A= BGP supports MD5 authentication of its peers for additional security,=0A= thereby possibly benefit directly to multicast VPN customer multicast=0A= routing, whether for intra-AS or inter-AS communications. By=0A contr= ast, with a PIM-based approach, no mechanism providing a=0A comparable le= vel of security to authenticate communications between=0A remote PEs has = been yet fully described yet=0A [I-D.ietf-pim-sm-linklocal][], and in any= case would require=0A significant additional operations for the provider= to be usable in a=0A multicast VPN context.=0A=0AI've read this several = times, yet I still have no idea what this is meant to communicate.=0A=0AThi= rd, it wouldn't hurt to refer the reader to other places where relevant sec= urity requirements are already discussed (e.g., RFC4834).=0A=0A--Scott=0A= =0A=0A From sm@elandsys.com Mon Mar 8 11:59: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 9EA9F3A6B36; Mon, 8 Mar 2010 11:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.366, 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 MtkxxJhmHk0W; Mon, 8 Mar 2010 11:59:22 -0800 (PST) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 8DF1D3A6991; Mon, 8 Mar 2010 11:59:22 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.238.97]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id o28JxD79017214; Mon, 8 Mar 2010 11:59:19 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=elandsys.com; s=mail; t=1268078362; x=1268164762; bh=AY4MHDsqAk9l0zXl6NI+sXXhAYw=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=y3vuhxlsvUHNaqp502DKrloSS1+ZFVqK1oqzYtaTW+MZVbRZpuiutIy1Ul72nFmM4 nrMBqho01qyBZu5O4lJYatHqUER9IS3udE7ZXLMYOc6ieUk1ULnivtvfy2+GrsFL8b cHChNNDqIxGgfgOFwf9qyJ+viCOxjjaG92uFwOjM= Message-Id: <6.2.5.6.2.20100308111008.0db293e0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 08 Mar 2010 11:49:02 -0800 To: Stephen Kent From: S Moonesamy In-Reply-To: References: <4B8E515A.6060608@isode.com> <6.2.5.6.2.20100303103218.0ba092a0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Mon, 08 Mar 2010 14:26:10 -0800 Cc: yam@ietf.org, 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: Mon, 08 Mar 2010 19:59:23 -0000 Hi Steve, The YAM WG discussed about the issues raised during the Sec-dir review of draft-ietf-yam-rfc1652bis-03 [1] and concluded that: (i) The presence of an option negotiation mechanism is not believed to facilitate attacks or raise any security issues not already endemic in electronic mail and present in fully conforming implementations of RFC 5321. (ii) Since MIME semantics are transport neutral the 8bitMIME option provides no added capability to disseminate malware than is provided by unextended 7bit SMTP. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/yam/current/msg00366.html From magnusn@gmail.com Mon Mar 8 22:35: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 A3F7A3A6832; Mon, 8 Mar 2010 22:35:04 -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 pljhGYydmQ3K; Mon, 8 Mar 2010 22:35:03 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 5B9D63A681F; Mon, 8 Mar 2010 22:35:02 -0800 (PST) Received: by gwj18 with SMTP id 18so76gwj.31 for ; Mon, 08 Mar 2010 22:35:04 -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=we0p0msTowaFVWK/XbwBdJsoRIrJy4vVHT4mUTIhpHQ=; b=mJWChYKJvnKWO5BQ4yabJBYTJ2pfHb/W11Xh0CEFtG+Be+mRyFSERh0sbH1BzwkKvf lioM6fr6NKHOKc8zQxN0uudcIZsAUNgpwaWaPUc8bmOG526wbPuF+rY4WaTDmqIA1R4E L65MGYIKtq9HKyVfSg0TAlL99I2Z3QmpGewZE= 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=lEEr+G/r8yZA0UoSy5z5b//f8swh9JeIviWPWfQrb8nNpntti4WMP8T0mOE6UGQWgw YFNBRABL0ZdKVpfu200D0EvBS2PzmA8FsOHh6bJLCcrybpEhl3+RRaGDPiByvo88TS0n pkV/XlI4DREOmWCtRk81zGE7tjXL4VRfM6les= MIME-Version: 1.0 Received: by 10.101.39.2 with SMTP id r2mr352457anj.67.1268116503334; Mon, 08 Mar 2010 22:35:03 -0800 (PST) In-Reply-To: References: <2f57b9e61003052142s36ec86baj3aa54ddac604ef6e@mail.gmail.com> Date: Mon, 8 Mar 2010 22:35:03 -0800 Message-ID: <2f57b9e61003082235v4fabe601w2e3f4c3fed5a1c71@mail.gmail.com> From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: Gregory Lebovitz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: magnus.westerlund@ericsson.com, Eric Rescorla , secdir@ietf.org, Tim Polk , iesg@ietf.org, lars.eggert@nokia.com Subject: Re: [secdir] Secdir review of draft-ietf-tcpm-tcp-ao-crypto-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, 09 Mar 2010 06:35:05 -0000 Thanks Gregory - a couple of comments below, inline. On Mon, Mar 8, 2010 at 9:52 PM, Gregory Lebovitz w= rote: > Hey Magnus, > Thanks a lot for the review. Comments inline below... > > On Fri, Mar 5, 2010 at 9:42 PM, Magnus Nystr=F6m wrot= e: >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. =A0These comments were written primarily for the benefit of the >> security area directors. =A0Document editors and WG chairs should treat >> these comments just like any other last call comments >> >> This document specifies requirements on cryptographic algorithms to be >> used in the TCP Authentication Option (TCP APO). It also specifies >> some mandatory algorithms. >> >> Comments: >> >> Abstract: >> >> - The abstract does not mention that the document also specifies >> requirements on future algorithms. IMO, it should. > > Ok > >> >> Section 1: >> (- Last paragraph is what prompted my comment on the abstract.) >> >> Section 2.2: >> >> - Suggest moving the note explaining the need to mandate two MAC >> algorithms to the Security Considerations section as it does not >> contain normative text but does contain security considerations. > > Good point. When I originally wrote this text it did contain normative te= xt. > Then I got some feedback that maybe we should down-grade the text to be > non-normative, but still clear guidance. If you think it makes a big > difference, I can move it. Otherwise, I'd like to keep it with the text > describing the "template" for how all TCP-AO algos are used, so that peop= le > who are looking for the template will see the text right there, whereas t= hey > might miss it if they are skimming and don't make it all the way to the S= C > section. Let me know what you think. You could also place the note in the Security Considerations section and then just reference it in 2.2, like "For an explanation of the need for two MAC algorithms, see the Security Considerations section." I think that would be better, keeping all security considerations in one place. >> - Section 3.1.1.3: >> >> - It is a little surprising to see that the SHA-1-based MAC algorithm >> is selected as the default one, given that this is a new specification >> and the industry is moving away from SHA-1. C.f. the work on XML >> Encryption 1.1 and XML Signature 1.1 that specificallly recommends >> against use of SHA-1 in new applications. > > In TCP-AO SHA-1 is used as an HMAC, not a signing algo, so it does not ha= ve > the same properties in this context, and has shown no weaknesses, afaik. = As > you can imagine we had a very long debate around which algo to make > mandatory. In the end (as the text was supposed to explain), Pasi and Tim > chose SHA-1 for both its strength and its wide availability in the target > devices (routers -- this is first and foremost being done for BGP > protection). But, since it's been around a while, and we always want to h= ave > 2 good algos in place, one the older more available, and a newer > up-and-comer, the AES was also specified. Unless Pasi and Tim want to cha= nge > their recommendations to the TCPM WG, we'll probably sit tight with this = the > way it reads currently. Yes, I can (and did...) imagine you had lengthy discussions around this... OK, since Pasi and Tim chose it I will rest my case... Best, -- Magnus >> - Section 6 (Security Considerations): >> >> In the fourth paragraph, there is a discussion around the fact that >> the document does not force use of a 16 octet key. I think it would be >> useful to at least clearly state a recommended minimum key size. > > Interesting point. We had this debate in WG too. > My .02: =A0this is a security vs convenience thing. We give the deployer > plenty enough guidance and pointers to other RFC's and NIST docs to allow > them to do their homework to decide what length key they want, stopping j= ust > short of telling them a recommended min key size. The deployers here are > router operators, for the most part. The ones that have a clue are alread= y > using 128bit keys, generated randomly. The ones that aren't probably aren= 't > going to read this document anyway. > Any thoughts from Tim or EKR? From gregory.ietf@gmail.com Mon Mar 8 21:52:40 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 54F823A688E; Mon, 8 Mar 2010 21:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.144 X-Spam-Level: X-Spam-Status: No, score=-102.144 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, USER_IN_WHITELIST=-100] 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 k1Q708Jm6Eaz; Mon, 8 Mar 2010 21:52:39 -0800 (PST) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id 460313A6849; Mon, 8 Mar 2010 21:52:34 -0800 (PST) Received: by bwz3 with SMTP id 3so503056bwz.29 for ; Mon, 08 Mar 2010 21:52:35 -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; bh=Yp5isnKVJ0S/RVYVqNzDEIM0rjD0OHW6qIP/kto3OFE=; b=SGIKfZIJifgR1CtWfIUQK5uctpaD9peEYoLLzGkoxZJtsr05alOY2pF4PZGkW54hXc Swk21rg+18B+i6Hr6wZfb4ABSlbV92J29W+LjuIIAscaBL0+2r/8mZL6NoItcnXoklld 2/FY+M2NIKmMGl86fyTZZ7u4MGVsVFSUEO3qU= 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; b=qljnWWoCeyRcuoyMvZck0yMdmS6sHedtcWmab5SRXf4m2Mypiyjk4e+e/fgVtW482B ZqRFTeNSi9BrEZnSCrMgxTgQTZ6/5ysi/qAXGGkvN+jbCqnra/4OvusJlKtOlZ9URxio ogIzPFvNTc5vOUHwmLzKkiSw8dSQWwIiueue8= MIME-Version: 1.0 Received: by 10.204.137.16 with SMTP id u16mr189415bkt.165.1268113955194; Mon, 08 Mar 2010 21:52:35 -0800 (PST) In-Reply-To: <2f57b9e61003052142s36ec86baj3aa54ddac604ef6e@mail.gmail.com> References: <2f57b9e61003052142s36ec86baj3aa54ddac604ef6e@mail.gmail.com> Date: Mon, 8 Mar 2010 21:52:35 -0800 Message-ID: From: Gregory Lebovitz To: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= , Eric Rescorla , Tim Polk Content-Type: multipart/alternative; boundary=0015173fe6f6d58766048157c9f0 X-Mailman-Approved-At: Mon, 08 Mar 2010 23:53:50 -0800 Cc: magnus.westerlund@ericsson.com, iesg@ietf.org, lars.eggert@nokia.com, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-tcpm-tcp-ao-crypto-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, 09 Mar 2010 05:52:40 -0000 --0015173fe6f6d58766048157c9f0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Magnus, Thanks a lot for the review. Comments inline below... On Fri, Mar 5, 2010 at 9:42 PM, Magnus Nystr=F6m wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments > > This document specifies requirements on cryptographic algorithms to be > used in the TCP Authentication Option (TCP APO). It also specifies > some mandatory algorithms. > > Comments: > > Abstract: > > - The abstract does not mention that the document also specifies > requirements on future algorithms. IMO, it should. > Ok > > Section 1: > (- Last paragraph is what prompted my comment on the abstract.) > > Section 2.2: > > - Suggest moving the note explaining the need to mandate two MAC > algorithms to the Security Considerations section as it does not > contain normative text but does contain security considerations. > Good point. When I originally wrote this text it did contain normative text= . Then I got some feedback that maybe we should down-grade the text to be non-normative, but still clear guidance. If you think it makes a big difference, I can move it. Otherwise, I'd like to keep it with the text describing the "template" for how all TCP-AO algos are used, so that people who are looking for the template will see the text right there, whereas the= y might miss it if they are skimming and don't make it all the way to the SC section. Let me know what you think. > > - Section 3.1.1.3: > > - It is a little surprising to see that the SHA-1-based MAC algorithm > is selected as the default one, given that this is a new specification > and the industry is moving away from SHA-1. C.f. the work on XML > Encryption 1.1 and XML Signature 1.1 that specificallly recommends > against use of SHA-1 in new applications. > In TCP-AO SHA-1 is used as an HMAC, not a signing algo, so it does not have the same properties in this context, and has shown no weaknesses, afaik. As you can imagine we had a very long debate around which algo to make mandatory. In the end (as the text was supposed to explain), Pasi and Tim chose SHA-1 for both its strength and its wide availability in the target devices (routers -- this is first and foremost being done for BGP protection). But, since it's been around a while, and we always want to hav= e 2 good algos in place, one the older more available, and a newer up-and-comer, the AES was also specified. Unless Pasi and Tim want to chang= e their recommendations to the TCPM WG, we'll probably sit tight with this th= e way it reads currently. > > - Section 6 (Security Considerations): > > In the fourth paragraph, there is a discussion around the fact that > the document does not force use of a 16 octet key. I think it would be > useful to at least clearly state a recommended minimum key size. > Interesting point. We had this debate in WG too. My .02: this is a security vs convenience thing. We give the deployer plenty enough guidance and pointers to other RFC's and NIST docs to allow them to do their homework to decide what length key they want, stopping jus= t short of telling them a recommended min key size. The deployers here are router operators, for the most part. The ones that have a clue are already using 128bit keys, generated randomly. The ones that aren't probably aren't going to read this document anyway. Any thoughts from Tim or EKR? > > Editorial: > > Section 1: > > - "between to endpoints" - "between two endpoints"? > good catch > > Section 3.1.1: > > - "fixed-length output lengths" -> "fixed-length output"? > good one > > Section 3.2.1: > > - "will be that has" -> "will be that"? > got it. Thanks a ton again, Magnus. Good read. Much appreciated, Gregory > > -- Magnus > --=20 ---- IETF related email from Gregory M. Lebovitz Juniper Networks --0015173fe6f6d58766048157c9f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Magnus,
Thanks a lot for the review. Comments inline below...
On Fri, Mar 5, 2010 at 9:42 PM, Magnus Nystr= =F6m <magnusn@gma= il.com> wrote:
I have reviewed this document as part of th= e security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. =A0These comments were written primarily for the benefit of the
security area directors. =A0Document editors and WG chairs should treat
these comments just like any other last call comments

This document specifies requirements on cryptographic algorithms to be
used in the TCP Authentication Option (TCP APO). It also specifies
some mandatory algorithms.

Comments:

Abstract:

- The abstract does not mention that the document also specifies
requirements on future algorithms. IMO, it should.
Ok
=A0

Section 1:
(- Last paragraph is what prompted my comment on the abstract.)

Section 2.2:

- Suggest moving the note explaining the need to mandate two MAC
algorithms to the Security Considerations section as it does not
contain normative text but does contain security considerations.

Good point. When I originally wrote this text it = did contain normative text. Then I got some feedback that maybe we should d= own-grade the text to be non-normative, but still clear guidance. If you th= ink it makes a big difference, I can move it. Otherwise, I'd like to ke= ep it with the text describing the "template" for how all TCP-AO = algos are used, so that people who are looking for the template will see th= e text right there, whereas they might miss it if they are skimming and don= 't make it all the way to the SC section. Let me know what you think.

=A0

- Section 3.1.1.3:

- It is a little surprising to see that the SHA-1-based MAC algorithm
is selected as the default one, given that this is a new specification
and the industry is moving away from SHA-1. C.f. the work on XML
Encryption 1.1 and XML Signature 1.1 that specificallly recommends
against use of SHA-1 in new applications.

In TCP-AO SHA-1 is used as an HMAC, not a signing algo, so it does not h= ave the same properties in this context, and has shown no weaknesses, afaik= . As you can imagine we had a very long debate around which algo to make ma= ndatory. In the end (as the text was supposed to explain), Pasi and Tim cho= se SHA-1 for both its strength and its wide availability in the target devi= ces (routers -- this is first and foremost being done for BGP protection). = But, since it's been around a while, and we always want to have 2 good = algos in place, one the older more available, and a newer up-and-comer, the= AES was also specified. Unless Pasi and Tim want to change their recommend= ations to the TCPM WG, we'll probably sit tight with this the way it re= ads currently.
=A0

- Section 6 (Security Considerations):

In the fourth paragraph, there is a discussion around the fact that
the document does not force use of a 16 octet key. I think it would be
useful to at least clearly state a recommended minimum key size.

Interesting point. We had this debate in WG too.<= /div>
My .02: =A0this is a security vs convenience thing. We give the d= eployer plenty enough guidance and pointers to other RFC's and NIST doc= s to allow them to do their homework to decide what length key they want, s= topping just short of telling them a recommended min key size. The deployer= s here are router operators, for the most part. The ones that have a clue a= re already using 128bit keys, generated randomly. The ones that aren't = probably aren't going to read this document anyway.=A0

Any thoughts from Tim or EKR?
=A0

Editorial:

Section 1:

- "between to endpoints" - "between two endpoints"?
=

good catch
=A0

Section 3.1.1:

- "fixed-length output lengths" -> "fixed-length output&q= uot;?

good one
=A0

Section 3.2.1:

- "will be that has" -> "will be that"?

got it.

Thanks a ton again= , Magnus. Good read. Much appreciated,
Gregory

=A0

-- Magnus



--
----
IETF rel= ated email from
Gregory M. Lebovitz
Juniper Networks
--0015173fe6f6d58766048157c9f0-- From gregory.ietf@gmail.com Mon Mar 8 22:59:38 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 511DC3A6890; Mon, 8 Mar 2010 22:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.155 X-Spam-Level: X-Spam-Status: No, score=-102.155 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, USER_IN_WHITELIST=-100] 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 p9fBEkZ2fPLG; Mon, 8 Mar 2010 22:59:37 -0800 (PST) Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by core3.amsl.com (Postfix) with ESMTP id 6E82A3A6407; Mon, 8 Mar 2010 22:59:36 -0800 (PST) Received: by bwz22 with SMTP id 22so269915bwz.28 for ; Mon, 08 Mar 2010 22:59:36 -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; bh=R18/AjfioGTe34NIwCbox+8ckJNZ2vc70UEYX8VJvns=; b=BOwVB/+J0ddgKVERMtm+bhStID0m4bJDjy/D6jDdgDiraEhgHjtfaEnph2U3tCOmX3 nfGx7wOQDy3DDBX6nHtHZ9rC8s9E6hXA3+kqF12ZpZOAZcu/TRI3TA2lkzjZEOzZmP4r 4QY84YkDbXIY7o5GnG7U/qt4y5kg7oVv/g2zI= 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; b=cAX0dm1gb2lxuvWb+QNDRwh0Sd7zoAJAvc7IDNpetP4utCioE78BHtJjn3OF9tCa7B 3EowvxNVT5CSrkz6EdrWQYOBIfHWJV/akkkzCuGjuNueiIW1YwxdknN+YPzk6eUUuECu Lp96EmbnS+fA3fc1kGqlo5GxkOcOsgx/Y8mxU= MIME-Version: 1.0 Received: by 10.204.138.212 with SMTP id b20mr2459205bku.63.1268117976667; Mon, 08 Mar 2010 22:59:36 -0800 (PST) In-Reply-To: <2f57b9e61003082235v4fabe601w2e3f4c3fed5a1c71@mail.gmail.com> References: <2f57b9e61003052142s36ec86baj3aa54ddac604ef6e@mail.gmail.com> <2f57b9e61003082235v4fabe601w2e3f4c3fed5a1c71@mail.gmail.com> Date: Mon, 8 Mar 2010 22:59:36 -0800 Message-ID: From: Gregory Lebovitz To: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= Content-Type: multipart/alternative; boundary=001517479186885971048158b965 X-Mailman-Approved-At: Mon, 08 Mar 2010 23:53:50 -0800 Cc: magnus.westerlund@ericsson.com, Eric Rescorla , secdir@ietf.org, Tim Polk , iesg@ietf.org, lars.eggert@nokia.com Subject: Re: [secdir] Secdir review of draft-ietf-tcpm-tcp-ao-crypto-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, 09 Mar 2010 06:59:38 -0000 --001517479186885971048158b965 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Mar 8, 2010 at 10:35 PM, Magnus Nystr=F6m wrote= : > Thanks Gregory - a couple of comments below, inline. > > On Mon, Mar 8, 2010 at 9:52 PM, Gregory Lebovitz > wrote: > > Hey Magnus, > > Thanks a lot for the review. Comments inline below... > > > > On Fri, Mar 5, 2010 at 9:42 PM, Magnus Nystr=F6m > wrote: > >> > >> I have reviewed this document as part of the security directorate's > >> ongoing effort to review all IETF documents being processed by the > >> IESG. These comments were written primarily for the benefit of the > >> security area directors. Document editors and WG chairs should treat > >> these comments just like any other last call comments > >> > >> This document specifies requirements on cryptographic algorithms to be > >> used in the TCP Authentication Option (TCP APO). It also specifies > >> some mandatory algorithms. > >> > >> Comments: > >> > >> Abstract: > >> > >> - The abstract does not mention that the document also specifies > >> requirements on future algorithms. IMO, it should. > > > > Ok > > > >> > >> Section 1: > >> (- Last paragraph is what prompted my comment on the abstract.) > >> > >> Section 2.2: > >> > >> - Suggest moving the note explaining the need to mandate two MAC > >> algorithms to the Security Considerations section as it does not > >> contain normative text but does contain security considerations. > > > > Good point. When I originally wrote this text it did contain normative > text. > > Then I got some feedback that maybe we should down-grade the text to be > > non-normative, but still clear guidance. If you think it makes a big > > difference, I can move it. Otherwise, I'd like to keep it with the text > > describing the "template" for how all TCP-AO algos are used, so that > people > > who are looking for the template will see the text right there, whereas > they > > might miss it if they are skimming and don't make it all the way to the > SC > > section. Let me know what you think. > > You could also place the note in the Security Considerations section > and then just reference it in 2.2, like "For an explanation of the > need for two MAC algorithms, see the Security Considerations section." > I think that would be better, keeping all security considerations in > one place. > That's a fine idea. I'll do that. > > >> - Section 3.1.1.3: > >> > >> - It is a little surprising to see that the SHA-1-based MAC algorithm > >> is selected as the default one, given that this is a new specification > >> and the industry is moving away from SHA-1. C.f. the work on XML > >> Encryption 1.1 and XML Signature 1.1 that specificallly recommends > >> against use of SHA-1 in new applications. > > > > In TCP-AO SHA-1 is used as an HMAC, not a signing algo, so it does not > have > > the same properties in this context, and has shown no weaknesses, afaik= . > As > > you can imagine we had a very long debate around which algo to make > > mandatory. In the end (as the text was supposed to explain), Pasi and T= im > > chose SHA-1 for both its strength and its wide availability in the targ= et > > devices (routers -- this is first and foremost being done for BGP > > protection). But, since it's been around a while, and we always want to > have > > 2 good algos in place, one the older more available, and a newer > > up-and-comer, the AES was also specified. Unless Pasi and Tim want to > change > > their recommendations to the TCPM WG, we'll probably sit tight with thi= s > the > > way it reads currently. > > Yes, I can (and did...) imagine you had lengthy discussions around > this... OK, since Pasi and Tim chose it I will rest my case... > Thanks. Gregory. > > Best, > -- Magnus > > >> - Section 6 (Security Considerations): > >> > >> In the fourth paragraph, there is a discussion around the fact that > >> the document does not force use of a 16 octet key. I think it would be > >> useful to at least clearly state a recommended minimum key size. > > > > Interesting point. We had this debate in WG too. > > My .02: this is a security vs convenience thing. We give the deployer > > plenty enough guidance and pointers to other RFC's and NIST docs to all= ow > > them to do their homework to decide what length key they want, stopping > just > > short of telling them a recommended min key size. The deployers here ar= e > > router operators, for the most part. The ones that have a clue are > already > > using 128bit keys, generated randomly. The ones that aren't probably > aren't > > going to read this document anyway. > > Any thoughts from Tim or EKR? > --=20 ---- IETF related email from Gregory M. Lebovitz Juniper Networks --001517479186885971048158b965 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 8, 2010 at 10:35 PM, Magnus Nyst= r=F6m <magnusn@gm= ail.com> wrote:
Thanks Gregory - a couple of comments below, inline.

On Mon, Mar 8, 2010 at 9:52 PM, Gregory Lebovitz <gregory.ietf@gmail.com> wrote:
> Hey Magnus,
> Thanks a lot for the review. Comments inline below...
>
> On Fri, Mar 5, 2010 at 9:42 PM, Magnus Nystr=F6m <magnusn@gmail.com> wrote:
>>
>> I have reviewed this document as part of the security directorate&= #39;s
>> ongoing effort to review all IETF documents being processed by the=
>> IESG. =A0These comments were written primarily for the benefit of = the
>> security area directors. =A0Document editors and WG chairs should = treat
>> these comments just like any other last call comments
>>
>> This document specifies requirements on cryptographic algorithms t= o be
>> used in the TCP Authentication Option (TCP APO). It also specifies=
>> some mandatory algorithms.
>>
>> Comments:
>>
>> Abstract:
>>
>> - The abstract does not mention that the document also specifies >> requirements on future algorithms. IMO, it should.
>
> Ok
>
>>
>> Section 1:
>> (- Last paragraph is what prompted my comment on the abstract.) >>
>> Section 2.2:
>>
>> - Suggest moving the note explaining the need to mandate two MAC >> algorithms to the Security Considerations section as it does not >> contain normative text but does contain security considerations. >
> Good point. When I originally wrote this text it did contain normative= text.
> Then I got some feedback that maybe we should down-grade the text to b= e
> non-normative, but still clear guidance. If you think it makes a big > difference, I can move it. Otherwise, I'd like to keep it with the= text
> describing the "template" for how all TCP-AO algos are used,= so that people
> who are looking for the template will see the text right there, wherea= s they
> might miss it if they are skimming and don't make it all the way t= o the SC
> section. Let me know what you think.

You could also place the note in the Security Considerations se= ction
and then just reference it in 2.2, like "For an explanation of the
need for two MAC algorithms, see the Security Considerations section."=
I think that would be better, keeping all security considerations in
one place.

That's a fine idea. I= 9;ll do that.=A0
=A0

>> - Section 3.1.1.3= :
>>
>> - It is a little surprising to see that the SHA-1-based MAC algori= thm
>> is selected as the default one, given that this is a new specifica= tion
>> and the industry is moving away from SHA-1. C.f. the work on XML >> Encryption 1.1 and XML Signature 1.1 that specificallly recommends=
>> against use of SHA-1 in new applications.
>
> In TCP-AO SHA-1 is used as an HMAC, not a signing algo, so it does not= have
> the same properties in this context, and has shown no weaknesses, afai= k. As
> you can imagine we had a very long debate around which algo to make > mandatory. In the end (as the text was supposed to explain), Pasi and = Tim
> chose SHA-1 for both its strength and its wide availability in the tar= get
> devices (routers -- this is first and foremost being done for BGP
> protection). But, since it's been around a while, and we always wa= nt to have
> 2 good algos in place, one the older more available, and a newer
> up-and-comer, the AES was also specified. Unless Pasi and Tim want to = change
> their recommendations to the TCPM WG, we'll probably sit tight wit= h this the
> way it reads currently.

Yes, I can (and did...) imagine you had lengthy discussions around this... OK, since Pasi and Tim chose it I will rest my case...

Thanks.
Gregory.

=A0

Best,
-- Magnus

>> - Section 6 (Security Considerations):
>>
>> In the fourth paragraph, there is a discussion around the fact tha= t
>> the document does not force use of a 16 octet key. I think it woul= d be
>> useful to at least clearly state a recommended minimum key size. >
> Interesting point. We had this debate in WG too.
> My .02: =A0this is a security vs convenience thing. We give the deploy= er
> plenty enough guidance and pointers to other RFC's and NIST docs t= o allow
> them to do their homework to decide what length key they want, stoppin= g just
> short of telling them a recommended min key size. The deployers here a= re
> router operators, for the most part. The ones that have a clue are alr= eady
> using 128bit keys, generated randomly. The ones that aren't probab= ly aren't
> going to read this document anyway.
> Any thoughts from Tim or EKR?



--
----
IET= F related email from
Gregory M. Lebovitz
Juniper Networks
--001517479186885971048158b965-- From mundy@sparta.com Tue Mar 9 20:50: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 9E1643A6B3E; Tue, 9 Mar 2010 20:50:01 -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 mMVJt4HiCDJL; Tue, 9 Mar 2010 20:50:00 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 2367A3A6841; Tue, 9 Mar 2010 20:49:59 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o2A4o1IZ007820; Tue, 9 Mar 2010 22:50:01 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o2A4o1Z1032457; Tue, 9 Mar 2010 22:50:01 -0600 Received: from calvin.home.tislabs.com ([69.250.64.147]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Mar 2010 23:50:00 -0500 Received: from calvin.home.tislabs.com (localhost [127.0.0.1]) by calvin.home.tislabs.com (Postfix) with ESMTP id 986AD1CFF6C0; Tue, 9 Mar 2010 23:50:30 -0500 (EST) Message-ID: <4B972516.3080701@sparta.com> Date: Tue, 09 Mar 2010 23:50:30 -0500 From: Russ Mundy User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: ietf@ietf.org, secdir@ietf.org, draft-ietf-geopriv-loc-filters-10.txt.all@tools.ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Mar 2010 04:50:00.0975 (UTC) FILETIME=[244F11F0:01CAC00D] X-Mailman-Approved-At: Tue, 09 Mar 2010 21:56:05 -0800 Cc: russ.mundy@cobham.com, mundy@sparta.com Subject: [secdir] Review of draft-ietf-geopriv-loc-filters-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, 10 Mar 2010 04:50:01 -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 basically provides additional (mostly finer grained) filters that have previous definitions in other specifications. I agree with this draft's assertion that security requirements associated with filters in this draft are (and should be) consistent with the definitions provided in other specifications. The Security Considerations section does a credible job of providing pointers to security requirements in other related specifications. I found the pointers to other specifications particularly useful in locating security requirement of the "basic" filters that this document extends. Russ From kent@bbn.com Wed Mar 10 07:53: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 7696D3A6973; Wed, 10 Mar 2010 07:53: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 iw-LHvUJrX9r; Wed, 10 Mar 2010 07:53:23 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id B4B373A6807; Wed, 10 Mar 2010 07:53:23 -0800 (PST) Received: from dhcp89-089-144.bbn.com ([128.89.89.144]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NpODv-000J2y-Mh; Wed, 10 Mar 2010 10:53:28 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.5.6.2.20100308111008.0db293e0@elandnews.com> References: <4B8E515A.6060608@isode.com> <6.2.5.6.2.20100303103218.0ba092a0@resistor.net> <6.2.5.6.2.20100308111008.0db293e0@elandnews.com> Date: Wed, 10 Mar 2010 10:44:38 -0500 To: S Moonesamy From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: yam@ietf.org, 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: Wed, 10 Mar 2010 15:53:24 -0000 At 11:49 AM -0800 3/8/10, S Moonesamy wrote: >Hi Steve, > >The YAM WG discussed about the issues raised during the Sec-dir >review of draft-ietf-yam-rfc1652bis-03 [1] and concluded that: > > (i) The presence of an option negotiation mechanism is not believed to > facilitate attacks or raise any security issues not already endemic > in electronic mail and present in fully conforming implementations > of RFC 5321. > > (ii) Since MIME semantics are transport neutral the 8bitMIME option > provides no added capability to disseminate malware than is > provided by unextended 7bit SMTP. > >Regards, >S. Moonesamy > Thanks for the reply. Steve From julienl@qualcomm.com Wed Mar 10 09:23: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 D1E523A6C0A; Wed, 10 Mar 2010 09:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.389 X-Spam-Level: X-Spam-Status: No, score=-105.389 tagged_above=-999 required=5 tests=[AWL=1.211, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 xkgq6jukeW56; Wed, 10 Mar 2010 09:23:53 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 6864A3A6C0B; Wed, 10 Mar 2010 09:23:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1268241817; x=1299777817; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20"secdir@ietf.org"=20,=0D=0A=09"dr aft-ietf-csi-hash-threat@tools.ietf.org"=0D=0A=09,=20"iesg@ietf.org"=20 ,=0D=0A=09"csi-chairs@tools.ietf.org"=20|Date:=20Wed,=2010=20Mar=202010 =2009:23:09=20-0800|Subject:=20SecDir=20review=20of=20dra ft-ietf-csi-hash-threat-09|Thread-Topic:=20SecDir=20revie w=20of=20draft-ietf-csi-hash-threat-09|Thread-Index:=20Ac rAdlr+WT9n88UoThCYk7RVGpFEAg=3D=3D|Message-ID:=20|Accept-Language:=20en-US|Content-Language:=20en-U S|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=RjcyAHx/tSi+Pn3rcjWYU+1T082rxhD30klB03bmq4g=; b=AJCyGf/fGSqAXRri67VxuOvbJK4CwWMO5Bf2lFBI/v/vRK5I14JFguuR HPVi+v9lRLFhCT6xP+fcQdjnLgNA1xBmUfjP3t4WxRaiBi+JXfYmd6UjT 8hLoiMTuV1jciPVIJ/AWhAJrC1Lup1BDXFC//A/KJxaf+ct2T1WhUYVHu w=; X-IronPort-AV: E=McAfee;i="5400,1158,5916"; a="36050649" Received: from ironstorm.qualcomm.com ([172.30.39.153]) by wolverine01.qualcomm.com with ESMTP; 10 Mar 2010 09:23:35 -0800 X-IronPort-AV: E=Sophos;i="4.49,614,1262592000"; d="scan'208";a="51612147" Received: from unknown (HELO nasanexhub02.na.qualcomm.com) ([10.46.143.120]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 10 Mar 2010 09:23:34 -0800 Received: from nalasexhc01.na.qualcomm.com (10.47.129.185) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.234.1; Wed, 10 Mar 2010 09:23:12 -0800 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc01.na.qualcomm.com ([10.47.129.185]) with mapi; Wed, 10 Mar 2010 09:23:12 -0800 From: "Laganier, Julien" To: "secdir@ietf.org" , "draft-ietf-csi-hash-threat@tools.ietf.org" , "iesg@ietf.org" , "csi-chairs@tools.ietf.org" Date: Wed, 10 Mar 2010 09:23:09 -0800 Thread-Topic: SecDir review of draft-ietf-csi-hash-threat-09 Thread-Index: AcrAdlr+WT9n88UoThCYk7RVGpFEAg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] SecDir review of draft-ietf-csi-hash-threat-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: Wed, 10 Mar 2010 17:23:54 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Document Abstract: This document analysis the use of hashes in SEND, possible threats and the impact of recent attacks on hash functions used by SEND. Current SEND specification [rfc3971] uses the SHA-1 [sha-1] hash algorithm and X.509 certificates [rfc5280] and does not provide support for the hash algorithm agility. The purpose of the document is to provide analysis of possible hash threats and to decide how to encode the hash agility support in SEND. Summary: Most of the document tries to explains how an attack on a given pr= operty of a hash function does or does not translate into an attack on othe= r hash-based cryptographic primitives (signature, certificate.) IMHO This d= ocument is not the right place to do so (these are documented elsewhere.) M= oreover, the document fail to clearly articulate how attacks against these = hash-based cryptographic primitives translates or does not translate into a= ttacks against the SEND protocol itself. Thus I think the document in its c= urrent form is not ready for publication and requires more work. Detailed comments:=20 - Section 3 explains what is a first-preimage attack, a second preimage att= ack, a collision attacks, etc. I do no think this document is the right pla= ce to do this. A simple reference to the definition of the attacks could be= added if necessary, e.g. "For a definition of the various attacks against = hash function properties, see [HAC] [...] [HAC] Handbook of Applied Cryptog= raphy, Alfred J. Menezes et al., 2001, http://www.cacr.math.uwaterloo.ca/ha= c/" - Section 3.1. explains that the "impacts of collision attacks on current u= ses of CGAs and the CGA hash agility are analyzed in the update of the CGA = specification [rfc4982]", yet it goes on with explaining what is the purpos= e of a CGA etc. If RFC4982 has done the analysis already, simply cite it, a= nd state the result, e.g. "impacts of collision attacks on current uses of = CGAs and the CGA hash agility are analyzed in the update of the CGA specifi= cation [rfc4982] which concludes that no current hash vulnerability impacts= the security properties afforded by the use of CGAs". - Section 3.2 similarly goes on musing on attacks against X.509 certificate= s. Again, I'd rather have the section refer to an analysis of the vulnerabi= lities introduced by the use of hashes by X.509 certificates, and simply st= ate the conclusion of the analysis in this document. If no proper analysis = has been done, then it could be done in this document, but this section as = is doesn't seem to do that in an appropriate way. - Section 3.3. has a similar problem as above. It muses on non-repudiation = etc. but does not say what I'm interested in. If security of SEND does not = rely on non-repudiation property of the signature, state it and explain why= . I am not interested in how to attack the non-repudiation property of a si= gnature using a hash vulnerability, I am interested in how can (or can't) I= attack SEND using a non-repudiation vulnerability... Editorial: the use of the English language could be improved. --julien From phoffman@imc.org Wed Mar 10 10:55:07 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 343AF3A698A; Wed, 10 Mar 2010 10:55:07 -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 Ya-r4UiSjstx; Wed, 10 Mar 2010 10:55:05 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 1D3583A6978; Wed, 10 Mar 2010 10:54:38 -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 o2AIsfqW067089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Mar 2010 11:54:42 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 10 Mar 2010 10:54:39 -0800 To: "secdir@ietf.org" , "draft-ietf-csi-hash-threat@tools.ietf.org" , "iesg@ietf.org" , "csi-chairs@tools.ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [secdir] SecDir review of draft-ietf-csi-hash-threat-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: Wed, 10 Mar 2010 18:55:07 -0000 At 9:23 AM -0800 3/10/10, Laganier, Julien wrote: >- Section 3 explains what is a first-preimage attack, a second preimage attack, a collision attacks, etc. I do no think this document is the right place to do this. A simple reference to the definition of the attacks could be added if necessary, e.g. "For a definition of the various attacks against hash function properties, see [HAC] [...] [HAC] Handbook of Applied Cryptography, Alfred J. Menezes et al., 2001, http://www.cacr.math.uwaterloo.ca/hac/" Or just shorten it to a two-sentence reference to RFC 4270, which is repeatedly referred to in this section. >- Section 3.1. explains that the "impacts of collision attacks on current uses of CGAs and the CGA hash agility are analyzed in the update of the CGA specification [rfc4982]", yet it goes on with explaining what is the purpose of a CGA etc. If RFC4982 has done the analysis already, simply cite it, and state the result, e.g. "impacts of collision attacks on current uses of CGAs and the CGA hash agility are analyzed in the update of the CGA specification [rfc4982] which concludes that no current hash vulnerability impacts the security properties afforded by the use of CGAs". Quite right. >- Section 3.2 similarly goes on musing on attacks against X.509 certificates. Again, I'd rather have the section refer to an analysis of the vulnerabilities introduced by the use of hashes by X.509 certificates, and simply state the conclusion of the analysis in this document. If no proper analysis has been done, then it could be done in this document, but this section as is doesn't seem to do that in an appropriate way. Fully agree. The quality of collision-based attacks on PKIX certificates continues to improve every few years. Arjen Lenstra and Benne de Weger have no problem finding grad students (and even undergraduates) who want to make their name in this area, often with success. >- Section 3.3. has a similar problem as above. It muses on non-repudiation etc. but does not say what I'm interested in. If security of SEND does not rely on non-repudiation property of the signature, state it and explain why. I am not interested in how to attack the non-repudiation property of a signature using a hash vulnerability, I am interested in how can (or can't) I attack SEND using a non-repudiation vulnerability... Non-repudiation is one of the best-known ratholes in the PKIX space. I apologize for not reading this document sooner, but it is really a mess and should not be published even as an Informational RFC. In addition to the problems listed above, the document is also riddled with factual problems: - It says that it "analyzes the hash usage in SEND following the recommended approach [rfc4270] [new-hashes]" but does not deal with the methods in [new-hashes] (which has an under-specified reference) at all. - It says that RFC 4270 says many things that absolutely are not in RFC 4270. - It says that there have been SHA-1 collisions, which are still likely but still completely theoretical. - There are numerous context-free statements like "The strength of Internet protocol does not have to be necessarily affected by the weakness of the underlaying hash function". - The CGA-specific discussion of if preimage attacks were feasible ignores the fact that CGA is the least of anyone's worries if preimage attacks were feasible: there would be a systemwide security meltdown, of which CGA would be a tiny whiff. Please strongly consider killing off this document, given that RFCs 4270 and 4982 already cover the material completely. If RFC 4982 does not cover every aspect relevant to SEND, a two-paragraph update to RC 4982 would be much better than this document. From jhutz@cmu.edu Wed Mar 10 13:46: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 469DC3A6A2E for ; Wed, 10 Mar 2010 13:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 6nqmVgRlG8TE for ; Wed, 10 Mar 2010 13:46:40 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 3FEFA3A697B for ; Wed, 10 Mar 2010 13:46:40 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o2ALkfxm005018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Mar 2010 16:46:42 -0500 (EST) Date: Wed, 10 Mar 2010 16:32:54 -0500 From: Jeffrey Hutzelman To: secdir@ietf.org Message-ID: In-Reply-To: <22431_1267836161_o260gexf032659_alpine.BSF.2.00.1003051940330.69134@fledge.watson.org> References: <22431_1267836161_o260gexf032659_alpine.BSF.2.00.1003051940330.69134@fledge.watson.org> 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.198 Subject: Re: [secdir] Assignments 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 Mar 2010 21:46:41 -0000 --On Friday, March 05, 2010 07:42:37 PM -0500 Samuel Weiler wrote: > Jeffrey Hutzelman T 2010-03-09 > draft-ietf-autoconf-adhoc-addr-model-02 I didn't find anything particularly wrong with this document, but I had a hard time understanding whether it actually _did_ anything, rather than simply recommending some considerations for future work. Maybe someone more familiar with autoconf and/or routing wants to take a look at this? -- Jeff From weiler@watson.org Wed Mar 10 13:48: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 6FF403A6BD9 for ; Wed, 10 Mar 2010 13:48: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=[AWL=0.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 vGf2-FYlp3gx for ; Wed, 10 Mar 2010 13:48:23 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 764573A6A0C for ; Wed, 10 Mar 2010 13:48:23 -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 o2ALmRG7044365 for ; Wed, 10 Mar 2010 16:48:27 -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 o2ALmRSm044362 for ; Wed, 10 Mar 2010 16:48:27 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 10 Mar 2010 16:48:27 -0500 (EST) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 10 Mar 2010 16:48:27 -0500 (EST) Subject: Re: [secdir] draft-ietf-autoconf-adhoc-addr-model-02 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: Wed, 10 Mar 2010 21:48:24 -0000 Resending with the search-friendly subject line... ---------- Forwarded message ---------- Date: Wed, 10 Mar 2010 16:32:54 -0500 From: Jeffrey Hutzelman To: secdir@ietf.org Subject: Re: [secdir] Assignments --On Friday, March 05, 2010 07:42:37 PM -0500 Samuel Weiler wrote: > Jeffrey Hutzelman T 2010-03-09 > draft-ietf-autoconf-adhoc-addr-model-02 I didn't find anything particularly wrong with this document, but I had a hard time understanding whether it actually _did_ anything, rather than simply recommending some considerations for future work. Maybe someone more familiar with autoconf and/or routing wants to take a look at this? -- Jeff _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir From suresh.krishnan@ericsson.com Wed Mar 10 21:29:51 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 325E93A6ABB; Wed, 10 Mar 2010 21:29:51 -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 MCgHLK9GA21F; Wed, 10 Mar 2010 21:29:50 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id E25DB3A6816; Wed, 10 Mar 2010 21:29:49 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o2B5Wfmv023207; Wed, 10 Mar 2010 23:32:41 -0600 Received: from [142.133.10.113] (147.117.20.213) by eusaamw0712.eamcs.ericsson.se (147.117.20.182) with Microsoft SMTP Server id 8.1.375.2; Thu, 11 Mar 2010 00:29:53 -0500 Message-ID: <4B987ECD.4040305@ericsson.com> Date: Thu, 11 Mar 2010 00:25:33 -0500 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Cc: "csi-chairs@tools.ietf.org" , "draft-ietf-csi-hash-threat@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-csi-hash-threat-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: Thu, 11 Mar 2010 05:29:51 -0000 Hi Julien/Paul, I agree with the points you have made regarding the gratuitous (and sometimes overreaching) text. That said, I think there is value in continuing with the document. The document needs to still talk about the following threats to SEND * Threats due to the hash algorithm used for the SEND router certificates. * Threats due to the hash algorithm used for the digital signature in the RSA signature option used in SEND. * Threats due to the hash algorithm used for the creating the hash of the public key in the RSA signature option. There is no other document that talks about these threats and how likely they are to occur in practice. We will make another editorial pass to remove test that is duplicated from the references and clean out some excessive text. Thanks Suresh On 10-03-10 01:54 PM, Paul Hoffman wrote: > At 9:23 AM -0800 3/10/10, Laganier, Julien wrote: >> - Section 3 explains what is a first-preimage attack, a second preimage attack, a collision attacks, etc. I do no think this document is the right place to do this. A simple reference to the definition of the attacks could be added if necessary, e.g. "For a definition of the various attacks against hash function properties, see [HAC] [...] [HAC] Handbook of Applied Cryptography, Alfred J. Menezes et al., 2001, http://www.cacr.math.uwaterloo.ca/hac/" > > Or just shorten it to a two-sentence reference to RFC 4270, which is repeatedly referred to in this section. > >> - Section 3.1. explains that the "impacts of collision attacks on current uses of CGAs and the CGA hash agility are analyzed in the update of the CGA specification [rfc4982]", yet it goes on with explaining what is the purpose of a CGA etc. If RFC4982 has done the analysis already, simply cite it, and state the result, e.g. "impacts of collision attacks on current uses of CGAs and the CGA hash agility are analyzed in the update of the CGA specification [rfc4982] which concludes that no current hash vulnerability impacts the security properties afforded by the use of CGAs". > > Quite right. > >> - Section 3.2 similarly goes on musing on attacks against X.509 certificates. Again, I'd rather have the section refer to an analysis of the vulnerabilities introduced by the use of hashes by X.509 certificates, and simply state the conclusion of the analysis in this document. If no proper analysis has been done, then it could be done in this document, but this section as is doesn't seem to do that in an appropriate way. > > Fully agree. The quality of collision-based attacks on PKIX certificates continues to improve every few years. Arjen Lenstra and Benne de Weger have no problem finding grad students (and even undergraduates) who want to make their name in this area, often with success. > >> - Section 3.3. has a similar problem as above. It muses on non-repudiation etc. but does not say what I'm interested in. If security of SEND does not rely on non-repudiation property of the signature, state it and explain why. I am not interested in how to attack the non-repudiation property of a signature using a hash vulnerability, I am interested in how can (or can't) I attack SEND using a non-repudiation vulnerability... > > Non-repudiation is one of the best-known ratholes in the PKIX space. > > I apologize for not reading this document sooner, but it is really a mess and should not be published even as an Informational RFC. In addition to the problems listed above, the document is also riddled with factual problems: > > - It says that it "analyzes the hash usage in SEND following the recommended approach [rfc4270] [new-hashes]" but does not deal with the methods in [new-hashes] (which has an under-specified reference) at all. > > - It says that RFC 4270 says many things that absolutely are not in RFC 4270. > > - It says that there have been SHA-1 collisions, which are still likely but still completely theoretical. > > - There are numerous context-free statements like "The strength of Internet protocol does not have to be necessarily affected by the weakness of the underlaying hash function". > > - The CGA-specific discussion of if preimage attacks were feasible ignores the fact that CGA is the least of anyone's worries if preimage attacks were feasible: there would be a systemwide security meltdown, of which CGA would be a tiny whiff. > > Please strongly consider killing off this document, given that RFCs 4270 and 4982 already cover the material completely. If RFC 4982 does not cover every aspect relevant to SEND, a two-paragraph update to RC 4982 would be much better than this document. > From yaronf@checkpoint.com Thu Mar 11 06:47: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 5E0DC3A690F for ; Thu, 11 Mar 2010 06:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 3HFv9s277o+G for ; Thu, 11 Mar 2010 06:47:11 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 77F6F3A6BB8 for ; Thu, 11 Mar 2010 06:47:04 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2BEl8sd007062; Thu, 11 Mar 2010 16:47:08 +0200 (IST) X-CheckPoint: {4B9900D1-0-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 11 Mar 2010 16:47:29 +0200 From: Yaron Sheffer To: "secdir@ietf.org" , "draft-ietf-ipfix-mediators-problem-statement.all@ietf.org" Date: Thu, 11 Mar 2010 16:47:28 +0200 Thread-Topic: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08 Thread-Index: AQHKwSnFhimeoX26UUOjJSTKNbzCAA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C897@il-ex01.ad.checkpoint.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 Subject: [secdir] SecDir review of draft-ietf-ipfix-mediators-problem-statement-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: Thu, 11 Mar 2010 14:47:12 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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 presents the need for introducing Mediators (known in other q= uarters as "proxies") into the IPFIX architecture. The document is in general well written, and it does attempt to cover most = of the relevant security issues. But I would have liked to see a bit more d= iscussion on: - Privacy concerns, especially where actual data packets are sampled. These= concerns may be amplified when streams from multiple sources are combined. - Multi-tenancy: large networks, i.e. those that require such solutions, ma= y process and sometime aggregate data from many different owners. An extrem= e example is virtualized processing clouds. Tenants should be protected fro= m one another, and possibly also from the service provider. - The subsection of the Security Considerations that discusses confidential= ity protection could be improved to more clearly point out that transport-l= evel security is no longer sufficient in this architecture, and (at least i= n some cases) should be replaced by end-to-end, application-level security. - The trust model should be clarified, possibly just to say "we all trust t= he Mediator". Non-security comments The document starts out by discussing IPFIX, and then suddenly in 3.2, PSAM= P is introduced. The clueless reader is left confused: how does PSAMP relat= e to per-flow information? I'd appreciate a clarifying paragraph at the top= of Sec. 3.= From yaronf@checkpoint.com Thu Mar 11 06:53: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 AC3793A6BD4 for ; Thu, 11 Mar 2010 06:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 eMJaxrEm0i49 for ; Thu, 11 Mar 2010 06:53:25 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id CC3C03A6922 for ; Thu, 11 Mar 2010 06:51:55 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2BEq0sd007998; Thu, 11 Mar 2010 16:52:00 +0200 (IST) X-CheckPoint: {4B9901F5-1-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 11 Mar 2010 16:52:21 +0200 From: Yaron Sheffer To: "secdir@ietf.org" , "draft-ietf-ipfix-mediators-problem-statement.all@tools.ietf.org" Date: Thu, 11 Mar 2010 16:50:58 +0200 Thread-Topic: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08 Thread-Index: AQHKwSnFhimeoX26UUOjJSTKNbzCAJHs0jFZ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C898@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C897@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C897@il-ex01.ad.checkpoint.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 Subject: Re: [secdir] SecDir review of draft-ietf-ipfix-mediators-problem-statement-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: Thu, 11 Mar 2010 14:53:26 -0000 Resending, sorry if you see it twice... ________________________________________ From: Yaron Sheffer Sent: Thursday, March 11, 2010 4:47 PM To: secdir@ietf.org; draft-ietf-ipfix-mediators-problem-statement.all@ietf.= org Subject: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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 presents the need for introducing Mediators (known in other q= uarters as "proxies") into the IPFIX architecture. The document is in general well written, and it does attempt to cover most = of the relevant security issues. But I would have liked to see a bit more d= iscussion on: - Privacy concerns, especially where actual data packets are sampled. These= concerns may be amplified when streams from multiple sources are combined. - Multi-tenancy: large networks, i.e. those that require such solutions, ma= y process and sometime aggregate data from many different owners. An extrem= e example is virtualized processing clouds. Tenants should be protected fro= m one another, and possibly also from the service provider. - The subsection of the Security Considerations that discusses confidential= ity protection could be improved to more clearly point out that transport-l= evel security is no longer sufficient in this architecture, and (at least i= n some cases) should be replaced by end-to-end, application-level security. - The trust model should be clarified, possibly just to say "we all trust t= he Mediator". Non-security comments The document starts out by discussing IPFIX, and then suddenly in 3.2, PSAM= P is introduced. The clueless reader is left confused: how does PSAMP relat= e to per-flow information? I'd appreciate a clarifying paragraph at the top= of Sec. 3.= From weiler@watson.org Fri Mar 12 11:06:05 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 0797B3A691E for ; Fri, 12 Mar 2010 11:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] 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 YcRAeuxlnhVA for ; Fri, 12 Mar 2010 11:06:04 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 773BD3A6848 for ; Fri, 12 Mar 2010 11:05:55 -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 o2CJ60HV094164 for ; Fri, 12 Mar 2010 14:06:00 -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 o2CJ60vm094161 for ; Fri, 12 Mar 2010 14:06:00 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 12 Mar 2010 14:06:00 -0500 (EST) From: Samuel Weiler 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, 12 Mar 2010 14:06:00 -0500 (EST) Subject: [secdir] New assignments deferred 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, 12 Mar 2010 19:06:05 -0000 With the next IESG telechat not scheduled 'til April 8th, I'm going to take the liberty of deferring this week's new assignments for a few days. As a reminder, we're near the top of the rotation (Rob Austein) and have seven new last calls, so if your last name begins with a B, C, D, or E (that includes you, Pasi!), expect something new soon. -- Sam From Dmitry.Anipko@microsoft.com Fri Mar 12 12:55: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 EABEB3A67E9; Fri, 12 Mar 2010 12:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 0Sy1OdX0dPvJ; Fri, 12 Mar 2010 12:55:16 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 107E43A687D; Fri, 12 Mar 2010 12:55:16 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 12 Mar 2010 12:55:21 -0800 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.0.639.21; Fri, 12 Mar 2010 12:55:08 -0800 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Fri, 12 Mar 2010 12:54:25 -0800 From: Dmitry Anipko To: "Templin, Fred L" , Gabi Nakibly , v6ops Date: Fri, 12 Mar 2010 12:54:23 -0800 Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcooErw/GQXNMWvASRqGPthARajqOQACrWeAJoHrlyA= Message-ID: References: <475898.88672.qm@web45510.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com> <212591.98462.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B3D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106555B3D@XCH-NW-7V2.nw.nos.boeing.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: Fri, 12 Mar 2010 13:11:16 -0800 Cc: "ipv6@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels 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, 12 Mar 2010 20:55:17 -0000 Hello, I wanted to follow up on Fred's comment earlier in this thread: >> OK. That will greatly simplify the checks needed for new automatic tunneling protocols that have a format other than ip-proto-41. For the designers of new tunneling protocols, shall perhaps a recommendatio= n on best practices be included into the draft or another document, that fo= r the new tunnels a different protocol value / format should be used? Examples of such protocol / formats could include using a different next-pr= otocol value, potentially with some multiplexing schema if just using diffe= rent next-protocol values is not scalable, or possibly some other format. Thank you, Dmitry -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Tem= plin, Fred L Sent: Friday, August 28, 2009 1:25 PM To: Gabi Nakibly; v6ops Cc: ipv6@ietf.org; secdir@ietf.org Subject: RE: Routing loop attacks using IPv6 tunnels Gabi, > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Friday, August 28, 2009 12:07 PM > To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels > > Correct. All the attacks rely on the fact that the ISATAP router encapsulates/decapsulates a packet > the 6to4 relay decapsulates/encapsulates, respectively. So the two tunnels must have the same > encapsulation type. OK. That will greatly simplify the checks needed for new automatic tunneling protocols that have a format other than ip-proto-41. Fred fred.l.templin@boeing.com > ----- Original Message ---- > > From: "Templin, Fred L" > > To: Gabi Nakibly ; v6ops > > Cc: ipv6@ietf.org; secdir@ietf.org > > Sent: Friday, August 28, 2009 7:23:03 PM > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > Gabi, > > > > Correct me if I am wrong, but if there were a new version > > of ISATAP that did not use ip-proto-41 encapsulation but > > instead used a different kind of encapsulation, then it > > need not concern itself with routing loop interactions > > with 6to4 relays since 6to4 relays only know about > > ip-proto-41. Does that match your understanding? > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From Fred.L.Templin@boeing.com Fri Mar 12 13:13:07 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 5EE4C3A691A; Fri, 12 Mar 2010 13:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.268 X-Spam-Level: X-Spam-Status: No, score=-6.268 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 dB1kViD9-IFR; Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 0F6A93A6901; Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2CLD6hc006414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2CLD6G2009102; Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2CLD6PB009097 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Fri, 12 Mar 2010 13:13:06 -0800 From: "Templin, Fred L" To: Dmitry Anipko , Gabi Nakibly , v6ops Date: Fri, 12 Mar 2010 13:13:05 -0800 Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcooErw/GQXNMWvASRqGPthARajqOQACrWeAJoHrlyAAALQzQA== Message-ID: References: <475898.88672.qm@web45510.mail.sp1.yahoo.com><39C363776A4E8C4A94 691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D 2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9 D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com><212591.98462.qm@web45502.mail. sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106555B3D@XCH-NW-7V2.nw.nos.boeing.com> 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 Cc: "ipv6@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels 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, 12 Mar 2010 21:13:07 -0000 Hi Dmitry, > -----Original Message----- > From: Dmitry Anipko [mailto:Dmitry.Anipko@microsoft.com] > Sent: Friday, March 12, 2010 12:54 PM > To: Templin, Fred L; Gabi Nakibly; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: RE: Routing loop attacks using IPv6 tunnels >=20 > Hello, >=20 > I wanted to follow up on Fred's comment earlier in this thread: >=20 > >> OK. That will greatly simplify the checks needed for new > automatic tunneling protocols that have a format other > than ip-proto-41. >=20 > For the designers of new tunneling protocols, shall perhaps a recommendat= ion on best practices be > included into the draft or another document, that for the new tunnels a d= ifferent protocol value / > format should be used? Are you are referring here to 'draft-nakibly-v6ops-tunnel-loop-01'? If so, IMHO this document would be the natural location for such a recommendation.=20 > Examples of such protocol / formats could include using a different next-= protocol value, potentially > with some multiplexing schema if just using different next-protocol value= s is not scalable, or > possibly some other format. Yes, I think it would be very good to declare ip-proto-41 as fully-developed and recommend that new tunneling protocols use a different ip protocol number and/or TCP/UDP port number. This would greatly reduce the concern for having to go back and revisit tunneling implementations that perform src/dst checks if a new tunneling protocol happens to emerge. Gabi - do you have any thoughts on this? Thanks - Fred fred.l.templin@boeing.com > Thank you, > Dmitry >=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of T= emplin, Fred L > Sent: Friday, August 28, 2009 1:25 PM > To: Gabi Nakibly; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: RE: Routing loop attacks using IPv6 tunnels >=20 > Gabi, >=20 > > -----Original Message----- > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > Sent: Friday, August 28, 2009 12:07 PM > > To: Templin, Fred L; v6ops > > Cc: ipv6@ietf.org; secdir@ietf.org > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > Correct. All the attacks rely on the fact that the ISATAP router > encapsulates/decapsulates a packet > > the 6to4 relay decapsulates/encapsulates, respectively. So the two > tunnels must have the same > > encapsulation type. >=20 > OK. That will greatly simplify the checks needed for new > automatic tunneling protocols that have a format other > than ip-proto-41. >=20 > Fred > fred.l.templin@boeing.com >=20 > > ----- Original Message ---- > > > From: "Templin, Fred L" > > > To: Gabi Nakibly ; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Sent: Friday, August 28, 2009 7:23:03 PM > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > Gabi, > > > > > > Correct me if I am wrong, but if there were a new version > > > of ISATAP that did not use ip-proto-41 encapsulation but > > > instead used a different kind of encapsulation, then it > > > need not concern itself with routing loop interactions > > > with 6to4 relays since 6to4 relays only know about > > > ip-proto-41. Does that match your understanding? > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fred.l.templin@boeing.com Fri Mar 12 15:18: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 ED6C43A6810; Fri, 12 Mar 2010 15:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.16 X-Spam-Level: X-Spam-Status: No, score=-7.16 tagged_above=-999 required=5 tests=[AWL=0.703, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, 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 09vtnzWjYbEs; Fri, 12 Mar 2010 15:18:16 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 51E8B3A6806; Fri, 12 Mar 2010 15:17:43 -0800 (PST) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74212483; Fri, 12 Mar 2010 18:17:44 -0500 Received: from NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 18:03:45 -0500 Received: from mail pickup service by NJCHLEXCMB01.cable.comcast.com with Microsoft SMTPSVC; Fri, 12 Mar 2010 18:03:43 -0500 Received: from PAOAKEXCSMTP01.cable.comcast.com ([10.52.116.30]) by NJCHLEXCMB01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 16:13:52 -0500 Received: from PACDCEXCSMTP03.cable.comcast.com ([24.40.15.92]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 16:13:29 -0500 Received: from cable.comcast.com ([24.40.8.136]) by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 16:13:29 -0500 Received: from ([24.40.8.143]) by pacdcimi02.cable.comcast.com with ESMTP id 5503616.86917225; Fri, 12 Mar 2010 16:13:23 -0500 Received: from ([64.170.98.32]) by pacdcedge01.cable.comcast.com with ESMTP id 5302275.EDGE; Fri, 12 Mar 2010 16:13:23 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1753A695B; Fri, 12 Mar 2010 13:13:09 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EE4C3A691A; Fri, 12 Mar 2010 13:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 dB1kViD9-IFR; Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 0F6A93A6901; Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o2CLD6hc006414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o2CLD6G2009102; Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o2CLD6PB009097 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 12 Mar 2010 13:13:06 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Fri, 12 Mar 2010 13:13:06 -0800 From: "Templin, Fred L" To: Dmitry Anipko , Gabi Nakibly , v6ops Date: Fri, 12 Mar 2010 13:13:05 -0800 Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcooErw/GQXNMWvASRqGPthARajqOQACrWeAJoHrlyAAALQzQA== Message-ID: References: <475898.88672.qm@web45510.mail.sp1.yahoo.com><39C363776A4E8C4A94 691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D 2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9 D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com><212591.98462.qm@web45502.mail. sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106555B3D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-esp: ESP<-40>= SHA:<0> UHA:<9> ISC:<0> BAYES:<0> SenderID:<0> DKIM:<0> TS:<-49> SIG: DSC:<0> TRU_scam_spam: <0> TRU_urllinks: <0> TRU_playsites: <0> TRU_spam2: <0> TRU_ru_spamsubj: <0> TRU_embedded_image_spam: <0> TRU_profanity_spam: <0> TRU_legal_spam: <0> TRU_stock_spam: <0> TRU_watch_spam: <0> TRU_money_spam: <0> URL Real-Time Signatures: <0> TRU_marketing_spam: <0> TRU_phish_spam: <0> TRU_lotto_spam: <0> TRU_medical_spam: <0> TRU_html_image_spam: <0> TRU_freehosting: <0> TRU_adult_spam: <0> TRU_misc_spam: <0> TRU_spam1: <0> X-OriginalArrivalTime: 12 Mar 2010 21:13:29.0352 (UTC) FILETIME=[DCDE5880:01CAC228] Cc: "ipv6@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels 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 Mar 2010 23:18:18 -0000 Hi Dmitry, > -----Original Message----- > From: Dmitry Anipko [mailto:Dmitry.Anipko@microsoft.com] > Sent: Friday, March 12, 2010 12:54 PM > To: Templin, Fred L; Gabi Nakibly; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: RE: Routing loop attacks using IPv6 tunnels > > Hello, > > I wanted to follow up on Fred's comment earlier in this thread: > > >> OK. That will greatly simplify the checks needed for new > automatic tunneling protocols that have a format other > than ip-proto-41. > > For the designers of new tunneling protocols, shall perhaps a recommendation on best practices be > included into the draft or another document, that for the new tunnels a different protocol value / > format should be used? Are you are referring here to 'draft-nakibly-v6ops-tunnel-loop-01'? If so, IMHO this document would be the natural location for such a recommendation. > Examples of such protocol / formats could include using a different next-protocol value, potentially > with some multiplexing schema if just using different next-protocol values is not scalable, or > possibly some other format. Yes, I think it would be very good to declare ip-proto-41 as fully-developed and recommend that new tunneling protocols use a different ip protocol number and/or TCP/UDP port number. This would greatly reduce the concern for having to go back and revisit tunneling implementations that perform src/dst checks if a new tunneling protocol happens to emerge. Gabi - do you have any thoughts on this? Thanks - Fred fred.l.templin@boeing.com > Thank you, > Dmitry > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, Fred L > Sent: Friday, August 28, 2009 1:25 PM > To: Gabi Nakibly; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: RE: Routing loop attacks using IPv6 tunnels > > Gabi, > > > -----Original Message----- > > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > > Sent: Friday, August 28, 2009 12:07 PM > > To: Templin, Fred L; v6ops > > Cc: ipv6@ietf.org; secdir@ietf.org > > Subject: Re: Routing loop attacks using IPv6 tunnels > > > > Correct. All the attacks rely on the fact that the ISATAP router > encapsulates/decapsulates a packet > > the 6to4 relay decapsulates/encapsulates, respectively. So the two > tunnels must have the same > > encapsulation type. > > OK. That will greatly simplify the checks needed for new > automatic tunneling protocols that have a format other > than ip-proto-41. > > Fred > fred.l.templin@boeing.com > > > ----- Original Message ---- > > > From: "Templin, Fred L" > > > To: Gabi Nakibly ; v6ops > > > Cc: ipv6@ietf.org; secdir@ietf.org > > > Sent: Friday, August 28, 2009 7:23:03 PM > > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > > > Gabi, > > > > > > Correct me if I am wrong, but if there were a new version > > > of ISATAP that did not use ip-proto-41 encapsulation but > > > instead used a different kind of encapsulation, then it > > > need not concern itself with routing loop interactions > > > with 6to4 relays since 6to4 relays only know about > > > ip-proto-41. Does that match your understanding? > > > > > > Thanks - Fred > > > fred.l.templin@boeing.com > > > > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From Dmitry.Anipko@microsoft.com Fri Mar 12 13:16: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 265843A6995; Fri, 12 Mar 2010 13:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 WiG+KRsApp3P; Fri, 12 Mar 2010 13:16:18 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 18D4C3A698E; Fri, 12 Mar 2010 13:16:18 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 12 Mar 2010 13:16:24 -0800 Received: from tk5-exmlt-s702.segroup.winse.corp.microsoft.com (157.54.90.70) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.0.639.21; Fri, 12 Mar 2010 13:16:17 -0800 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s702.segroup.winse.corp.microsoft.com ([157.54.90.70]) with mapi; Fri, 12 Mar 2010 13:16:18 -0800 From: Dmitry Anipko To: "Templin, Fred L" , Gabi Nakibly , v6ops Date: Fri, 12 Mar 2010 13:16:16 -0800 Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcooErw/GQXNMWvASRqGPthARajqOQACrWeAJoHrlyAAALQzQAAASWTQ Message-ID: References: <475898.88672.qm@web45510.mail.sp1.yahoo.com><39C363776A4E8C4A94 691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D 2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9 D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com><212591.98462.qm@web45502.mail. sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106555B3D@XCH-NW-7V2.nw.nos.boeing.com> 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-Mailman-Approved-At: Mon, 15 Mar 2010 01:27:33 -0700 Cc: "ipv6@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels 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, 12 Mar 2010 21:16:22 -0000 Hi Fred, >> Are you are referring here to 'draft-nakibly-v6ops-tunnel-loop-01'? Yes, that's correct. Thank you, Dmitry -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Tem= plin, Fred L Sent: Friday, March 12, 2010 1:13 PM To: Dmitry Anipko; Gabi Nakibly; v6ops Cc: ipv6@ietf.org; secdir@ietf.org Subject: RE: Routing loop attacks using IPv6 tunnels Hi Dmitry, > -----Original Message----- > From: Dmitry Anipko [mailto:Dmitry.Anipko@microsoft.com] > Sent: Friday, March 12, 2010 12:54 PM > To: Templin, Fred L; Gabi Nakibly; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: RE: Routing loop attacks using IPv6 tunnels > > Hello, > > I wanted to follow up on Fred's comment earlier in this thread: > > >> OK. That will greatly simplify the checks needed for new > automatic tunneling protocols that have a format other > than ip-proto-41. > > For the designers of new tunneling protocols, shall perhaps a recommendat= ion on best practices be > included into the draft or another document, that for the new tunnels a d= ifferent protocol value / > format should be used? Are you are referring here to 'draft-nakibly-v6ops-tunnel-loop-01'? If so, IMHO this document would be the natural location for such a recommendation. > Examples of such protocol / formats could include using a different next-= protocol value, potentially > with some multiplexing schema if just using different next-protocol value= s is not scalable, or > possibly some other format. Yes, I think it would be very good to declare ip-proto-41 as fully-developed and recommend that new tunneling protocols use a different ip protocol number and/or TCP/UDP port number. This would greatly reduce the concern for having to go back and revisit tunneling implementations that perform src/dst checks if a new tunneling protocol happens to emerge. Gabi - do you have any thoughts on this? Thanks - Fred fred.l.templin@boeing.com From dmitry.anipko@microsoft.com Fri Mar 12 15:21:27 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 4F04B3A67FC; Fri, 12 Mar 2010 15:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.931 X-Spam-Level: X-Spam-Status: No, score=-8.931 tagged_above=-999 required=5 tests=[AWL=-1.068, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, 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 0dPzZjJEh3ua; Fri, 12 Mar 2010 15:21:23 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 1D10A3A683E; Fri, 12 Mar 2010 15:21:12 -0800 (PST) Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.74212660; Fri, 12 Mar 2010 18:21:15 -0500 Received: from NJCHLEXCMB01.cable.comcast.com ([172.24.2.44]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 18:10:18 -0500 Received: from mail pickup service by NJCHLEXCMB01.cable.comcast.com with Microsoft SMTPSVC; Fri, 12 Mar 2010 18:10:01 -0500 Received: from PACDCEXCSMTP04.cable.comcast.com ([24.40.15.118]) by NJCHLEXCMB01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 16:54:47 -0500 Received: from PACDCEXCSMTP04.cable.comcast.com ([24.40.15.118]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 15:55:39 -0500 Received: from cable.comcast.com ([24.40.8.136]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Mar 2010 15:55:39 -0500 Received: from ([24.40.8.143]) by pacdcimi02.cable.comcast.com with ESMTP id 5503616.86914423; Fri, 12 Mar 2010 15:55:36 -0500 Received: from ([64.170.98.32]) by pacdcedge01.cable.comcast.com with ESMTP id 5302275.EDGE; Fri, 12 Mar 2010 15:55:35 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC1A43A68F9; Fri, 12 Mar 2010 12:55:18 -0800 (PST) X-Original-To: ipv6@core3.amsl.com Delivered-To: ipv6@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EABEB3A67E9; Fri, 12 Mar 2010 12:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 0Sy1OdX0dPvJ; Fri, 12 Mar 2010 12:55:16 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 107E43A687D; Fri, 12 Mar 2010 12:55:16 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 12 Mar 2010 12:55:21 -0800 Received: from tk5-exmlt-s701.segroup.winse.corp.microsoft.com (157.54.90.63) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.0.639.21; Fri, 12 Mar 2010 12:55:08 -0800 Received: from NA-EXMSG-S702.segroup.winse.corp.microsoft.com ([157.54.98.200]) by tk5-exmlt-s701.segroup.winse.corp.microsoft.com ([157.54.90.63]) with mapi; Fri, 12 Mar 2010 12:54:25 -0800 From: Dmitry Anipko To: "Templin, Fred L" , Gabi Nakibly , v6ops Date: Fri, 12 Mar 2010 12:54:23 -0800 Thread-Topic: Routing loop attacks using IPv6 tunnels Thread-Index: AcooErw/GQXNMWvASRqGPthARajqOQACrWeAJoHrlyA= Message-ID: References: <475898.88672.qm@web45510.mail.sp1.yahoo.com><39C363776A4E8C4A94691D2BD9D1C9A106514554@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1065145AE@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A106555996@XCH-NW-7V2.nw.nos.boeing.com> <212591.98462.qm@web45502.mail.sp1.yahoo.com> <39C363776A4E8C4A94691D2BD9D1C9A106555B3D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A106555B3D@XCH-NW-7V2.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipv6-bounces@ietf.org Errors-To: ipv6-bounces@ietf.org X-esp: ESP<-40>= SHA:<0> UHA:<9> ISC:<0> BAYES:<0> SenderID:<0> DKIM:<0> TS:<-49> SIG: DSC:<0> TRU_scam_spam: <0> TRU_urllinks: <0> TRU_playsites: <0> TRU_spam2: <0> TRU_ru_spamsubj: <0> TRU_embedded_image_spam: <0> TRU_profanity_spam: <0> TRU_legal_spam: <0> TRU_stock_spam: <0> TRU_watch_spam: <0> TRU_money_spam: <0> URL Real-Time Signatures: <0> TRU_marketing_spam: <0> TRU_phish_spam: <0> TRU_lotto_spam: <0> TRU_medical_spam: <0> TRU_html_image_spam: <0> TRU_freehosting: <0> TRU_adult_spam: <0> TRU_misc_spam: <0> TRU_spam1: <0> X-OriginalArrivalTime: 12 Mar 2010 20:55:39.0577 (UTC) FILETIME=[5F3BA290:01CAC226] X-Mailman-Approved-At: Mon, 15 Mar 2010 01:27:33 -0700 Cc: "ipv6@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Routing loop attacks using IPv6 tunnels 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 Mar 2010 23:21:27 -0000 Hello, I wanted to follow up on Fred's comment earlier in this thread: >> OK. That will greatly simplify the checks needed for new automatic tunneling protocols that have a format other than ip-proto-41. For the designers of new tunneling protocols, shall perhaps a recommendation on best practices be included into the draft or another document, that for the new tunnels a different protocol value / format should be used? Examples of such protocol / formats could include using a different next-protocol value, potentially with some multiplexing schema if just using different next-protocol values is not scalable, or possibly some other format. Thank you, Dmitry -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Friday, August 28, 2009 1:25 PM To: Gabi Nakibly; v6ops Cc: ipv6@ietf.org; secdir@ietf.org Subject: RE: Routing loop attacks using IPv6 tunnels Gabi, > -----Original Message----- > From: Gabi Nakibly [mailto:gnakibly@yahoo.com] > Sent: Friday, August 28, 2009 12:07 PM > To: Templin, Fred L; v6ops > Cc: ipv6@ietf.org; secdir@ietf.org > Subject: Re: Routing loop attacks using IPv6 tunnels > > Correct. All the attacks rely on the fact that the ISATAP router encapsulates/decapsulates a packet > the 6to4 relay decapsulates/encapsulates, respectively. So the two tunnels must have the same > encapsulation type. OK. That will greatly simplify the checks needed for new automatic tunneling protocols that have a format other than ip-proto-41. Fred fred.l.templin@boeing.com > ----- Original Message ---- > > From: "Templin, Fred L" > > To: Gabi Nakibly ; v6ops > > Cc: ipv6@ietf.org; secdir@ietf.org > > Sent: Friday, August 28, 2009 7:23:03 PM > > Subject: RE: Routing loop attacks using IPv6 tunnels > > > > Gabi, > > > > Correct me if I am wrong, but if there were a new version > > of ISATAP that did not use ip-proto-41 encapsulation but > > instead used a different kind of encapsulation, then it > > need not concern itself with routing loop interactions > > with 6to4 relays since 6to4 relays only know about > > ip-proto-41. Does that match your understanding? > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From weiler+secdir@watson.org Mon Mar 15 12:37:33 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 C62513A69C8 for ; Mon, 15 Mar 2010 12:37:33 -0700 (PDT) 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_50=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 wUjMkWfy8kcl for ; Mon, 15 Mar 2010 12:37:32 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 96A033A6991 for ; Mon, 15 Mar 2010 12:37:32 -0700 (PDT) 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 o2FJbdAR032290 for ; Mon, 15 Mar 2010 15:37:39 -0400 (EDT) (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 o2FJbd6X032287 for ; Mon, 15 Mar 2010 15:37:39 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 15 Mar 2010 15:37:39 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 15 Mar 2010 15:37:39 -0400 (EDT) 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: Mon, 15 Mar 2010 19:37:33 -0000 Phillip Hallam-Baker 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-04-08 Reviewer Deadline Draft Love Hornquist-Astrand T 2010-04-06 draft-ietf-ccamp-gmpls-mef-uni-03 Chris Newman T 2010-04-06 draft-ietf-krb-wg-preauth-framework-16 Chris Newman T 2010-04-06 draft-ietf-pce-pcep-svec-list-04 For telechat 2010-04-22 Love Hornquist-Astrand T 2010-04-20 draft-ietf-opsawg-smi-datatypes-in-xsd-06 Last calls and special requests: Derek Atkins 2010-03-19 draft-turner-asymmetrickeyformat-04 Rob Austein 2010-03-29 draft-denenberg-mods-etc-media-types-01 Richard Barnes 2010-03-23 draft-ietf-behave-turn-ipv6-09 Pat Cain 2010-03-23 draft-ietf-behave-turn-tcp-06 Dave Cridland 2010-03-22 draft-ietf-isms-dtls-tm-09 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Alan DeKok 2010-03-24 draft-ietf-netmod-yang-11 Donald Eastlake 2010-03-24 draft-ietf-netmod-yang-types-07 Shawn Emery R2010-03-19 draft-ietf-manet-nhdp-11 Shawn Emery 2010-03-23 draft-ietf-nsis-ext-06 Stephen Farrell 2010-03-29 draft-ietf-sipcore-info-events-07 Tobias Gondrom 2010-03-24 draft-mattsson-mikey-ticket-02 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-07 Tina TSOU 2010-03-15 draft-ietf-ippm-twamp-session-cntrl-04 Sam Weiler 2010-03-12 draft-ietf-nsis-ntlp-statemachine-09 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Brian Weis 2010-03-15 draft-ietf-nsis-rmd-16 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Nico Williams 2010-03-20 draft-haberman-rpsl-reachable-test-03 Tom Yu 2010-03-18 draft-ietf-ipsecme-ikev2bis-08 Kurt Zeilenga 2010-03-18 draft-ietf-mmusic-rfc4756bis-06 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-05 From tena@huawei.com Mon Mar 15 19:26: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 729F03A6832; Mon, 15 Mar 2010 19:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.565 X-Spam-Level: X-Spam-Status: No, score=-100.565 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] 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 WcEPSV0lkzeS; Mon, 15 Mar 2010 19:26:53 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CB0053A67FF; Mon, 15 Mar 2010 19:26:52 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZC00CSLS4N9Q@szxga03-in.huawei.com>; Tue, 16 Mar 2010 10:26:47 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZC005BGS4NDV@szxga03-in.huawei.com>; Tue, 16 Mar 2010 10:26:47 +0800 (CST) Received: from z00147053k ([10.70.39.148]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZC00COQS4NLJ@szxml06-in.huawei.com>; Tue, 16 Mar 2010 10:26:47 +0800 (CST) Date: Tue, 16 Mar 2010 10:26:47 +0800 From: Tina TSOU To: secdir@ietf.org, draft-ietf-ippm-twamp-session-cntrl@tools.ietf.org, iesg@ietf.org Message-id: <9A90D3D3722C4A04879B3B6C57ECF65C@china.huawei.com> 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: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C897@il-ex01.ad.checkpoint.com> Subject: [secdir] SecDir review of draft-ietf-ippm-twamp-session-cntrl-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: Tue, 16 Mar 2010 02:26:54 -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. A nit: in the first paragraph of section 2, the second sentence is outdated and should be deleted. In paragraph 3 of section 4.2, given that there is no change to the TWAMP-test packet format, I assume we use the exact TWAMP-test packet format as defined RFC5357, so that the SID is not carried in the test packets. My question is that how the reflector just whether a TWAMP-test packet belongs to the same session/SID or not. Since per definition the testing message does not include SID, how to differentiate the testing message of different testing sessions after multiple testing started? This is not obvious and the text should be improved to make it clear how this works. B. R. Tina http://tinatsou.weebly.com/contact.html From shawn.emery@sun.com Tue Mar 16 00:01:27 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 2743B3A6876 for ; Tue, 16 Mar 2010 00:01:27 -0700 (PDT) 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 n55MMBGow29r for ; Tue, 16 Mar 2010 00:01:27 -0700 (PDT) Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by core3.amsl.com (Postfix) with ESMTP id EC6433A62C1 for ; Tue, 16 Mar 2010 00:01:26 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2G71Rr0002295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 16 Mar 2010 07:01:29 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2G6d3Sc015274 for ; Tue, 16 Mar 2010 07:01:26 GMT Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 88900041268722839; Tue, 16 Mar 2010 00:00:39 -0700 Received: from [10.7.250.239] (/10.7.250.239) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 16 Mar 2010 00:00:39 -0700 Message-ID: <4B9F2C96.1090403@sun.com> Date: Tue, 16 Mar 2010 01:00:38 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20100117 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B020B.4B9F2CC7.0108,ss=1,fgs=0 Subject: [secdir] Review of draft-ietf-manet-nhdp-11 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 Mar 2010 07:01:27 -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 a protocol for a one-hop and a symmetric two-hop neighborhood discovery for mobile ad hoc networks (MANETs). The security considerations section does exist and discusses the various attack scenarios. The first being HELLO messages that are correctly formatted, but malicious. Preventing this scenario can be handled in different ways depending on the constraints in which the protocol is deployed; physical or proximity access, link-layer authentication, integrity checks, and confidentiality. Then the section suggests how to protect HELLO messages for this protocol by using the same mechanisms that RFC5444 outlines. For integrity; using signatures in Message TLV or Packet TLVs. For privacy; using link-layer protection, IPsec, or encrypting the Value field and specifying the encrypted TLV type for the associated message. It might be helpful if they state something like this instead of just referring to 5444 for confidentiality. Other than this, I believe that the section covers the possible issues and their respective solution. General comments: None. Editorial comments: 5.5. Parameter Change Constraints The first occurrence of L_time and NL_time should have their corresponding definition. 9.2. Removing an Interface s/router will longer participate/router will no longer participate/ 9.3. Adding a Network Address to an Interface s/network address is removed/network address, is removed/ -- Shawn. From acmorton@att.com Tue Mar 16 05:24: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 2BDD63A6A26; Tue, 16 Mar 2010 05:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 oXU5r1IxIxmd; Tue, 16 Mar 2010 05:24:17 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 294593A6A46; Tue, 16 Mar 2010 05:24:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-12.tower-167.messagelabs.com!1268742261!28044783!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 9921 invoked from network); 16 Mar 2010 12:24:22 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-12.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Mar 2010 12:24:22 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2GCOAW0014400; Tue, 16 Mar 2010 08:24:11 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2GCO79r014366; Tue, 16 Mar 2010 08:24:07 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o2GCOHJX009469; Tue, 16 Mar 2010 07:24:18 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o2GCOFFp009439; Tue, 16 Mar 2010 07:24:16 -0500 Message-Id: <201003161224.o2GCOFFp009439@klpd017.kcdc.att.com> Received: from acmt.att.com (dyp004254dys.mt.att.com[135.16.251.229](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100316122414gw100b8i0ne>; Tue, 16 Mar 2010 12:24:14 +0000 X-Originating-IP: [135.16.251.229] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 16 Mar 2010 08:22:36 -0400 To: Tina TSOU , secdir@ietf.org, draft-ietf-ippm-twamp-session-cntrl@tools.ietf.org, iesg@ietf.org From: Al Morton In-Reply-To: <9A90D3D3722C4A04879B3B6C57ECF65C@china.huawei.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C897@il-ex01.ad.checkpoint.com> <9A90D3D3722C4A04879B3B6C57ECF65C@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [secdir] SecDir review of draft-ietf-ippm-twamp-session-cntrl-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: Tue, 16 Mar 2010 12:24:18 -0000 Thanks for your comments, Tina. At 10:26 PM 3/15/2010, Tina TSOU wrote: >In paragraph 3 of section 4.2, given that there is no change to the >TWAMP-test packet format, I assume we use the exact TWAMP-test >packet format as defined RFC5357, so that the SID is not carried in >the test packets. My question is that how the reflector just whether >a TWAMP-test packet belongs to the same session/SID or not. Since >per definition the testing message does not include SID, how to >differentiate the testing message of different testing sessions >after multiple testing started? The Request-TW-Session command includes sender address + port and receiver address + port, and this is usually sufficient. Al From akoba@nttv6.net Tue Mar 16 11:26:07 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 F3A753A6AB3 for ; Tue, 16 Mar 2010 11:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.541 X-Spam-Level: * X-Spam-Status: No, score=1.541 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1, SUBJ_RE_NUM=2.799] 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 PEDiXIjqQtK4 for ; Tue, 16 Mar 2010 11:26:05 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 0C7CD3A6AD2 for ; Tue, 16 Mar 2010 11:24:32 -0700 (PDT) Received: from [127.0.0.1] (dhcp-3-152.nttv6.com [192.47.163.152]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o2GIOK06031047; Wed, 17 Mar 2010 03:24:21 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Wed, 17 Mar 2010 03:19:03 +0900 From: Atsushi Kobayashi To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C898@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C897@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C898@il-ex01.ad.checkpoint.com> Message-Id: <20100317010923.AFAB.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Wed, 17 Mar 2010 03:24:21 +0900 (JST) X-Mailman-Approved-At: Wed, 17 Mar 2010 01:09:15 -0700 Cc: "draft-ietf-ipfix-mediators-problem-statement.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-ipfix-mediators-problem-statement-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, 16 Mar 2010 18:26:07 -0000 Dear Yaron, Thank you for your feedbacks. Please see in-line. On Thu, 11 Mar 2010 16:50:58 +0200 Yaron Sheffer wrote: > Resending, sorry if you see it twice... > > ________________________________________ > From: Yaron Sheffer > Sent: Thursday, March 11, 2010 4:47 PM > To: secdir@ietf.org; draft-ietf-ipfix-mediators-problem-statement.all@ietf.org > Subject: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08 > > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > This document presents the need for introducing Mediators (known in other quarters as "proxies") into the IPFIX architecture. > > The document is in general well written, and it does attempt to cover most of the relevant security issues. But I would have liked to see a bit more discussion on: > > - Privacy concerns, especially where actual data packets are sampled. These concerns may be amplified when streams from multiple sources are combined. Could you please clarify your concerns. I assume your concerns as follows. a) Flow Records from multiple sources can reveal the path for flows. It may create another privacy issue. b) Generally, it is difficult that random sampling technique captures specific customer's traffic. However, the probability to capture specific customer's traffic increases, when there are multiple observation points. I think a) and b) are general privacy issues regarding flow-based measurement whether there are intermediate devices or not. > - Multi-tenancy: large networks, i.e. those that require such solutions, may process and sometime aggregate data from many different owners. An extreme example is virtualized processing clouds. Tenants should be protected from one another, and possibly also from the service provider. Yes. It needs to identify the customer's identifier, e.g., IP addess, vlan, mac address, and etc., to feed them to appropriate intermediate process anonymizing them, and to export them to Collector to separate one another. When an IPFIX Mediator can not identify the customer, in special case where VM motion occurs, it may need to drop the flow records. I will put above paragraph in sentence. > - The subsection of the Security Considerations that discusses confidentiality protection could be improved to more clearly point out that transport-level security is no longer sufficient in this architecture, and (at least in some cases) should be replaced by end-to-end, application-level security. Actually, the scope of this document is problem statement. It is just starting points to continue to the series of IPFIX Mediation documents. At this level, I can not come up with the suitable end-to-end confidentiality protection method via Mediator. If the confidentiality protection for Flow Records is kept on Mediators, Mediator would not be able to handle Flow Records. Could you please show some cases you mentioned. > - The trust model should be clarified, possibly just to say "we all trust the Mediator". I have two scenarios. a) A Collector certificates a Mediator by using X.509 certificates, and the Collector certificates an Original Exporter by its X.509 certificates informed by the Mediator. b) A Collector certificates a Mediator by using X.509 certificates, and the Collector receives the report that the Mediator certificates an Original Exporter. Case a) is recommended. Case b) can be applied to the following cases, service providers feed customer flow data, and also would like to avoid to disclose the network devices information, that is exporters. Any other cases should be avoid so far. I think the above description should be put into the later framework document as some requirement. http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-05 I will discussed with authors and WG members. > > Non-security comments > > The document starts out by discussing IPFIX, and then suddenly in 3.2, PSAMP is introduced. The clueless reader is left confused: how does PSAMP relate to per-flow information? I'd appreciate a clarifying paragraph at the top of Sec. 3. Ok, I will put the following paragraph at the top of section 3. IPFIX Mediation can be applied to flow- or packet-based information. The flow-based information is encoded by IPFIX protocol, and the packet-based information is extracted by some sampling techniques and then encoded by PSAMP protocol. Thus, this section describes relevant documents for both protocols. --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From new-work-bounces@ietf.org Tue Mar 16 20:21:27 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 52B253A6BF6; Tue, 16 Mar 2010 20:21:26 -0700 (PDT) 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 936743A6BF6 for ; Tue, 16 Mar 2010 20:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.869 X-Spam-Level: X-Spam-Status: No, score=-6.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 7NfgB-huZUzS for ; Tue, 16 Mar 2010 20:21:18 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id CC7453A6A07 for ; Tue, 16 Mar 2010 20:21:17 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1Nrjoz-0007gz-VW; Tue, 16 Mar 2010 23:21:26 -0400 Message-Id: From: Ian Jacobs To: new-work@ietf.org Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 16 Mar 2010 22:21:25 -0500 X-Mailer: Apple Mail (2.936) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 17 Mar 2010 01:09:15 -0700 Subject: [secdir] [New-work] Proposed W3C Charter: Web Applications Working Group (until 2010-04-08) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 03:21:27 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the Rich Web Client Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the Web Applications Working Group: http://www.w3.org/2010/webapps/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-04-08 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 Doug Schepers, Team Contact or Steven Pemberton . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2006/rwc/Activity.html [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- 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 yaronf@checkpoint.com Wed Mar 17 03:44: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 66F163A6859 for ; Wed, 17 Mar 2010 03:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 irJff5icciYo for ; Wed, 17 Mar 2010 03:44:29 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 152693A69D3 for ; Wed, 17 Mar 2010 03:43:58 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2HAi6sd024568; Wed, 17 Mar 2010 12:44:06 +0200 (IST) X-CheckPoint: {4BA0B217-0-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 17 Mar 2010 12:44:28 +0200 From: Yaron Sheffer To: Atsushi Kobayashi Date: Wed, 17 Mar 2010 12:44:26 +0200 Thread-Topic: Re[2]: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08 Thread-Index: AcrFNgMq5U1Z4m3YQH6wAzyw+AlK2gAhy+hf Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C8F0@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C897@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C898@il-ex01.ad.checkpoint.com>, <20100317010923.AFAB.17391CF2@nttv6.net> In-Reply-To: <20100317010923.AFAB.17391CF2@nttv6.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 17 Mar 2010 03:57:03 -0700 Cc: "draft-ietf-ipfix-mediators-problem-statement.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-ipfix-mediators-problem-statement-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: Wed, 17 Mar 2010 10:55:04 -0000 Dear Atsushi, Please see my answers inline. Thanks, Yaron ________________________________________ From: Atsushi Kobayashi [akoba@nttv6.net] Sent: Tuesday, March 16, 2010 8:19 PM To: Yaron Sheffer Cc: secdir@ietf.org; draft-ietf-ipfix-mediators-problem-statement.all@tools= .ietf.org Subject: Re[2]: SecDir review of draft-ietf-ipfix-mediators-problem-stateme= nt-08 Dear Yaron, Thank you for your feedbacks. Please see in-line. On Thu, 11 Mar 2010 16:50:58 +0200 Yaron Sheffer wrote: > Resending, sorry if you see it twice... > > ________________________________________ > From: Yaron Sheffer > Sent: Thursday, March 11, 2010 4:47 PM > To: secdir@ietf.org; draft-ietf-ipfix-mediators-problem-statement.all@iet= f.org > Subject: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08 > > I have reviewed this document as part of the security directorate's ongoi= ng effort to review all IETF documents being processed by the IESG. These = comments were written primarily for the benefit of the security area direct= ors. Document editors and WG chairs should treat these comments just like = any other last call comments. > > This document presents the need for introducing Mediators (known in other= quarters as "proxies") into the IPFIX architecture. > > The document is in general well written, and it does attempt to cover mos= t of the relevant security issues. But I would have liked to see a bit more= discussion on: > > - Privacy concerns, especially where actual data packets are sampled. The= se concerns may be amplified when streams from multiple sources are combine= d. Could you please clarify your concerns. I assume your concerns as follows. a) Flow Records from multiple sources can reveal the path for flows. It may create another privacy issue. b) Generally, it is difficult that random sampling technique captures specific customer's traffic. However, the probability to capture specific customer's traffic increases, when there are multiple observation points. I think a) and b) are general privacy issues regarding flow-based measurement whether there are intermediate devices or not. [YS] I was thinking more of point (b) above. And as you say, when you have = multiple observation points, this problem potentially becomes more acute. > - Multi-tenancy: large networks, i.e. those that require such solutions, = may process and sometime aggregate data from many different owners. An extr= eme example is virtualized processing clouds. Tenants should be protected f= rom one another, and possibly also from the service provider. Yes. It needs to identify the customer's identifier, e.g., IP addess, vlan, mac address, and etc., to feed them to appropriate intermediate process anonymizing them, and to export them to Collector to separate one another. When an IPFIX Mediator can not identify the customer, in special case where VM motion occurs, it may need to drop the flow records. I will put above paragraph in sentence. > - The subsection of the Security Considerations that discusses confidenti= ality protection could be improved to more clearly point out that transport= -level security is no longer sufficient in this architecture, and (at least= in some cases) should be replaced by end-to-end, application-level securit= y. Actually, the scope of this document is problem statement. It is just starting points to continue to the series of IPFIX Mediation documents. At this level, I can not come up with the suitable end-to-end confidentiality protection method via Mediator. If the confidentiality protection for Flow Records is kept on Mediators, Mediator would not be able to handle Flow Records. Could you please show some cases you mentioned. [YS] I was thinking of integrity protection, rather than confidentiality pr= otection, i.e. the Mediator can still see the traffic. But I agree that eve= n this is impractical for a generic Mediator, one which is expected to modi= fy records, merge multiple records etc. So I cannot offer a good solution h= ere. But I had an issue with the first sentence "To ensure integrity and co= nfidentiality of Data Records, its transport for Data Records should use Tr= ansport Layer Security (TLS) or Datagram Transport Layer Security (DTLS). "= This sounds like a specific solution would solve the problem, and I believ= e this is not the case. > - The trust model should be clarified, possibly just to say "we all trust= the Mediator". I have two scenarios. a) A Collector certificates a Mediator by using X.509 certificates, and the Collector certificates an Original Exporter by its X.509 certificates informed by the Mediator. b) A Collector certificates a Mediator by using X.509 certificates, and the Collector receives the report that the Mediator certificates an Original Exporter. Case a) is recommended. Case b) can be applied to the following cases, service providers feed customer flow data, and also would like to avoid to disclose the network devices information, that is exporters. Any other cases should be avoid so far. I think the above description should be put into the later framework document as some requirement. http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-05 [YS] This is fine, what you are describing above is a solution outline. But= a few words describing the use cases (closed network vs. ISP?) in the cont= ext of trust would be appropriate for the problem statement as well. I will discussed with authors and WG members. > > Non-security comments > > The document starts out by discussing IPFIX, and then suddenly in 3.2, PS= AMP is introduced. The clueless reader is left confused: how does PSAMP rel= ate to per-flow information? I'd appreciate a clarifying paragraph at the t= op of Sec. 3. Ok, I will put the following paragraph at the top of section 3. IPFIX Mediation can be applied to flow- or packet-based information. The flow-based information is encoded by IPFIX protocol, and the packet-based information is extracted by some sampling techniques and then encoded by PSAMP protocol. Thus, this section describes relevant documents for both protocols. [YS] Good. Thanks. --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 Scanned by Check Point Total Security Gateway.= From weiler+secdir@watson.org Wed Mar 17 14:28:21 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 4887E3A67BD; Wed, 17 Mar 2010 14:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 lWkj+4VLjEwu; Wed, 17 Mar 2010 14:28:20 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 9ABDA3A676A; Wed, 17 Mar 2010 14:28:18 -0700 (PDT) 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 o2HLSS4Q013833; Wed, 17 Mar 2010 17:28:28 -0400 (EDT) (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 o2HLSRO3013830; Wed, 17 Mar 2010 17:28:28 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 17 Mar 2010 17:28:27 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: draft-ietf-nsis-ntlp-statemachine.all@tools.ietf.org, 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]); Wed, 17 Mar 2010 17:28:28 -0400 (EDT) Subject: [secdir] secdir review of draft-ietf-nsis-ntlp-statemachine 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 Mar 2010 21:28:21 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. NOTE: there's a PDF form of this draft which has easier-to-read pictures. If you're going to review it in depth, use the PDF version. This is an informational doc giving a state machine model (with diagrams) for GIST. The base GIST spec was approved by the IESG in August. This claims to make no changes to the protocol, just present the same protocol in a different form. I see no concerns here. -- Sam From fluffy@cisco.com Wed Mar 17 19:03: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 150213A6807; Wed, 17 Mar 2010 19:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.729 X-Spam-Level: X-Spam-Status: No, score=-109.729 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 xZXbShNNttPj; Wed, 17 Mar 2010 19:03:53 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A8A2B3A68BD; Wed, 17 Mar 2010 19:03:52 -0700 (PDT) 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: AvsEALMmoUurR7Ht/2dsb2JhbACbJnOfWJh3hHYEgxo X-IronPort-AV: E=Sophos;i="4.51,262,1267401600"; d="scan'208";a="498539816" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 18 Mar 2010 01:55:58 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2I1tvXF021796; Thu, 18 Mar 2010 01:55:57 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Wed, 17 Mar 2010 19:55:56 -0600 Message-Id: To: saag@ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [secdir] E2MD BOF 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 Mar 2010 02:03:54 -0000 The E2MD BOF is wrestling with some complicated issues around putting = personal data about individuals in DNS (names, phones numbers etc). They = are considering various approaches to constrain access to the private = data. The leading contender as far as I can tell is to only run the DNS = with the private data in a walled garden and make sure no one that = should not see the data can query a server in the walled garden. One or = two people have mentioned you might want to encrypt the private data and = control access to the keys but that idea has not received much = discussion. It seems to me like a possibility worth exploring a little.=20= If anyone is interested or has spend time thinking about privacy of data = in DNS, input from folks on this list would be valuable and I hope at = least a few security folks can show up at the BOF.=20 Thanks, Cullen Mailing list archive at = http://www.ietf.org/mail-archive/web/e2md/index.html From tena@huawei.com Wed Mar 17 19:37: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 99D093A69B3; Wed, 17 Mar 2010 19:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.912 X-Spam-Level: X-Spam-Status: No, score=-99.912 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 7Sh6HdvHMvKh; Wed, 17 Mar 2010 19:37:34 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 82E383A6831; Wed, 17 Mar 2010 19:37:34 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZG00A2VHYMPZ@szxga03-in.huawei.com>; Thu, 18 Mar 2010 10:37:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZG005Q7HYMX8@szxga03-in.huawei.com>; Thu, 18 Mar 2010 10:37:34 +0800 (CST) Received: from z00147053k ([10.70.39.148]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZG00JDXHYLO9@szxml04-in.huawei.com>; Thu, 18 Mar 2010 10:37:34 +0800 (CST) Date: Thu, 18 Mar 2010 10:37:33 +0800 From: Tina TSOU To: iesg@ietf.org, draft-ietf-ippm-twamp-session-cntrl@tools.ietf.org, secdir@ietf.org, Al Morton Message-id: <2746FB9F002445DCBCB7E52F071D4A69@china.huawei.com> 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=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C897@il-ex01.ad.checkpoint.com> <9A90D3D3722C4A04879B3B6C57ECF65C@china.huawei.com> <201003161224.o2GCOFig009438@klpd017.kcdc.att.com> Subject: Re: [secdir] SecDir review of draft-ietf-ippm-twamp-session-cntrl-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: Thu, 18 Mar 2010 02:37:35 -0000 B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message ----- From: "Al Morton" To: "Tina TSOU" ; ; ; Sent: Tuesday, March 16, 2010 8:22 PM Subject: Re: SecDir review of draft-ietf-ippm-twamp-session-cntrl-04 > Thanks for your comments, Tina. > > At 10:26 PM 3/15/2010, Tina TSOU wrote: >>In paragraph 3 of section 4.2, given that there is no change to the >>TWAMP-test packet format, I assume we use the exact TWAMP-test packet >>format as defined RFC5357, so that the SID is not carried in the test >>packets. My question is that how the reflector just whether a TWAMP-test >>packet belongs to the same session/SID or not. Since per definition the >>testing message does not include SID, how to differentiate the testing >>message of different testing sessions after multiple testing started? > The Request-TW-Session command includes sender address + port > and receiver address + port, and this is usually sufficient. Can the server identify the corresponding SID based on sender address + port and receiver address + port? > Al > > From Kurt.Zeilenga@Isode.com Wed Mar 17 19:38: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 D11513A6A14; Wed, 17 Mar 2010 19:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.215 X-Spam-Level: X-Spam-Status: No, score=-1.215 tagged_above=-999 required=5 tests=[AWL=-1.234, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] 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 f3EAs5mTqN7H; Wed, 17 Mar 2010 19:38:45 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id BDA023A69B3; Wed, 17 Mar 2010 19:38:44 -0700 (PDT) Received: from [192.168.1.102] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 18 Mar 2010 02:38:54 +0000 X-SMTP-Protocol-Errors: NORDNS From: Kurt Zeilenga Date: Wed, 17 Mar 2010 19:38:52 -0700 Message-Id: <9271EFAC-A24D-4FAE-AC69-63FA5DAE1639@Isode.com> To: The IESG X-Mailer: Apple Mail (2.1077) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-mmusic-rfc4756bis.all@tools.ietf.org, Security Area Directorate Subject: [secdir] secdir review of draft-ietf-mmusic-rfc4756bis 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 Mar 2010 02:38:46 -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. I find the Security Considerations section, which appears unchanged from = RFC 4756, adequately addresses security considerations of the revised = technical specification. Regards, Kurt= From acmorton@att.com Thu Mar 18 05:10: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 5DCE33A6B6A; Thu, 18 Mar 2010 05:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.77 X-Spam-Level: X-Spam-Status: No, score=-104.77 tagged_above=-999 required=5 tests=[AWL=-0.704, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_44=0.6, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 9h9Rs69+Zd6s; Thu, 18 Mar 2010 05:10:51 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 936323A68CD; Thu, 18 Mar 2010 05:10:36 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-13.tower-121.messagelabs.com!1268914246!38189372!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 31280 invoked from network); 18 Mar 2010 12:10:46 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-13.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Mar 2010 12:10:46 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2ICAu0I019233; Thu, 18 Mar 2010 08:10:56 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2ICArg9019164; Thu, 18 Mar 2010 08:10:53 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o2ICAg5P001207; Thu, 18 Mar 2010 08:10:42 -0400 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.4) with ESMTP id o2ICAbE7001117; Thu, 18 Mar 2010 08:10:37 -0400 Message-Id: <201003181210.o2ICAbE7001117@alpd052.aldc.att.com> Received: from acmt.att.com (dyp004254dys.mt.att.com[135.16.251.229](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100318121037gw100b8ic3e>; Thu, 18 Mar 2010 12:10:37 +0000 X-Originating-IP: [135.16.251.229] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 18 Mar 2010 08:10:44 -0400 To: Tina TSOU , iesg@ietf.org, draft-ietf-ippm-twamp-session-cntrl@tools.ietf.org, secdir@ietf.org From: Al Morton In-Reply-To: <2746FB9F002445DCBCB7E52F071D4A69@china.huawei.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C897@il-ex01.ad.checkpoint.com> <9A90D3D3722C4A04879B3B6C57ECF65C@china.huawei.com> <201003161224.o2GCOFig009438@klpd017.kcdc.att.com> <2746FB9F002445DCBCB7E52F071D4A69@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [secdir] SecDir review of draft-ietf-ippm-twamp-session-cntrl-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: Thu, 18 Mar 2010 12:10:57 -0000 At 10:37 PM 3/17/2010, Tina TSOU wrote: >>At 10:26 PM 3/15/2010, Tina TSOU wrote: >>>In paragraph 3 of section 4.2, given that there is no change to >>>the TWAMP-test packet format, I assume we use the exact TWAMP-test >>>packet format as defined RFC5357, so that the SID is not carried >>>in the test packets. My question is that how the reflector just >>>whether a TWAMP-test packet belongs to the same session/SID or >>>not. Since per definition the testing message does not include >>>SID, how to differentiate the testing message of different testing >>>sessions after multiple testing started? >>The Request-TW-Session command includes sender address + port >>and receiver address + port, and this is usually sufficient. >Can the server identify the corresponding SID based on sender >address + port and receiver address + port? Yes, the server assigns the SID with all addr+port information in hand. From derek@ihtfp.com Thu Mar 18 19:34: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 C534C3A69E2; Thu, 18 Mar 2010 19:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.742 X-Spam-Level: * X-Spam-Status: No, score=1.742 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_ORG=0.611] 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 I863IDRGte2B; Thu, 18 Mar 2010 19:34:54 -0700 (PDT) Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by core3.amsl.com (Postfix) with ESMTP id D61A73A67DF; Thu, 18 Mar 2010 19:34:52 -0700 (PDT) Received: from pgpdev.ihtfp.org (unknown [192.168.248.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 3798BBD82FF; Thu, 18 Mar 2010 22:35:02 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.3/8.14.3/Submit) id o2J2YsV2011007; Thu, 18 Mar 2010 22:34:54 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Thu, 18 Mar 2010 22:34:54 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: cwallace@cygnacom.com Subject: [secdir] sec-dir review of draft-turner-asymmetrickeyformat-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: Fri, 19 Mar 2010 02:34:54 -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 the syntax for private key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. In particular this document describes extensions to existing protocols to encode and transfer public and private asymmetric key information. I find no additional issues with this document. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From weiler@watson.org Thu Mar 18 20:49: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 465D33A677C; Thu, 18 Mar 2010 20:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=-0.324, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 iSgqBZ7+E7w1; Thu, 18 Mar 2010 20:49:01 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 7D0103A6403; Thu, 18 Mar 2010 20:49:01 -0700 (PDT) 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 o2J3nB3Q026769; Thu, 18 Mar 2010 23:49:11 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o2J3nBek026766; Thu, 18 Mar 2010 23:49:11 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 18 Mar 2010 23:49:11 -0400 (EDT) From: Samuel Weiler To: Cullen Jennings In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 18 Mar 2010 23:49:11 -0400 (EDT) Cc: saag@ietf.org, secdir@ietf.org Subject: Re: [secdir] E2MD BOF 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, 19 Mar 2010 03:49:02 -0000 Cullen, I suggest taking this question to the DNSEXT WG. AFAIK, the DNSEXT agenda in Anaheim still has two minutes left open, which is about all the WG will tolerate of this. :-) -- Sam On Wed, 17 Mar 2010, Cullen Jennings wrote: > The E2MD BOF is wrestling with some complicated issues around > putting personal data about individuals in DNS (names, phones > numbers etc). They are considering various approaches to constrain > access to the private data. The leading contender as far as I can > tell is to only run the DNS with the private data in a walled garden > and make sure no one that should not see the data can query a server > in the walled garden. One or two people have mentioned you might > want to encrypt the private data and control access to the keys but > that idea has not received much discussion. It seems to me like a > possibility worth exploring a little. > > If anyone is interested or has spend time thinking about privacy of > data in DNS, input from folks on this list would be valuable and I > hope at least a few security folks can show up at the BOF. > > Thanks, Cullen > > Mailing list archive at http://www.ietf.org/mail-archive/web/e2md/index.html From akoba@nttv6.net Fri Mar 19 01:02:33 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 356243A685D for ; Fri, 19 Mar 2010 01:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.775 X-Spam-Level: ** X-Spam-Status: No, score=2.775 tagged_above=-999 required=5 tests=[AWL=-1.566, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1, SUBJ_RE_NUM=2.799] 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 qOdHVxnyUivb for ; Fri, 19 Mar 2010 01:02:31 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 314993A6892 for ; Fri, 19 Mar 2010 01:02:29 -0700 (PDT) Received: from [127.0.0.1] (dhcp-3-152.nttv6.com [192.47.163.152]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o2J82WT0050401; Fri, 19 Mar 2010 17:02:33 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Fri, 19 Mar 2010 16:57:10 +0900 From: Atsushi Kobayashi To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C8F0@il-ex01.ad.checkpoint.com> References: <20100317010923.AFAB.17391CF2@nttv6.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C8F0@il-ex01.ad.checkpoint.com> Message-Id: <20100319154759.EC18.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.05 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [192.16.178.5]); Fri, 19 Mar 2010 17:02:33 +0900 (JST) X-Mailman-Approved-At: Fri, 19 Mar 2010 08:07:54 -0700 Cc: "draft-ietf-ipfix-mediators-problem-statement.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-ipfix-mediators-problem-statement-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: Fri, 19 Mar 2010 08:02:33 -0000 Dear Yaron, Thank you for quick reply. Please see in-line as usual. On Wed, 17 Mar 2010 12:44:26 +0200 Yaron Sheffer wrote: > Dear Atsushi, > > Please see my answers inline. > > Thanks, > Yaron > > ________________________________________ > From: Atsushi Kobayashi [akoba@nttv6.net] > Sent: Tuesday, March 16, 2010 8:19 PM > To: Yaron Sheffer > Cc: secdir@ietf.org; draft-ietf-ipfix-mediators-problem-statement.all@tools.ietf.org > Subject: Re[2]: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08 > > Dear Yaron, > > Thank you for your feedbacks. Please see in-line. > > On Thu, 11 Mar 2010 16:50:58 +0200 > Yaron Sheffer wrote: > > > Resending, sorry if you see it twice... > > > > ________________________________________ > > From: Yaron Sheffer > > Sent: Thursday, March 11, 2010 4:47 PM > > To: secdir@ietf.org; draft-ietf-ipfix-mediators-problem-statement.all@ietf.org > > Subject: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08 > > > > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > > > This document presents the need for introducing Mediators (known in other quarters as "proxies") into the IPFIX architecture. > > > > The document is in general well written, and it does attempt to cover most of the relevant security issues. But I would have liked to see a bit more discussion on: > > > > - Privacy concerns, especially where actual data packets are sampled. These concerns may be amplified when streams from multiple sources are combined. > > > Could you please clarify your concerns. > I assume your concerns as follows. > > a) Flow Records from multiple sources can reveal the path for flows. It > may create another privacy issue. > > b) Generally, it is difficult that random sampling technique captures > specific customer's traffic. However, the probability to capture > specific customer's traffic increases, when there are multiple > observation points. > > I think a) and b) are general privacy issues regarding flow-based > measurement whether there are intermediate devices or not. > > [YS] I was thinking more of point (b) above. And as you say, when you have multiple observation points, this problem potentially becomes more acute. Ok, but, this issue is more general. If there is no Mediator, collecting Flow Records from multiple sources raises the risk for privacy. I am not sure what description suitable for this document. Even if I say so, my idea is as follows. o Privacy concerns on an IPFIX Mediator The probability to get specific user's traffic generally increases by increasing the number of Observation Points. An IPFIX Mediator collecting Flow Records from multiple Observation Points potentially raises the risk for privacy. Thus, the IPFIX Mediator needs to apply appropriately anonymization or aggregation function to Data Records to cope with privacy concerns. In addition, an IPFIX Mediator needs to identify the user's identifier, e.g., IP addess, VLAN ID, MAC address, and etc., when feeding user's traffic data to an user own dedicated IPFIX Collector. If the IPFIX Mediator can not identify each user, it may need to drop the Data Records. How about that? Some description will be changed after discussing it with co-authors. > > > - Multi-tenancy: large networks, i.e. those that require such solutions, may process and sometime aggregate data from many different owners. An extreme example is virtualized processing clouds. Tenants should be protected from one another, and possibly also from the service provider. > > Yes. > > It needs to identify the customer's identifier, e.g., IP addess, vlan, > mac address, and etc., to feed them to appropriate intermediate process > anonymizing them, and to export them to Collector to separate one another. > > When an IPFIX Mediator can not identify the customer, in special case > where VM motion occurs, it may need to drop the flow records. > http://en.wikipedia.org/wiki/Information_security > I will put above paragraph in sentence. I will merge above the paragraph into "privacy concern" bullet. > > > - The subsection of the Security Considerations that discusses confidentiality protection could be improved to more clearly point out that transport-level security is no longer sufficient in this architecture, and (at least in some cases) should be replaced by end-to-end, application-level security. > > Actually, the scope of this document is problem statement. It is just > starting points to continue to the series of IPFIX Mediation documents. > > At this level, I can not come up with the suitable end-to-end > confidentiality protection method via Mediator. If the > confidentiality protection for Flow Records is kept on Mediators, > Mediator would not be able to handle Flow Records. Could you please > show some cases you mentioned. > > [YS] I was thinking of integrity protection, rather than confidentiality protection, i.e. the Mediator can still see the traffic. But I agree that even this is impractical for a generic Mediator, one which is expected to modify records, merge multiple records etc. So I cannot offer a good solution here. But I had an issue with the first sentence "To ensure integrity and confidentiality of Data Records, its transport for Data Records should use Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS). " This sounds like a specific solution would solve the problem, and I believe this is not the case. > Yes. It is too hard for an IPFIX Collector to confirm the integrity of original Data Record. At this level, I will remove term "integrity" from this paragraph. o Confidentiality protection via IPFIX Mediator To ensure confidentiality of Data Records, its transport for Data Records should use Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS). However, an IPFIX Collector cannot know whether received Data Records are transported as encrypted data between an Original Exporter and an IPFIX Mediator. Some function is required to make up for this drawback. > > - The trust model should be clarified, possibly just to say "we all trust the Mediator". > > I have two scenarios. > > a) A Collector certificates a Mediator by using X.509 certificates, and > the Collector certificates an Original Exporter by its X.509 > certificates informed by the Mediator. > > b) A Collector certificates a Mediator by using X.509 certificates, and > the Collector receives the report that the Mediator certificates > an Original Exporter. > > Case a) is recommended. Case b) can be applied to the following cases, > service providers feed customer flow data, and also would like to avoid > to disclose the network devices information, that is exporters. Any > other cases should be avoid so far. > > I think the above description should be put into the later framework > document as some requirement. > http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-05 > > [YS] This is fine, what you are describing above is a solution outline. But a few words describing the use cases (closed network vs. ISP?) in the context of trust would be appropriate for the problem statement as well. > Ok, I will put it into this section. o Certification for an Original Exporter An IPFIX Collector communicating via an IPFIX Mediator can not certificate an Original Exporter directly. If each device is located in different administrative domain, an IPFIX Collector can not trust its Data Records. Some function is required to make up for this drawback. Regards, Atsushi > I will discussed with authors and WG members. > > > > > Non-security comments > > > > The document starts out by discussing IPFIX, and then suddenly in 3.2, PSAMP is introduced. The clueless reader is left confused: how does PSAMP relate to per-flow information? I'd appreciate a clarifying paragraph at the top of Sec. 3. > > Ok, I will put the following paragraph at the top of section 3. > > IPFIX Mediation can be applied to flow- or packet-based information. > The flow-based information is encoded by IPFIX protocol, and the > packet-based information is extracted by some sampling techniques and > then encoded by PSAMP protocol. Thus, this section describes relevant > documents for both protocols. > > [YS] Good. Thanks. > > --- > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > > > > Scanned by Check Point Total Security Gateway. --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 From hartmans@mit.edu Fri Mar 19 11:48: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 6D1913A681B; Fri, 19 Mar 2010 11:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 pyvb6slslSxp; Fri, 19 Mar 2010 11:48:29 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 7A7603A67F2; Fri, 19 Mar 2010 11:48:29 -0700 (PDT) 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 99FC1200FA; Fri, 19 Mar 2010 14:48:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8236D413C; Fri, 19 Mar 2010 14:48:21 -0400 (EDT) From: Sam Hartman To: ietf@ietf.org,secdir@ietf.org References: <20100317174540.39CAD3A6891@core3.amsl.com> <4BA13EF6.5@gmail.com> <20100318132523.GB25752@shinkuro.com> <4BA38B39.9000206@ogud.com> Date: Fri, 19 Mar 2010 14:48:21 -0400 In-Reply-To: (Paul Hoffman's message of "Fri\, 19 Mar 2010 09\:14\:46 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ogud-iana-protocol-maintenance-words@tools.ietf.org Subject: [secdir] secdir review/last call comments for : draft-ogud-iana-protocol-maintenance-words 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, 19 Mar 2010 18:48:30 -0000 I have been assigned this draft as part of the secdir review process. I see no security issues with the draft that are really within the scope of a secdir review. I do have significant concerns I'd like to raise as last call comments. In general, I agree with most of the concerns raised about this draft. I believe that an applicability statement is the appropriate way to address what this draft is trying to do. If you're looking to make a process change how about writing a simple proposal for allowing IANA registries to reference applicability statements that describe protocols they cover. You might have a note like "For current status of the implementation requirements for these algorithms in dnssec, se RFC xyzzy." The applicability statement could say which registries it links to, and could remove the links of statements it obsoletes. I realize that's somewhat going down the path of including unnecessary information in a registry, but I think it is a reasonable compromise until/unless something broader like ISDs come along. Also, by all means try to put together an ISD-like proposal if you have the energy. I'm one of the people who thought that the last ISD proposal was not sufficiently specified and might run into fundamental problems, but thought there were some really good ideas there, so if you do go down that route I'd be happy to share some concerns while remaining constructive. Stunningly, given the concerns raised so far, I think I have some new ones. First, this draft attempts to establish operational requirements. The term operational requirements is not well defined. In the context of DNSsec, we can imagine what that might mean: zone operators need to use one of the mandatory algorithms to sign their zones in order to guarantee that others can validate it. Especially for Internet-wide protocols it is often appropriate to have best-current-practice recommendations for the operational deployment of those protocols. We have groups like gro and dnsop that develop such recommendations. For other protocols this makes no sense at all. In the past I've worked on VPN deployments for clients. Those clients chose algorithms that were right for their environments. IF within that environment they happened to choose a protocol that was not labeled as MANDATORY by an IANA registry, that's totally fine. Neither the IETF nor the IANA has a good reason to tell people what IPsec algorithms they need to use in their operational environment, nor even what algorithms must be enabled in a given configuration. If we try, we will be ignored. This draft conflates implementation requirements with operations requirements. In many cases we SHOULD NOT specify operations requirements. In other cases, there is no reason to be sure that the implementation and operations requirements will be the same. Others have pointed out the broken definition of mandatory. The definition at the top of 3.1 provides an escape and makes MANDATORY much like SHOULD. However the explanation for what it means for implementations and operations provides no such escape. There is a lack of alignment between the implementation requirement and operations requirement for obsolete: if I'm starting to phase something out, it is too early to say SHOULD NOT implement. This draft fails to adequately describe its relationship to RFC 2119. When should I use MUST? When should I use MANDATORY? Why do I need both? If you're going to introduce new terms, you need to clearly specify their applicability. From weiler+secdir@watson.org Fri Mar 19 12:40: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 2F7D13A63EB for ; Fri, 19 Mar 2010 12:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.268 X-Spam-Level: X-Spam-Status: No, score=-0.268 tagged_above=-999 required=5 tests=[AWL=-1.399, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 W6WeTfiPy-im for ; Fri, 19 Mar 2010 12:40:24 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 2D71B3A695E for ; Fri, 19 Mar 2010 12:40:24 -0700 (PDT) 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 o2JJeahb016035 for ; Fri, 19 Mar 2010 15:40:36 -0400 (EDT) (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 o2JJeaB7016032 for ; Fri, 19 Mar 2010 15:40:36 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 19 Mar 2010 15:40:36 -0400 (EDT) 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, 19 Mar 2010 15:40:36 -0400 (EDT) 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, 19 Mar 2010 19:40:25 -0000 Paul Hoffman 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-04-08 Reviewer Deadline Draft Love Hornquist-Astrand T 2010-04-06 draft-ietf-ccamp-gmpls-mef-uni-03 Chris Newman T 2010-04-06 draft-ietf-krb-wg-preauth-framework-16 Chris Newman T 2010-04-06 draft-ietf-pce-pcep-svec-list-04 For telechat 2010-04-22 Love Hornquist-Astrand T 2010-04-20 draft-ietf-opsawg-smi-datatypes-in-xsd-06 Nico Williams T 2010-04-20 draft-haberman-rpsl-reachable-test-03 Last calls and special requests: Rob Austein 2010-03-29 draft-denenberg-mods-etc-media-types-01 Richard Barnes 2010-03-23 draft-ietf-behave-turn-ipv6-09 Pat Cain 2010-03-23 draft-ietf-behave-turn-tcp-06 Dave Cridland 2010-03-22 draft-ietf-isms-dtls-tm-09 Alan DeKok 2009-10-01 draft-ietf-enum-enumservices-transition-04 Alan DeKok 2010-03-24 draft-ietf-netmod-yang-11 Donald Eastlake 2010-03-24 draft-ietf-netmod-yang-types-07 Shawn Emery 2010-03-23 draft-ietf-nsis-ext-06 Stephen Farrell 2010-03-29 draft-ietf-sipcore-info-events-07 Tobias Gondrom 2010-03-24 draft-mattsson-mikey-ticket-02 Phillip Hallam-Baker 2010-03-29 draft-ietf-radext-status-server-06 Steve Hanna None draft-ietf-tsvwg-ecn-tunnel-08 Dan Harkins 2010-03-31 draft-zimmermann-avt-zrtp-17 David McGrew 2010-03-10 draft-ietf-ecrit-framework-10 Catherine Meadows 2008-01-17 draft-ietf-speechsc-mrcpv2-20 Vidya Narayanan 2008-11-21 draft-ietf-sip-saml-07 Sam Weiler 2008-08-13 draft-chown-v6ops-rogue-ra-03 Brian Weis 2010-03-15 draft-ietf-nsis-rmd-16 Nico Williams 2008-08-13 draft-ietf-v6ops-ra-guard-04 Tom Yu 2010-03-18 draft-ietf-ipsecme-ikev2bis-08 Kurt Zeilenga 2010-03-18 draft-ietf-mmusic-rfc4756bis-06 Larry Zhu 2008-08-13 draft-thaler-v6ops-teredo-extensions-06 Larry Zhu 2010-03-20 draft-ietf-sip-domain-certs-05 From shawn.emery@sun.com Sat Mar 20 01:23: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 63D5B3A68CE; Sat, 20 Mar 2010 01:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 3eSlGywEgxch; Sat, 20 Mar 2010 01:23:20 -0700 (PDT) Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by core3.amsl.com (Postfix) with ESMTP id 2EEA63A68AD; Sat, 20 Mar 2010 01:23:20 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2K8NHpr028813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Mar 2010 08:23:33 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2K8NGau005198; Sat, 20 Mar 2010 08:23:16 GMT Received: from abhmt009.oracle.com by acsmt353.oracle.com with ESMTP id 97197161269073300; Sat, 20 Mar 2010 01:21:40 -0700 Received: from [10.7.251.48] (/10.7.251.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 20 Mar 2010 01:21:39 -0700 Message-ID: <4BA48592.8040804@sun.com> Date: Sat, 20 Mar 2010 02:21:38 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BA485F5.00EE,ss=1,fgs=0 Cc: draft-ietf-nsis-ext.all@tools.ietf.org, iesg@ietf.org Subject: [secdir] Review of draft-ietf-nsis-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: Sat, 20 Mar 2010 08:23:23 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes is an informational document that provides an overview of the Next Steps in Signaling (NSIS) set of protocols, how to deploy said protocols, and how to extend the set of NSIS protocols. The security considerations section does exist and gives guidance for any extensions to the NSIS protocol set. It then talks about using authentication, integrity checks, and authorization for any NSIS supported routers. The section continues guidance for extensions by making sure they leverage NSIS' lower layer transport authentication and that any new transport protocols created support NSIS' low layer authentication and integrity check capabilities. I think this section should include a reference to RFC 4081 for the possible attack scenarios for NSIS when considering an extension to the NSIS protocol set. General comments: None. Editorial comments: 3. The General Internet Signaling Transport s/in future/in the future/ 8. Extending the Protocols s/identified in future/identified in the future/ -- Shawn. From elwynd@folly.org.uk Sat Mar 20 08:33:51 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 6F9853A6AAA; Sat, 20 Mar 2010 08:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 WhGLeOxWJ2f6; Sat, 20 Mar 2010 08:33:50 -0700 (PDT) Received: from b.painless.aaisp.net.uk (b.painless.aaisp.net.uk [IPv6:2001:8b0:0:30::51bb:1e34]) by core3.amsl.com (Postfix) with ESMTP id 88D2E3A6A7A; Sat, 20 Mar 2010 08:33:47 -0700 (PDT) Received: from 153.107.2.81.in-addr.arpa ([81.2.107.153] helo=[81.187.254.247]) by b.painless.aaisp.net.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Nt0gT-0004VN-KM; Sat, 20 Mar 2010 15:33:53 +0000 Message-ID: <4BA4EB7D.3080702@folly.org.uk> Date: Sat, 20 Mar 2010 15:36:29 +0000 From: Elwyn Davies User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Shawn M Emery References: <4BA48592.8040804@sun.com> In-Reply-To: <4BA48592.8040804@sun.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 20 Mar 2010 09:35:05 -0700 Cc: draft-ietf-nsis-ext.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-nsis-ext-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: elwynd@folly.org.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2010 15:33:51 -0000 Thanks for the review. The suggestion about RFC 4081 is well taken. I will take the editorials under advisement! Regards, Elwyn Shawn M Emery wrote: > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This draft describes is an informational document that provides an > overview of the Next Steps in Signaling (NSIS) set of protocols, how > to deploy said protocols, and how to extend the set of NSIS protocols. > > The security considerations section does exist and gives guidance for > any extensions to the NSIS protocol set. It then talks about using > authentication, integrity checks, and authorization for any NSIS > supported routers. > > The section continues guidance for extensions by making sure they > leverage NSIS' lower layer transport authentication and that any new > transport protocols created support NSIS' low layer authentication and > integrity check capabilities. > > I think this section should include a reference to RFC 4081 for the > possible attack scenarios for NSIS when considering an extension to > the NSIS protocol set. > > General comments: > > None. > > Editorial comments: > > 3. The General Internet Signaling Transport > > s/in future/in the future/ > > > 8. Extending the Protocols > > s/identified in future/identified in the future/ > From akoba@nttv6.net Sun Mar 21 20:29:31 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 ECB893A67B2 for ; Sun, 21 Mar 2010 20:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.979 X-Spam-Level: *** X-Spam-Status: No, score=3.979 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, SUBJ_RE_NUM=2.799] 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 oBVQj2FxGMJU for ; Sun, 21 Mar 2010 20:29:30 -0700 (PDT) Received: from mail.nttv6.net (mail.nttv6.net [IPv6:2001:fa8::25]) by core3.amsl.com (Postfix) with ESMTP id 352443A67A7 for ; Sun, 21 Mar 2010 20:29:28 -0700 (PDT) Received: from [192.168.0.134] (mail.nttv6.net [IPv6:2001:fa8::25]) by mail.nttv6.net (8.14.3/8.14.3) with ESMTP id o2M3TLrc069980; Mon, 22 Mar 2010 12:29:24 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Mon, 22 Mar 2010 12:29:24 +0900 From: Atsushi Kobayashi To: Yaron Sheffer In-Reply-To: <20100319154759.EC18.17391CF2@nttv6.net> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C8F0@il-ex01.ad.checkpoint.com> <20100319154759.EC18.17391CF2@nttv6.net> Message-Id: <20100322122915.9240.17391CF2@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.52.03 [ja] (Unregistered) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.nttv6.net [IPv6:2001:fa8::25]); Mon, 22 Mar 2010 12:29:35 +0900 (JST) X-Mailman-Approved-At: Sun, 21 Mar 2010 21:49:17 -0700 Cc: akoba@nttv6.net, "draft-ietf-ipfix-mediators-problem-statement.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-ipfix-mediators-problem-statement-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: Mon, 22 Mar 2010 03:29:32 -0000 Dear Yaron, After discussing with co-author, I will rewrite security consideration section as follows. I think this version covers your concerns. You can see the difference between the current and new version. http://www.nttv6.net/~akoba/wdiff-ps08-ps09-02.htm I would like to receive your go-ahead before IPFIX meeting within Monday. Is it OK? -------------------- 8. Security Considerations A flow-based measurement system must prevent potential security threats: the disclosure of confidential traffic data, injection of incorrect data, and unauthorized access to traffic data. These security threats of the IPFIX protocol are covered by the security considerations section in [RFC5101] and are still valid for IPFIX Mediators. A measurement system must also prevent the following security threats related to IPFIX Mediation: o Attacks against an IPFIX Mediator IPFIX Mediators can be considered as a prime target for attacks, as an alternative to IPFIX Exporters and Collectors. IPFIX Proxies or Masquerading Proxies need to prevent unauthorized access or denial-of-service (DoS) attacks from untrusted public networks. o Man-in-the-middle attack by untrusted IPFIX Mediator The Exporter-Mediator-Collector structure model could be misused for man-in-the-middle attack. o Configuration on IPFIX Mediation An accidental misconfiguration and unauthorized access to configuration data could lead to the crucial problem of disclosure of confidential traffic data. o Privacy concerns on an IPFIX Mediator The probability to get specific user's traffic generally increases by increasing the number of Observation Points. An IPFIX Mediator collecting Flow Records from multiple Observation Points potentially raises the risk for privacy. The IPFIX Mediator needs to apply appropriately anonymization or aggregation function to Data Records to avoid the risk for privacy, when the purpose of traffic measurement is not to monitor specific user's traffic trend. On the other hand, an IPFIX Mediator needs to identify the user's identifier, e.g., IP addess, VLAN ID, MAC address, and etc., when feeding user's traffic data to an user own dedicated IPFIX Collector. If the IPFIX Mediator can not identify each user, it may need to drop the Flow Records. o Confidentiality protection via an IPFIX Mediator To ensure confidentiality of Data Records, its transport for Data Records should use Transport Layer Security (TLS) [RFC4346] or Datagram Transport Layer Security (DTLS) [RFC4347]. However, an IPFIX Collector can not know whether received Data Records are transported as encrypted data between an Original Exporter and an IPFIX Mediator. If this information is required on the IPFIX Collector, it must be encoded in the IPFIX Mediator. o Certification for an Original Exporter An IPFIX Collector communicating via an IPFIX Mediator can not verify the identity of an Original Exporter directly. If an Original Exporter and an IPFIX Collector are located in different administrative domains, an IPFIX Collector can not trust its Data Records. If this information is required on the IPFIX Collector, it must be encoded in the IPFIX Mediator. Regards, Atsushi On Fri, 19 Mar 2010 16:57:10 +0900 Atsushi Kobayashi wrote: > > Dear Yaron, > > Thank you for quick reply. Please see in-line as usual. > > On Wed, 17 Mar 2010 12:44:26 +0200 > Yaron Sheffer wrote: > > > Dear Atsushi, > > > > Please see my answers inline. > > > > Thanks, > > Yaron > > > > ________________________________________ > > From: Atsushi Kobayashi [akoba@nttv6.net] > > Sent: Tuesday, March 16, 2010 8:19 PM > > To: Yaron Sheffer > > Cc: secdir@ietf.org; draft-ietf-ipfix-mediators-problem-statement.all@tools.ietf.org > > Subject: Re[2]: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08 > > > > Dear Yaron, > > > > Thank you for your feedbacks. Please see in-line. > > > > On Thu, 11 Mar 2010 16:50:58 +0200 > > Yaron Sheffer wrote: > > > > > Resending, sorry if you see it twice... > > > > > > ________________________________________ > > > From: Yaron Sheffer > > > Sent: Thursday, March 11, 2010 4:47 PM > > > To: secdir@ietf.org; draft-ietf-ipfix-mediators-problem-statement.all@ietf.org > > > Subject: SecDir review of draft-ietf-ipfix-mediators-problem-statement-08 > > > > > > I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. > > > > > > This document presents the need for introducing Mediators (known in other quarters as "proxies") into the IPFIX architecture. > > > > > > The document is in general well written, and it does attempt to cover most of the relevant security issues. But I would have liked to see a bit more discussion on: > > > > > > - Privacy concerns, especially where actual data packets are sampled. These concerns may be amplified when streams from multiple sources are combined. > > > > > > Could you please clarify your concerns. > > I assume your concerns as follows. > > > > a) Flow Records from multiple sources can reveal the path for flows. It > > may create another privacy issue. > > > > b) Generally, it is difficult that random sampling technique captures > > specific customer's traffic. However, the probability to capture > > specific customer's traffic increases, when there are multiple > > observation points. > > > > I think a) and b) are general privacy issues regarding flow-based > > measurement whether there are intermediate devices or not. > > > > [YS] I was thinking more of point (b) above. And as you say, when you have multiple observation points, this problem potentially becomes more acute. > > Ok, but, this issue is more general. If there is no Mediator, > collecting Flow Records from multiple sources raises the risk for privacy. > I am not sure what description suitable for this document. Even if I say > so, my idea is as follows. > > o Privacy concerns on an IPFIX Mediator > > The probability to get specific user's traffic generally increases > by increasing the number of Observation Points. An IPFIX Mediator > collecting Flow Records from multiple Observation Points > potentially raises the risk for privacy. Thus, the IPFIX Mediator > needs to apply appropriately anonymization or aggregation function > to Data Records to cope with privacy concerns. > > In addition, an IPFIX Mediator needs to identify the user's > identifier, e.g., IP addess, VLAN ID, MAC address, and etc., when > feeding user's traffic data to an user own dedicated IPFIX > Collector. If the IPFIX Mediator can not identify each user, it > may need to drop the Data Records. > > How about that? Some description will be changed after discussing it > with co-authors. > > > > > > - Multi-tenancy: large networks, i.e. those that require such solutions, may process and sometime aggregate data from many different owners. An extreme example is virtualized processing clouds. Tenants should be protected from one another, and possibly also from the service provider. > > > > Yes. > > > > It needs to identify the customer's identifier, e.g., IP addess, vlan, > > mac address, and etc., to feed them to appropriate intermediate process > > anonymizing them, and to export them to Collector to separate one another. > > > > When an IPFIX Mediator can not identify the customer, in special case > > where VM motion occurs, it may need to drop the flow records. > > http://en.wikipedia.org/wiki/Information_security > > I will put above paragraph in sentence. > > I will merge above the paragraph into "privacy concern" bullet. > > > > > > - The subsection of the Security Considerations that discusses confidentiality protection could be improved to more clearly point out that transport-level security is no longer sufficient in this architecture, and (at least in some cases) should be replaced by end-to-end, application-level security. > > > > Actually, the scope of this document is problem statement. It is just > > starting points to continue to the series of IPFIX Mediation documents. > > > > At this level, I can not come up with the suitable end-to-end > > confidentiality protection method via Mediator. If the > > confidentiality protection for Flow Records is kept on Mediators, > > Mediator would not be able to handle Flow Records. Could you please > > show some cases you mentioned. > > > > [YS] I was thinking of integrity protection, rather than confidentiality protection, i.e. the Mediator can still see the traffic. But I agree that even this is impractical for a generic Mediator, one which is expected to modify records, merge multiple records etc. So I cannot offer a good solution here. But I had an issue with the first sentence "To ensure integrity and confidentiality of Data Records, its transport for Data Records should use Transport Layer Security (TLS) or Datagram Transport Layer Security (DTLS). " This sounds like a specific solution would solve the problem, and I believe this is not the case. > > > > Yes. It is too hard for an IPFIX Collector to confirm the integrity of > original Data Record. At this level, I will remove term "integrity" from > this paragraph. > > o Confidentiality protection via IPFIX Mediator > > To ensure confidentiality of Data Records, its transport for Data > Records should use Transport Layer Security (TLS) or Datagram > Transport Layer Security (DTLS). However, an IPFIX Collector > cannot know whether received Data Records are transported as > encrypted data between an Original Exporter and an IPFIX Mediator. > Some function is required to make up for this drawback. > > > > - The trust model should be clarified, possibly just to say "we all trust the Mediator". > > > > I have two scenarios. > > > > a) A Collector certificates a Mediator by using X.509 certificates, and > > the Collector certificates an Original Exporter by its X.509 > > certificates informed by the Mediator. > > > > b) A Collector certificates a Mediator by using X.509 certificates, and > > the Collector receives the report that the Mediator certificates > > an Original Exporter. > > > > Case a) is recommended. Case b) can be applied to the following cases, > > service providers feed customer flow data, and also would like to avoid > > to disclose the network devices information, that is exporters. Any > > other cases should be avoid so far. > > > > I think the above description should be put into the later framework > > document as some requirement. > > http://tools.ietf.org/html/draft-ietf-ipfix-mediators-framework-05 > > > > [YS] This is fine, what you are describing above is a solution outline. But a few words describing the use cases (closed network vs. ISP?) in the context of trust would be appropriate for the problem statement as well. > > > > Ok, I will put it into this section. > > o Certification for an Original Exporter > > An IPFIX Collector communicating via an IPFIX Mediator can not > certificate an Original Exporter directly. If each device is > located in different administrative domain, an IPFIX Collector can > not trust its Data Records. Some function is required to make up > for this drawback. > > Regards, > Atsushi > > > > I will discussed with authors and WG members. > > > > > > > > Non-security comments > > > > > > The document starts out by discussing IPFIX, and then suddenly in 3.2, PSAMP is introduced. The clueless reader is left confused: how does PSAMP relate to per-flow information? I'd appreciate a clarifying paragraph at the top of Sec. 3. > > > > Ok, I will put the following paragraph at the top of section 3. > > > > IPFIX Mediation can be applied to flow- or packet-based information. > > The flow-based information is encoded by IPFIX protocol, and the > > packet-based information is extracted by some sampling techniques and > > then encoded by PSAMP protocol. Thus, this section describes relevant > > documents for both protocols. > > > > [YS] Good. Thanks. > > > > --- > > Atsushi KOBAYASHI > > NTT Information Sharing Platform Lab. > > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 > > > > > > > > Scanned by Check Point Total Security Gateway. > > --- > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637 -- Atsushi Kobayashi From d3e3e3@gmail.com Sun Mar 21 23:49: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 0A79428C0E5; Sun, 21 Mar 2010 23:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.773 X-Spam-Level: X-Spam-Status: No, score=-0.773 tagged_above=-999 required=5 tests=[AWL=-0.793, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] 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 B3BfQyHwEVNZ; Sun, 21 Mar 2010 23:49:55 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id D457828C0FA; Sun, 21 Mar 2010 23:48:28 -0700 (PDT) Received: by wwg30 with SMTP id 30so1978322wwg.31 for ; Sun, 21 Mar 2010 23:48:41 -0700 (PDT) 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=FyrFvqWSZbwucrRnPJ/Nai/PY7Xr9qLyS0GX8X/rugg=; b=OYbBBn3FfeO2fVoz63UWPUpsy68mVsbbgUqx3yajOjmzfy+9eju0rHfEAOTstHi7S2 Lg6kdJpwDE8pexsDaH2jJmilSZJRdVCInjqQ4dHfM4kj0vINR+fyW/O97rStj4wj8p+t m6duIcz/MbUikIus7AiIdYpAb8BFbdO+3ct2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=eAPlp+DlmtdbVGq+LJrbmZsFE8BDJ8oRzlgLoD4ZXiuBE27MfdpmwWz6WpQWxZlQ/P hbUKkIpcwqvag06ZKbWcuccjhyFnIvg8hCgxlzJfkTxpoP9xyuN3x6annjrGm2hV2e81 rjJEfnK5EXMAwVOcxP4yo+2OfWD5E+baQydxc= MIME-Version: 1.0 Received: by 10.216.87.83 with SMTP id x61mr1263417wee.7.1269240521708; Sun, 21 Mar 2010 23:48:41 -0700 (PDT) Date: Mon, 22 Mar 2010 02:48:41 -0400 Message-ID: <1028365c1003212348k4d0fc523of26a7db47715619b@mail.gmail.com> From: Donald Eastlake To: iesg@ietf.org, secdir@ietf.org, draft-ietf-netmod-yang.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] draft-ietf-netmod-yang-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, 22 Mar 2010 06:49:56 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This document is essentially data type definitions in YANG for use in NETCONF. As such, the Security Considerations section seems quite adequate. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street +1-508-634-2066 (home) Milford, MA 01757 USA d3e3e3@gmail.com From william.polk@nist.gov Mon Mar 22 09:29: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 EF1BF3A69A8 for ; Mon, 22 Mar 2010 09:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.597 X-Spam-Level: X-Spam-Status: No, score=-4.597 tagged_above=-999 required=5 tests=[AWL=-1.729, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, 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 4EwDt639e2sV for ; Mon, 22 Mar 2010 09:29:52 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 413FF3A691D for ; Mon, 22 Mar 2010 09:29:52 -0700 (PDT) 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 o2MGU0fg031321; Mon, 22 Mar 2010 12:30:01 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Mon, 22 Mar 2010 12:29:59 -0400 From: "Polk, William T." To: "Pasi.Eronen@nokia.com" , "secdir@ietf.org" Date: Mon, 22 Mar 2010 12:34:29 -0400 Thread-Topic: Finding food before the Security Directorate lunch in IETF77 Thread-Index: Acq6ubquOa5h8s4oQE27vjXmyGyVFgPI9BLE Message-ID: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775848240A2F@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7CCEA2514A79timpolknistgov_" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Subject: [secdir] Finding food before the Security Directorate lunch in IETF77 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, 22 Mar 2010 16:29:59 -0000 --_000_C7CCEA2514A79timpolknistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, As always, the great challenge of IETF meetings is finding food in time for= the Security Directorate lunch. I did a little research with the conciera= ge and the secretariat about logistics, and I'd like to share what I've lea= rned: The hotel will not have a box lunch setup. The cost would have been rather= high ($15) and the IETF would have been required to guarantee the sales. If the lines are manageable, the best bet would be the restaraunts in the H= ilton's "food court": Sbarro (fast food Italian) and Baja Fresh (fast food = Mexican - burritos, etc.). The Starbucks in the lobby has some premade san= dwiches. If you need to leave the hotel, the best bets are on Harbor Blvd. To the l= eft (North), there is a Subway (subs) and an Alertos (Mexican). To the rig= ht (South) there is a Carl's Jr (burgers) and a Jack in the Box (tacos, bur= gers, etc.). These restaurants are a 10-15 minute walk, though, so don't d= awdle after the morning session! Hope to see you all tomorrow, Thanks, Tim On 3/3/10 5:10 AM, "Pasi.Eronen@nokia.com" wrote: As usual, we're planning to have the Security Directorate lunch on Tuesday. The room will be Pacific B. If there's anything special you'd like to discuss, please drop an email to Tim, Sean, and me. Best regards, Pasi & Tim & Sean _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir --_000_C7CCEA2514A79timpolknistgov_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Finding food before the Security Directorate lunch in IETF77 Folks,

As always, the great challenge of IETF meetings is finding food in time for= the Security Directorate lunch.  I did a little research with the con= cierage and the secretariat about logistics, and I’d like to share wh= at I’ve learned:

The hotel will not have a box lunch setup.  The cost would have been r= ather high ($15) and the IETF would have been required to guarantee the sal= es.

If the lines are manageable, the best bet would be the restaraunts in the H= ilton’s “food court”: Sbarro (fast food Italian) and Baja= Fresh (fast food Mexican – burritos, etc.).  The Starbucks in t= he lobby has some premade sandwiches.

If you need to leave the hotel, the best bets are on Harbor Blvd.  To = the left (North), there is a Subway (subs) and an Alertos (Mexican).  = To the right (South) there is a Carl’s Jr (burgers) and a Jack in the= Box (tacos, burgers, etc.).  These restaurants are a 10-15 minute wal= k, though, so don’t dawdle after the morning session!

Hope to see you all tomorrow,

Thanks,

Tim


On 3/3/10 5:10 AM, "Pasi.Eronen@noki= a.com" <Pasi.Eronen@nokia.com= > wrote:

As usual, we're planning to have the Securi= ty Directorate
lunch on Tuesday. The room will be Pacific B.

If there's anything special you'd like to discuss, please
drop an email to Tim, Sean, and me.

Best regards,
Pasi & Tim & Sean
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.o= rg/mailman/listinfo/secdir

--_000_C7CCEA2514A79timpolknistgov_-- From jf.mule@cablelabs.com Mon Mar 22 11:23:51 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 DD9F43A682E for ; Mon, 22 Mar 2010 11:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.396 X-Spam-Level: X-Spam-Status: No, score=0.396 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 SFixAbSHGDdv for ; Mon, 22 Mar 2010 11:23:51 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 2B31C3A67E3 for ; Mon, 22 Mar 2010 11:23:51 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o2MIO7qZ008976; Mon, 22 Mar 2010 12:24:08 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 22 Mar 2010 12:24:08 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 22 Mar 2010 12:24:08 -0600 From: Jean-Francois Mule To: Kurt Zeilenga Date: Mon, 22 Mar 2010 12:24:05 -0600 Thread-Topic: secdir review of draft-ietf-mmusic-rfc4756bis Thread-Index: AcrGRC3rchTAlWX+QfyOlaW76nRcTADqJ9LA Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD4E30C7F@srvxchg> References: <9271EFAC-A24D-4FAE-AC69-63FA5DAE1639@Isode.com> In-Reply-To: <9271EFAC-A24D-4FAE-AC69-63FA5DAE1639@Isode.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-Approved: ondar X-Mailman-Approved-At: Mon, 22 Mar 2010 13:34:10 -0700 Cc: Security Area Directorate Subject: Re: [secdir] secdir review of draft-ietf-mmusic-rfc4756bis 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, 22 Mar 2010 18:23:52 -0000 Kurt - thank you for the review. > -----Original Message----- > From: Kurt Zeilenga [mailto:Kurt.Zeilenga@isode.com] > Sent: Wednesday, March 17, 2010 8:39 PM > To: The IESG > Cc: Security Area Directorate; draft-ietf-mmusic- > rfc4756bis.all@tools.ietf.org > Subject: secdir review of draft-ietf-mmusic-rfc4756bis >=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 > I find the Security Considerations section, which appears unchanged > from RFC 4756, adequately addresses security considerations of the > revised technical specification. >=20 > Regards, Kurt From weiler@watson.org Tue Mar 23 09:18:07 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 1D29D3A68EB for ; Tue, 23 Mar 2010 09:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 CYRrUDKUtEYI for ; Tue, 23 Mar 2010 09:18:06 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 1FA753A6CE2 for ; Tue, 23 Mar 2010 09:17:38 -0700 (PDT) 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 o2NGHvss041379 for ; Tue, 23 Mar 2010 12:17:57 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o2NGHvjw041376 for ; Tue, 23 Mar 2010 12:17:57 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 23 Mar 2010 12:17:57 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775848240A2F@NOK-EUMSG-01.mgdnok.nokia.com> Message-ID: References: <808FD6E27AD4884E94820BC333B2DB775848240A2F@NOK-EUMSG-01.mgdnok.nokia.com> 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, 23 Mar 2010 12:17:57 -0400 (EDT) Subject: [secdir] Lunch in Pacific B. Bring your own. 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 Mar 2010 16:18:07 -0000 As a reminder: On Wed, 3 Mar 2010, Pasi.Eronen@nokia.com wrote: > As usual, we're planning to have the Security Directorate > lunch on Tuesday. The room will be Pacific B. > > If there's anything special you'd like to discuss, please > drop an email to Tim, Sean, and me. Tim sent a note yesterday with lunch ideas. -- Sam From turners@ieca.com Tue Mar 23 12:02: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 B32153A6358 for ; Tue, 23 Mar 2010 12:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.095 X-Spam-Level: * X-Spam-Status: No, score=1.095 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=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 HywaAawGUA7V for ; Tue, 23 Mar 2010 12:02:55 -0700 (PDT) Received: from smtp115.biz.mail.sp1.yahoo.com (smtp115.biz.mail.sp1.yahoo.com [69.147.92.217]) by core3.amsl.com (Postfix) with SMTP id 5F0523A659A for ; Tue, 23 Mar 2010 12:02:55 -0700 (PDT) Received: (qmail 2117 invoked from network); 23 Mar 2010 19:03:12 -0000 Received: from dhcp-wireless-open-abg-24-191.meeting.ietf.org (turners@130.129.24.191 with plain) by smtp115.biz.mail.sp1.yahoo.com with SMTP; 23 Mar 2010 12:03:11 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: gSqCVaUVM1lxUIyCeSfLGCikv4AFhBUbpB1ssoLFN13.MJxJsc8E59aChokUmkXTlK_xsstcipm5jH7A0CCmL5DbHSLEhfTXVvA2axOKyZsCtNQW6m3txFol0zsSbC6eBKtfEkIlxgzHXt3siBlsZd5IunTFtpRw01MxIjP63V92qUhKnvbtD.GJI_MxrB9wX.9J.HiRcx4g3bEepnVHL.aTPFZoVIPGmQL8zK1dyc3NKwotcDr9InsZUZVQaIR2aEwzGXf4J2LvfL2eueF.j1VcbwzHdfRGZfGiXeXdNhfUv1fPdYK0BfPr6DXwZ0G1Chcy99GbeLErEno8DQ2slA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BA9106F.7070707@ieca.com> Date: Tue, 23 Mar 2010 12:03:11 -0700 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: secdir Content-Type: multipart/mixed; boundary="------------050300060707020800040903" Subject: [secdir] [Fwd: High Assurance Cryptographic API Bar BoF at IETF 77 in Anaheim, CA] 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 Mar 2010 19:02:56 -0000 This is a multi-part message in MIME format. --------------050300060707020800040903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI --------------050300060707020800040903 Content-Type: message/rfc822; name="High Assurance Cryptographic API Bar BoF at IETF 77 in Anaheim, CA.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="High Assurance Cryptographic API Bar BoF at IETF 77 in Anahe"; filename*1="im, CA.eml" X-Account-Key: account2 X-Mozilla-Keys: X-Apparently-To: turners@ieca.com via 216.252.120.76; Wed, 10 Mar 2010 10:28:23 -0800 X-YMailISG: 5MVexFMWLDuDVOBsMF_puxc7dUTiCWTK.FB7GxhAusQGr8aFj0TtH4bMfe39al3tWMdRpIhUqZatIiRe0fXvXpG5wjATWAoNAgMRwWNQ.BUtq1k_reHSsgB4sVunYR7SoDf4lqxNcm7zLLmZaxcXTlMafC5l5jmPqGFDlDVUlZuwyiTFMfn7VnuFWeZdMY77F0RUBS1Ca09bz9h8dFV7DiWffEVZ0dV7h5dCsIt2yH.ddCElQrqzxlgRYc4o_YbtdipG6cO_QC5RWX9kes8PlexOdvo_1u2xouRDdAmJhdtwwZMkbPUU.witOJgH7YpuEzg5wFajn_HA4jhs.3XrdTxrjNc36.rAleTbg32tQvsvufK9Rhz.L8P6iXSr_tXW0AFpC.LJjUaY2b2iVCV0UKMy5_pDFn1qaPQjchN4B8nmjJ0- X-Originating-IP: [64.170.98.32] Authentication-Results: mta124.biz.mail.mud.yahoo.com from=; domainkeys=neutral (no sig); from=mitre.org; dkim=neutral (no sig) Received: from 64.170.98.32 (EHLO mail.ietf.org) (64.170.98.32) by mta124.biz.mail.mud.yahoo.com with SMTP; Wed, 10 Mar 2010 10:28:23 -0800 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21CC23A6A93; Wed, 10 Mar 2010 10:28:06 -0800 (PST) X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152853A6972; Wed, 10 Mar 2010 07:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 9DcS9jmPToQP; Wed, 10 Mar 2010 07:28:18 -0800 (PST) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id CF3A43A67CC; Wed, 10 Mar 2010 07:28:17 -0800 (PST) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o2AFSLwn007050; Wed, 10 Mar 2010 10:28:21 -0500 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o2AFSLx4007044; Wed, 10 Mar 2010 10:28:21 -0500 Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Wed, 10 Mar 2010 10:28:21 -0500 From: "Novikov, Lev" To: IETF-Announce , IETF-77 <77attendees@ietf.org> Date: Wed, 10 Mar 2010 10:28:20 -0500 Subject: High Assurance Cryptographic API Bar BoF at IETF 77 in Anaheim, CA Thread-Topic: High Assurance Cryptographic API Bar BoF at IETF 77 in Anaheim, CA Thread-Index: AcrAZlCsCC2ad0H2S7KTdTNlGPV9pA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 10 Mar 2010 10:28:04 -0800 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org There will be a bar BoF on high assurance cryptographic APIs during IETF 77. When: Tue, March 23, 2010 from 17:30 - 19:00 (tentatively) Where: Mix Restaurant (in the Hilton Anaheim) Menu available at: http://www1.hilton.com/en_US/hi/hotel/SNAAHHH-Hilton-Anaheim-California/dining.do#1 Commercial cryptographic APIs (e.g., PKCS#11) are not suitable for high assurance cryptographic devices that have special considerations (e.g., security domain separation, rich module & key management). We'd like to discuss the problems surrounding creating a logical model for high assurance cryptographic devices and a potential solution we've published as an Internet-Draft: https://datatracker.ietf.org/drafts/draft-lanz-cicm/ Interested parties are invited to join our IETF mailing list for potential updates on the bar BoF and/or other matters relating to high assurance cryptographic APIs: https://www.ietf.org/mailman/listinfo/cicm Thanks, Lev Novikov The MITRE Corporation _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --------------050300060707020800040903-- From paul.hoffman@vpnc.org Tue Mar 23 12:43:44 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 C08C43A69F2 for ; Tue, 23 Mar 2010 12:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 1cxDttblQ7py for ; Tue, 23 Mar 2010 12:43:43 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8369E3A699F for ; Tue, 23 Mar 2010 12:43:43 -0700 (PDT) Received: from [10.6.19.70] (dhcp-wireless-open-a-40-51.meeting.ietf.org [130.129.40.51]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o2NJi1xX064843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Mar 2010 12:44:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 23 Mar 2010 12:44:00 -0700 To: secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [secdir] FNV web site 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 Mar 2010 19:43:44 -0000 --Paul Hoffman, Director --VPN Consortium From aland@deployingradius.com Tue Mar 23 12:47:19 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 EFC273A69B5 for ; Tue, 23 Mar 2010 12:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 hOWyaWnQXOq6 for ; Tue, 23 Mar 2010 12:47:19 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id D78B63A699F for ; Tue, 23 Mar 2010 12:47:18 -0700 (PDT) Received: from dhcp-wireless-open-abg-27-214.meeting.ietf.org (dhcp-wireless-open-abg-27-214.meeting.ietf.org [130.129.27.214]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 5480B1234566 for ; Tue, 23 Mar 2010 20:47:37 +0100 (CET) Message-ID: <4BA91AD8.3060000@deployingradius.com> Date: Tue, 23 Mar 2010 12:47:36 -0700 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: secdir@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] FNV web site 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 Mar 2010 19:47:20 -0000 Paul Hoffman wrote: > If hash distribution matters, see: http://sites.google.com/site/murmurhash/avalanche ... This is why you probably shouldn't use FNV. Both low bits of the hash and end bits of the key aren't thorougly mixed. ... If hash distributions don't matter, FNV is very fast. Alan DeKok. From d3e3e3@gmail.com Tue Mar 23 12:51: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 B8B4B3A6784 for ; Tue, 23 Mar 2010 12:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.282 X-Spam-Level: * X-Spam-Status: No, score=1.282 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 iKitExYaoILR for ; Tue, 23 Mar 2010 12:51:35 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 64D4F3A659A for ; Tue, 23 Mar 2010 12:51:35 -0700 (PDT) Received: by wyb29 with SMTP id 29so3226118wyb.31 for ; Tue, 23 Mar 2010 12:51:50 -0700 (PDT) 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; bh=MLwoASf4wkONE8gXSdiNF6y7EKClnCKsf8JJ5Nif+u8=; b=KIWMjIoZ9c2Wa3UadCFSSUIyP0COOIP00/Uu2fwtTrNIX3VpbVLu2BhWd8LzT8Hr5j IVBe0i3RCgP/CmVZwNAKUGWTMewqbamEPCIw0R0H3ZsjpFS5tu2WzhKw28OXVHRBwAT8 NNdTcfUB07s6B2OL5zQbCCCa77kQ4B8QAb16g= 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; b=eQ5GcUfYGkyu81U/pFMl9Taeya9NgAM+It1KvjAK4B8DVqSTh5f7zPU+8zuXramJkw egL/tI+q+soCi90dnwJV8zoojPa2yHcRmn5AoMo4Ul2KTiQU10tMgnaJ8woOtVzUJIZ/ sa/XAZFdo5p4hf/U9ZWkA0M1p5SHvkaQvbTW4= MIME-Version: 1.0 Received: by 10.216.89.84 with SMTP id b62mr3780328wef.226.1269373910709; Tue, 23 Mar 2010 12:51:50 -0700 (PDT) In-Reply-To: <4BA91AD8.3060000@deployingradius.com> References: <4BA91AD8.3060000@deployingradius.com> Date: Tue, 23 Mar 2010 15:51:50 -0400 Message-ID: <1028365c1003231251j1ce360eev574b34f7fd910621@mail.gmail.com> From: Donald Eastlake To: Alan DeKok Content-Type: multipart/alternative; boundary=0016e6d9710208ffbe04827d25ca Cc: secdir@ietf.org Subject: Re: [secdir] FNV web site 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 Mar 2010 19:51:36 -0000 --0016e6d9710208ffbe04827d25ca Content-Type: text/plain; charset=ISO-8859-1 So, couldn't you just use it to compute twice as many hash bits as you need and then xor the top and bottom half of the output to fix this flaw? Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street +1-508-634-2066 (home) Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Mar 23, 2010 at 3:47 PM, Alan DeKok wrote: > Paul Hoffman wrote: > > > > If hash distribution matters, see: > > http://sites.google.com/site/murmurhash/avalanche > ... > This is why you probably shouldn't use FNV. Both low bits of the hash > and end bits of the key aren't thorougly mixed. > ... > > > If hash distributions don't matter, FNV is very fast. > > Alan DeKok. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > --0016e6d9710208ffbe04827d25ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So, couldn't you just use it to compute twice as many hash bits as you = need and then xor the top and bottom half of the output to fix this flaw?
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
Donald E. Eastlake 3rd =A0 +1-508-333-2270 (cell)
155 Beaver Street = =A0 +1-508-634-2066 (home)
Milford, MA 01757 USA
d3e3e3@gmail.com


On Tue, Mar 23, 2010 at 3:47 PM, Alan De= Kok <alan= d@deployingradius.com> wrote:
Paul Hoffman wrote:
> <http://isthe.com/chongo/tech/comp/fnv/>

=A0If hash distribution matters, see:

http://sites.google.com/site/murmurhash/avalanche
...
This is why you probably shouldn't use FNV. Both low bits of the hash and end bits of the key aren't thorougly mixed.
...


=A0If hash distributions don't matter, FNV is very fast.

=A0Alan DeKok.
__________________________________= _____________
secdir mailing list
secdir@ietf.org
= https://www.ietf.org/mailman/listinfo/secdir

--0016e6d9710208ffbe04827d25ca-- From william.polk@nist.gov Tue Mar 23 13:24:27 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 DAD0E3A6784 for ; Tue, 23 Mar 2010 13:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.184 X-Spam-Level: X-Spam-Status: No, score=-4.184 tagged_above=-999 required=5 tests=[AWL=1.285, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 e2CjiO7SOc5k for ; Tue, 23 Mar 2010 13:24:27 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 7D3D33A684F for ; Tue, 23 Mar 2010 13:24:16 -0700 (PDT) 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 o2NKOIbv008562 for ; Tue, 23 Mar 2010 16:24:18 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Tue, 23 Mar 2010 16:24:18 -0400 From: "Polk, William T." To: "secdir@ietf.org" Date: Tue, 23 Mar 2010 16:28:47 -0400 Thread-Topic: mac power cord at registration desk Thread-Index: AcrKx3Cb3adWkITvNUepzP5JXQCtHA== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Subject: [secdir] mac power cord at registration desk 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 Mar 2010 20:24:28 -0000 Folks, If you are missing a macintosh power cord, it may have been left at the security directorate lunch.... Check with the folks at the registration desk. Thanks, Tim From thomas@thomasclausen.org Tue Mar 23 14:50:21 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 AEE3C3A6BF4; Tue, 23 Mar 2010 14:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 5sjS8k+yjnXr; Tue, 23 Mar 2010 14:50:20 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id E4A203A6C45; Tue, 23 Mar 2010 14:50:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id C40E032356B5; Tue, 23 Mar 2010 14:50:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [172.27.171.249] (207.88.181.2.ptr.us.xo.net [207.88.181.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 8D2913228088; Tue, 23 Mar 2010 14:50:40 -0700 (PDT) Message-Id: <4112EE01-AEB6-435C-95DC-2EBAF5AA3E75@thomasclausen.org> From: Thomas Heide Clausen To: Shawn M Emery In-Reply-To: <4B9F2B36.3060700@oracle.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 23 Mar 2010 22:50:40 +0100 References: <4B9F2B36.3060700@oracle.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Tue, 23 Mar 2010 14:53:19 -0700 Cc: draft-ietf-manet-nhdp.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-manet-nhdp-11 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 Mar 2010 21:50:21 -0000 Dear Shawn, Thank you for your review. We have updated the document to reflect your comments -- and thank you profoundly for the efforts that you have put in to helping us improve the document quality. The updated document should be submitted to the repository shortly. Sincerely, Thomas On Mar 16, 2010, at 07:54 AM, Shawn M Emery wrote: > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This draft describes a protocol for a one-hop and a symmetric two-hop > neighborhood discovery for mobile ad hoc networks (MANETs). > > The security considerations section does exist and discusses the > various > attack scenarios. The first being HELLO messages that are correctly > formatted, but malicious. Preventing this scenario can be handled in > different ways depending on the constraints in which the protocol is > deployed; physical or proximity access, link-layer authentication, > integrity checks, and confidentiality. > > Then the section suggests how to protect HELLO messages for this > protocol by using the same mechanisms that RFC5444 outlines. For > integrity; using signatures in Message TLV or Packet TLVs. For > privacy; > using link-layer protection, IPsec, or encrypting the Value field and > specifying the encrypted TLV type for the associated message. It > might > be helpful if they state something like this instead of just referring > to 5444 for confidentiality. Other than this, I believe that the > section covers the possible issues and their respective solution. > > General comments: > > None. > > Editorial comments: > > 5.5. Parameter Change Constraints > > The first occurrence of L_time and NL_time should have their > corresponding definition. > > > 9.2. Removing an Interface > > s/router will longer participate/router will no longer participate/ > > > 9.3. Adding a Network Address to an Interface > > s/network address is removed/network address, is removed/ > > -- > Shawn. > From gregory.ietf@gmail.com Wed Mar 24 01:12: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 9B7BA3A68F6; Wed, 24 Mar 2010 01:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.075 X-Spam-Level: X-Spam-Status: No, score=-98.075 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, USER_IN_WHITELIST=-100] 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 qTkn65MvhfPN; Wed, 24 Mar 2010 01:12:20 -0700 (PDT) Received: from mail-iw0-f197.google.com (mail-iw0-f197.google.com [209.85.223.197]) by core3.amsl.com (Postfix) with ESMTP id EF13D3A6C71; Wed, 24 Mar 2010 01:12:13 -0700 (PDT) Received: by iwn35 with SMTP id 35so4608119iwn.31 for ; Wed, 24 Mar 2010 01:12:31 -0700 (PDT) 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; bh=0JOQBjRM6WMPD3rGvAdG9rpsbaE0017fHQq0eciWK68=; b=kL4AlW/xAlr3RQxFLBTZpqh/TCLu/pe5QYiD8y2kNtAm49LSF8/BW7PBeuzZRL6CUJ kyeSSZXl7WqvQ9ISHjiFxsLgJfCRuDp+bQHQ05bBQK/xxxNR01YAds55/riFC5TdGFet AJatpsJ8Uv49fbrxzOBzYBfekUcHQmzgUyF1Y= 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; b=TilXYNmaIOuDnClFMygvbJ29+7wqUL+ZIYoFkgmvCjZHeHpXpi6XrNjLb/vYnCUU0U hAy5EeSNHq+vOMjoRfYSmNMl/X6sQNAbpmcfJweFg6ibuJxa2tQ7V75VtHz54xOKrG63 744eeZLp6Q0meR4DBxsJ6V0u+0yYgO8rr4PvA= MIME-Version: 1.0 Received: by 10.231.169.144 with SMTP id z16mr1520599iby.25.1269418351280; Wed, 24 Mar 2010 01:12:31 -0700 (PDT) In-Reply-To: <2f57b9e61003082235v4fabe601w2e3f4c3fed5a1c71@mail.gmail.com> References: <2f57b9e61003052142s36ec86baj3aa54ddac604ef6e@mail.gmail.com> <2f57b9e61003082235v4fabe601w2e3f4c3fed5a1c71@mail.gmail.com> Date: Wed, 24 Mar 2010 01:12:31 -0700 Message-ID: From: Gregory Lebovitz To: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= Content-Type: multipart/alternative; boundary=0016e6d26c5ae642ba0482877d85 Cc: magnus.westerlund@ericsson.com, Eric Rescorla , tcpm@ietf.org, secdir@ietf.org, Tim Polk , iesg@ietf.org, lars.eggert@nokia.com Subject: Re: [secdir] Secdir review of draft-ietf-tcpm-tcp-ao-crypto-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 Mar 2010 08:12:22 -0000 --0016e6d26c5ae642ba0482877d85 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable all the below changes indicated, plus the editorial suggestions indicated i= n Magnus' Mar 05 email, are included in -03, which I'll publish shortly. See comments inline... On Mon, Mar 8, 2010 at 11:35 PM, Magnus Nystr=F6m wrote= : > Thanks Gregory - a couple of comments below, inline. > > On Mon, Mar 8, 2010 at 9:52 PM, Gregory Lebovitz > wrote: > > Hey Magnus, > > Thanks a lot for the review. Comments inline below... > > > > On Fri, Mar 5, 2010 at 9:42 PM, Magnus Nystr=F6m > wrote: > >> > >> I have reviewed this document as part of the security directorate's > >> ongoing effort to review all IETF documents being processed by the > >> IESG. These comments were written primarily for the benefit of the > >> security area directors. Document editors and WG chairs should treat > >> these comments just like any other last call comments > >> > >> This document specifies requirements on cryptographic algorithms to be > >> used in the TCP Authentication Option (TCP APO). It also specifies > >> some mandatory algorithms. > >> > >> Comments: > >> > >> Abstract: > >> > >> - The abstract does not mention that the document also specifies > >> requirements on future algorithms. IMO, it should. > > > > Ok > done > > > >> > >> Section 1: > >> (- Last paragraph is what prompted my comment on the abstract.) > >> > >> Section 2.2: > >> > >> - Suggest moving the note explaining the need to mandate two MAC > >> algorithms to the Security Considerations section as it does not > >> contain normative text but does contain security considerations. > > > > Good point. When I originally wrote this text it did contain normative > text. > > Then I got some feedback that maybe we should down-grade the text to be > > non-normative, but still clear guidance. If you think it makes a big > > difference, I can move it. Otherwise, I'd like to keep it with the text > > describing the "template" for how all TCP-AO algos are used, so that > people > > who are looking for the template will see the text right there, whereas > they > > might miss it if they are skimming and don't make it all the way to the > SC > > section. Let me know what you think. > > You could also place the note in the Security Considerations section > and then just reference it in 2.2, like "For an explanation of the > need for two MAC algorithms, see the Security Considerations section." > I think that would be better, keeping all security considerations in > one place. > done > > >> - Section 3.1.1.3: > >> > >> - It is a little surprising to see that the SHA-1-based MAC algorithm > >> is selected as the default one, given that this is a new specification > >> and the industry is moving away from SHA-1. C.f. the work on XML > >> Encryption 1.1 and XML Signature 1.1 that specificallly recommends > >> against use of SHA-1 in new applications. > > > > In TCP-AO SHA-1 is used as an HMAC, not a signing algo, so it does not > have > > the same properties in this context, and has shown no weaknesses, afaik= . > As > > you can imagine we had a very long debate around which algo to make > > mandatory. In the end (as the text was supposed to explain), Pasi and T= im > > chose SHA-1 for both its strength and its wide availability in the targ= et > > devices (routers -- this is first and foremost being done for BGP > > protection). But, since it's been around a while, and we always want to > have > > 2 good algos in place, one the older more available, and a newer > > up-and-comer, the AES was also specified. Unless Pasi and Tim want to > change > > their recommendations to the TCPM WG, we'll probably sit tight with thi= s > the > > way it reads currently. > > Yes, I can (and did...) imagine you had lengthy discussions around > this... OK, since Pasi and Tim chose it I will rest my case... > > Best, > -- Magnus > > >> - Section 6 (Security Considerations): > >> > >> In the fourth paragraph, there is a discussion around the fact that > >> the document does not force use of a 16 octet key. I think it would be > >> useful to at least clearly state a recommended minimum key size. > > > > Interesting point. We had this debate in WG too. > > My .02: this is a security vs convenience thing. We give the deployer > > plenty enough guidance and pointers to other RFC's and NIST docs to all= ow > > them to do their homework to decide what length key they want, stopping > just > > short of telling them a recommended min key size. The deployers here ar= e > > router operators, for the most part. The ones that have a clue are > already > > using 128bit keys, generated randomly. The ones that aren't probably > aren't > > going to read this document anyway. > > Any thoughts from Tim or EKR? > No change made. Gregory. --=20 ---- IETF related email from Gregory M. Lebovitz Juniper Networks --0016e6d26c5ae642ba0482877d85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable all the below changes indicated, plus the editorial suggestions indicated i= n Magnus' Mar 05 email, are included in -03, which I'll publish sho= rtly. See comments inline...

On Mon, Mar = 8, 2010 at 11:35 PM, Magnus Nystr=F6m <magnusn@gmail.com> wrote:
Thanks Gregory - a couple of comments below= , inline.

On Mon, Mar 8, 2010 at 9:52 PM, Gregory Lebovitz <gregory.ietf@gmail.com> wrote:
> Hey Magnus,
> Thanks a lot for the review. Comments inline below...
>
> On Fri, Mar 5, 2010 at 9:42 PM, Magnus Nystr=F6m <magnusn@gmail.com> wrote:
>>
>> I have reviewed this document as part of the security directorate&= #39;s
>> ongoing effort to review all IETF documents being processed by the=
>> IESG. =A0These comments were written primarily for the benefit of = the
>> security area directors. =A0Document editors and WG chairs should = treat
>> these comments just like any other last call comments
>>
>> This document specifies requirements on cryptographic algorithms t= o be
>> used in the TCP Authentication Option (TCP APO). It also specifies=
>> some mandatory algorithms.
>>
>> Comments:
>>
>> Abstract:
>>
>> - The abstract does not mention that the document also specifies >> requirements on future algorithms. IMO, it should.
>
> Ok

done
=A0<= /div>
>
>>
>> Section 1:
>> (- Last paragraph is what prompted my comment on the abstract.) >>
>> Section 2.2:
>>
>> - Suggest moving the note explaining the need to mandate two MAC >> algorithms to the Security Considerations section as it does not >> contain normative text but does contain security considerations. >
> Good point. When I originally wrote this text it did contain normative= text.
> Then I got some feedback that maybe we should down-grade the text to b= e
> non-normative, but still clear guidance. If you think it makes a big > difference, I can move it. Otherwise, I'd like to keep it with the= text
> describing the "template" for how all TCP-AO algos are used,= so that people
> who are looking for the template will see the text right there, wherea= s they
> might miss it if they are skimming and don't make it all the way t= o the SC
> section. Let me know what you think.

You could also place the note in the Security Considerations se= ction
and then just reference it in 2.2, like "For an explanation of the
need for two MAC algorithms, see the Security Considerations section."=
I think that would be better, keeping all security considerations in
one place.

done
=A0

>> - Section 3.1.1.3= :
>>
>> - It is a little surprising to see that the SHA-1-based MAC algori= thm
>> is selected as the default one, given that this is a new specifica= tion
>> and the industry is moving away from SHA-1. C.f. the work on XML >> Encryption 1.1 and XML Signature 1.1 that specificallly recommends=
>> against use of SHA-1 in new applications.
>
> In TCP-AO SHA-1 is used as an HMAC, not a signing algo, so it does not= have
> the same properties in this context, and has shown no weaknesses, afai= k. As
> you can imagine we had a very long debate around which algo to make > mandatory. In the end (as the text was supposed to explain), Pasi and = Tim
> chose SHA-1 for both its strength and its wide availability in the tar= get
> devices (routers -- this is first and foremost being done for BGP
> protection). But, since it's been around a while, and we always wa= nt to have
> 2 good algos in place, one the older more available, and a newer
> up-and-comer, the AES was also specified. Unless Pasi and Tim want to = change
> their recommendations to the TCPM WG, we'll probably sit tight wit= h this the
> way it reads currently.

Yes, I can (and did...) imagine you had lengthy discussions around this... OK, since Pasi and Tim chose it I will rest my case...

Best,
-- Magnus

>> - Section 6 (Security Considerations):
>>
>> In the fourth paragraph, there is a discussion around the fact tha= t
>> the document does not force use of a 16 octet key. I think it woul= d be
>> useful to at least clearly state a recommended minimum key size. >
> Interesting point. We had this debate in WG too.
> My .02: =A0this is a security vs convenience thing. We give the deploy= er
> plenty enough guidance and pointers to other RFC's and NIST docs t= o allow
> them to do their homework to decide what length key they want, stoppin= g just
> short of telling them a recommended min key size. The deployers here a= re
> router operators, for the most part. The ones that have a clue are alr= eady
> using 128bit keys, generated randomly. The ones that aren't probab= ly aren't
> going to read this document anyway.
> Any thoughts from Tim or EKR?

No change made.

Gregory.=A0


--
----
IETF related email from
Gregory M.= Lebovitz
Juniper Networks
--0016e6d26c5ae642ba0482877d85-- From Pasi.Eronen@nokia.com Thu Mar 25 10:03:28 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 A9E8F3A6CA5; Thu, 25 Mar 2010 10:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.24 X-Spam-Level: X-Spam-Status: No, score=-3.24 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 iPa-V+gjy7v9; Thu, 25 Mar 2010 10:03:26 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A18903A6B45; Thu, 25 Mar 2010 10:03:24 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o2PH3MSr029827; Thu, 25 Mar 2010 19:03:43 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Mar 2010 19:03:39 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Mar 2010 19:03:30 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Mar 2010 19:03:25 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 25 Mar 2010 18:03:24 +0100 From: To: , Date: Thu, 25 Mar 2010 18:03:33 +0100 Thread-Topic: Pasi's final AD notes (mid-March 2010) Thread-Index: AcrMPRnbkVve3ufeQ2G8k87U2/6Jdw== Message-ID: <808FD6E27AD4884E94820BC333B2DB775848688C66@NOK-EUMSG-01.mgdnok.nokia.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-OriginalArrivalTime: 25 Mar 2010 17:03:25.0088 (UTC) FILETIME=[15001A00:01CACC3D] X-Nokia-AV: Clean Subject: [secdir] Pasi's final AD notes (mid-March 2010) 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, 25 Mar 2010 17:03:28 -0000 I'm writing an expanded version of my notes so that Sean and Tim will have the information they need to continue the work. If you notice anything that doesn't look right, let Sean and Tim know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D - Planning AD transition with Tim/Sean - IETF 77 planning with Tim/Sean: SAAG meeting, SecDir=20 lunch, overall agenda - (not wearing AD hat) draft-krawczyk-hkdf was approved by IESG; now in RFC editor queue. - (not wearing AD hat) Waiting for Dan Romascanu to process=20 errata 1955/1956 for RFC 4072 [since 2009-12-09] - Lot of tools work to finish the datatracker UI changes. DKIM =3D=3D=3D=3D - draft-ietf-dkim-deployment: was approved by IESG, now in RFC editor queue. If the WG decides to change its mind about errata 1532 (see below), appendix A.1.2.3 could require small changes. - Processed errata 1942. - Errata 1532 for RFC 4871: Currently (March 2010) being discussed. Waiting for the WG chairs to drive the discussion, and send the exact new text and recommended status to Sean. The conclusion back in 2008 is here: http://mipassoc.org/pipermail/ietf-dkim/2008q4/010820.html The dkim-deployment draft, appendix A.1.2.3 seems to be aligned the conclusion above. But given that we now have the dkim-deployment document ready (which has the recommendations for e.g. DomainKeys deployers), we probably want to edit the 2008 text slightly (at the very least, add a pointer to dkim-deployment) before marking it as "verified". - Errata 1596 for RFC 4871. Waiting for the WG chairs to drive the discussion, and send the exact new text and recommended status to Sean. Relevant emails from 2008: http://mipassoc.org/pipermail/ietf-dkim/2008q4/010820.html http://mipassoc.org/pipermail/ietf-dkim/2008q4/010818.html - The WG is currently (February-March 2010) discussing rechartering; Waiting for the chairs to send agreed text to IESG. EMU =3D=3D=3D - The WG chairs have the token for doing something about ITU-T=20 X.1034 liaison statement. IPSECME =3D=3D=3D=3D=3D=3D=3D - draft-ietf-ipsecme-traffic-visibility: in RFC editor queue. Nothing special to note. - draft-ietf-ipsecme-esp-null-heuristics: was approved by IESG; now in RFC editor queue. Nothing special to note. - Processed errata 1919 (for RFC 4106) and 1937 (for RFC 4307). - draft-ietf-ipsecme-aes-ctr-ikev2: The draft was updated to address my AD review comments, but WG members found couple of additional minor nits that should be fixed before starting IETF last call. Waiting for authors to submit a revised ID [since early March 2010]. - draft-ietf-ipsecme-roadmap: I think we've roughly agreed on how to address my AD review comments; waiting for the authors to=20 submit a revised ID [since March 2010]. ISMS =3D=3D=3D=3D - draft-ietf-isms-dtls-tm: currently in IETF Last Call; ends 2010-04-02. Nothing special to note. KEYPROV =3D=3D=3D=3D=3D=3D=3D - draft-ietf-keyprov-pskc and draft-ietf-keyprov-symmetrickeyformat:=20 current in Publication Requested, waiting for Tim to do his=20 AD review. SASL =3D=3D=3D=3D - draft-ietf-sasl-gs2 and draft-ietf-sasl-scram: in RFC editor queue, waiting for draft-altman-tls-channel-bindings. =20 These went to AUTH48 already once; I approved the AUTH48 changes, but we changed draft-altman-tls-channel-bindings (see below) to=20 be a normative reference, so they went from AUTH48 to MISSREF. =20 The authors are currently discussing whether SCRAM needs some minor changes and/or clarifications related to error messages ("e=3D" parameter). - (not WG item) draft-altman-tls-channel-bindings:=20 Back in October/early November 2009 there were discussions about how to make the text clearer about TLS session resumption and/or renegotiation. Although we mostly agreed on clearer text back then, the discussions were put on hold while the TLS renegotiation fix was done. However, the latest emails (March 2010) suggest that the text in -07 draft (and the 'tls-unique' IANA registration) isn't anywhere close to what Microsoft has actually implemented. The current plan is to update the draft (and IANA registration, when the draft is approved) to match what Microsoft implemented. However, this MUST be double-checked with Mark Novak, as the information about what the Microsoft code actually does has been somewhat inconsistent in the past. Alexey will be the responsible AD for this draft. - (not WG item) draft-melnikov-sasl-scram-ldap: in=20 RFC editor queue/AUTH48 (waiting for GS2 and SCRAM).=20 Thankfully, nothing special to note for this draft :-) - Errata 1812 for RFC 4013: I think the current text in the=20 errata is OK, and it should be marked as "Verified" -- but I'm waiting for OK from Kurt (author of RFC 4013) before=20 approving this [since 2010-03-12]. SYSLOG =3D=3D=3D=3D=3D=3D - draft-ietf-syslog-sign: in RFC editor queue. Nothing special to note. - draft-ietf-syslog-dtls: still in WG, but probably coming to=20 AD Evaluation soon. I'm expecting that all the security-related issues will be exactly the same as in RFC 5425 (Syslog over TLS/TCP), and UDP-related issues (like MTU, congestion, etc.) will be the same as in RFC 5426 (Syslog over UDP), and only very few DTLS-specific details will be new to this document. (And the new text about DCCP probably should be checked carefully.) Currently it looks like the document is copying some text from RFC 5425/5426, so it's not very clear what is new and what is the same. My guess is that it's easier to get this through IESG if we're referencing text instead of copying it... TLS =3D=3D=3D - draft-ietf-tls-extractor: published as RFC 5705. - draft-ietf-tls-rfc4366-bis: waiting for WG chairs/editor to=20 drive discussion/propose text about the following topics: 1) The "server_name" extension contains a list of domain names. Apparently, existing clients only send one, and some servers ignore everything except the first one. Since it seems nobody is using multiple names (and there are some unclear aspects about their exact semantics), perhaps the spec should just forbid more than one name of same "name_type"? 2) The document probably should be clearer about how "server_name" and session resumption interact (or do not interact). In particular, are Session IDs scoped by "server_name"? (If they are, the client MUST send the same "server_name" when resuming a session.) If they are not, does the server ignore the "server_name" when it resumes the session (in case the "server_name" in the original session was different) or not? IMHO RFC 4366 is quite clear that "server_name" is completely ignored when the server resumes a session (so Session IDs are not scoped by "server_name", and the server does not check it against the original session), but perhaps it doesn't hurt to clarify this with some new text. 3) As noted in Stephen Farrell's SecDir review (http://www.ietf.org/mail-archive/web/secdir/current/msg01195.html), the document probably should explain why SHA-1 is OK and algorithm agility is not needed. Tim and I have agreed with the WG that this use of SHA-1 (without algorithm agility) is acceptable.=20 "trusted_ca_keys" clearly does not need a cryptographic function, and client_certificate_url does not seem to be affected by collisions either (and this extension is rarely used, so creating a new extension with agility is not really useful work). 4) Joe thought the WG should also consider whether the renegotiation fix has any effect on the "server_name" extension. I don't think it necessarily does (beyond the one sentence that's already in RFC 5746). - (not WG item yet) draft-seggelmann-tls-dtls-heartbeat: waiting for the WG chairs to determine whether to take this as WG item. - (not WG item) see SASL WG for draft-altman-tls-channel-bindings - There is one errata (1077 for RFC 2818), but it's very unclear what, if anything, should be done about it. I've understood that the text in RFC 2818 isn't exactly what e.g. the major browsers do, but it seems this errata isn't either (and no, the major browsers don't all do the same thing either :-). Since there hasn't been any discussion about this errata, I'm just leaving it as "Reported"... =20 DISCUSSES =3D=3D=3D=3D=3D=3D=3D=3D=3D draft-ietf-geopriv-lis-discovery Discussion currently ongoing. The authors have proposed simply noting that the security depends on DNS, but I would really like to see better arguments than "it's simpler to implement with some HTTP libraries" for ignoring this important security advice from RFC 3958. To me it looks like someone implementing HELD and this discovery mechanism can pick one of the many libraries that does support this, and this is not something that e.g. would have to work with all currently deployed web browsers. LoST had a quite reasonable description (RFC 5222, Section 18) why the approach recommended in RFC 3958 would not actually work in the deployment scenarios envisioned for LoST. But it seems the deployment considerations would HELD would be quite different, and the same argument does not apply here. draft-zorn-radius-pkmv1 I have sent Glen proposed text on 2010-03-11; waiting for his answer. =20 I'm also hoping Glen reverts back to version -10 which used the RFC 2119 keywords (these were in the version sent to IESG, but got removed in -11), but that's not part of my DISCUSS. draft-ietf-bmwg-ipsec-meth/draft-ietf-bmwg-ipsec-term=20 For ipsec-meth Section 12.x (where the proposed methodology measures setup latency, not setup rate), I think we've agreed to move those tests to an appendix (with a note saying they're not useful for comparing implementations, but might be still useful for internal SW/HW development). For other changes, I'm waiting for authors to submit revised IDs [since 2010-01-29] draft-cheshire-dnsext-nbp It has been 15 months since my DISCUSS, and I have been unable to get a single email reply from the author, despite pinging him and the responsible AD every couple of months. IMHO first asking the IESG to consider a document and then refusing to answer emails for this long is rude behavior. If the author doesn't have sufficient energy to engage in a discussion, he shouldn't have asked the IESG to consider this in this first place. I have asked Ralph to end this farce and declare the document dead several times, but he keeps saying the author has promised to work on this soon (but it's been "soon" for more then 8 months now). Since it seems the author has lost all interest, I'm not expecting this to really progress anywhere. The DISCUSS itself wouldn't be very difficult to address: the first and third concern are just one or two sentences. The second concern probably needs more thinking, but even then, I'm not expecting this document to come up with new solutions to known-to-be-difficult problems, just being realistic about a protocol might do (so text-wise, that could be something like two paragraphs). draft-ietf-tsvwg-port-randomization I think we have agreed on the changes (below); waiting for the authors to submit a revised ID [since 2010-03-04] Section 3.3.1: rephprase as "random() is a function that returns a 32-bit pseudo-random unsigned integer number. Note that the output needs to be unpredictable, and typical implementations of POSIX random() function do not necessarily meet this requirement. See [RFC4086] for randomness requirements for security." Section 3.4: recommend 128 bit keys instead of 32. draft-ietf-smime-cms-rsa-kem For the first issue (alignment with 18033-2/X9.44), I'm waiting for a reply from the authors [since 2010-03-11]. The second and third issues are minor, and I think we've agreed on the changes already. draft-ietf-csi-hash-threat Waiting for the authors to submit a revised ID to address the comments from SecDir [since 2010-03-11]. --end-- From stefan@aaa-sec.com Mon Mar 29 02:34:39 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 A732B3A68FA for ; Mon, 29 Mar 2010 02:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.481 X-Spam-Level: X-Spam-Status: No, score=0.481 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35, 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 oWsPAGGDcggG for ; Mon, 29 Mar 2010 02:34:38 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by core3.amsl.com (Postfix) with ESMTP id 1F93A3A67F5 for ; Mon, 29 Mar 2010 02:34:36 -0700 (PDT) Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E289229B492 for ; Mon, 29 Mar 2010 11:31:58 +0200 (CEST) Received: (qmail 78437 invoked from network); 29 Mar 2010 09:31:54 -0000 Received: from unknown (HELO [192.168.1.3]) (stefan@fiddler.nu@[85.235.2.114]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 Mar 2010 09:31:54 -0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 29 Mar 2010 11:31:53 +0100 From: Stefan Santesson To: Alan DeKok , Message-ID: Thread-Topic: [secdir] FNV web site Thread-Index: AcrPIqqCVi8YjmaTQ0+Sxlm+B2HSzg== In-Reply-To: <4BA91AD8.3060000@deployingradius.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [secdir] FNV web site 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, 29 Mar 2010 09:34:39 -0000 I assume that the result for the modified FNV is the FNV-1a. I would suggest using the FNV-1a over FNV-1 since FNV-1 has the downside that the last octet to hash only influence the lowest 8 bits of hash. The result for FNV-1a seems OK. /Stefan On 10-03-23 12:47 PM, "Alan DeKok" wrote: > Paul Hoffman wrote: >> > > If hash distribution matters, see: > > http://sites.google.com/site/murmurhash/avalanche > ... > This is why you probably shouldn't use FNV. Both low bits of the hash > and end bits of the key aren't thorougly mixed. > ... > > > If hash distributions don't matter, FNV is very fast. > > Alan DeKok. > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From pcain@coopercain.com Mon Mar 29 14:16: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 DEEA13A6975; Mon, 29 Mar 2010 14:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2] 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 r99H1h98NlHr; Mon, 29 Mar 2010 14:16:44 -0700 (PDT) Received: from server1.acmehacking.com (server1.acmehacking.com [72.51.39.79]) by core3.amsl.com (Postfix) with ESMTP id A50D93A694E; Mon, 29 Mar 2010 14:16:44 -0700 (PDT) Received: from familyroom (phoneroom10.bc.edu [136.167.27.76]) (authenticated bits=0) by server1.acmehacking.com (8.14.3/8.13.8) with ESMTP id o2TLH5VJ024661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Mar 2010 16:17:11 -0500 Received: from familyroom by familyroom (PGP Universal service); Mon, 29 Mar 2010 17:17:12 -0500 X-PGP-Universal: processed; by familyroom on Mon, 29 Mar 2010 17:17:12 -0500 From: "Patrick Cain" To: , Date: Mon, 29 Mar 2010 17:17:05 -0400 Message-ID: <017001cacf85$327ccc40$977664c0$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrPhR7+0oqLAfTnQw2+aOdEigah5Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us Cc: iesg@ietf.org Subject: [secdir] secdir review of: draft-ietf-behave-turn-tcp-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, 29 Mar 2010 21:16:48 -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. The document defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for NAT traversal, to allow a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client's peers. After reading the other four-letter protocol specs (TURN, STUN) I have no problems with this document. The new features do not raise any security concerns that are not already addressed in the base TURN documents. Pat Cain From rbarnes@bbn.com Mon Mar 29 14:44: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 45A343A6998; Mon, 29 Mar 2010 14:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.159 X-Spam-Level: * X-Spam-Status: No, score=1.159 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 Zz0i76oX8tqz; Mon, 29 Mar 2010 14:44:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 2902C3A698E; Mon, 29 Mar 2010 14:44:58 -0700 (PDT) Received: from [128.89.254.172] (port=51407 helo=[192.168.1.46]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwMlx-000Cft-Ho; Mon, 29 Mar 2010 17:45:26 -0400 Message-Id: <188D3671-05E9-40A2-9498-24BAE91B269E@bbn.com> From: Richard Barnes To: secdir@ietf.org, iesg@ietf.org, draft-ietf-behave-turn-ipv6@tools.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, 29 Mar 2010 17:45:24 -0400 X-Mailer: Apple Mail (2.936) Subject: [secdir] secdir review of draft-ietf-behave-turn-ipv6-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, 29 Mar 2010 21:44:59 -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 an extension to the TURN protocol, a relay protocol for NAT traversal, that allows endpoints to request that the TURN server allocate them an IPv4 or IPv6 address (the protocol currently supports only IPv4). On important feature of this extension is that it allows a TURN server to act as a relay in all four combinations of protocols (4-4, 4-6, 6-4, 6-6), depending on which protocol the TURN request is carried in and which address family is requested. As the Security Considerations correctly note, TURN with this extension is basically equivalent to TURN without it, with the exception that certain routing loop attacks inherent to TURN could be easier with this mechanism. My only significant concern that is not addressed in the document is how this mechanism relates to the routing loop attacks introduced by other forms of v4/v6 translation and tunneling, e.g., as discussed in this paper: It's not immediately obvious to me that extending TURN in this way makes these (currently non-TURN-related) attacks viable, but I would encourage the authors to consider the issue and add some text to the document explaining how the attacks do or do not apply here. A few specific comments follow. --Richard Comments on draft-ietf-behave-turn-ipv6 S.3, Paragraph "Assuming the request..." The server doesn't "assume" that the request is authenticated. Suggest rephrasing as "After the request has been successfully authenticated, ..." S4.1.1 Why not just make this option one byte long? If you're already anticipating a usage for the reserved space, you should just specify it. S4.2, First paragraph As above, suggest rephrasing as "Once a server has verified that the request is authenticated and has not been tampered with, ..." S4.3 Why is this a SHOULD NOT and not a MUST NOT? What's the exceptional case? Section 9, First para It seems overly broad to say that "an IPv4-only client having access to ... this specifictation is now able to access the IPv6 Internet". The client can't just send/receive traffic with any node, right? Explain the restrictions in place here. Section 9, Might some of the Teredo / 6to4 loop attacks apply as well? If not, why not? -- Spoof 4-to-6 allocate request from relay's v4 address -- Spoof authorization relay's v6 address -- Spoof packet from either of relay's addresses If there is some risk here, you might consider saying something like "Server MUST NOT allocate 6to4 or Teredo addresses or accept them as peers"? From dharkins@lounge.org Tue Mar 30 13:22: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 154883A68AA; Tue, 30 Mar 2010 13:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.296 X-Spam-Level: X-Spam-Status: No, score=-3.296 tagged_above=-999 required=5 tests=[AWL=-1.361, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, 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 UtIP50qio2HR; Tue, 30 Mar 2010 13:21:56 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 4BEB33A681C; Tue, 30 Mar 2010 13:21:35 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E139B1022404A; Tue, 30 Mar 2010 13:22:04 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 30 Mar 2010 13:22:04 -0700 (PDT) Message-ID: <142c29cbb5f6f54edc203861e7c6ac7b.squirrel@www.trepanning.net> Date: Tue, 30 Mar 2010 13:22:04 -0700 (PDT) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-zimmermann-avt-zrtp.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] secdir review of draft-zimmermann-avt-zrtp-17 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, 30 Mar 2010 20:22:01 -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 draft defines a Diffie-Hellman based key exchange to generate a session key to use with SRTP. It prevents a man-in-the-middle attack against the Diffie-Hellman key exchange without requiring traditional authentication. It does not require use of a PKI. There are three things I think the ADs should take a look at: having the protocol resist a small sub-group attack, use of the "auxsecret", and the hashing mishmash. All are described below. The MitM attack is thwarted by using a short authentication string (SAS) that is presented to users on each side of the ZRTP exchange to be read and verbally compared. An immediate concern with such an approach is that it might enable a small sub-group attack against the Diffie-Hellman exchange that would be undetectable by verification of the SAS. An attacker could take an element of small order, f, and create pvi' = pvi^f modp and pvr' = pvr^f mod p and the shared secret, DHResult', would be confined to the small group. The SAS would verbally verify and the two parties would continue unaware of the attack. But the DH shared secret is subsequently used (indirectly) in a hash which fixes it and exposes it to the MitM, which can run through the values in the small sub-group to determine DHResult' and then attack the SRTP connection. The draft specifies support for a Diffie-Hellman domain parameter set using a safe prime (from RFC 3526) which would prevent such an attack but it seems that the protocol should be secure in and of itself and not rely on external safeguards. I recommend sections 4.4.1.2 and 4.4.1.3 define an additional processing step to ensure pvi and pvr are not in a small sub-group. For a safe-prime this can be viewed as a "belt and suspenders" approach, but I don't see why ZRTP couldn't be used in the future with other domain parameter sets which may not be based on safe primes and therefore such a check would be vital. The draft has a clever shared secret state matching algorithm to use secrets from a cache of state associated with a peer. One of these is called "auxsecret", as described in section 4.3.1: "the auxsecret shared secret may be manually provisioned in other application-specific ways that are out-of-band, such as computed from a hashed pass phrase by prior agreement between the two parties. Or it may be a family key used by an institution that the two parties both belong to." If one does not have an "auxsecret" configured a random value is used in its field during the ZRTP exchange. If one does have an "auxsecret" though it does not appear to change. Traffic analysis, therefore, would tell an attacker whether an "auxsecret" is being used or not. If one is, an off-line dictionary attack might be possible if the "auxsecret" is being used per section 4.3.1 (if it is a "family key used by an institution" then every member of the institution would use the same "auxsecret" and that could also be easily detected). I recommend that the "auxsecret" be updated in the cache in section 4.6.1 so that it is different with a subsequent run of the protocol. If that logistically isn't possible then perhaps hash rs1 or rs2 with it in 4.3.1 to produce "auxsecretIDi" and "auxsecretIDr". Since there is a matching algorithm for r1 and r2 then it might be necessary to have two "auxsecretIDi" and two "auxsecretIDr", one hashed with r1 and one with r2. The cost is a little extra space but the benefit seems worth it. There is a confusing mix of hashing, HMACing, and KDFing. In section 4.4.1.4 a secret value s0 is derived using the KDF technique from SP800-56A, which is not of the keyed variety, it just uses a hash function in counter mode. But if a preshared key is used then section 4.4.2.4 derives s0 with an HMAC-based KDF based on SP800-108. This value, s0, is then used to derive the SRTP session key, the SAS, and various encryption and integrity protection keys using the HMAC-based, SP800-108 version of a KDF. When a session is terminated all keys are destroyed except ZRTPSess which is replace by a hash of itself. But it was originally derived by a keyed KDF. This seems unnecessarily complex and would make this protocol very difficult to analyze. There has been much discussion on the CFRG list about how the output of a hash function is too structured to use the key to an HMAC (see Hugo Krawczyk's HKDF draft). Whether the SP800-56A hash-style KDF is good or whether the SP800-108 keyed HMAC-style KDF is good is a debate for another forum but I think this draft should choose one and stick to it. Keys derived from a hash function should not be used as keys to an HMAC and keys derived from an HMAC-based KDF should not be replaced with a simple hash of themselves. Editorial nits: * sections 4.4.1.1 and 4.4.1.2 mention the "width of the DH prime". How about "bit-length of the DH prime" instead? * section 4.4.1.1 mentions ECDH but then goes on to specify the finite field (MODP) version of the exchange. I suggest adding an example of ECDH in 4.4.1.1 and 4.4.1.2. regards, Dan. From simon.perreault@viagenie.ca Mon Mar 29 14:23: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 B03173A6985; Mon, 29 Mar 2010 14:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2] 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 d91BgxAe-oce; Mon, 29 Mar 2010 14:22:57 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by core3.amsl.com (Postfix) with ESMTP id 45A4E3A6975; Mon, 29 Mar 2010 14:22:55 -0700 (PDT) Received: from [10.24.69.140] (unknown [216.207.245.1]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 585AF21BE1; Mon, 29 Mar 2010 17:23:21 -0400 (EDT) Message-ID: <4BB11A48.9090401@viagenie.ca> Date: Mon, 29 Mar 2010 16:23:20 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Patrick Cain References: <017001cacf85$327ccc40$977664c0$@com> In-Reply-To: <017001cacf85$327ccc40$977664c0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 30 Mar 2010 19:30:10 -0700 Cc: draft-ietf-behave-turn-tcp.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of: draft-ietf-behave-turn-tcp-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, 29 Mar 2010 21:23:01 -0000 Thanks! Simon On 2010-03-29 16:17, Patrick Cain wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The document defines an extension of Traversal Using Relays > around NAT (TURN), a relay protocol for NAT traversal, to allow a > TURN client to request TCP allocations, and defines new requests and > indications for the TURN server to open and accept TCP connections > with the client's peers. > > After reading the other four-letter protocol specs (TURN, STUN) I have no > problems with this document. The new features do not raise any security > concerns that are not already addressed in the base TURN documents. > > Pat Cain -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From john.mattsson@ericsson.com Tue Mar 30 02:20: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 F229E3A67AE; Tue, 30 Mar 2010 02:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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+c+p-JNtwtL; Tue, 30 Mar 2010 02:20:16 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 29B2D3A67A1; Tue, 30 Mar 2010 02:20:15 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-74-4bb1c26b0f60 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 93.86.23740.B62C1BB4; Tue, 30 Mar 2010 11:20:44 +0200 (CEST) Received: from ESESSCMS0357.eemea.ericsson.se ([169.254.2.37]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 30 Mar 2010 11:20:44 +0200 From: John Mattsson To: Tobias Gondrom , "secdir@ietf.org" , "iesg@ietf.org" , "draft-mattsson-mikey-ticket.all@tools.ietf.org" Date: Tue, 30 Mar 2010 11:20:42 +0200 Thread-Topic: Secdir review of draft-mattsson-mikey-ticket-02 Thread-Index: AcrG5p+WPyg5tJasRNuKx6ZG17MdNQJAzZ+Q Message-ID: References: <4BA2A2F7.7020502@gondrom.org> In-Reply-To: <4BA2A2F7.7020502@gondrom.org> 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: Tue, 30 Mar 2010 19:30:10 -0700 Cc: "tian.tian1@zte.com.cn" , "tim.polk@nist.gov" , Rolf Blom J Subject: Re: [secdir] Secdir review of draft-mattsson-mikey-ticket-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, 30 Mar 2010 09:20:18 -0000 Dear Tobias, Many thanks for the review. I'll update the draft based on your comments. Best Regards, John -----Original Message----- From: Tobias Gondrom [mailto:tobias.gondrom@gondrom.org]=20 Sent: den 18 mars 2010 23:03 To: secdir@ietf.org; iesg@ietf.org; draft-mattsson-mikey-ticket.all@tools.i= etf.org Cc: bew@cisco.com; vincent.roca@inrialpes.fr; tim.polk@nist.gov; John Matts= son; tian.tian1@zte.com.cn Subject: Secdir review of draft-mattsson-mikey-ticket-02 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > 0. From the security perspective, the considerations in this document > appear to be overall sufficient. >=20 > 1. COMMENT: Intended Status > I am not quite sure why this draft status is planned to be informational.= It > adds new protocol specification, which by my understanding should not be = done > in an informational draft. I can see why it was not aimed for standards t= rack > but the intended status "experimental" would seem more appropriate to me.= =20 I'm no expert at statuses but having it informal is in line with some other= 3GPP related RFCs like EAP-SIM and EAP-AKA. > 2. COMMENT:=20 > Spelling:=20 > s/5.4. Error Handling If an error occurs, the message SHOULD be discarde= d and > the the error SHOULD be reported with an error message./ 5.4. Error Hand= ling > If an error occurs, the message SHOULD be discarded and the error SHOULD = be > reported with an error message. Yes > 3. COMMENT: section 10:=20 > s/New Ticket Types SHOULD not change/New Ticket Types SHOULD NOT change > (for rfc2119 consistent language use) Yes > 4. COMMENT: section 6.7. Cert Hash Payload (CHASH) "Hash func (8 bits): > besides the algorithms already defined in [RFC3830], this specification > defines that the following hash function algorithm may be used. > SHA-256 | TBD20 | 256" > Why do you add SHA-256 but no other hash algorithms (i.e. SHA-512/ripemd)= , > how do you intend to provide for hash agility? This seems more like a question for MIKEY in general than for the MIKEY-TIC= KET draft.=20 > 5. COMMENT: section 8. Pre-Encrypted Content "The default setting is that= the KMS > supplies the session keys (encoded in the ticket). This is not possible i= f the content > is pre-encrypted (e.g. Video on Demand). In such use cases, the key exch= ange is > typically reversed and MAY be carried out as follows. The Initiator sends= a ticket > without encoded session keys to the Responder in a TRANSFER_INIT message.= The > Responder includes the TEKs used to protect the requested content in the = TRANSFER_RESP > message, which is sent to the Initiator." >=20 > I wonder whether the pre-step of "initiator sends a ticket without encode= d session key"=20 > allows a potential DoS vulnerability with request flooding, when it may t= rigger calculations > at the Responder or KMS.=20 > Would it be necessary to mention this risk in the Security Section 12.2. = as well? I do not see how "ticket without encoded session key" makes any difference?= I feel that this is already covered in Section 12.2: "Since the Responder = in general cannot verify the validity of a TRANSFER_INIT message without fi= rst contacting the KMS, Denial of Service may be launched against the Respo= nder and/or the KMS via the Responder."=20 > 6. COMMENT: section 10. Signaling Between Different KMSs paragraph 1: "si= gnaling > between them SHALL be integrity protected." > I understand and fully agree that you require integrity protection, but w= hy do > you not need confidentiality protected, too? Yes, it should be fully protected. I'll update the draft. > 7. COMMENT: section 12.4. Forking > "To prevent all forms of eavesdropping, only the endpoint that answers sh= ould > get access to the session keys." > From my perspective the use of RFC2119 "SHOULD" would be more appropriate= here?=20 Yes I agree. > Best regards, Tobias >=20 > Ps.: I cc'ed the WGChairs of msec to this review as MIKEY got originated = there.=20