From tobias.gondrom@gondrom.org Wed Jul 3 05:21:06 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D4521F9C19 for ; Wed, 3 Jul 2013 05:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.361 X-Spam-Level: X-Spam-Status: No, score=-95.361 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4+ZKgo58PAY for ; Wed, 3 Jul 2013 05:20:58 -0700 (PDT) Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5B36611E8196 for ; Wed, 3 Jul 2013 05:20:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=YeFj8CPO/ElktePTpqaMEQC7cC0aSHnbdXfFAF6urqWnPg5PFjibslzJGcQhEnHSkt51+GRvTkKW+Rwju/LZ1MxCG5OZgF9TZf+04OmjNC8wdtCfM4IEtjndeHVQGhSq; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type; Received: (qmail 11832 invoked from network); 3 Jul 2013 14:20:54 +0200 Received: from d1-162-57-143-118-on-nets.com (HELO ?10.8.16.105?) (118.143.57.162) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 3 Jul 2013 14:20:54 +0200 Message-ID: <51D41722.8080900@gondrom.org> Date: Wed, 03 Jul 2013 20:20:50 +0800 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org, draft-ietf-appsawg-rfc5451bis.all@tools.ietf.org X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------010805030407070205070605" Subject: [secdir] secdir review of draft-ietf-appsawg-rfc5451bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 12:21:06 -0000 This is a multi-part message in MIME format. --------------010805030407070205070605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments ust like any other last call comments. This ID is Standards Track and specifies specifies a header field for use with electronic mail messages to indicate the results of message authentication efforts. I believe the security implications have been evaluated sufficiently in the security considerations sections and think the draft is ok to proceed. One personal comment IMHO: the security considerations rely heavily on the established trust boundary. However in section 1.2 it is declared that "How this trust is obtained is outside the scope of this document. It is entirely a local matter." So the document itself is ok, but I feel that this "local matter" of establishing and ensuring this trust is an essential pre-requisite for a secure system. Best regards, Tobias --------------010805030407070205070605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments ust like any other last call comments.

This ID is Standards Track and specifies specifies a header field for use with electronic mail messages to indicate the results of message authentication efforts.

I believe the security implications have been evaluated sufficiently in the security considerations sections and think the draft is ok to proceed.

One personal comment IMHO:
the security considerations rely heavily on the established trust boundary. However in section 1.2 it is declared that "How this trust is obtained is outside the scope of this document.  It is entirely a local matter."  So the document itself is ok, but I feel that this "local matter" of establishing and ensuring this trust is an essential pre-requisite for a secure system.

Best regards, Tobias
 --------------010805030407070205070605-- From kivinen@iki.fi Fri Jul 5 05:32:57 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC3011E82C0 for ; Fri, 5 Jul 2013 05:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQNuQo7Wly9Y for ; Fri, 5 Jul 2013 05:32:56 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 20E7511E82BC for ; Fri, 5 Jul 2013 05:32:55 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r65CWrDb019571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 5 Jul 2013 15:32:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r65CWrv7023996; Fri, 5 Jul 2013 15:32:53 +0300 (EEST) 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: <20950.48373.48584.836037@fireball.kivinen.iki.fi> Date: Fri, 5 Jul 2013 15:32:53 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 24.3.1 X-Edit-Time: 2 min X-Total-Time: 1 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 12:32:57 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Ben Laurie is next in the rotation. For telechat 2013-07-11 Reviewer LC end Draft David Harrington T 2013-07-01 draft-ietf-straw-b2bua-taxonomy-02 Sam Weiler T 2013-06-19 draft-ietf-ospf-manet-single-hop-mdr-03 For telechat 2013-07-18 Simon Josefsson T 2013-07-23 draft-merkle-tls-brainpool-03 Stephen Kent T 2013-07-18 draft-ietf-jcardcal-jcard-04 For telechat 2013-08-15 Sandy Murphy T 2013-07-17 draft-jabley-dnsext-eui48-eui64-rrtypes-05 Last calls and special requests: Rob Austein 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Dave Cridland - draft-ietf-httpbis-p5-range-22 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 Donald Eastlake 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Steve Hanna 2013-06-27 draft-ietf-manet-rfc6622-bis-03 Dan Harkins 2013-07-03 draft-ietf-multimob-pmipv6-ropt-07 Paul Hoffman 2013-07-16 draft-ivov-xmpp-cusax-06 Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-03 Leif Johansson 2013-07-22 draft-ivov-grouptextchat-purpose-03 Charlie Kaufman 2013-07-18 draft-ietf-trill-directory-framework-05 Scott Kelly 2013-07-17 draft-ietf-dhc-dhcpv6-failover-requirements-06 Tero Kivinen 2013-07-31 draft-housley-ltans-oids-00 Warren Kumari 2013-07-15 draft-ietf-lisp-deployment-08 Julien Laganier - draft-ietf-avtcore-rtp-security-options-03 Julien Laganier - draft-ietf-websec-key-pinning-06 Alexey Melnikov - draft-ietf-payload-rtp-howto-04 Vincent Roca 2013-06-11 draft-ietf-avtcore-idms-11 Ondrej Sury 2013-06-17 draft-ietf-abfab-eapapplicability-03 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-10 Glen Zorn 2012-11-27 draft-ietf-lisp-eid-block-04 -- kivinen@iki.fi From simon@josefsson.org Fri Jul 5 06:20:55 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048E911E82E3; Fri, 5 Jul 2013 06:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhVtXD6W8SdS; Fri, 5 Jul 2013 06:20:49 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [37.123.176.9]) by ietfa.amsl.com (Postfix) with ESMTP id C827F21F9622; Fri, 5 Jul 2013 06:20:48 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r64MgIIi015051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Jul 2013 00:42:20 +0200 Date: Fri, 5 Jul 2013 00:42:18 +0200 From: Simon Josefsson To: iesg@ietf.org, secdir@ietf.org, draft-merkle-tls-brainpool.all@tools.ietf.org Message-ID: <20130705004218.233f8942@latte.josefsson.org> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Subject: [secdir] Review of draft-merkle-tls-brainpool-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 13:20:55 -0000 I have reviewed draft-merkle-tls-brainpool-03 and consider the document to be "Ready with nits". I support its publication. 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 haven't verified the test vectors, but as an implementer I'm happy that they are present and they improve the credibility of the draft. I believe the document would be improved by addressing the suggestions below, but these comments are not critical. 1) When I read the document, it seems to be missing its "gut". There is one section "Introduction" and then you would expect the actual specification. But instead comes the Security Considerations and the rest of the usual IETF boiler plate. The contribution of this document is hidden in the IANA Considerations. In particular, there is no TLS presentation language of the new fields. Adding new TLS enum types is done by several other documents, and they usually contain a bit more detail. Compare how RFC5878 introduces new enum types in section 2. For an alternative approach, look at how rfc6042 introduces new enum types. Further, I feel it is more appropriate to put the comment about DTLS compatibility in this new section rather than in the IANA Considerations. I would propose to add a new section after "Introduction": --->>> 2. Brainpool NamedCurve Types This document adds three new NamedCurve types as follows. enum { brainpoolP256r1(TBD1), brainpoolP384r1(TBD2), brainpoolP512r1(TBD3) } NamedCurve; These curves are suitable for use with DTLS [RFC6347]. <<<--- 2) In section 1, remove a whitespace after the RFC5480 citation. It causes a comma to appear standalone. OLD: certificates according to [RFC3279] and [RFC5480] , their negotiation NEW: certificates according to [RFC3279] and [RFC5480], their negotiation /Simon From ietfdbh@comcast.net Fri Jul 5 07:34:12 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0FF11E80F4 for ; Fri, 5 Jul 2013 07:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.137 X-Spam-Level: X-Spam-Status: No, score=-100.137 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd3OHOH2UKHk for ; Fri, 5 Jul 2013 07:34:06 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 15B7E11E812B for ; Fri, 5 Jul 2013 07:34:05 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta08.westchester.pa.mail.comcast.net with comcast id weVD1l0011ZXKqc58ea5Se; Fri, 05 Jul 2013 14:34:05 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta21.westchester.pa.mail.comcast.net with comcast id wea41l00c2yZEBF3hea4in; Fri, 05 Jul 2013 14:34:05 +0000 From: "ietfdbh" To: , Date: Fri, 5 Jul 2013 10:33:39 -0400 Message-ID: <01c701ce798c$a4572540$ed056fc0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac55iDhwAJwDrFHbScmXQfLxAtCynQ== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1373034845; bh=pmTmU8qf38oMQ0NaFomMhEjKPcYUgSv/fyEdLou4oJk=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=DvtOuJegHHdsVaJSKwV4WtgvyssB4gyzq6h33otHPIr70LvHDzIjQd/eP/mppNvr2 lsI3RtiNDji8UPOrhIxyYNa4JCBomgyy8a6UmWClVWo8/Qb0kvUtxqm7IgGyPWwKun d9xQ6tFIBRunuV5Q46Lx77OZxnM9DlTy72satPLw4EoJgEDZ4tMjgX+gQmZd9kFi34 EBZW5Q/gVqFA07GIB2XJOxnncinopTr/lBZJMaMBZDfDf3edSigCfeGKkb5e5mFh0f kM0zwgBMA1MI+JdvHGyHMm+KzziTti5qJdRe1juJX0/lEOHrH0dRTiNIp42XkRvO+8 Et7DqvadJel5Q== Subject: [secdir] secdir review of draft-ietf-straw-b2bua-taxonomy X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 14:34: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 ID is Informational, and gathers together a list of terms and definitions, with references, for subsequent use. There seem to be no security implications created by creating this list. The security considerations section says that relevant security is considered within the referenced documents, all but one of which is an IETF RFC. I didn't check the 3GPP reference. >From the security standpoint, I think this document is OK to advance. I don't have strong background into the referenced technologies, so cannot tell whether the content is fine for the community. David Harrington ietfdbh@comcast.net +1-603-828-1401 From Johannes.Merkle@secunet.com Fri Jul 5 08:11:54 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B39311E8104; Fri, 5 Jul 2013 08:11:54 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8bfXIuQQ8tY; Fri, 5 Jul 2013 08:11:49 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id C822711E80F4; Fri, 5 Jul 2013 08:11:48 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 553971A0084; Fri, 5 Jul 2013 17:11:44 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0AdQsri8WD55; Fri, 5 Jul 2013 17:11:43 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 1F4251A008C; Fri, 5 Jul 2013 17:11:43 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Jul 2013 17:11:42 +0200 Message-ID: <51D6E22E.3040107@secunet.com> Date: Fri, 05 Jul 2013 17:11:42 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Simon Josefsson References: <20130705004218.233f8942@latte.josefsson.org> In-Reply-To: <20130705004218.233f8942@latte.josefsson.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2013 15:11:43.0047 (UTC) FILETIME=[F5264D70:01CE7991] X-Mailman-Approved-At: Fri, 05 Jul 2013 08:13:20 -0700 Cc: iesg@ietf.org, draft-merkle-tls-brainpool.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-merkle-tls-brainpool-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 15:11:54 -0000 Simon, thank you for the thorough and competent review. Some of your points nees discussion. > > I haven't verified the test vectors, but as an implementer I'm happy > that they are present and they improve the credibility of the draft. the test vectors are identical to those used in draft-merkle-ikev2-ke-brainpool and in RFC 6932, and they have been verified by Dan Harkins. > When I read the document, it seems to be missing its "gut". There is > one section "Introduction" and then you would expect the actual > specification. But instead comes the Security Considerations and the > rest of the usual IETF boiler plate. The contribution of this document > is hidden in the IANA Considerations. If you have a look at version 01, you see that such a section 2 was present. Sean suggested to remove it. It seems that your tastes as to the structure differ... I am willing to change the structure and wording as long as there is consensus on that. > --->>> > 2. Brainpool NamedCurve Types > > This document adds three new NamedCurve types as follows. > > enum { > brainpoolP256r1(TBD1), > brainpoolP384r1(TBD2), > brainpoolP512r1(TBD3) > } NamedCurve; > > These curves are suitable for use with DTLS [RFC6347]. > <<<--- > This is much less verbose as our previous section 2. Maybe this could be a compromise between Sean's preference of being compact and your preference of the draft having "guts". But isn't this syntax incorrect as there are already code points defined for namedCurve? Your text defines namedCurve as comprising of three values which is not true. -- Johannes From simon@josefsson.org Sat Jul 6 00:54:05 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138B121F9B44; Sat, 6 Jul 2013 00:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OK5eCe4q9vIB; Sat, 6 Jul 2013 00:53:49 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [37.123.176.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3117421F9B45; Sat, 6 Jul 2013 00:53:48 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r667rdvx005030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 6 Jul 2013 09:53:40 +0200 Date: Sat, 6 Jul 2013 09:53:38 +0200 From: Simon Josefsson To: Johannes Merkle Message-ID: <20130706095338.2a12aa7b@latte.josefsson.org> In-Reply-To: <51D6E22E.3040107@secunet.com> References: <20130705004218.233f8942@latte.josefsson.org> <51D6E22E.3040107@secunet.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: iesg@ietf.org, draft-merkle-tls-brainpool.all@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-merkle-tls-brainpool-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 07:54:05 -0000 You wrote: > > When I read the document, it seems to be missing its "gut". There > > is one section "Introduction" and then you would expect the actual > > specification. But instead comes the Security Considerations and > > the rest of the usual IETF boiler plate. The contribution of this > > document is hidden in the IANA Considerations. > > If you have a look at version 01, you see that such a section 2 was > present. Sean suggested to remove it. It seems that your tastes as to > the structure differ... I am willing to change the structure and > wording as long as there is consensus on that. I wasn't aware of this earlier discussion -- it was just my reaction reading the current document, so you shouldn't take it too seriously. Version 01 seems to contain a lot more normative language in that section, maybe that was the issue. > > --->>> > > 2. Brainpool NamedCurve Types > > > > This document adds three new NamedCurve types as follows. > > > > enum { > > brainpoolP256r1(TBD1), > > brainpoolP384r1(TBD2), > > brainpoolP512r1(TBD3) > > } NamedCurve; > > > > These curves are suitable for use with DTLS [RFC6347]. > > <<<--- > > > This is much less verbose as our previous section 2. Maybe this could > be a compromise between Sean's preference of being compact and your > preference of the draft having "guts". Yes. > But isn't this syntax incorrect as there are already code points > defined for namedCurve? Your text defines namedCurve as comprising of > three values which is not true. No, the TLS meta language is not strictly defined, and the above is fine. If you compare other TLS documents inroduce new types, this is how you often express adding new enums. Compare RFC5878 and RFC6042. /Simon From shanna@juniper.net Tue Jul 9 13:54:00 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6B421E8053; Tue, 9 Jul 2013 13:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.638 X-Spam-Level: X-Spam-Status: No, score=-101.638 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0hGkDADHjOS; Tue, 9 Jul 2013 13:53:45 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF3821E8050; Tue, 9 Jul 2013 13:53:45 -0700 (PDT) Received: from mail110-co9-R.bigfish.com (10.236.132.252) by CO9EHSOBE010.bigfish.com (10.236.130.73) with Microsoft SMTP Server id 14.1.225.22; Tue, 9 Jul 2013 20:53:44 +0000 Received: from mail110-co9 (localhost [127.0.0.1]) by mail110-co9-R.bigfish.com (Postfix) with ESMTP id A9B1F420098; Tue, 9 Jul 2013 20:53:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: PS-1(zz4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail110-co9: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=shanna@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail110-co9 (localhost.localdomain [127.0.0.1]) by mail110-co9 (MessageSwitch) id 1373403222274648_28857; Tue, 9 Jul 2013 20:53:42 +0000 (UTC) Received: from CO9EHSMHS013.bigfish.com (unknown [10.236.132.229]) by mail110-co9.bigfish.com (Postfix) with ESMTP id 3F5E5200E0; Tue, 9 Jul 2013 20:53:42 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.50) by CO9EHSMHS013.bigfish.com (10.236.130.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Jul 2013 20:53:39 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 9 Jul 2013 13:53:38 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 9 Jul 2013 13:53:37 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 9 Jul 2013 13:57:22 -0700 Received: from mail31-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.22; Tue, 9 Jul 2013 20:53:37 +0000 Received: from mail31-ch1 (localhost [127.0.0.1]) by mail31-ch1-R.bigfish.com (Postfix) with ESMTP id D5F6860B54; Tue, 9 Jul 2013 20:53:36 +0000 (UTC) Received: from mail31-ch1 (localhost.localdomain [127.0.0.1]) by mail31-ch1 (MessageSwitch) id 1373403215338679_22884; Tue, 9 Jul 2013 20:53:35 +0000 (UTC) Received: from CH1EHSMHS021.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail31-ch1.bigfish.com (Postfix) with ESMTP id 4E9274C004E; Tue, 9 Jul 2013 20:53:35 +0000 (UTC) Received: from SN2PRD0510HT002.namprd05.prod.outlook.com (157.56.234.117) by CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Jul 2013 20:53:32 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.180]) by SN2PRD0510HT002.namprd05.prod.outlook.com ([10.255.116.37]) with mapi id 14.16.0329.000; Tue, 9 Jul 2013 20:53:26 +0000 From: Stephen Hanna To: The IESG , "secdir@ietf.org" , "draft-ietf-manet-rfc6622bis.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-manet-rfc6622-bis Thread-Index: Ac585lquiSITc2udRvyhyrd4ww7TEQ== Date: Tue, 9 Jul 2013 20:53:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net Subject: [secdir] secdir review of draft-ietf-manet-rfc6622-bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 20:54: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. And I apologize for missing the IETF Last Call deadline with this email. In my view, this document is Not Ready. This document obsoletes RFC 6622 but the text is confusing. Instead of having one section that explains what changed and the rest of the document just saying how it is now (as if this document is an RFC), the text is forever referring to the old RFC. For example, "This document reports previously assigned TLV types (from [RFC6622]) from the registries defined for Packet, Message, and Address Block TLVs in [RFC5444]." What do you mean "reports"? This document should stand on its own and only refer to RFC 6622 in a few places since RFC 6622 will be obsolete once this document is adopted. Otherwise, you're going to need to add a normative reference to an obsolete RFC! Section 1 contains these contradictory sentences: This document retains the IANA registries, defined in [RFC6622], for recording code points for ICV calculations, and requests an additional allocation from each these registries. This document retains the IANA registries, defined in [RFC6622], for recording code points for timestamps, hash-functions, and cryptographic functions, but does not request any additional allocations from these registries. To resolve IANA's confusion, I suggest that the IANA Considerations section state how things will be after this document is adopted and also include a section in square brackets with clear instructions about what IANA should change relative to what they have now in their registries. The section in square brackets can be marked for deletion by the RFC editor. Changing the name of existing TLVs is confusing! I guess I see why you changed "Packet ICV TLV" to "ICV Packet TLV" but it's still confusing. You should at least mention this change in the section that lists changes since the last version. And you should search your draft for instances of the old names ("Packet ICV TLV", "Packet TIMESTAMP TLV", and so on). There are still some of them left. I see that you changed the normative requirements in some places to make them more strict. For example, you changed a SHOULD to a MUST in section 9.2. That's OK if there's a good reason but this may cause implementations that comply with RFC 6622 to not comply with this new version. Therefore, you should mention any such changes in the "What Changed" section. People who implemented the old version will want to know what they need to change in their implementation. Although this document includes algorithm identifiers for RSA and DSA, there's no provision for conveying certificates. Perhaps the recipient is expected to already have those certificates on hand and to find them somehow (based on the Message Originator Address and the Key Identifier?). If the authors really intend for these algorithms to be useful, they should describe how certificates are handled. At first, I thought there were not Mandatory-To-Implement (MTI) algorithms in this document. Later, I learned that OLSRv2 says that all implementations of that document MUST implement draft-ietf-manet-nhdp-olsrv2-sec-03, which makes certain algorithms in RFC6622bis mandatory. RFC 6622bis should refer to draft-ietf-manet-nhdp-olsrv2-sec-03 and mention that it makes some of the algorithms in RFC 6622bis mandatory to implement. Finally, I would like to point out that implementing draft-ietf-manet-nhdp-olsrv2-sec-03 (which seems to be mandatory for OLSRv2 implementations) means that the ICV uses a "secret key shared by all routers". If any router is compromised, this shared key will be compromised as well so the attacker will be able to forge or modify OLSRv2 packets. Essentially, the compromise of any router will compromise the entire network. Such a security model is not suitable for use on the Internet. Therefore, I suggest that OLSRv2 and all the associated documents be published with Experimental status. If that is not possible, they should be published with an Applicability Statement limiting their use to networks where such a security flaw is acceptable. Thanks, Steve From shanna@juniper.net Tue Jul 9 14:30:06 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952DF21F9C4C; Tue, 9 Jul 2013 14:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.581 X-Spam-Level: X-Spam-Status: No, score=-99.581 tagged_above=-999 required=5 tests=[AWL=-2.114, BAYES_00=-2.599, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72nulnpZ-Cvh; Tue, 9 Jul 2013 14:30:00 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id A369F21F9C41; Tue, 9 Jul 2013 14:29:57 -0700 (PDT) Received: from mail29-db9-R.bigfish.com (10.174.16.227) by DB9EHSOBE027.bigfish.com (10.174.14.90) with Microsoft SMTP Server id 14.1.225.22; Tue, 9 Jul 2013 21:29:56 +0000 Received: from mail29-db9 (localhost [127.0.0.1]) by mail29-db9-R.bigfish.com (Postfix) with ESMTP id 861FF140131; Tue, 9 Jul 2013 21:29:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB02-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz9371I542I4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail29-db9: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=shanna@juniper.net; helo=P-EMHUB02-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail29-db9 (localhost.localdomain [127.0.0.1]) by mail29-db9 (MessageSwitch) id 1373405394526506_4561; Tue, 9 Jul 2013 21:29:54 +0000 (UTC) Received: from DB9EHSMHS027.bigfish.com (unknown [10.174.16.228]) by mail29-db9.bigfish.com (Postfix) with ESMTP id 71CDF300031; Tue, 9 Jul 2013 21:29:54 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net (66.129.224.53) by DB9EHSMHS027.bigfish.com (10.174.14.37) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 9 Jul 2013 21:29:53 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 9 Jul 2013 14:29:39 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 9 Jul 2013 14:29:38 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.182) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 9 Jul 2013 14:33:23 -0700 Received: from mail122-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.22; Tue, 9 Jul 2013 21:29:38 +0000 Received: from mail122-ch1 (localhost [127.0.0.1]) by mail122-ch1-R.bigfish.com (Postfix) with ESMTP id 05C723201C2; Tue, 9 Jul 2013 21:29:38 +0000 (UTC) Received: from mail122-ch1 (localhost.localdomain [127.0.0.1]) by mail122-ch1 (MessageSwitch) id 1373405375303019_5546; Tue, 9 Jul 2013 21:29:35 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail122-ch1.bigfish.com (Postfix) with ESMTP id 3C1174A007D; Tue, 9 Jul 2013 21:29:35 +0000 (UTC) Received: from SN2PRD0510HT001.namprd05.prod.outlook.com (157.56.234.117) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Jul 2013 21:29:34 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.9.180]) by SN2PRD0510HT001.namprd05.prod.outlook.com ([10.255.116.36]) with mapi id 14.16.0329.000; Tue, 9 Jul 2013 21:29:33 +0000 From: Stephen Hanna To: The IESG , "secdir@ietf.org" , "draft-ietf-manet-rfc6622-bis.all@tools.ietf.org" Thread-Topic: RESEND: secdir review of draft-ietf-manet-rfc6622-bis Thread-Index: AQHOfOtnTP8JImNHZEu4EyoEiBOZiQ== Date: Tue, 9 Jul 2013 21:29:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [secdir] RESEND: secdir review of draft-ietf-manet-rfc6622-bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 21:30:06 -0000 I left out a hyphen in the email alias for the draft authors. Sorry about that! Thanks, Steve -----Original Message----- From: secdir-bounces@ietf.org [mailto:secdir-bounces@ietf.org] On Behalf Of= Stephen Hanna Sent: Tuesday, July 09, 2013 4:53 PM To: The IESG; secdir@ietf.org; draft-ietf-manet-rfc6622bis.all@tools.ietf.o= rg Subject: [secdir] secdir review of draft-ietf-manet-rfc6622-bis 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. And I apologize for missing the IETF Last Call deadline with this email. In my view, this document is Not Ready. This document obsoletes RFC 6622 but the text is confusing. Instead of having one section that explains what changed and the rest of the document just saying how it is now (as if this document is an RFC), the text is forever referring to the old RFC. For example, "This document reports previously assigned TLV types (from [RFC6622]) from the registries defined for Packet, Message, and Address Block TLVs in [RFC5444]." What do you mean "reports"? This document should stand on its own and only refer to RFC 6622 in a few places since RFC 6622 will be obsolete once this document is adopted. Otherwise, you're going to need to add a normative reference to an obsolete RFC! Section 1 contains these contradictory sentences: This document retains the IANA registries, defined in [RFC6622], for recording code points for ICV calculations, and requests an additional allocation from each these registries. This document retains the IANA registries, defined in [RFC6622], for recording code points for timestamps, hash-functions, and cryptographic functions, but does not request any additional allocations from these registries. To resolve IANA's confusion, I suggest that the IANA Considerations section state how things will be after this document is adopted and also include a section in square brackets with clear instructions about what IANA should change relative to what they have now in their registries. The section in square brackets can be marked for deletion by the RFC editor. Changing the name of existing TLVs is confusing! I guess I see why you changed "Packet ICV TLV" to "ICV Packet TLV" but it's still confusing. You should at least mention this change in the section that lists changes since the last version. And you should search your draft for instances of the old names ("Packet ICV TLV", "Packet TIMESTAMP TLV", and so on). There are still some of them left. I see that you changed the normative requirements in some places to make them more strict. For example, you changed a SHOULD to a MUST in section 9.2. That's OK if there's a good reason but this may cause implementations that comply with RFC 6622 to not comply with this new version. Therefore, you should mention any such changes in the "What Changed" section. People who implemented the old version will want to know what they need to change in their implementation. Although this document includes algorithm identifiers for RSA and DSA, there's no provision for conveying certificates. Perhaps the recipient is expected to already have those certificates on hand and to find them somehow (based on the Message Originator Address and the Key Identifier?). If the authors really intend for these algorithms to be useful, they should describe how certificates are handled. At first, I thought there were not Mandatory-To-Implement (MTI) algorithms in this document. Later, I learned that OLSRv2 says that all implementations of that document MUST implement draft-ietf-manet-nhdp-olsrv2-sec-03, which makes certain algorithms in RFC6622bis mandatory. RFC 6622bis should refer to draft-ietf-manet-nhdp-olsrv2-sec-03 and mention that it makes some of the algorithms in RFC 6622bis mandatory to implement. Finally, I would like to point out that implementing draft-ietf-manet-nhdp-olsrv2-sec-03 (which seems to be mandatory for OLSRv2 implementations) means that the ICV uses a "secret key shared by all routers". If any router is compromised, this shared key will be compromised as well so the attacker will be able to forge or modify OLSRv2 packets. Essentially, the compromise of any router will compromise the entire network. Such a security model is not suitable for use on the Internet. Therefore, I suggest that OLSRv2 and all the associated documents be published with Experimental status. If that is not possible, they should be published with an Applicability Statement limiting their use to networks where such a security flaw is acceptable. Thanks, Steve _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From stephen.farrell@cs.tcd.ie Wed Jul 10 06:00:18 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B29711E81A2 for ; Wed, 10 Jul 2013 06:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siJJe6DT6+3a for ; Wed, 10 Jul 2013 06:00:14 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC8511E8167 for ; Wed, 10 Jul 2013 06:00:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 41470BEB3 for ; Wed, 10 Jul 2013 13:59:14 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PKvt7lbfJOe for ; Wed, 10 Jul 2013 13:59:14 +0100 (IST) Received: from [IPv6:2001:770:10:203:955f:61fb:179d:3ebe] (unknown [IPv6:2001:770:10:203:955f:61fb:179d:3ebe]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1FCAEBE8A for ; Wed, 10 Jul 2013 13:59:14 +0100 (IST) Message-ID: <51DD5AA2.7060108@cs.tcd.ie> Date: Wed, 10 Jul 2013 13:59:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "secdir@ietf.org" References: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net> <519F2EBD.1030408@cs.tcd.ie> In-Reply-To: <519F2EBD.1030408@cs.tcd.ie> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [secdir] Fwd: timing of reviews X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 13:00:18 -0000 Hi folks, Coming back to this topic and thanks for the feedback. This is on as a management item for tomorrow's IESG telechat. The IESG won't be putting in place any new rule or dictat then but we'll try to move things along some. I plan to say the following: "Secdir reviewers expressed a willingness to carry out reviews at WGLC time where a specific request from the relevant WG chair is made. We'd like to try this out for a bit with some drafts and see how it goes for a few months and not immediately start getting review requests for everything at WGLC. If WG chairs select "more baked" drafts for this it may work better. If a WG chair asks for a review for a document that's really not ready for secdir then a "not baked" review may well be the sole response. (We do understand that starting a WGLC on a not-yet-baked draft is a valid thing for a WG chair to do sometimes, but those are maybe not good drafts for which to ask for a secdir review.) Given that the hit-rate for secdir reviews is about 80% WG chairs should understand that there's a roughly 20% chance that they won't get a secdir review, and there's a chance that the review might not be received before the end of WGLC, but that's still leaves a good probabailty of getting a very useful and timely review. For now, the simplest mechanics for this are for the WG chair to mail sec-ads@ietf.org, cc'ing secdir-secretary@mit.edu and asking that draft-foo, which is starting WGLC, be put into the secdir review rotation." There's no need to wordsmith that since its not a formal statement of anything, but if there are any major issues it'd be great to hear about those today/tomorrow. And since we'll work it out as we go anyway, there's no need to panic:-) Cheers and thanks again for all the continuing good work, S. On 05/24/2013 10:11 AM, Stephen Farrell wrote: > > Folks, > > Jari's mail below says it better than I could. > > What do you think about this? > > Thanks, > S. > > > -------- Original Message -------- > Subject: timing of reviews > Date: Fri, 24 May 2013 01:28:48 +0300 > From: Jari Arkko > To: General Area Review Team > CC: The IESG > > Thanks again for all your hard work in doing the reviews. They make it > possible for me to concentrate on reviewing just those documents where > there are problems or I have deeper expertise. And the quality of the > protocol specifications coming out of the IETF is obviously very > important, particularly for protocols that are gaining significant use. > > As you may have seen, the IESG and the community has been wondering if > there'd be something that we could do about the IETF process, in the > sense that there's quite many things happening at the very end of the > document's life cycle. This results in some surprises, and often also > moves some important decisions out of the working group and to > author/shepherd/AD hands. A while ago we met for the IESG retreat and > wanted to experiment with three specific changes: > > - sending work back to the WGs when significant changes are needed, and > making the WG the central place of the edits > - moving some directorate reviews earlier, without impact reviewer > effort too much > - inviting some of the shepherds onto tele chats > > I am writing to you in order to discuss the second item. How big of a > change would it be to have Gen-ART reviews be invoked during WGLC, while > the documents are still in the working groups? The goal of the reviews > would still be the same, e.g., I would be checking that the reviews were > positive and/or that the issues brought up have been properly addressed. > > There are important details to consider, however, and I would like to > get your feedback on how you would seem them having an effect, and what > would be the best way to organise this, if we decide to go ahead with > the change for the Gen-ART. > > Triggering the review would have to be done by something else than IETF > last call announcement. Is the best approach is to have the WG chairs > manually request for this? Note that sometimes there are multiple WGLCs. > I presume that it would be preferable to have a Gen-ART review be done > only once at this stage, as otherwise the work load would increase. The > chairs may have some idea of whether they are likely to need another > WGLC before they start one. > > There may be possibly bigger changes and time lag between the first > Gen-ART review and the one that checks that the changes are ok. > > Some specs may not make it through WGLC, and a review at that stage may > increase the effort you guys are putting in, by reviewing those specs > that will fail. > > Jari > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > From charliek@microsoft.com Wed Jul 10 22:22:43 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AA521F9E28; Wed, 10 Jul 2013 22:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.533 X-Spam-Level: * X-Spam-Status: No, score=1.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfuhxjXjHj-1; Wed, 10 Jul 2013 22:22:36 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 2B72B21F935A; Wed, 10 Jul 2013 22:22:35 -0700 (PDT) Received: from BL2FFO11FD011.protection.gbl (10.173.161.203) by BL2FFO11HUB040.protection.gbl (10.173.160.246) with Microsoft SMTP Server (TLS) id 15.0.717.3; Thu, 11 Jul 2013 05:22:34 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Thu, 11 Jul 2013 05:22:34 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.3.136.1; Thu, 11 Jul 2013 05:20:53 +0000 Received: from mail100-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Thu, 11 Jul 2013 05:20:52 +0000 Received: from mail100-ch1 (localhost [127.0.0.1]) by mail100-ch1-R.bigfish.com (Postfix) with ESMTP id B953F600C7; Thu, 11 Jul 2013 05:20:52 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 2 X-BigFish: PS2(zzzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz31h2a8h668h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: softfail (mail100-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=charliek@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(76176001)(77096001)(46102001)(56776001)(74316001)(51856001)(76482001)(80022001)(79102001)(56816003)(76796001)(76576001)(59766001)(49866001)(53806001)(69226001)(74366001)(74502001)(54356001)(83072001)(76786001)(63696002)(4396001)(16406001)(65816001)(33646001)(74876001)(66066001)(74662001)(54316002)(31966008)(50986001)(47736001)(47976001)(81342001)(47446002)(77982001)(81542001)(74706001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB592; H:BL2PR03MB592.namprd03.prod.outlook.com; CLIP:50.46.151.49; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail100-ch1 (localhost.localdomain [127.0.0.1]) by mail100-ch1 (MessageSwitch) id 1373520050457693_7752; Thu, 11 Jul 2013 05:20:50 +0000 (UTC) Received: from CH1EHSMHS016.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail100-ch1.bigfish.com (Postfix) with ESMTP id 69F25A004D; Thu, 11 Jul 2013 05:20:50 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 11 Jul 2013 05:20:48 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.329.3; Thu, 11 Jul 2013 05:20:48 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) by BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) with Microsoft SMTP Server (TLS) id 15.0.731.11; Thu, 11 Jul 2013 05:20:47 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.121]) by BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.121]) with mapi id 15.00.0731.000; Thu, 11 Jul 2013 05:20:47 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-trill-directory-framework.all@tools.ietf.org" Thread-Topic: secdir review of draft-ietf-trill-directory-framework-05 Thread-Index: Ac598XBBv+Y+ucf3RaayD+kk4dv1wQ== Date: Thu, 11 Jul 2013 05:20:46 +0000 Message-ID: <6d411f21bfcb4636a4d9d234cec91bd0@BL2PR03MB592.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.151.49] x-forefront-prvs: 0904004ECB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PR03MB592.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(77096001)(74876001)(50986001)(76176001)(54316002)(20776003)(49866001)(76786001)(47976001)(56816003)(47776003)(74366001)(77982001)(47736001)(65816001)(44976004)(76796001)(76576001)(59766001)(4396001)(81342001)(80022001)(83072001)(6806004)(16676001)(63696002)(74316001)(76482001)(74502001)(53806001)(66066001)(47446002)(74662001)(50466002)(23756003)(54356001)(81542001)(56776001)(51856001)(69226001)(46102001)(74706001)(33646001)(79102001)(31966008)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB040; H:TK5EX14HUBC106.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0904004ECB Subject: [secdir] secdir review of draft-ietf-trill-directory-framework-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 05:22: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.=A0 These = comments were written primarily for the benefit of the security area direct= ors.=A0 Document editors and WG chairs should treat these comments just lik= e any other last call comments. This document describes a framework for adding a central control mechanism = to trill to replace or supplement its autoconfiguring mechanism of dynamica= lly learning the locations of all addresses on the LAN. The specific protoc= ols for supplying and consuming this configuration information will presuma= bly appear in future specs. This sort of configuration control is useful in= a datacenter where all connections are carefully configured rather than be= ing plug and play. It is particularly applicable in a "cloud" environment w= here virtual machines are moved between physical machines by some sort of V= irtual Machine Management System that will also assign addresses and place = them. The Security Considerations section of this document is very bland, noting = that reachability depends on the correct delivery of information and statin= g that there may be security considerations specific to particular director= y assistance mechanisms. The feature is designed to improve performance rat= her than security. I believe this seriously understates the security advant= ages that are possible if a central control mechanism replaces the autoconf= iguration mechanism. In particular, the main protection/isolation mechanism= s available today on a LAN concern partitioning by VLAN. Within a VLAN, any= node can impersonate any other and can arrange to receive traffic addresse= d to another node. This can be prevented if the network learns the addresse= s belonging to each physical connection port not from looking at what the n= ode transmits but rather from a central controller. A node cannot receive t= raffic addressed to someone else simply by sending a packet from that addre= ss or responding to an ARP searching for an IP address. In fact, such packe= ts can be blocked by the ingress Rbridge. So control is much more fine-grai= ned than with VLANs. The network guarantees the authenticity of the source = address of each incoming packet. The directory framework could be made more useful in serving this security = functionality if its configuration included in each entry not simply the IP= address, MAC/VLAN, and list of attached Rbridges, but also a port identifi= er for each attached RBridge. Egress RBridges could use this information to= impose more precise limits. If this information is not in the database, a = central controlling mechanism would need a separate protocol and communicat= ions path to communicate this information to the Egress RBridges. The curre= nt spec allows such information to be included in the directory, but does n= ot require it. Nits: Page 4, bullet 4: "more common occurrence" -> "more frequent occurrence" From Sandra.Murphy@sparta.com Thu Jul 11 02:41:41 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EE421F9AC9; Thu, 11 Jul 2013 02:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcyfjVG94OeZ; Thu, 11 Jul 2013 02:41:36 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id A296221F9B52; Thu, 11 Jul 2013 02:41:32 -0700 (PDT) Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r6B9fUtA013376; Thu, 11 Jul 2013 04:41:30 -0500 Received: from CVA-HUB001.centreville.ads.sparta.com ([10.62.108.11]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r6B9fTBN029060; Thu, 11 Jul 2013 04:41:30 -0500 Received: from CVA-MB001.centreville.ads.sparta.com ([fe80::58b4:c7c2:f9d:dff9]) by CVA-HUB001.centreville.ads.sparta.com ([fe80::8ca8:7aea:3db9:1972%11]) with mapi id 14.02.0342.003; Thu, 11 Jul 2013 05:42:15 -0400 From: "Murphy, Sandra" To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-jabley-dnsext-eui48-eui64-rrtypes@tools.ietf.org" Thread-Topic: secdir review of draft-jabley-dnsext-eui48-eui64-rrtypes Thread-Index: Ac5+GumGNRYPxviKTWiCYPIIjmd3zQ== Date: Thu, 11 Jul 2013 09:42:12 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6749A56A9@CVA-MB001.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] secdir review of draft-jabley-dnsext-eui48-eui64-rrtypes X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 09:41:41 -0000 I have reviewed this document as part of the security=0A= directorate's ongoing effort to review all IETF documents=0A= being processed by the IESG. These comments were written=0A= primarily for the benefit of the security area directors.=0A= Document editors and WG chairs should treat these comments=0A= just like any other last call comments.=0A= =0A= This draft suggests two new DNS RRtypes that could encode IEEE=0A= EUI-48 and EUI-64 layer-2 addresses. There is at least one=0A= known use case of a Canadian required reverse DNS mapping of=0A= IP addresses to MAC addresses.=0A= =0A= The draft is simple and straight forward and follows the usual=0A= procedure for requesting a new RRtype.=0A= =0A= Security concern.=0A= =0A= You might want to mention that publication of the EUI's could=0A= facilitate MAC cloning.=0A= =0A= This isn't original to me. I followed the reference to the Canadian=0A= CRTC decision NTRE038D and looked at the various=0A= company "contributions" that led to that decision. One=0A= contribution from Clearcable (NTCO0362, see=0A= http://www.crtc.gc.ca/public/cisc/nt/NTCO0362.pdf) speaks of the=0A= risk that publication of EUI addresses in the global reverse DNS=0A= would facilitate the theft of service that arises from cloning=0A= the MAC address of a valid subscriber. DOCSIS modem MAC cloning=0A= does seem to be a known problem and concern, so perhaps this=0A= should be mentioned.=0A= =0A= The draft recommends restricting access to zones containing EUI64=0A= addresses to limit the privacy exposure. This is similar to the=0A= recommendation in the NTRE038D to use a split-view reverse DNS=0A= service. The draft's recommendation would also limit the=0A= exposure of valid EUI-64 addresses to MAC cloners, so I don't=0A= think you need to describe additional countermeasures.=0A= =0A= Nits and even more anal comments:=0A= =0A= Section 9 says "with the Global bit zero". I presume you mean=0A= the next-to-least-significant-bit in the first octet.=0A= =0A= RFC 5342 calls this bit the "Local bit" and the "Local/Global=0A= bit". RFC4291 calls this the "universal/local" bit. The IEEE=0A= 802 standard talks about "universal" and "local" without actually=0A= naming the bit, but lots of online documentation=0A= says "universal/local" and "U/L". So you and the RFC Editor can=0A= decide what term to use.=0A= =0A= IMHO: Continuing to call it the "Global bit" is my least favorite=0A= choice. Consistency with RFC5342 or RFC4291 would be preferable.=0A= =0A= Section 9 says:=0A= Publication of EUI-48 or EUI-64 addresses in the global DNS may=0A= result in privacy issues in the form of unique trackable identities.=0A= =0A= The privacy concern arises not just from the uniqueness of the=0A= EUI but from the fact that it is a more permanent identifier than=0A= the IP address associated with the subscriber (as the next=0A= paragraph notes). So "in the form of unique, permanent trackable=0A= identities" is probably more accurate. Similarly in the next=0A= paragraph "EUI-64 addresses normally provide a unique identifier"=0A= - the point is that the IP address "typically change over time"=0A= so "provide a unique permanent identifier" is what you mean. I=0A= think.=0A= =0A= The details of the IEEE references are incomplete. I might have=0A= recommended copying the references in RFC5342 but those=0A= references look to be out of date. I did find "Guidelines for=0A= 64-bit Global Identifier (EUI-64)"=0A= http://standards.ieee.org/develop/regauth/tut/eui64.pdf. The URL=0A= shown in RFC5342 for [EUI-64] redirects to that URL.=0A= =0A= --Sandy= From Sandra.Murphy@sparta.com Thu Jul 11 03:02:03 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC6721F9CAC for ; Thu, 11 Jul 2013 03:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILK58w3X-bfF for ; Thu, 11 Jul 2013 03:01:59 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2889121F9CF8 for ; Thu, 11 Jul 2013 03:01:59 -0700 (PDT) Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r6BA1wRi013427 for ; Thu, 11 Jul 2013 05:01:58 -0500 Received: from CVA-HUB002.centreville.ads.sparta.com ([10.62.108.29]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r6BA1wen029230 for ; Thu, 11 Jul 2013 05:01:58 -0500 Received: from CVA-MB001.centreville.ads.sparta.com ([fe80::58b4:c7c2:f9d:dff9]) by CVA-HUB002.centreville.ads.sparta.com ([fe80::9817:c0c5:e172:9d1c%11]) with mapi id 14.02.0342.003; Thu, 11 Jul 2013 06:02:44 -0400 From: "Murphy, Sandra" To: "secdir@ietf.org" Thread-Topic: secdir review of draft-jabley-dnsext-eui48-eui64-rrtypes Thread-Index: Ac5+GumGNRYPxviKTWiCYPIIjmd3zQAAgg/W Date: Thu, 11 Jul 2013 10:02:43 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6749A56DB@CVA-MB001.centreville.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6749A56A9@CVA-MB001.centreville.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6749A56A9@CVA-MB001.centreville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.62.8.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [secdir] secdir review of draft-jabley-dnsext-eui48-eui64-rrtypes X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 10:02:03 -0000 A further comment, for secdir consideration only.=0A= =0A= IPv6 addresses are in some cases derived from the MAC address,=0A= which would seem to make facilitating MAC cloning also facilitate=0A= IP address spoofing. But I haven't worked out a way that cloning=0A= MAC addresses and thereby spoofing the corresponding IPv6 address=0A= results in some *new* risk, particularly since finding the MAC=0A= address in the Canadian DOCSIS case requires knowing the IP=0A= address to begin with in order to look up the EUI in the reverse=0A= DNS, if I understand NTRE038 correctly. If the EUI RR were=0A= associated with some other DNS name (not the reverse zone), then=0A= the bad guy could look up that DNS name, find the EUI, construct=0A= the corresponding IPv6 address and misuse the IPv6 address. But=0A= that additional risk would apply only to an application in which=0A= there was a DNS name was associated with an EUI record but not=0A= an A record. Given the tendency to stuff everything into DNS,=0A= I can't say that *won't* happen.=0A= =0A= Perhaps someone here more inventive can see an exploit. I'm only=0A= uneasy, not really worried.=0A= =0A= --Sandy=0A= ________________________________________=0A= From: secdir-bounces@ietf.org [secdir-bounces@ietf.org] on behalf of Murphy= , Sandra [Sandra.Murphy@sparta.com]=0A= Sent: Thursday, July 11, 2013 5:42 AM=0A= To: secdir@ietf.org; iesg@ietf.org; draft-jabley-dnsext-eui48-eui64-rrtypes= @tools.ietf.org=0A= Subject: [secdir] secdir review of draft-jabley-dnsext-eui48-eui64-rrtypes= =0A= =0A= I have reviewed this document as part of the security=0A= directorate's ongoing effort to review all IETF documents=0A= being processed by the IESG. These comments were written=0A= primarily for the benefit of the security area directors.=0A= Document editors and WG chairs should treat these comments=0A= just like any other last call comments.=0A= =0A= This draft suggests two new DNS RRtypes that could encode IEEE=0A= EUI-48 and EUI-64 layer-2 addresses. There is at least one=0A= known use case of a Canadian required reverse DNS mapping of=0A= IP addresses to MAC addresses.=0A= =0A= The draft is simple and straight forward and follows the usual=0A= procedure for requesting a new RRtype.=0A= =0A= Security concern.=0A= =0A= You might want to mention that publication of the EUI's could=0A= facilitate MAC cloning.=0A= =0A= This isn't original to me. I followed the reference to the Canadian=0A= CRTC decision NTRE038D and looked at the various=0A= company "contributions" that led to that decision. One=0A= contribution from Clearcable (NTCO0362, see=0A= http://www.crtc.gc.ca/public/cisc/nt/NTCO0362.pdf) speaks of the=0A= risk that publication of EUI addresses in the global reverse DNS=0A= would facilitate the theft of service that arises from cloning=0A= the MAC address of a valid subscriber. DOCSIS modem MAC cloning=0A= does seem to be a known problem and concern, so perhaps this=0A= should be mentioned.=0A= =0A= The draft recommends restricting access to zones containing EUI64=0A= addresses to limit the privacy exposure. This is similar to the=0A= recommendation in the NTRE038D to use a split-view reverse DNS=0A= service. The draft's recommendation would also limit the=0A= exposure of valid EUI-64 addresses to MAC cloners, so I don't=0A= think you need to describe additional countermeasures.=0A= =0A= Nits and even more anal comments:=0A= =0A= Section 9 says "with the Global bit zero". I presume you mean=0A= the next-to-least-significant-bit in the first octet.=0A= =0A= RFC 5342 calls this bit the "Local bit" and the "Local/Global=0A= bit". RFC4291 calls this the "universal/local" bit. The IEEE=0A= 802 standard talks about "universal" and "local" without actually=0A= naming the bit, but lots of online documentation=0A= says "universal/local" and "U/L". So you and the RFC Editor can=0A= decide what term to use.=0A= =0A= IMHO: Continuing to call it the "Global bit" is my least favorite=0A= choice. Consistency with RFC5342 or RFC4291 would be preferable.=0A= =0A= Section 9 says:=0A= Publication of EUI-48 or EUI-64 addresses in the global DNS may=0A= result in privacy issues in the form of unique trackable identities.=0A= =0A= The privacy concern arises not just from the uniqueness of the=0A= EUI but from the fact that it is a more permanent identifier than=0A= the IP address associated with the subscriber (as the next=0A= paragraph notes). So "in the form of unique, permanent trackable=0A= identities" is probably more accurate. Similarly in the next=0A= paragraph "EUI-64 addresses normally provide a unique identifier"=0A= - the point is that the IP address "typically change over time"=0A= so "provide a unique permanent identifier" is what you mean. I=0A= think.=0A= =0A= The details of the IEEE references are incomplete. I might have=0A= recommended copying the references in RFC5342 but those=0A= references look to be out of date. I did find "Guidelines for=0A= 64-bit Global Identifier (EUI-64)"=0A= http://standards.ieee.org/develop/regauth/tut/eui64.pdf. The URL=0A= shown in RFC5342 for [EUI-64] redirects to that URL.=0A= =0A= --Sandy=0A= _______________________________________________=0A= secdir mailing list=0A= secdir@ietf.org=0A= https://www.ietf.org/mailman/listinfo/secdir=0A= wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview=0A= From kivinen@iki.fi Fri Jul 12 14:40:27 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B27F11E8111; Fri, 12 Jul 2013 14:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3RayeOFYzwE; Fri, 12 Jul 2013 14:40:26 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7153F21F9FFE; Fri, 12 Jul 2013 14:40:26 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r6CLeI35001027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 13 Jul 2013 00:40:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r6CLeFpR002904; Sat, 13 Jul 2013 00:40:15 +0300 (EEST) 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: <20960.30655.526275.938616@fireball.kivinen.iki.fi> Date: Sat, 13 Jul 2013 00:40:15 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-housley-ltans-oids.all@tools.ietf.org X-Mailer: VM 7.19 under Emacs 24.3.1 X-Edit-Time: 16 min X-Total-Time: 15 min Subject: [secdir] Secdir review of draft-housley-ltans-oids-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 21:40: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 document fills up the LTANS ASN.1 OID arc in the IANA registry. It adds some values and points them to published RFCs, and also reserves some values where there was never RFC published for those protocols. For some reason some of values include two OIDs, one for the 1997 and another 1988 ASN.1 syntax. I do not know enough of LTANS to understand why this distinction needs to be made in the OIDs themselves, I only assumed this affected the compilers and textual descriptions of the ASN.1 stuff, but perhaps OIDs here are used to indicate some ASN.1 text module or something. The security considerations section is very short: This document populates an IANA registry, and it raise no new security considerations. The protocols that specify these values include the security considerations associated with their usage. While this is true, it might be helpful to add references to the actual protocols it is refering here. The list of relevant RFCs can be found in the IANA considerations section, but adding pointers here might be helpful. I have not checked out whether the security considerations sections in those documents contain anything useful. One odd thing is that all registries are marked as "Expert Review or IESG Approval", but which one of those is used? Is this supposed to mean that if IESG appoints a designed expert for these, then he does checks the updates, but if not, then IESG approval is needed? Or is it mean to say that even when there is designated expert, the IESG and ignore him and do the approval themselves (in which case I Would ask what is the point of having the designated expert)? Usually there is only one way of doing the IANA updates. -- kivinen@iki.fi From housley@vigilsec.com Fri Jul 12 14:57:49 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211E421F9FE7; Fri, 12 Jul 2013 14:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMn5DQJ4MW0T; Fri, 12 Jul 2013 14:57:44 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id D98BB21F9FE9; Fri, 12 Jul 2013 14:57:43 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id A362AF240B0; Fri, 12 Jul 2013 17:58:29 -0400 (EDT) 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 RgeRjoHDeLQ6; Fri, 12 Jul 2013 17:57:26 -0400 (EDT) Received: from [192.168.2.109] (pool-96-241-163-41.washdc.fios.verizon.net [96.241.163.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CEB02F2408B; Fri, 12 Jul 2013 17:58:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <20960.30655.526275.938616@fireball.kivinen.iki.fi> Date: Fri, 12 Jul 2013 17:57:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0825B2AF-4B45-4B1A-888B-829D03D32AFB@vigilsec.com> References: <20960.30655.526275.938616@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1085) Cc: IESG , IETF SecDir Subject: Re: [secdir] Secdir review of draft-housley-ltans-oids-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 21:57:49 -0000 Tero: Thanks for the review. There are two ASN.1 flavors, and the documents provide a module for each = of them. Yes, the ITU-T really did make a second flavor without = considering backward compatibility. People that implement with ASN.1 = know which flavor their tools use. I do not think that the document that established a registry ought to = point to the security considerations of the protocols that make use of = the registry. A protocol implementor needs to read the protocol = document. Since the IESG designates all experts (and may also remove them), Expert = Review is sufficient. Russ On Jul 12, 2013, at 5:40 PM, Tero Kivinen wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > This document fills up the LTANS ASN.1 OID arc in the IANA registry. > It adds some values and points them to published RFCs, and also > reserves some values where there was never RFC published for those > protocols. >=20 > For some reason some of values include two OIDs, one for the 1997 and > another 1988 ASN.1 syntax. I do not know enough of LTANS to understand > why this distinction needs to be made in the OIDs themselves, I only > assumed this affected the compilers and textual descriptions of the > ASN.1 stuff, but perhaps OIDs here are used to indicate some ASN.1 > text module or something. >=20 > The security considerations section is very short: >=20 > This document populates an IANA registry, and it raise no new > security considerations. The protocols that specify these values > include the security considerations associated with their usage. >=20 > While this is true, it might be helpful to add references to the > actual protocols it is refering here. The list of relevant RFCs can be > found in the IANA considerations section, but adding pointers here > might be helpful. I have not checked out whether the security > considerations sections in those documents contain anything useful. >=20 > One odd thing is that all registries are marked as "Expert Review or > IESG Approval", but which one of those is used? Is this supposed to > mean that if IESG appoints a designed expert for these, then he does > checks the updates, but if not, then IESG approval is needed? Or is it > mean to say that even when there is designated expert, the IESG and > ignore him and do the approval themselves (in which case I Would ask > what is the point of having the designated expert)? >=20 > Usually there is only one way of doing the IANA updates. > --=20 > kivinen@iki.fi > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From kivinen@iki.fi Fri Jul 12 15:07:45 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E7C21F9ED9 for ; Fri, 12 Jul 2013 15:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lr1sfr6G36E2 for ; Fri, 12 Jul 2013 15:07:44 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7B121F9F27 for ; Fri, 12 Jul 2013 15:07:44 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r6CM7gwh022137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 13 Jul 2013 01:07:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r6CM7gI9004598; Sat, 13 Jul 2013 01:07:42 +0300 (EEST) 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: <20960.32302.718062.611976@fireball.kivinen.iki.fi> Date: Sat, 13 Jul 2013 01:07:42 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 7.19 under Emacs 24.3.1 X-Edit-Time: 1 min X-Total-Time: 0 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 22:07:45 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Matt Lepinski is next in the rotation. For telechat 2013-07-18 Reviewer LC end Draft Dan Harkins T 2013-07-03 draft-ietf-multimob-pmipv6-ropt-07 Stephen Kent T 2013-07-18 draft-ietf-jcardcal-jcard-04 Ondrej Sury T 2013-06-17 draft-ietf-abfab-eapapplicability-05 For telechat 2013-08-15 Simon Josefsson TR2013-07-23 draft-merkle-tls-brainpool-04 Last calls and special requests: Rob Austein 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Dave Cridland - draft-ietf-httpbis-p5-range-22 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 Donald Eastlake 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Paul Hoffman 2013-07-16 draft-ivov-xmpp-cusax-06 Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-04 Leif Johansson 2013-07-22 draft-ivov-grouptextchat-purpose-03 Scott Kelly 2013-07-17 draft-ietf-dhc-dhcpv6-failover-requirements-06 Warren Kumari 2013-07-15 draft-ietf-lisp-deployment-09 Julien Laganier - draft-ietf-avtcore-rtp-security-options-03 Julien Laganier - draft-ietf-websec-key-pinning-08 Ben Laurie 2013-07-25 draft-ietf-emu-crypto-bind-04 Alexey Melnikov - draft-ietf-payload-rtp-howto-04 Vincent Roca 2013-06-11 draft-ietf-avtcore-idms-11 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-10 Glen Zorn 2012-11-27 draft-ietf-lisp-eid-block-04 -- kivinen@iki.fi From d3e3e3@gmail.com Fri Jul 12 17:59:57 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1A821F9D62; Fri, 12 Jul 2013 17:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccbbTtKsT8tn; Fri, 12 Jul 2013 17:59:56 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6337921F9D0D; Fri, 12 Jul 2013 17:59:56 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id ef5so12076966obb.1 for ; Fri, 12 Jul 2013 17:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=2zX+0xY7Oaun8HOTgQcGhZmv9qnWyc5eerMViBZfudc=; b=fYF8pIgWFTuUbNs2hO/180qUJGto16pc9LF9gE+ZMMxDsR1E1lF4xbsqugXrr3Diwf O4y1WPyK/Xs5nBdo9pyQk8gWVG9TbJtafldtxVLILcMBY+nPW1hV9shlFzH4m1lIiIRs aTSLLH/57qmkB14JuMx2y1ZJJTtOlmnf7oeqef4HnM8dytHGK7A6QA/BCd2iutiOggl5 pD48ihdg6Lryo9Z3CZXPOAEkMKCpWsjSOXWp5wPbyPs7a470BLsOL45cx+vqjdmtVghe sybu76zWf3cJR0h9XEj0DT8sqsn7TrArnY/JPsHpYnhu6gFyg8jIMkdza+BeSU0t4BLc 5EOg== X-Received: by 10.182.72.137 with SMTP id d9mr36880844obv.99.1373677194851; Fri, 12 Jul 2013 17:59:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.73.106 with HTTP; Fri, 12 Jul 2013 17:59:34 -0700 (PDT) In-Reply-To: <6d411f21bfcb4636a4d9d234cec91bd0@BL2PR03MB592.namprd03.prod.outlook.com> References: <6d411f21bfcb4636a4d9d234cec91bd0@BL2PR03MB592.namprd03.prod.outlook.com> From: Donald Eastlake Date: Fri, 12 Jul 2013 20:59:34 -0400 Message-ID: To: Charlie Kaufman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-trill-directory-framework.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-trill-directory-framework-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 00:59:57 -0000 Hi Charlie, Thanks for the review, I believe I agree with all your points! See below. On Thu, Jul 11, 2013 at 1:20 AM, Charlie Kaufman w= rote: > 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 describes a framework for adding a central control mechanis= m to trill to replace or supplement its autoconfiguring mechanism of dynami= cally learning the locations of all addresses on the LAN. The specific prot= ocols for supplying and consuming this configuration information will presu= mably appear in future specs. This sort of configuration control is useful = in a datacenter where all connections are carefully configured rather than = being plug and play. It is particularly applicable in a "cloud" environment= where virtual machines are moved between physical machines by some sort of= Virtual Machine Management System that will also assign addresses and plac= e them. > > The Security Considerations section of this document is very bland, notin= g that reachability depends on the correct delivery of information and stat= ing that there may be security considerations specific to particular direct= ory assistance mechanisms. The feature is designed to improve performance r= ather than security. I believe this seriously understates the security adva= ntages that are possible if a central control mechanism replaces the autoco= nfiguration mechanism. In particular, the main protection/isolation mechani= sms available today on a LAN concern partitioning by VLAN. Within a VLAN, a= ny node can impersonate any other and can arrange to receive traffic addres= sed to another node. This can be prevented if the network learns the addres= ses belonging to each physical connection port not from looking at what the= node transmits but rather from a central controller. A node cannot receive= traffic addressed to someone else simply by sending a packet from that add= ress or responding to an ARP searching for an IP address. In fact, such pac= kets can be blocked by the ingress Rbridge. So control is much more fine-gr= ained than with VLANs. The network guarantees the authenticity of the sourc= e address of each incoming packet. Right. > The directory framework could be made more useful in serving this securit= y functionality if its configuration included in each entry not simply the = IP address, MAC/VLAN, and list of attached Rbridges, but also a port identi= fier for each attached RBridge. Egress RBridges could use this information = to impose more precise limits. If this information is not in the database, = a central controlling mechanism would need a separate protocol and communic= ations path to communicate this information to the Egress RBridges. The cur= rent spec allows such information to be included in the directory, but does= not require it. Another good point. How about if we replace the Security Considerations Section as follows: OLD Accurate mapping of IP addresses into MAC addresses and of MAC addresses to the RBridge from which they are reachable is important to the correct delivery of information. The security of specific directory assisted mechanisms will be discussed in the document or documents specifying those mechanisms. For general TRILL security considerations, see [RFC6325]. NEW For general TRILL security considerations, see Section 6 of [RFC6325]. Accurate mapping of IP addresses into MAC addresses and of MAC addresses to the RBridges from which they are reachable is important to the correct delivery of information. The security of specific directory assisted mechanisms for delivering such information will be discussed in the document or documents specifying those mechanisms. Directory assisted TRILL edge can substantially improve on the security of the default MAC address learning from the data plane used in a TRILL campus. With that data plane learning, any node can impersonate any other in the same data label (VLAN or FGL [FGL]) and can arrange to receive traffic addressed to another node. This can be prevented by disabling data plane MAC address learning and using trusted directory services, espeically if, when appropriate, ARP and ND messages are intercepted and responded too locally. Then end stations cannot receive traffic addressed to someone else simply by sending a packet from that MAC address or responding to an ARP or ND searching for an IP address. (Security ND or use of secure ESADI [ESADI] may also be helpful to security.) In fact, such possibly malicious packets can be blocked by the ingress RBridge. So control is much more fine-grained than the scope of a data labels, limiting spoofing to imposters directly connected to the same RBridge or, if RBrige port information is also provided by the directory, to on-link imposters. and also add just a few words earlier on mentioning improved security with a reference to the Security Considerations Section? > Nits: > > Page 4, bullet 4: "more common occurrence" -> "more frequent occurrence" OK. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From charliek@microsoft.com Fri Jul 12 20:46:48 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0CC11E817F; Fri, 12 Jul 2013 20:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.533 X-Spam-Level: * X-Spam-Status: No, score=1.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZnl9++GxYSR; Fri, 12 Jul 2013 20:46:41 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2C611E80E4; Fri, 12 Jul 2013 20:46:40 -0700 (PDT) Received: from BN1BFFO11FD016.protection.gbl (10.58.52.202) by BN1BFFO11HUB027.protection.gbl (10.58.53.137) with Microsoft SMTP Server (TLS) id 15.0.717.3; Sat, 13 Jul 2013 03:46:39 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD016.mail.protection.outlook.com (10.58.53.76) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Sat, 13 Jul 2013 03:46:39 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.3.136.1; Sat, 13 Jul 2013 03:46:38 +0000 Received: from mail114-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.22; Sat, 13 Jul 2013 03:46:37 +0000 Received: from mail114-ch1 (localhost [127.0.0.1]) by mail114-ch1-R.bigfish.com (Postfix) with ESMTP id 190691C0472; Sat, 13 Jul 2013 03:46:37 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -39 X-BigFish: PS-39(zz98dI9371I542I1432Ibf3W4015I1447Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hz8dhz1033IL8275bh8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) Received-SPF: softfail (mail114-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=charliek@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(24454002)(51704005)(164054003)(30594002)(377454003)(13464003)(51914003)(51856001)(77096001)(56776001)(59766001)(46102001)(56816003)(80022001)(76576001)(76796001)(76482001)(53806001)(74366001)(49866001)(74502001)(69226001)(76786001)(83072001)(74316001)(54356001)(4396001)(54316002)(65816001)(66066001)(16406001)(63696002)(33646001)(47736001)(74662001)(74876001)(31966008)(50986001)(47976001)(47446002)(79102001)(74706001)(77982001)(81342001)(81542001)(1411001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB592; H:BL2PR03MB592.namprd03.prod.outlook.com; CLIP:50.46.151.49; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail114-ch1 (localhost.localdomain [127.0.0.1]) by mail114-ch1 (MessageSwitch) id 137368719562702_25594; Sat, 13 Jul 2013 03:46:35 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail114-ch1.bigfish.com (Postfix) with ESMTP id F417D20047; Sat, 13 Jul 2013 03:46:34 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 13 Jul 2013 03:46:34 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.329.3; Sat, 13 Jul 2013 03:46:33 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) by BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) with Microsoft SMTP Server (TLS) id 15.0.731.11; Sat, 13 Jul 2013 03:46:32 +0000 Received: from BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.121]) by BL2PR03MB592.namprd03.prod.outlook.com ([169.254.11.121]) with mapi id 15.00.0731.000; Sat, 13 Jul 2013 03:46:31 +0000 From: Charlie Kaufman To: Donald Eastlake Thread-Topic: [secdir] secdir review of draft-ietf-trill-directory-framework-05 Thread-Index: Ac598XBBv+Y+ucf3RaayD+kk4dv1wQBcszoAAAXSzzA= Date: Sat, 13 Jul 2013 03:46:31 +0000 Message-ID: References: <6d411f21bfcb4636a4d9d234cec91bd0@BL2PR03MB592.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.151.49] x-forefront-prvs: 0906E83A25 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PR03MB592.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TOOLS.IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51914003)(189002)(24454002)(30594002)(377454003)(164054003)(51704005)(13464003)(199002)(76786001)(46406003)(46102001)(76482001)(33646001)(1411001)(79102001)(74502001)(56776001)(23726002)(80022001)(76796001)(74316001)(4396001)(74876001)(69226001)(50986001)(16676001)(20776003)(81542001)(47776003)(76576001)(74662001)(50466002)(74706001)(31966008)(66066001)(77096001)(83072001)(47976001)(81342001)(54316002)(6806004)(47736001)(59766001)(74366001)(65816001)(47446002)(54356001)(77982001)(49866001)(44976005)(51856001)(56816003)(63696002)(53806001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB027; H:TK5EX14MLTC104.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0906E83A25 Cc: "draft-ietf-trill-directory-framework.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-trill-directory-framework-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 03:46:48 -0000 Sounds great! --Charlie -----Original Message----- From: Donald Eastlake [mailto:d3e3e3@gmail.com]=20 Sent: Friday, July 12, 2013 6:00 PM To: Charlie Kaufman Cc: secdir@ietf.org; iesg@ietf.org; draft-ietf-trill-directory-framework.al= l@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-trill-directory-framework= -05 Hi Charlie, Thanks for the review, I believe I agree with all your points! See below. On Thu, Jul 11, 2013 at 1:20 AM, Charlie Kaufman w= rote: > 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 describes a framework for adding a central control mechanis= m to trill to replace or supplement its autoconfiguring mechanism of dynami= cally learning the locations of all addresses on the LAN. The specific prot= ocols for supplying and consuming this configuration information will presu= mably appear in future specs. This sort of configuration control is useful = in a datacenter where all connections are carefully configured rather than = being plug and play. It is particularly applicable in a "cloud" environment= where virtual machines are moved between physical machines by some sort of= Virtual Machine Management System that will also assign addresses and plac= e them. > > The Security Considerations section of this document is very bland, notin= g that reachability depends on the correct delivery of information and stat= ing that there may be security considerations specific to particular direct= ory assistance mechanisms. The feature is designed to improve performance r= ather than security. I believe this seriously understates the security adva= ntages that are possible if a central control mechanism replaces the autoco= nfiguration mechanism. In particular, the main protection/isolation mechani= sms available today on a LAN concern partitioning by VLAN. Within a VLAN, a= ny node can impersonate any other and can arrange to receive traffic addres= sed to another node. This can be prevented if the network learns the addres= ses belonging to each physical connection port not from looking at what the= node transmits but rather from a central controller. A node cannot receive= traffic addressed to someone else simply by sending a packet from that add= ress or responding to an ARP searching for an IP address. In fact, such pac= kets can be blocked by the ingress Rbridge. So control is much more fine-gr= ained than with VLANs. The network guarantees the authenticity of the sourc= e address of each incoming packet. Right. > The directory framework could be made more useful in serving this securit= y functionality if its configuration included in each entry not simply the = IP address, MAC/VLAN, and list of attached Rbridges, but also a port identi= fier for each attached RBridge. Egress RBridges could use this information = to impose more precise limits. If this information is not in the database, = a central controlling mechanism would need a separate protocol and communic= ations path to communicate this information to the Egress RBridges. The cur= rent spec allows such information to be included in the directory, but does= not require it. Another good point. How about if we replace the Security Considerations Sec= tion as follows: OLD Accurate mapping of IP addresses into MAC addresses and of MAC addresses to the RBridge from which they are reachable is important to the correct delivery of information. The security of specific directory assisted mechanisms will be discussed in the document or documents specifying those mechanisms. For general TRILL security considerations, see [RFC6325]. NEW For general TRILL security considerations, see Section 6 of [RFC6325]. Accurate mapping of IP addresses into MAC addresses and of MAC addresses to the RBridges from which they are reachable is important to the correct delivery of information. The security of specific directory assisted mechanisms for delivering such information will be discussed in the document or documents specifying those mechanisms. Directory assisted TRILL edge can substantially improve on the security of the default MAC address learning from the data plane used in a TRILL campus. With that data plane learning, any node can impersonate any other in the same data label (VLAN or FGL [FGL]) and can arrange to receive traffic addressed to another node. This can be prevented by disabling data plane MAC address learning and using trusted directory services, espeically if, when appropriate, ARP and ND messages are intercepted and responded too locally. Then end stations cannot receive traffic addressed to someone else simply by sending a packet from that MAC address or responding to an ARP or ND searching for an IP address. (Security ND or use of secure ESADI [ESADI] may also be helpful to security.) In fact, such possibly malicious packets can be blocked by the ingress RBridge. So control is much more fine-grained than the scope of a data labels, limiting spoofing to imposters directly connected to the same RBridge or, if RBrige port information is also provided by the directory, to on-link imposters. and also add just a few words earlier on mentioning improved security with = a reference to the Security Considerations Section? > Nits: > > Page 4, bullet 4: "more common occurrence" -> "more frequent occurrence" OK. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From scott@hyperthought.com Sat Jul 13 15:09:10 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C48521F9EA7 for ; Sat, 13 Jul 2013 15:09:10 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raqOGLmPstCm for ; Sat, 13 Jul 2013 15:09:05 -0700 (PDT) Received: from smtp122.iad.emailsrvr.com (smtp122.iad.emailsrvr.com [207.97.245.122]) by ietfa.amsl.com (Postfix) with ESMTP id E538521F9E2D for ; Sat, 13 Jul 2013 15:09:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp52.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id C1C9B240272; Sat, 13 Jul 2013 18:09:02 -0400 (EDT) X-Virus-Scanned: OK Received: from legacy7.wa-web.iad1a (legacy7.wa-web.iad1a.rsapps.net [192.168.2.216]) by smtp52.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 8F9B9240260; Sat, 13 Jul 2013 18:09:02 -0400 (EDT) Received: from hyperthought.com (localhost [127.0.0.1]) by legacy7.wa-web.iad1a (Postfix) with ESMTP id 60E8D3200B4; Sat, 13 Jul 2013 18:09:02 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Sat, 13 Jul 2013 15:09:02 -0700 (PDT) Date: Sat, 13 Jul 2013 15:09:02 -0700 (PDT) From: "Scott G. Kelly" To: draft-ietf-dhc-dhcpv6-failover-requirements.all@tools.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: <1373753342.3954517@apps.rackspace.com> X-Mailer: webmail7.0 Cc: "iesg@ietf.org" Subject: [secdir] secdir review of draft-ietf-dhc-dhcpv6-failover-requirements X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 22:09:10 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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 describes requirements for d= hcpv6 failover. The document seems to be a combined problem statement and r= equirements document.=0A=0AWhen I read requirements document like this, I e= xpect to see a progression from use cases to goals to requirements. Sometim= es the use cases (and some/all goals) are outlined in a problem statement, = but the point is that the described requirements have some associated basis= /rationale. This allows us to understand the relative importance of a given= requirement, and the tradeoffs if we can't meet it for some reason.=0A=0AI= didn't find this when it comes to security. There is a security considerat= ions section, and for convenience, here it is:=0A=0A The design must allo= w secure communication between the failover=0A partners. This requiremen= t applies to the specification only, i.e.=0A the design must include a wa= y to secure communication. It does not=0A mandate such security be emplo= yed, just that it be available.=0A=0A The protocol specification, when it= is written, should provide=0A operational guidelines in the case of auth= entication mechanisms that=0A require access to network servers that have= the potential to be=0A unreachable (e.g. what to do if a partner is reac= hable, but remote=0A Certificate Authority is unreachable due to network = partition event).=0A=0A The security considerations for the design itself= will be discussed=0A in the design document.=0A=0AWhat is "secure commun= ication", and why is it required? The second paragraph seems to imply that = authentication is part of it, but is that all? =0A=0AThe last line seems to= punt on security considerations, and maybe that is acceptable to the worki= ng group. I'm not advocating for a detailed security analysis in the requir= ements document, but I do think a high level discussion of goals/requiremen= ts for confidentiality, integrity, and availability makes sense. You will n= eed this in order to discuss the suitability of any proposed security mecha= nisms in later documents. This document seems like the right place for that= .=0A=0A--Scott=0A From jhutz@cmu.edu Mon Jul 15 11:33:59 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000FE1F0D3E; Mon, 15 Jul 2013 11:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmMpFV+vSQw5; Mon, 15 Jul 2013 11:33:52 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 46AE721E8115; Mon, 15 Jul 2013 11:33:36 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r6FIXW45020921 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 15 Jul 2013 14:33:32 -0400 (EDT) Message-ID: <1373913212.23365.299.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Tero Kivinen Date: Mon, 15 Jul 2013 14:33:32 -0400 In-Reply-To: <23706_1373665231_r6CLeT1d025396_20960.30655.526275.938616@fireball.kivinen.iki.fi> References: <23706_1373665231_r6CLeT1d025396_20960.30655.526275.938616@fireball.kivinen.iki.fi> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: draft-housley-ltans-oids.all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org, jhutz@cmu.edu Subject: Re: [secdir] Secdir review of draft-housley-ltans-oids-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:33:59 -0000 On Sat, 2013-07-13 at 00:40 +0300, Tero Kivinen wrote: > One odd thing is that all registries are marked as "Expert Review or > IESG Approval", but which one of those is used? Is this supposed to > mean that if IESG appoints a designed expert for these, then he does > checks the updates, but if not, then IESG approval is needed? Or is it > mean to say that even when there is designated expert, the IESG and > ignore him and do the approval themselves (in which case I Would ask > what is the point of having the designated expert)? It means that either the "Expert Review" or "IESG Approval" methods can be used. Over the years, we've seen a number of cases where it turns out to be desirable to assign a number under circumstances not foreseen by the authors of the document that originally set up a registry, and under which none of the policies attached to that registry can be applied. As defined in RFC5226, the "IESG Approval" policy is intended to be an escape valve that allows the IESG to handle these exceptions, rather than failing an allocation due to a policy bug when it clearly should have been accepted. Of course, in such a case one can always publish an IETF consensus document to change the policy, but often that introduces an unacceptable level of delay. As Russ notes, when the defined policy is "Expert Review", the IESG can likely handle exceptions by designating an expert, so perhaps the escape valve is not necessary. However, I don't think it's harmful. However, I do note that this document uses the "Expert Review" policy several times, but fails to specify the required level of documentation or the review criteria to be used by the Designated Expert. Without this information, I don't think it's possible to make any meaningful comment on the IANA registration policies. -- Jeff From paul.hoffman@vpnc.org Wed Jul 17 08:13:47 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9AC11E80F9 for ; Wed, 17 Jul 2013 08:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxma67TGY83K for ; Wed, 17 Jul 2013 08:13:47 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 16B9E11E80FA for ; Wed, 17 Jul 2013 08:13:42 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r6HFDe30060696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Jul 2013 08:13:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <845C917C-4115-4F3E-9E91-E6A3DB903F0C@vpnc.org> Date: Wed, 17 Jul 2013 08:13:42 -0700 To: secdir , draft-ivov-xmpp-cusax.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [secdir] Secdir review of draft-ivov-xmpp-cusax X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 15:13:47 -0000 Greetings. I have reviewed this document for security issues, and have = mixed feelings. I apologize for the lateness of this review. The draft specifies a non-normative way to make clients (and to a small = extent, servers) mostly-transparently combine the use of SIP for voice = and video with XMPP for instant messaging. It is informational, and = talks about the various things that applications developers of software = that makes this combination should think about. Security is barely discussed, likely because a client that is presenting = two different protocols that each have their own security frameworks is = not going to make the security of either protocol worse. However, user = perception of security will be significantly affected by the = combination. There is one paragraph that alludes to this in the Security = Considerations, but there should be more. The first sentence of that one paragraph describes mis-matched crypto = between the SIP part and the XMPP part, which is fine but mostly = invisible to users. The second sentence is much more worrying: it describes the case where = one of the protocols is cryptographically protected and the other has = none. This is an all-too-common case with IETF protocols: the user = doesn't have to turn on crypto, and once it is not turned on, that fact = is forgotten. The document blithely says that the application developer = should ensure that such mis-matches are avoided to prevent downgrade = attacks, but says nothing about how that could be avoided. A stronger = statement would be "if both protocols are not protected by similar = levels of cryptographic protection, the user MUST be informed of that = and given the opportunity to bring both up to the same level". There should also be at least a paragraph describing the difference in = commonly-used authentication mechanisms for SIP and XMPP. A user may = have authenticated one of the two channels with an easily-attacked = password, but the other channel with a strong cryptographic mechanism = such as TLS client certificates. When you combine two similar functions = into one application without making that clear, a user might assume that = their IM and voice communications are similarly protected when in fact = they are not. It would also be valuable if the document mentioned the possibility of = security mis-match in the introduction, given the high chance for user = confusion on the issue. --Paul Hoffman= From stephen.farrell@cs.tcd.ie Wed Jul 17 11:38:10 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D84221F9A5F for ; Wed, 17 Jul 2013 11:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE-SJwNYK+Qy for ; Wed, 17 Jul 2013 11:38:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7897A21F9814 for ; Wed, 17 Jul 2013 11:38:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CE134BEB0 for ; Wed, 17 Jul 2013 19:37:42 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTsB-9lkgD1J for ; Wed, 17 Jul 2013 19:37:41 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.52.27]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BA2DEBE9C for ; Wed, 17 Jul 2013 19:37:41 +0100 (IST) Message-ID: <51E6E46A.3070109@cs.tcd.ie> Date: Wed, 17 Jul 2013 19:37:30 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "secdir@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] AD expertise X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 18:38:10 -0000 Hiya, Each year the IESG send nomcom a description of what the IESG believe is the expertise that's needed for the AD role. As a recent nomcom may have interpreted these as hard requirements, and that might have made nomcom's job of picking someone (or not picking someone) harder, its been suggested that it might be useful to get a bit of feedback before we shoot it off this year. So, if you have any comments on these descriptions please send those to Sean and I or to the IESG as a whole (which is iesg@ietf.org). The security AD description is at [1] and the generic AD text is at [2]. Note - I'd rather we get comments on this offlist since an onlist discussion could maybe possibly just risk heading towards someone being perceived as lobbying for something. Even though that's not too likely I think its better to just not go there. But of course I can't stop you from hitting reply-all;-) And of course, once nomcom get going it'd be really great for them if you provide them with feedback both on folks who put their name forward but also on the AD roles in general, and that latter you could do pretty much anytime. Thanks, S. [1] http://trac.tools.ietf.org/group/iesg/trac/wiki/SecurityExpertise [2] http://trac.tools.ietf.org/group/iesg/trac/wiki/GenericExpertise From psaintan@cisco.com Wed Jul 17 12:56:59 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E616E21E808F for ; Wed, 17 Jul 2013 12:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUZICmewZv9a for ; Wed, 17 Jul 2013 12:56:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 56CA621E808E for ; Wed, 17 Jul 2013 12:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3079; q=dns/txt; s=iport; t=1374091014; x=1375300614; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wyDLnm4xAuydEL5/v2cPfG4EUbCsA8m9mtzjxF/gBWg=; b=Rsk/6TUuxuKnW1TcPREHX9z72BYuINP7/m7DJjf/XD19D/QYBTaGGrQd It/drQzl/B7/1KOgcnCfGq2mJC85XA73SBXF4F+KR1ZwQGzeIja4tZt7b ayJzBURLpb/4q2sEaaGzjRFXzRQiShIgPqLAF6QUFxxUmRJx77etM3yI3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAIP15lGtJV2c/2dsb2JhbABagwaBBMB/gRIWdIIjAQEBAwE6PwULAgEIIg4GEDIlAgQOBQiIAga2Do9HAjEHGIJ1bgOpKYMSgig X-IronPort-AV: E=Sophos;i="4.89,687,1367971200"; d="scan'208";a="236108111" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 17 Jul 2013 19:56:53 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6HJurwe016543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 19:56:53 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.51]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 14:56:53 -0500 From: "Peter Saint-Andre (psaintan)" To: Paul Hoffman Thread-Topic: Secdir review of draft-ivov-xmpp-cusax Thread-Index: AQHOgwBB/5UCzShgO0ORdAU4etqp25lpnWAA Date: Wed, 17 Jul 2013 19:56:52 +0000 Message-ID: <1670FE635C32C34AAD005D960F1C501115CA4D2B@xmb-aln-x11.cisco.com> References: <845C917C-4115-4F3E-9E91-E6A3DB903F0C@vpnc.org> In-Reply-To: <845C917C-4115-4F3E-9E91-E6A3DB903F0C@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.116] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ivov-xmpp-cusax.all@tools.ietf.org" , Peter Saint-Andre , secdir Subject: Re: [secdir] Secdir review of draft-ivov-xmpp-cusax X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 19:57:00 -0000 Hi Paul, thank you for the review. On Jul 17, 2013, at 9:13 AM, Paul Hoffman wrote: > Greetings. I have reviewed this document for security issues, and have mi= xed feelings. I apologize for the lateness of this review. >=20 > The draft specifies a non-normative way to make clients (and to a small e= xtent, servers) mostly-transparently combine the use of SIP for voice and v= ideo with XMPP for instant messaging. It is informational, and talks about = the various things that applications developers of software that makes this= combination should think about. >=20 > Security is barely discussed, likely because a client that is presenting = two different protocols that each have their own security frameworks is not= going to make the security of either protocol worse. However, user percept= ion of security will be significantly affected by the combination. There is= one paragraph that alludes to this in the Security Considerations, but the= re should be more. >=20 > The first sentence of that one paragraph describes mis-matched crypto bet= ween the SIP part and the XMPP part, which is fine but mostly invisible to = users. >=20 > The second sentence is much more worrying: it describes the case where on= e of the protocols is cryptographically protected and the other has none. T= his is an all-too-common case with IETF protocols: the user doesn't have to= turn on crypto, and once it is not turned on, that fact is forgotten. The = document blithely says that the application developer should ensure that su= ch mis-matches are avoided to prevent downgrade attacks, but says nothing a= bout how that could be avoided. A stronger statement would be "if both prot= ocols are not protected by similar levels of cryptographic protection, the = user MUST be informed of that and given the opportunity to bring both up to= the same level". Agreed. Thanks for the text suggestion. > There should also be at least a paragraph describing the difference in co= mmonly-used authentication mechanisms for SIP and XMPP. A user may have aut= henticated one of the two channels with an easily-attacked password, but th= e other channel with a strong cryptographic mechanism such as TLS client ce= rtificates. When you combine two similar functions into one application wit= hout making that clear, a user might assume that their IM and voice communi= cations are similarly protected when in fact they are not. The two examples in the Security Considerations are (1) authentication and = (2) channel encryption. Do you think we need a full new paragraph about aut= hentication mechanism mismatches, or would it be acceptable to expand upon = the text that's there now? > It would also be valuable if the document mentioned the possibility of se= curity mis-match in the introduction, given the high chance for user confus= ion on the issue. Yes, that would be helpful. The authors will put their heads together and come back with proposed text = changes. -- Peter Saint-Andre From kent@bbn.com Wed Jul 17 13:16:28 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E30911E80DC for ; Wed, 17 Jul 2013 13:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHreCIjgXxWj for ; Wed, 17 Jul 2013 13:16:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E1FDD11E80AE for ; Wed, 17 Jul 2013 13:16:21 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:57627) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UzY8i-00004r-8O; Wed, 17 Jul 2013 16:15:56 -0400 Message-ID: <51E6FB7C.2060106@bbn.com> Date: Wed, 17 Jul 2013 16:15:56 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: secdir , mozilla@kewis.ch Content-Type: multipart/alternative; boundary="------------020705000104040705020103" Cc: bert.greevenbosch@huawei.com, Barry Leiba , Pete Resnick , stpeter@stpeter.im Subject: [secdir] SECDIR review of draft-ietf-jcardcal-jcard-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:16:28 -0000 This is a multi-part message in MIME format. --------------020705000104040705020103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit SECDIR review of draft-ietf-jcardcal-jcard-05 I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.These comments were written primarily for the benefit of the security area directors.Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a JSON format for vCard data, as previously defined in RFC 6350. This document cites the Security Considerations section of original vCard RFC (noted above) as the primary content for its Security Considerations section. It asserts that no new security concerns arise with respect to _calendar data_, because this specification merely maps the original vCard data to a new format.However, it then cites the Security Considerations section of the JSON specification (RFC 4627) noting that there are additional security risks that arise from using JSON to represent vCard data! To me these two statements seem somewhat contradictory, but that can be addressed by refining the wording here. More worrisome is the fact that this very brief section mentions only calendar data security. Does that mean that no other type of vCard use, when using JSON encoding, creates any new security concerns? This document is much broader in scope than just iCal data (the subject of draft-ietf-jcardcal-jcal-07), so this narrowly focused comment seems out of place. RFC 6350's Security Considerations section notes few concerns that are Vcard-specific; most of the comments in that section relate to the need to provide security for vCards when they are transported, e.g., via email. All of these concerns are equally applicable here, as indicated, without the calendar data comment. RFC 4627's security considerations section turns out to be an indirect reference to two paragraphs in the IANA Considerations section! (This seems silly and it's not clear why that document was published with such an obvious structural error, but ...). The security concern cited in 4627 is that JavaScript (JS) is a scripting language and thus JSON might be used to execute malicious JS. However JSON is intended to be a "safe" subset of JS, i.e., it should be able to be evaluated in JS without security concerns, if it is properly constrained.The text in 4627 provides two regular expressions that can be invoked to strip any characters that might cause security problems. I'd feel a lot more comfortable if this text were explicitly replicated in this I-D, and the I-D _mandated_ this processing step before passing the Jcard data to JS. (It might even make sense as a post processing step as part of the vCard to JCard processing described in Section 3.) The level of indirection currently used in the Security Considerations section, and the casual advisory nature of the original text might easily be overlooked by an implementer. Finally, the notion of JSON as "safe" JS subset assumes that the parser processing the JSON does not have a security flaw. Such flaws have been identified, one as recently as February of this year. It might be good to note that this represents a new type of security concern that would not arise in a conventional vCard context. --------------020705000104040705020103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

SECDIR review of draft-ietf-jcardcal-jcard-05

 

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

 

This document describes a JSON format for vCard data, as previously defined in RFC 6350.

 

This document cites the Security Considerations section of original vCard RFC (noted above) as the primary content for its Security Considerations section. It asserts that no new security concerns arise with respect to calendar data, because this specification merely maps the original vCard data to a new format.  However, it then cites the Security Considerations section of the JSON specification (RFC 4627) noting that there are additional security risks that arise from using JSON to represent vCard data! To me these two statements seem somewhat contradictory, but that can be addressed by refining the wording here.

 

More worrisome is the fact that this very brief section mentions only calendar data security. Does that mean that no other type of vCard use, when using JSON encoding, creates any new security concerns? This document is much broader in scope than just iCal data (the subject of draft-ietf-jcardcal-jcal-07), so this narrowly focused comment seems out of place.

 

RFC 6350’s Security Considerations section notes few concerns that are Vcard-specific; most of the comments in that section relate to the need to provide security for vCards when they are transported, e.g., via email. All of these concerns are equally applicable here, as indicated, without the calendar data comment.

 

RFC 4627’s security considerations section turns out to be an indirect reference to two paragraphs in the IANA Considerations section! (This seems silly and it’s not clear why that document was published with such an obvious structural error, but …). The security concern cited in 4627 is that JavaScript (JS) is a scripting language and thus JSON might be used to execute malicious JS. However JSON is intended to be a “safe” subset of JS, i.e., it should be able to be evaluated in JS without security concerns, if it is properly constrained.  The text in 4627 provides two regular expressions that can be invoked to strip any characters that might cause security problems. I’d feel a lot more comfortable if this text were explicitly replicated in this I-D, and the I-D mandated this processing step before passing the Jcard data to JS. (It might even make sense as a post processing step as part of the vCard to JCard processing described in Section 3.) The level of indirection currently used in the Security Considerations section, and the casual advisory nature of the original text might easily be overlooked by an implementer.

 

Finally, the notion of JSON as “safe” JS subset assumes that the parser processing the JSON does not have a security flaw. Such flaws have been identified, one as recently as February of this year. It might be good to note that this represents a new type of security concern that would not arise in a conventional vCard context.

 

--------------020705000104040705020103-- From kent@bbn.com Wed Jul 17 13:30:03 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD36521F9C33 for ; Wed, 17 Jul 2013 13:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xt7jh20-B6FI for ; Wed, 17 Jul 2013 13:29:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 174B921F9A1C for ; Wed, 17 Jul 2013 13:29:58 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:57641) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UzYM1-0000Cy-45; Wed, 17 Jul 2013 16:29:41 -0400 Message-ID: <51E6FEB4.8020402@bbn.com> Date: Wed, 17 Jul 2013 16:29:40 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Pete Resnick References: <51E6FB7C.2060106@bbn.com> <51E6FD7E.5000504@qti.qualcomm.com> In-Reply-To: <51E6FD7E.5000504@qti.qualcomm.com> Content-Type: multipart/alternative; boundary="------------050009050500060306020206" Cc: bert.greevenbosch@huawei.com, Barry Leiba , stpeter@stpeter.im, mozilla@kewis.ch, secdir Subject: Re: [secdir] SECDIR review of draft-ietf-jcardcal-jcard-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:30:04 -0000 This is a multi-part message in MIME format. --------------050009050500060306020206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pete, > Steve, > > Are you OK with us forwarding this to the jcardcal mailing list? I > think the entire list would benefit by seeing it. sure. Steve --------------050009050500060306020206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pete,
Steve,

Are you OK with us forwarding this to the jcardcal mailing list? I think the entire list would benefit by seeing it.
sure.

Steve

--------------050009050500060306020206-- From presnick@qti.qualcomm.com Wed Jul 17 13:24:40 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC6121F9A4A for ; Wed, 17 Jul 2013 13:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZiLf59uQkR4 for ; Wed, 17 Jul 2013 13:24:36 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 029FF21F99E9 for ; Wed, 17 Jul 2013 13:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1374092675; x=1405628675; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=h0+Fp2dxw9KWd7ZUE2BM2o9G5Jx4pD/jTChzLBTPGgg=; b=TJO3pAycxy24unbm2XazahQLs32gk7K3B9Ia6NI9AR7NG3HKfrcb5ihI PiQXS1cIMoMukbQIw/hZyGjxHqNMlQEeerZnFP7JC7BBJvCvmxAQHXQa1 dhQof+YImAL556XPV/H4UVvGrDSzoxCJihHx4svK2R+UajpQAvEq3OPWm I=; X-IronPort-AV: E=Sophos;i="4.89,687,1367996400"; d="scan'208,217";a="47588867" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 17 Jul 2013 13:24:35 -0700 X-IronPort-AV: E=Sophos;i="4.89,687,1367996400"; d="scan'208,217";a="516139921" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Jul 2013 13:24:35 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 17 Jul 2013 13:24:34 -0700 Message-ID: <51E6FD7E.5000504@qti.qualcomm.com> Date: Wed, 17 Jul 2013 15:24:30 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Stephen Kent References: <51E6FB7C.2060106@bbn.com> In-Reply-To: <51E6FB7C.2060106@bbn.com> Content-Type: multipart/alternative; boundary="------------070906010709060407090704" X-Originating-IP: [172.30.48.1] X-Mailman-Approved-At: Wed, 17 Jul 2013 13:31:12 -0700 Cc: bert.greevenbosch@huawei.com, Barry Leiba , stpeter@stpeter.im, mozilla@kewis.ch, secdir Subject: Re: [secdir] SECDIR review of draft-ietf-jcardcal-jcard-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:24:41 -0000 --------------070906010709060407090704 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Steve, Are you OK with us forwarding this to the jcardcal mailing list? I think the entire list would benefit by seeing it. You are correct that references to "calendar data" in section 7 are bogus. It should refer to "contact" or simply "vCard" data. Clearly all of us have been standing too close to the document. Thanks for your comments. We will address them in the document. pr On 7/17/13 3:15 PM, Stephen Kent wrote: > > SECDIR review of draft-ietf-jcardcal-jcard-05 > > I reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments > just like any other last call comments. > > This document describes a JSON format for vCard data, as previously > defined in RFC 6350. > > This document cites the Security Considerations section of original > vCard RFC (noted above) as the primary content for its Security > Considerations section. It asserts that no new security concerns arise > with respect to _calendar data_, because this specification merely > maps the original vCard data to a new format. However, it then cites > the Security Considerations section of the JSON specification (RFC > 4627) noting that there are additional security risks that arise from > using JSON to represent vCard data! To me these two statements seem > somewhat contradictory, but that can be addressed by refining the > wording here. > > More worrisome is the fact that this very brief section mentions only > calendar data security. Does that mean that no other type of vCard > use, when using JSON encoding, creates any new security concerns? This > document is much broader in scope than just iCal data (the subject of > draft-ietf-jcardcal-jcal-07), so this narrowly focused comment seems > out of place. > > RFC 6350's Security Considerations section notes few concerns that are > Vcard-specific; most of the comments in that section relate to the > need to provide security for vCards when they are transported, e.g., > via email. All of these concerns are equally applicable here, as > indicated, without the calendar data comment. > > RFC 4627's security considerations section turns out to be an indirect > reference to two paragraphs in the IANA Considerations section! (This > seems silly and it's not clear why that document was published with > such an obvious structural error, but ...). The security concern cited > in 4627 is that JavaScript (JS) is a scripting language and thus JSON > might be used to execute malicious JS. However JSON is intended to be > a "safe" subset of JS, i.e., it should be able to be evaluated in JS > without security concerns, if it is properly constrained. The text in > 4627 provides two regular expressions that can be invoked to strip any > characters that might cause security problems. I'd feel a lot more > comfortable if this text were explicitly replicated in this I-D, and > the I-D _mandated_ this processing step before passing the Jcard data > to JS. (It might even make sense as a post processing step as part of > the vCard to JCard processing described in Section 3.) The level of > indirection currently used in the Security Considerations section, and > the casual advisory nature of the original text might easily be > overlooked by an implementer. > > Finally, the notion of JSON as "safe" JS subset assumes that the > parser processing the JSON does not have a security flaw. Such flaws > have been identified, one as recently as February of this year. It > might be good to note that this represents a new type of security > concern that would not arise in a conventional vCard context. > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------070906010709060407090704 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Steve,

Are you OK with us forwarding this to the jcardcal mailing list? I think the entire list would benefit by seeing it.

You are correct that references to "calendar data" in section 7 are bogus. It should refer to "contact" or simply "vCard" data. Clearly all of us have been standing too close to the document.

Thanks for your comments. We will address them in the document.

pr

On 7/17/13 3:15 PM, Stephen Kent wrote:

SECDIR review of draft-ietf-jcardcal-jcard-05

 

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

 

This document describes a JSON format for vCard data, as previously defined in RFC 6350.

 

This document cites the Security Considerations section of original vCard RFC (noted above) as the primary content for its Security Considerations section. It asserts that no new security concerns arise with respect to calendar data, because this specification merely maps the original vCard data to a new format.  However, it then cites the Security Considerations section of the JSON specification (RFC 4627) noting that there are additional security risks that arise from using JSON to represent vCard data! To me these two statements seem somewhat contradictory, but that can be addressed by refining the wording here.

 

More worrisome is the fact that this very brief section mentions only calendar data security. Does that mean that no other type of vCard use, when using JSON encoding, creates any new security concerns? This document is much broader in scope than just iCal data (the subject of draft-ietf-jcardcal-jcal-07), so this narrowly focused comment seems out of place.

 

RFC 6350’s Security Considerations section notes few concerns that are Vcard-specific; most of the comments in that section relate to the need to provide security for vCards when they are transported, e.g., via email. All of these concerns are equally applicable here, as indicated, without the calendar data comment.

 

RFC 4627’s security considerations section turns out to be an indirect reference to two paragraphs in the IANA Considerations section! (This seems silly and it’s not clear why that document was published with such an obvious structural error, but …). The security concern cited in 4627 is that JavaScript (JS) is a scripting language and thus JSON might be used to execute malicious JS. However JSON is intended to be a “safe” subset of JS, i.e., it should be able to be evaluated in JS without security concerns, if it is properly constrained.  The text in 4627 provides two regular expressions that can be invoked to strip any characters that might cause security problems. I’d feel a lot more comfortable if this text were explicitly replicated in this I-D, and the I-D mandated this processing step before passing the Jcard data to JS. (It might even make sense as a post processing step as part of the vCard to JCard processing described in Section 3.) The level of indirection currently used in the Security Considerations section, and the casual advisory nature of the original text might easily be overlooked by an implementer.

 

Finally, the notion of JSON as “safe” JS subset assumes that the parser processing the JSON does not have a security flaw. Such flaws have been identified, one as recently as February of this year. It might be good to note that this represents a new type of security concern that would not arise in a conventional vCard context.

 


-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------070906010709060407090704-- From paul.hoffman@vpnc.org Wed Jul 17 13:33:05 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4661421F9C33 for ; Wed, 17 Jul 2013 13:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94NnHDQHMbQm for ; Wed, 17 Jul 2013 13:33:04 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8793E21F968B for ; Wed, 17 Jul 2013 13:33:00 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r6HKWw27071220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Jul 2013 13:32:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <1670FE635C32C34AAD005D960F1C501115CA4D2B@xmb-aln-x11.cisco.com> Date: Wed, 17 Jul 2013 13:33:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <85CA57E8-1B3D-4537-87D1-3926B3CAFB76@vpnc.org> References: <845C917C-4115-4F3E-9E91-E6A3DB903F0C@vpnc.org> <1670FE635C32C34AAD005D960F1C501115CA4D2B@xmb-aln-x11.cisco.com> To: "draft-ivov-xmpp-cusax.all@tools.ietf.org" X-Mailer: Apple Mail (2.1508) Cc: secdir Subject: Re: [secdir] Secdir review of draft-ivov-xmpp-cusax X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:33:05 -0000 On Jul 17, 2013, at 12:56 PM, Peter Saint-Andre (psaintan) = wrote: >> There should also be at least a paragraph describing the difference = in commonly-used authentication mechanisms for SIP and XMPP. A user may = have authenticated one of the two channels with an easily-attacked = password, but the other channel with a strong cryptographic mechanism = such as TLS client certificates. When you combine two similar functions = into one application without making that clear, a user might assume that = their IM and voice communications are similarly protected when in fact = they are not. >=20 > The two examples in the Security Considerations are (1) authentication = and (2) channel encryption. But they are not called out as such, and they are in a single paragraph. > Do you think we need a full new paragraph about authentication = mechanism mismatches, or would it be acceptable to expand upon the text = that's there now? Full new paragraph. And maybe split out the previous two. --Paul Hoffman From kivinen@iki.fi Thu Jul 18 11:29:48 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEE821E8168 for ; Thu, 18 Jul 2013 11:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1R7nn7i6pxjz for ; Thu, 18 Jul 2013 11:29:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 59E8B21E8161 for ; Thu, 18 Jul 2013 11:29:47 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r6IITiZR015759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 18 Jul 2013 21:29:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r6IITiZ3027858; Thu, 18 Jul 2013 21:29:44 +0300 (EEST) 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: <20968.13335.927544.375742@fireball.kivinen.iki.fi> Date: Thu, 18 Jul 2013 21:29:43 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 2 min X-Total-Time: 1 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 18:29:48 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Yoav Nir is next in the rotation. For telechat 2013-07-18 Reviewer LC end Draft Ondrej Sury T 2013-06-17 draft-ietf-abfab-eapapplicability-05 For telechat 2013-08-15 Dan Harkins T 2013-07-03 draft-ietf-multimob-pmipv6-ropt-07 Simon Josefsson TR2013-07-23 draft-merkle-tls-brainpool-04 Ben Laurie T 2013-07-25 draft-ietf-emu-crypto-bind-04 Kathleen Moriarty T 2013-07-29 draft-ietf-weirds-rdap-sec-04 Sandy Murphy T 2013-07-29 draft-ietf-weirds-using-http-07 Last calls and special requests: Rob Austein 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Dave Cridland - draft-ietf-httpbis-p5-range-23 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 Donald Eastlake 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-04 Leif Johansson 2013-07-22 draft-ivov-grouptextchat-purpose-03 Warren Kumari 2013-07-15 draft-ietf-lisp-deployment-09 Julien Laganier - draft-ietf-avtcore-rtp-security-options-04 Julien Laganier - draft-ietf-websec-key-pinning-08 Matt Lepinski 2013-08-13 draft-bormann-cbor-04 Chris Lonvick 2013-07-30 draft-ietf-emu-eap-tunnel-method-07 Catherine Meadows 2013-07-31 draft-ietf-geopriv-res-gw-lis-discovery-05 Alexey Melnikov - draft-ietf-payload-rtp-howto-04 Alexey Melnikov 2013-07-31 draft-ietf-mpls-retire-ach-tlv-02 Vincent Roca 2013-06-11 draft-ietf-avtcore-idms-11 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-10 Glen Zorn 2012-11-27 draft-ietf-lisp-eid-block-04 -- kivinen@iki.fi From new-work-bounces@ietf.org Fri Jul 19 08:09:51 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E2F21E80EE; Fri, 19 Jul 2013 08:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1374246591; bh=xyMg2+fSi898Su8+us2QPDhT7+Fv6DIV0KqdnD8iWOM=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=k+sPuNFqSzUDu8thUwFCM8x07MijEyV0fkebz4M11VVBLsTzQOB501Wdj0M2x+jcN zDt9lPgYrS9kodWoZ7faxJEDTuNSEc3MDE5Enn6X1JsQs6iUjQIwP2goerNUNmbJmr 4gloc1/PUDaZeggGo3HUT9CM7PBv6RgXxHeCYJy8= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9B611E8153; Fri, 19 Jul 2013 08:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Txiujh4XbDI6; Fri, 19 Jul 2013 08:09:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1FC11E8146; Fri, 19 Jul 2013 08:09:49 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.53 Message-ID: <20130719150949.8374.64555.idtracker@ietfa.amsl.com> Date: Fri, 19 Jul 2013 08:09:49 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Fri, 19 Jul 2013 08:11:18 -0700 Subject: [secdir] [new-work] WG Review: Transparent Interconnection of Lots of Links (trill) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 15:09:51 -0000 The Transparent Interconnection of Lots of Links (trill) working group in the Internet Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-07-29. Transparent Interconnection of Lots of Links (trill) ------------------------------------------------ Current Status: Active WG Chairs: Donald Eastlake Erik Nordmark Secretaries: Jon Hudson Assigned Area Director: Ted Lemon Mailing list Address: trill@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/trill Archive: http://www.ietf.org/mail-archive/web/trill/current/maillist.html Charter: TRILL Charter Draft July 2013 ================================= The TRILL WG has specified a solution for transparent unicast shortest-path and multi-destination frame routing in multi-hop networks with arbitrary topology. End stations, including Layer 3 routers, are connected to TRILL switches through IEEE 802.1-compliant Ethernet. TRILL switches may be interconnected with multi-access or point-to-point links of arbitrary technology. The current work of the working group is around operational support and additional extensions and optimizations of TRILL for the properties of the networks on which it is deployed. The TRILL WG may also produce corrections, clarifications, and updates of existing TRILL RFCs. The WG will work on the following items: (1) Following on from the TRILL OAM requirements (RFC 6905), specify a framework and specific protocols for the handling of Operations, Administration, and Maintenance (OAM) in networks using TRILL, focusing on fault management and performance and taking into consideration existing OAM mechanisms that might apply to TRILL. (2) Specify protocols to support "active-active" service to end stations that are multiply connected to a TRILL campus to provide them with flow level traffic spreading and rapid adaptation to link failure similar to that provided by TRILL for TRILL switches. (3) Develop, within the TRILL protocol context, protocol specifications for broadcast/multicast (multi-destination) frame reduction. Examples: protocol extensions supporting replacement of broadcast/multicast by unicast where appropriate; ARP/ND (Neighbor Discovery) reduction through extensions to the TRILL ESADI protocol. (4) Specify protocols for TRILL over pseudowires and TRILL over IP tunnels, for example to connect branch office TRILL switches to a central TRILL campus over the Internet. (5) Specify extensions to the TRILL protocol to support multi-level routing to improve scaling and multi-topology routing to provide different topologies for different classes or types of traffic, based existing IS-IS multi-level and multi-topology routing facilities. (6) Specify a reduced TRILL control plane protocol for interconnection, with improved error isolation, between TRILL campuses under coordinated management. (7) Analyze the use of IS-IS security in TRILL and determine if any work is needed to accommodate any specific TRILL control or data plane security leveraging IS-IS security. (8) Produce an interoperability / implementation report for TRILL. The TRILL WG will continue to work with other IETF working groups such as the ISIS WG, and SDO groups such as IEEE 802.1 through established inter-WG relationships and SDO liaison processes, including early and WG last call review by the ISIS WG of documents extending IS-IS routing. Milestones: Done Accept base protocol specification as a WG document Done Accept problem statement and applicability as a WG work item Done Start work with routing area WG(s) to undertake TRILL extensions Done Accept architecture document as a WG work item Done Accept routing protocol requirements as a WG work item Done Choose routing protocol(s) that can meet the requirements Done Submit problem statement and applicability to IESG for Informational RFC Done Submit base protocol specification to IEEE/IETF expert review Done Base protocol specification submitted to the IESG for publication as a Proposed Standard RFC Done First draft showing what is needed for MIB Done Initial WG draft on VLAN Mapping (draft-ietf-trill-rbridge-vlan-mapping) Done Initial WG draft TRILL Header Options (draft-ietf-trill-rbridge-options) Done Initial WG draft on RBridge MIB module (draft-ietf-trill-rbridge-mib) Done Initial WG draft on trill adjacency state machine (draft-ietf-trill-adj) Done Submit trill adjacency state machine to IESG for publication as Proposed Standard (draft-ietf-trill-adj) Done Submit RBridge MIB module to IESG for publication as Proposed Standard (draft-ietf-trill-rbridge-mib) Done Submit TRILL Header Options to IESG for publication as Proposed Standard (draft-ietf-trill-rbridge-options) Done Initial WG draft on RBridge OAM (draft-bond-trill-rbridge-oam) Done Submit TRILL Header Options to IESG for publication as Proposed Standard (draft-ietf-trill-rbridge-options) Done Initial WG draft on RBridge OAM (draft-bond-trill-rbridge-oam) Done Submit RBridge OAM requirements document to the IESG for publication draft-ietf-trill-oam-req Nov 2012 Initial WG framework document on RBridge OAM draft-ietf-trill-oam-framework Done Submit RBridge OAM framework document to the IESG for publication Done Initial WG document on RBridge OAM fault management draft-ietf-trill-oam-fm Mar 2013 Initial WG draft on ARP/ND optimizations Apr 2013 Initial WG document on RBridge OAM performance management Jul 2013 Submit RBridge support of Data Center Bridging to IESG for publication as Proposed Standard (draft-eastlake-trill-rbridge-dcb) Dec 2013 Submit TRILL ARP/ND optimizations to IESG for publication as Proposed Standard Dec 2014 Re-charter or shut down the WG _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From kewisch@gmail.com Sun Jul 21 12:02:31 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D4D21F9E3B; Sun, 21 Jul 2013 12:02:31 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-JlIoxrdOJn; Sun, 21 Jul 2013 12:02:28 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id DD56121F9CA9; Sun, 21 Jul 2013 12:02:27 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id d10so3425711eaj.13 for ; Sun, 21 Jul 2013 12:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=0oWZ+OM2eqoIW4QxYMxwmqjz4k08xmYeF13+10nPAuo=; b=0UHpa/fbZuxmBOC9bmRSbJ5tY+7c8Hk4YTwzMZ0mG5gpfTpz6/fZB+tZs1jscwPRkr 7GlT1wzlLwlf11c8tC9cx9n0oUvK5yPRtj8bNy9Fgiu3yqQrNu6sjbM/I6uPsIAC/IjU KJs2/dxIzI0nRTCJ/RlB7//14qfKQASUcD0Av32RTxhDvA8wU+xzDsotuj98LXMuuFBn W5hvR2tOY16+BCsOHWHw+HWi2Bk3E2YeKIMMph2f124O1G64yq0xPsNBbqlxo14MdQYI rna/RsaJlIBjaQ3ch/QK5C7mycAIXs/H553LfNgBLeC9hdAw7gpJN7fLnFTvvie/EK/Q P7Ew== X-Received: by 10.14.95.135 with SMTP id p7mr24517918eef.16.1374433345863; Sun, 21 Jul 2013 12:02:25 -0700 (PDT) Received: from oskar.fritz.box (g231164173.adsl.alicedsl.de. [92.231.164.173]) by mx.google.com with ESMTPSA id ci50sm44927901eeb.12.2013.07.21.12.02.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 12:02:25 -0700 (PDT) Message-ID: <51EC3040.4000900@gmail.com> Date: Sun, 21 Jul 2013 21:02:24 +0200 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Stephen Kent , secdir References: <51E6FB7C.2060106@bbn.com> In-Reply-To: <51E6FB7C.2060106@bbn.com> Content-Type: multipart/alternative; boundary="------------090209010507030803070906" X-Mailman-Approved-At: Sun, 21 Jul 2013 12:09:53 -0700 Cc: bert.greevenbosch@huawei.com, Barry Leiba , Pete Resnick , stpeter@stpeter.im, "jcardcal@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-jcardcal-jcard-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 19:02:31 -0000 This is a multi-part message in MIME format. --------------090209010507030803070906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/17/13 10:15 PM, Stephen Kent wrote: > > This document cites the Security Considerations section of original > vCard RFC (noted above) as the primary content for its Security > Considerations section. It asserts that no new security concerns arise > with respect to _calendar data_, because this specification merely > maps the original vCard data to a new format.However, it then cites > the Security Considerations section of the JSON specification (RFC > 4627) noting that there are additional security risks that arise from > using JSON to represent vCard data! To me these two statements seem > somewhat contradictory, but that can be addressed by refining the > wording here. > > More worrisome is the fact that this very brief section mentions only > calendar data security. Does that mean that no other type of vCard > use, when using JSON encoding, creates any new security concerns? This > document is much broader in scope than just iCal data (the subject of > draft-ietf-jcardcal-jcal-07), so this narrowly focused comment seems > out of place. > Yes, this was a copy/paste fail from the jCal draft. I've corrected both instances of "calendar" to "vCard". OLD: For security considerations specific to calendar data, see Section 9 of [RFC6350]. Since this specification is a mapping from vCard, no new security concerns are introduced related to calendar data. NEW: For security considerations specific to vCard data, see Section 9 of [RFC6350]. Since this specification is a mapping from vCard, no new security concerns are introduced related to vCard data. > RFC 6350's Security Considerations section notes few concerns that are > Vcard-specific; most of the comments in that section relate to the > need to provide security for vCards when they are transported, e.g., > via email. All of these concerns are equally applicable here, as > indicated, without the calendar data comment. > Taken care of by the previous change. > RFC 4627's security considerations section turns out to be an indirect > reference to two paragraphs in the IANA Considerations section! (This > seems silly and it's not clear why that document was published with > such an obvious structural error, but ...). The security concern cited > in 4627 is that JavaScript (JS) is a scripting language and thus JSON > might be used to execute malicious JS. However JSON is intended to be > a "safe" subset of JS, i.e., it should be able to be evaluated in JS > without security concerns, if it is properly constrained.The text in > 4627 provides two regular expressions that can be invoked to strip any > characters that might cause security problems. I'd feel a lot more > comfortable if this text were explicitly replicated in this I-D, and > the I-D _mandated_ this processing step before passing the Jcard data > to JS. (It might even make sense as a post processing step as part of > the vCard to JCard processing described in Section 3.) The level of > indirection currently used in the Security Considerations section, and > the casual advisory nature of the original text might easily be > overlooked by an implementer. > > Finally, the notion of JSON as "safe" JS subset assumes that the > parser processing the JSON does not have a security flaw. Such flaws > have been identified, one as recently as February of this year. It > might be good to note that this represents a new type of security > concern that would not arise in a conventional vCard context. > As most popular JavaScript implementations use JSON.parse() for parsing JSON data, I don't see the need to put this into Section 3. I've changed the text to include the regex and a little more information from what you wrote via email, let me know what you think: OLD: The use of JSON as a format does have security risks. Section 7 of [RFC4627] discusses these risks. NEW: The use of JSON as a format does have security concerns. Even though JSON is considered a safe subset of JavaScript, this does not ensure that the parser processing JSON does not have a security flaw. When processing jCard data, this concern should be taken into account as it doesn't arise with conventional vCard data. As with JSON, when passing jCard data to JavaScript's eval() function, certain precautions must be taken to ensure that no security issues arise. Specifically, all characters not enclosed in strings MUST exclusively be in the set of characters that form JSON tokens. This can be quickly determined in JavaScript with two regular expressions and calls to the test and replace methods. var my_jCal_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test( text.replace(/"(\\.|[^"\\])*"/g, ''))) && eval('(' + text + ')'); See also Section 7 of [RFC4627] for security considerations of the JSON format. --------------090209010507030803070906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/17/13 10:15 PM, Stephen Kent wrote:

This document cites the Security Considerations section of original vCard RFC (noted above) as the primary content for its Security Considerations section. It asserts that no new security concerns arise with respect to calendar data, because this specification merely maps the original vCard data to a new format.  However, it then cites the Security Considerations section of the JSON specification (RFC 4627) noting that there are additional security risks that arise from using JSON to represent vCard data! To me these two statements seem somewhat contradictory, but that can be addressed by refining the wording here.

More worrisome is the fact that this very brief section mentions only calendar data security. Does that mean that no other type of vCard use, when using JSON encoding, creates any new security concerns? This document is much broader in scope than just iCal data (the subject of draft-ietf-jcardcal-jcal-07), so this narrowly focused comment seems out of place.

Yes, this was a copy/paste fail from the jCal draft. I've corrected both instances of "calendar" to "vCard".

OLD:
   For security considerations specific to calendar data, see Section 9
   of [RFC6350].  Since this specification is a mapping from vCard, no
   new security concerns are introduced related to calendar data.

NEW:
   For security considerations specific to vCard data, see Section 9 of
   [RFC6350].  Since this specification is a mapping from vCard, no new
   security concerns are introduced related to vCard data.

RFC 6350’s Security Considerations section notes few concerns that are Vcard-specific; most of the comments in that section relate to the need to provide security for vCards when they are transported, e.g., via email. All of these concerns are equally applicable here, as indicated, without the calendar data comment.

Taken care of by the previous change.

RFC 4627’s security considerations section turns out to be an indirect reference to two paragraphs in the IANA Considerations section! (This seems silly and it’s not clear why that document was published with such an obvious structural error, but …). The security concern cited in 4627 is that JavaScript (JS) is a scripting language and thus JSON might be used to execute malicious JS. However JSON is intended to be a “safe” subset of JS, i.e., it should be able to be evaluated in JS without security concerns, if it is properly constrained.  The text in 4627 provides two regular expressions that can be invoked to strip any characters that might cause security problems. I’d feel a lot more comfortable if this text were explicitly replicated in this I-D, and the I-D mandated this processing step before passing the Jcard data to JS. (It might even make sense as a post processing step as part of the vCard to JCard processing described in Section 3.) The level of indirection currently used in the Security Considerations section, and the casual advisory nature of the original text might easily be overlooked by an implementer.

Finally, the notion of JSON as “safe” JS subset assumes that the parser processing the JSON does not have a security flaw. Such flaws have been identified, one as recently as February of this year. It might be good to note that this represents a new type of security concern that would not arise in a conventional vCard context.

As most popular JavaScript implementations use JSON.parse() for parsing JSON data, I don't see the need to put this into Section 3. I've changed the text to include the regex and a little more information from what you wrote via email, let me know what you think:

OLD:
   The use of JSON as a format does have security risks.  Section 7 of
   [RFC4627] discusses these risks.

NEW:
   The use of JSON as a format does have security concerns.  Even though
   JSON is considered a safe subset of JavaScript, this does not ensure
   that the parser processing JSON does not have a security flaw.  When
   processing jCard data, this concern should be taken into account as
   it doesn't arise with conventional vCard data.

   As with JSON, when passing jCard data to JavaScript's eval()
   function, certain precautions must be taken to ensure that no
   security issues arise.  Specifically, all characters not enclosed in
   strings MUST exclusively be in the set of characters that form JSON
   tokens.  This can be quickly determined in JavaScript with two
   regular expressions and calls to the test and replace methods.

   var my_jCal_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
          text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
      eval('(' + text + ')');

   See also Section 7 of [RFC4627] for security considerations of the
   JSON format.
--------------090209010507030803070906-- From kewisch@gmail.com Sun Jul 21 14:01:36 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B7C21F9D13 for ; Sun, 21 Jul 2013 14:01:35 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsZphz-s0FcI for ; Sun, 21 Jul 2013 14:01:33 -0700 (PDT) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 67CD521F9CE7 for ; Sun, 21 Jul 2013 14:01:32 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id a15so3483319eae.12 for ; Sun, 21 Jul 2013 14:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Z3ePPG+s5mJsBM382DF7jY/oGU6S8tjHHki/yUgMvZM=; b=V/w0LMVnk7RDh/iSXDy3tNxOQBTqdA2VrKf+9cBmZGntyLCPTsarv4FWf6qLxIQN9S bCpaUAjG9QIVv6hgutb9Ncb1wsqFCO3Nc/Yu05ERba3MYD8BYOGLf6qfOgOXaSGV+uPR fYMRdwcXnqqjArIfWkme+elRvrad+YRVkNlqpZoSBuXNFbeJxGHcvKAkPHU/sncuJsKr gaz6E2GayQHsurFXmY+kNVqz7oajmWfuIyH0PWXk1doPmTkAw5eZhi2AS0/s3Ly43Jjr X9ODHMUgbCW426ygdyGV0E4tOOvChw3/Bqemxw3cmhNK3kc8DnsqZA1btbRt+7rCyNUb YX+Q== X-Received: by 10.14.32.197 with SMTP id o45mr24949837eea.9.1374440491511; Sun, 21 Jul 2013 14:01:31 -0700 (PDT) Received: from oskar.fritz.box (g231164173.adsl.alicedsl.de. [92.231.164.173]) by mx.google.com with ESMTPSA id c3sm45736286eev.3.2013.07.21.14.01.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 21 Jul 2013 14:01:31 -0700 (PDT) Message-ID: <51EC4C29.70908@gmail.com> Date: Sun, 21 Jul 2013 23:01:29 +0200 From: Philipp Kewisch User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 MIME-Version: 1.0 To: Stephen Kent , secdir References: <51E6FB7C.2060106@bbn.com> In-Reply-To: <51E6FB7C.2060106@bbn.com> Content-Type: multipart/alternative; boundary="------------080003000905010709010709" Cc: bert.greevenbosch@huawei.com, Barry Leiba , Pete Resnick , stpeter@stpeter.im Subject: Re: [secdir] SECDIR review of draft-ietf-jcardcal-jcard-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 21:01:36 -0000 This is a multi-part message in MIME format. --------------080003000905010709010709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/17/13 10:15 PM, Stephen Kent wrote: > > RFC 4627's security considerations section turns out to be an indirect > reference to two paragraphs in the IANA Considerations section! (This > seems silly and it's not clear why that document was published with > such an obvious structural error, but ...). The security concern cited > in 4627 is that JavaScript (JS) is a scripting language and thus JSON > might be used to execute malicious JS. However JSON is intended to be > a "safe" subset of JS, i.e., it should be able to be evaluated in JS > without security concerns, if it is properly constrained.The text in > 4627 provides two regular expressions that can be invoked to strip any > characters that might cause security problems. I'd feel a lot more > comfortable if this text were explicitly replicated in this I-D, and > the I-D _mandated_ this processing step before passing the Jcard data > to JS. (It might even make sense as a post processing step as part of > the vCard to JCard processing described in Section 3.) The level of > indirection currently used in the Security Considerations section, and > the casual advisory nature of the original text might easily be > overlooked by an implementer. > > Finally, the notion of JSON as "safe" JS subset assumes that the > parser processing the JSON does not have a security flaw. Such flaws > have been identified, one as recently as February of this year. It > might be good to note that this represents a new type of security > concern that would not arise in a conventional vCard context. > Sorry, I would like to again modify the security considerations in reaction to Stephen Farell's DISCUSS/COMMENT and the discussion around it. Please ignore my previous reply to the SECDIR review. Here are the some of the discussion links for reference: http://www.ietf.org/mail-archive/web/jcardcal/current/msg00279.html http://www.ietf.org/mail-archive/web/jcardcal/current/msg00288.html http://www.ietf.org/mail-archive/web/jcardcal/current/msg00290.html http://www.ietf.org/mail-archive/web/jcardcal/current/msg00291.html (one more message by me from a few minutes ago, no link on the archive yet) Proposed changes, replacing the whole security considerations section: OLD: For security considerations specific to calendar data, see Section 9 of [RFC6350]. Since this specification is a mapping from vCard, no new security concerns are introduced related to calendar data. The use of JSON as a format does have security risks. Section 7 of [RFC4627] discusses these risks. NEW: This specification defines how vCard data can be "translated" between two different data formats - the original text format and JSON - with a one-to-one mapping to ensure all the semantic data in one format (properties, parameters and values) are preserved in the other. It does not change the semantic meaning of the underlying data itself, or impose or remove any security considerations that apply to the underlying data. The use of JSON as a format does have its own inherent security risks as discussed in Section 7 of [RFC4627]. Even though JSON is considered a safe subset of JavaScript, it should be kept in mind that a flaw in the parser processing JSON could still impose a threat which doesn't arise with conventional vCard data. With this in mind, a parser for JSON data should be used for jCard that is aware of the security implications. For example, the use of JavaScript's eval() function is only allowed using the regular expression in Section 6 of [RFC4627]. A native parser with full awareness of the JSON format should be preferred. In addition, it is expected that this new format will result in vCard data being more widely disseminated (e.g., with use in web applications rather than just dedicated "contact managers"). In all cases, application developers have to conform to the semantics of the vCard data as defined by [RFC6350] and associated extensions, and all of the security considerations described in Section 9 of [RFC6350], or any associated extensions, are applicable. --------------080003000905010709010709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/17/13 10:15 PM, Stephen Kent wrote:

RFC 4627’s security considerations section turns out to be an indirect reference to two paragraphs in the IANA Considerations section! (This seems silly and it’s not clear why that document was published with such an obvious structural error, but …). The security concern cited in 4627 is that JavaScript (JS) is a scripting language and thus JSON might be used to execute malicious JS. However JSON is intended to be a “safe” subset of JS, i.e., it should be able to be evaluated in JS without security concerns, if it is properly constrained.  The text in 4627 provides two regular expressions that can be invoked to strip any characters that might cause security problems. I’d feel a lot more comfortable if this text were explicitly replicated in this I-D, and the I-D mandated this processing step before passing the Jcard data to JS. (It might even make sense as a post processing step as part of the vCard to JCard processing described in Section 3.) The level of indirection currently used in the Security Considerations section, and the casual advisory nature of the original text might easily be overlooked by an implementer.

 

Finally, the notion of JSON as “safe” JS subset assumes that the parser processing the JSON does not have a security flaw. Such flaws have been identified, one as recently as February of this year. It might be good to note that this represents a new type of security concern that would not arise in a conventional vCard context.

 

Sorry, I would like to again modify the security considerations in reaction to Stephen Farell's DISCUSS/COMMENT and the discussion around it. Please ignore my previous reply to the SECDIR review. Here are the some of the discussion links for reference:

http://www.ietf.org/mail-archive/web/jcardcal/current/msg00279.html
http://www.ietf.org/mail-archive/web/jcardcal/current/msg00288.html
http://www.ietf.org/mail-archive/web/jcardcal/current/msg00290.html
http://www.ietf.org/mail-archive/web/jcardcal/current/msg00291.html
(one more message by me from a few minutes ago, no link on the archive yet)


Proposed changes, replacing the whole security considerations section:

OLD:
   For security considerations specific to calendar data, see Section 9
   of [RFC6350].  Since this specification is a mapping from vCard, no
   new security concerns are introduced related to calendar data.

   The use of JSON as a format does have security risks.  Section 7 of
   [RFC4627] discusses these risks.

NEW:
   This specification defines how vCard data can be "translated" between
   two different data formats - the original text format and JSON - with
   a one-to-one mapping to ensure all the semantic data in one format
   (properties, parameters and values) are preserved in the other.  It
   does not change the semantic meaning of the underlying data itself,
   or impose or remove any security considerations that apply to the
   underlying data.

   The use of JSON as a format does have its own inherent security risks
   as discussed in Section 7 of [RFC4627].  Even though JSON is
   considered a safe subset of JavaScript, it should be kept in mind
   that a flaw in the parser processing JSON could still impose a threat
   which doesn't arise with conventional vCard data.

   With this in mind, a parser for JSON data should be used for jCard
   that is aware of the security implications.  For example, the use of
   JavaScript's eval() function is only allowed using the regular
   expression in Section 6 of [RFC4627].  A native parser with full
   awareness of the JSON format should be preferred.

   In addition, it is expected that this new format will result in vCard
   data being more widely disseminated (e.g., with use in web
   applications rather than just dedicated "contact managers").

   In all cases, application developers have to conform to the semantics
   of the vCard data as defined by [RFC6350] and associated extensions,
   and all of the security considerations described in Section 9 of
   [RFC6350], or any associated extensions, are applicable.


--------------080003000905010709010709-- From leifj@sunet.se Mon Jul 22 04:58:08 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE0221E8051; Mon, 22 Jul 2013 04:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEprpDWxZUti; Mon, 22 Jul 2013 04:58:08 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) by ietfa.amsl.com (Postfix) with ESMTP id 035B421E8091; Mon, 22 Jul 2013 04:58:07 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6MBw34W032261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 13:58:03 +0200 Received: from [109.105.104.183] (dhcp49.se-tug.nordu.net [109.105.104.183]) (authenticated bits=0) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r6MBw0sq019554 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Jul 2013 11:58:02 GMT Message-ID: <51ED1E48.90307@sunet.se> Date: Mon, 22 Jul 2013 13:58:00 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org, draft-ivov-grouptextchat-purpose.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.104.183; country=SE; region=26; city=Stockholm; latitude=59.3333; longitude=18.0500; http://maps.google.com/maps?q=59.3333,18.0500&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aK3nW3Ip - 98c654b43432 - 20130722 X-Antispam-Training-Forget: https://mailfilter.nordu.net/canit/b.php?i=0aK3nW3Ip&m=98c654b43432&t=20130722&c=f X-Antispam-Training-Nonspam: https://mailfilter.nordu.net/canit/b.php?i=0aK3nW3Ip&m=98c654b43432&t=20130722&c=n X-Antispam-Training-Spam: https://mailfilter.nordu.net/canit/b.php?i=0aK3nW3Ip&m=98c654b43432&t=20130722&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: [secdir] secdir review of draft-ivov-grouptextchat-purpose-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 11:58:08 -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 found the document reasonably well written and easy to understand. The security considerations section does a fair job of identifying the threats. I would have liked to see a little bit more concrete guidance for implementers about how to handle the identified threats for the most common text chat protocols identified in the text (eg xmpp, irc & "web chats") though. Best R Leif From kent@bbn.com Mon Jul 22 08:11:44 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E77221E80C4; Mon, 22 Jul 2013 08:11:44 -0700 (PDT) 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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuNsZpAwxtv0; Mon, 22 Jul 2013 08:11:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B6BB211E811E; Mon, 22 Jul 2013 08:11:24 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:44774 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V1HlK-0007jN-Hd; Mon, 22 Jul 2013 11:10:59 -0400 Message-ID: <51ED4B82.300@bbn.com> Date: Mon, 22 Jul 2013 11:10:58 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Philipp Kewisch References: <51E6FB7C.2060106@bbn.com> <51EC3040.4000900@gmail.com> In-Reply-To: <51EC3040.4000900@gmail.com> Content-Type: multipart/alternative; boundary="------------030002080403000709060907" Cc: secdir , bert.greevenbosch@huawei.com, "jcardcal@ietf.org" , stpeter@stpeter.im, Barry Leiba , Pete Resnick Subject: Re: [secdir] SECDIR review of draft-ietf-jcardcal-jcard-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 15:11:44 -0000 This is a multi-part message in MIME format. --------------030002080403000709060907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Phillip, Thanks for the edits. They address my concerns. Steve -------- On 7/21/13 3:02 PM, Philipp Kewisch wrote: > > On 7/17/13 10:15 PM, Stephen Kent wrote: >> >> This document cites the Security Considerations section of original >> vCard RFC (noted above) as the primary content for its Security >> Considerations section. It asserts that no new security concerns >> arise with respect to _calendar data_, because this specification >> merely maps the original vCard data to a new format.However, it then >> cites the Security Considerations section of the JSON specification >> (RFC 4627) noting that there are additional security risks that arise >> from using JSON to represent vCard data! To me these two statements >> seem somewhat contradictory, but that can be addressed by refining >> the wording here. >> >> More worrisome is the fact that this very brief section mentions only >> calendar data security. Does that mean that no other type of vCard >> use, when using JSON encoding, creates any new security concerns? >> This document is much broader in scope than just iCal data (the >> subject of draft-ietf-jcardcal-jcal-07), so this narrowly focused >> comment seems out of place. >> > Yes, this was a copy/paste fail from the jCal draft. I've corrected > both instances of "calendar" to "vCard". > > OLD: > For security considerations specific to calendar data, see Section 9 > of [RFC6350]. Since this specification is a mapping from vCard, no > new security concerns are introduced related to calendar data. > > NEW: > For security considerations specific to vCard data, see Section 9 of > [RFC6350]. Since this specification is a mapping from vCard, no new > security concerns are introduced related to vCard data. > >> RFC 6350's Security Considerations section notes few concerns that >> are Vcard-specific; most of the comments in that section relate to >> the need to provide security for vCards when they are transported, >> e.g., via email. All of these concerns are equally applicable here, >> as indicated, without the calendar data comment. >> > Taken care of by the previous change. > >> RFC 4627's security considerations section turns out to be an >> indirect reference to two paragraphs in the IANA Considerations >> section! (This seems silly and it's not clear why that document was >> published with such an obvious structural error, but ...). The >> security concern cited in 4627 is that JavaScript (JS) is a scripting >> language and thus JSON might be used to execute malicious JS. However >> JSON is intended to be a "safe" subset of JS, i.e., it should be able >> to be evaluated in JS without security concerns, if it is properly >> constrained.The text in 4627 provides two regular expressions that >> can be invoked to strip any characters that might cause security >> problems. I'd feel a lot more comfortable if this text were >> explicitly replicated in this I-D, and the I-D _mandated_ this >> processing step before passing the Jcard data to JS. (It might even >> make sense as a post processing step as part of the vCard to JCard >> processing described in Section 3.) The level of indirection >> currently used in the Security Considerations section, and the casual >> advisory nature of the original text might easily be overlooked by an >> implementer. >> >> Finally, the notion of JSON as "safe" JS subset assumes that the >> parser processing the JSON does not have a security flaw. Such flaws >> have been identified, one as recently as February of this year. It >> might be good to note that this represents a new type of security >> concern that would not arise in a conventional vCard context. >> > As most popular JavaScript implementations use JSON.parse() for > parsing JSON data, I don't see the need to put this into Section 3. > I've changed the text to include the regex and a little more > information from what you wrote via email, let me know what you think: > > OLD: > The use of JSON as a format does have security risks. Section 7 of > [RFC4627] discusses these risks. > > NEW: > The use of JSON as a format does have security concerns. Even though > JSON is considered a safe subset of JavaScript, this does not ensure > that the parser processing JSON does not have a security flaw. When > processing jCard data, this concern should be taken into account as > it doesn't arise with conventional vCard data. > > As with JSON, when passing jCard data to JavaScript's eval() > function, certain precautions must be taken to ensure that no > security issues arise. Specifically, all characters not enclosed in > strings MUST exclusively be in the set of characters that form JSON > tokens. This can be quickly determined in JavaScript with two > regular expressions and calls to the test and replace methods. > > var my_jCal_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test( > text.replace(/"(\\.|[^"\\])*"/g, ''))) && > eval('(' + text + ')'); > > See also Section 7 of [RFC4627] for security considerations of the > JSON format. --------------030002080403000709060907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Phillip,

Thanks for the edits.  They address my concerns.

Steve
--------
On 7/21/13 3:02 PM, Philipp Kewisch wrote:

On 7/17/13 10:15 PM, Stephen Kent wrote:

This document cites the Security Considerations section of original vCard RFC (noted above) as the primary content for its Security Considerations section. It asserts that no new security concerns arise with respect to calendar data, because this specification merely maps the original vCard data to a new format.  However, it then cites the Security Considerations section of the JSON specification (RFC 4627) noting that there are additional security risks that arise from using JSON to represent vCard data! To me these two statements seem somewhat contradictory, but that can be addressed by refining the wording here.

More worrisome is the fact that this very brief section mentions only calendar data security. Does that mean that no other type of vCard use, when using JSON encoding, creates any new security concerns? This document is much broader in scope than just iCal data (the subject of draft-ietf-jcardcal-jcal-07), so this narrowly focused comment seems out of place.

Yes, this was a copy/paste fail from the jCal draft. I've corrected both instances of "calendar" to "vCard".

OLD:
   For security considerations specific to calendar data, see Section 9
   of [RFC6350].  Since this specification is a mapping from vCard, no
   new security concerns are introduced related to calendar data.

NEW:
   For security considerations specific to vCard data, see Section 9 of
   [RFC6350].  Since this specification is a mapping from vCard, no new
   security concerns are introduced related to vCard data.

RFC 6350’s Security Considerations section notes few concerns that are Vcard-specific; most of the comments in that section relate to the need to provide security for vCards when they are transported, e.g., via email. All of these concerns are equally applicable here, as indicated, without the calendar data comment.

Taken care of by the previous change.

RFC 4627’s security considerations section turns out to be an indirect reference to two paragraphs in the IANA Considerations section! (This seems silly and it’s not clear why that document was published with such an obvious structural error, but …). The security concern cited in 4627 is that JavaScript (JS) is a scripting language and thus JSON might be used to execute malicious JS. However JSON is intended to be a “safe” subset of JS, i.e., it should be able to be evaluated in JS without security concerns, if it is properly constrained.  The text in 4627 provides two regular expressions that can be invoked to strip any characters that might cause security problems. I’d feel a lot more comfortable if this text were explicitly replicated in this I-D, and the I-D mandated this processing step before passing the Jcard data to JS. (It might even make sense as a post processing step as part of the vCard to JCard processing described in Section 3.) The level of indirection currently used in the Security Considerations section, and the casual advisory nature of the original text might easily be overlooked by an implementer.

Finally, the notion of JSON as “safe” JS subset assumes that the parser processing the JSON does not have a security flaw. Such flaws have been identified, one as recently as February of this year. It might be good to note that this represents a new type of security concern that would not arise in a conventional vCard context.

As most popular JavaScript implementations use JSON.parse() for parsing JSON data, I don't see the need to put this into Section 3. I've changed the text to include the regex and a little more information from what you wrote via email, let me know what you think:

OLD:
   The use of JSON as a format does have security risks.  Section 7 of
   [RFC4627] discusses these risks.

NEW:
   The use of JSON as a format does have security concerns.  Even though
   JSON is considered a safe subset of JavaScript, this does not ensure
   that the parser processing JSON does not have a security flaw.  When
   processing jCard data, this concern should be taken into account as
   it doesn't arise with conventional vCard data.

   As with JSON, when passing jCard data to JavaScript's eval()
   function, certain precautions must be taken to ensure that no
   security issues arise.  Specifically, all characters not enclosed in
   strings MUST exclusively be in the set of characters that form JSON
   tokens.  This can be quickly determined in JavaScript with two
   regular expressions and calls to the test and replace methods.

   var my_jCal_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
          text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
      eval('(' + text + ')');

   See also Section 7 of [RFC4627] for security considerations of the
   JSON format.

--------------030002080403000709060907-- From kent@bbn.com Mon Jul 22 13:43:03 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8500111E815B for ; Mon, 22 Jul 2013 13:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OudDilWlg6Qy for ; Mon, 22 Jul 2013 13:42:45 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 70E0C11E8163 for ; Mon, 22 Jul 2013 13:42:39 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:48270 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V1Mvz-000BdV-75; Mon, 22 Jul 2013 16:42:19 -0400 Message-ID: <51ED992C.9040908@bbn.com> Date: Mon, 22 Jul 2013 16:42:20 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Philipp Kewisch References: <51E6FB7C.2060106@bbn.com> <51EC4C29.70908@gmail.com> In-Reply-To: <51EC4C29.70908@gmail.com> Content-Type: multipart/alternative; boundary="------------090008030502070103070902" Cc: bert.greevenbosch@huawei.com, Barry Leiba , Pete Resnick , stpeter@stpeter.im, secdir Subject: Re: [secdir] SECDIR review of draft-ietf-jcardcal-jcard-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 20:43:03 -0000 This is a multi-part message in MIME format. --------------090008030502070103070902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pjillip, I like the tone of the new text, but it does need some edits to be more readable: > NEW: > This specification defines how vCard data can be "translated" between > two different data formats - the original text format and JSON - with > a one-to-one mapping to ensure all the semantic data in one format > (properties, parameters and values) are preserved in the other. It > does not change the semantics (meaning) of the underlying data itself, > or impose or remove any security considerations that apply to the > underlying data. > > The use of JSON as a format does have its own inherent security risks > as discussed in Section 7 of [RFC4627]. Even though JSON is > considered a safe subset of JavaScript, it should be kept in mind > that a flaw in the parser processing JSON could still introduce a > vulnerability > which doesn't arise with conventional vCard data. > > With this in mind, any parser used with jCard data should be > security-aware. For example, the use of > JavaScript's eval() function is allowed only after applying the regular > expression in Section 6 of [RFC4627]. A native parser with full > awareness of the JSON format is preferred. > > In addition, it is expected that this new format will result in vCard > data being more widely disseminated (e.g., used in web > applications rather than just dedicated "contact managers"). > > In all cases, application developers MUST conform to the semantics > of the vCard data as defined by [RFC6350] and associated extensions, > and all of the security considerations described in Section 9 of > [RFC6350], or any associated extensions, are applicable. > > --------------090008030502070103070902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pjillip,

I like the tone of the new text, but it does need some edits to be
more readable:
NEW:
   This specification defines how vCard data can be "translated" between
   two different data formats - the original text format and JSON - with
   a one-to-one mapping to ensure all the semantic data in one format
   (properties, parameters and values) are preserved in the other.  It
   does not change the semantics (meaning) of the underlying data itself,
   or impose or remove any security considerations that apply to the
   underlying data.

   The use of JSON as a format does have its own inherent security risks
   as discussed in Section 7 of [RFC4627].  Even though JSON is
   considered a safe subset of JavaScript, it should be kept in mind
   that a flaw in the parser processing JSON could still introduce a vulnerability
   which doesn't arise with conventional vCard data.

   With this in mind, any parser used with jCard data should be security-aware.  For example, the use of
   JavaScript's eval() function is allowed only after applying the regular
   expression in Section 6 of [RFC4627].  A native parser with full
   awareness of the JSON format is preferred.

   In addition, it is expected that this new format will result in vCard
   data being more widely disseminated (e.g., used in web
   applications rather than just dedicated "contact managers").

   In all cases, application developers MUST conform to the semantics
   of the vCard data as defined by [RFC6350] and associated extensions,
   and all of the security considerations described in Section 9 of
   [RFC6350], or any associated extensions, are applicable.



--------------090008030502070103070902-- From clonvick@cisco.com Wed Jul 24 09:44:32 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5B211E8108; Wed, 24 Jul 2013 09:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lno0z1IuC2Bu; Wed, 24 Jul 2013 09:44:26 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id CDE6D11E8111; Wed, 24 Jul 2013 09:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2845; q=dns/txt; s=iport; t=1374684257; x=1375893857; h=date:from:to:subject:message-id:mime-version; bh=++0mm/PWml8EqoODVkc+2Wu4y4H8Z16+28EdnufAa2w=; b=kwH13nsJf5E95uQ/NrtesUsXVJ9vQJPxpeAKrBXSv4n2Pvj/M2CKXRgO z/E/Vd/LmhkzdHUTbuCrSQ2GUAOpjf1QkTJH2l9oo3KikIxsmbMqdHrQW xeg0ADC0/cikKe/V35xQEjbY/pYJ9cCW4pEZgql11Vs3q1VVGzM5Zxxhg M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAPAC8FGrRDoJ/2dsb2JhbABagwa/fRZ0gmMCLYFRiCG5E5QEA4kqoAKDNA X-IronPort-AV: E=Sophos;i="4.89,736,1367971200"; d="scan'208";a="87060735" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 24 Jul 2013 16:44:15 +0000 Received: from sjc-xdm-112 (sjc-xdm-112.cisco.com [171.71.188.44]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6OGiE4h016952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 16:44:14 GMT Date: Wed, 24 Jul 2013 09:44:14 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-ietf-emu-eap-tunnel-method.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [secdir] SECDIR review of draft-ietf-emu-eap-tunnel-method-07.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 16:44:33 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overall the document is well written and I found it to be complete. Since the document is a bit on the long side, I focused on sections 1 through 3, and 7. I scanned sections 4, 5, and 6. I did not review the Appendixes. I did have a couple of issues that I want to raise: In Section 3.6.1, point #2 says that the TEAP packet is to be "ignored" if the other fields are "wrong". - What does "wrong" mean? - Also, I'd like to see some more clarification of what is expected from the carrier protocol if the TEAP packet is "ignored". Wouldn't the carrier protocol just attempt redelivery if it doesn't get some sort of acknowldegement of the delivery of the TEAP packet? Section 3.8 (second paragraph) says: > TEAP implementations SHOULD have > a configuration where authentication fails if mutual authentication > cannot be achieved. My personal feeling is that the SHOULD should be replaced with a MUST, but I acknowledge that is an implementation detail. I then went looking for a discussion of this in the Security Considerations section and found 7.1 on "Mutual Authentication and Integrity Protection". However I couldn't find anything in that section on Mutual Authentication. Would you please add some discussion to that section on the problems that could arise if an implementation does not have mutual authentication? I also found a few nits that you may want to look at. You mostly use "Type-Length-Value" but you have one instance of "Type Length Value". Section 3.1 says, > MUST use a version field set to 1. Throughout section 4 you sometimes use "set to 1", and sometimes use "set to zero (0)", and in a few cases "set to (1)". This inconsistency just set my OCD value to one (1). ;-) Section 3.3 > If the server ignores the > request, it proceeds with termination of the tunnel and send the > clear text EAP Success or Failure message based on the Status field > of the peer's Request-Action TLV. Maybe: If the server ignores the request, it proceeds with termination of the tunnel and sends the or "will send". Typo in section 3.8.4 > after it has succ;essfully authenticated the server and established Section 7 > greater. The threat model used for the security evaluation of TEAP > is defined in the EAP [RFC3748]. Maybe just "defined in EAP [RFC3748].", or "defined in the security consideration section in EAP [[RFC3748]." Regards, Chris From new-work-bounces@ietf.org Thu Jul 25 07:44:51 2013 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBEA21F967C; Thu, 25 Jul 2013 07:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1374763491; bh=SYzzwHTP0Ixt6L72UGo6GQ839NM1oEIIS0n34us703s=; h=From:To:Date:Message-ID:MIME-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=G7IswuVpQWGvdBjmx7oxiw4HbOq1WQpgTddECuBDekADq6yCDRrWU7W+asWnyBkOk TnZH9OfmbfxKlt5imjJUc/+sB6f31anSRb4t6HFSN4QpR2PScvpHqik7ryE6q1lipl bYTwtU4e0+VG+YsyK3229NLrExZxgl6K5XjwYO40= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5535A21F8C0C for ; Thu, 25 Jul 2013 07:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.598 X-Spam-Level: X-Spam-Status: No, score=-8.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UE-Mm3STp4G for ; Thu, 25 Jul 2013 07:44:42 -0700 (PDT) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) by ietfa.amsl.com (Postfix) with ESMTP id A001F21F967C for ; Thu, 25 Jul 2013 07:44:41 -0700 (PDT) X-LoopCount0: from 10.175.216.250 X-IronPort-AV: E=Sophos;i="4.89,743,1367989200"; d="scan'208,217";a="208628537" From: To: Date: Thu, 25 Jul 2013 09:44:38 -0500 Thread-Topic: IEEE 802 July Plenary - New Study Groups Thread-Index: Ac6JRWtGiGCAz+qlT2qt19rk2I6Gzg== Message-ID: <28616F4740DDF542AA1DB7C9F5979639078D50A432@AUSX7MCPS301.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: multipart/mixed; boundary="===============3064974233060267074==" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Thu, 25 Jul 2013 07:52:00 -0700 Cc: paul.nikolich@att.net Subject: [secdir] [new-work] IEEE 802 July Plenary - New Study Groups X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 14:44:51 -0000 --===============3064974233060267074== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_28616F4740DDF542AA1DB7C9F5979639078D50A432AUSX7MCPS301A_" --_000_28616F4740DDF542AA1DB7C9F5979639078D50A432AUSX7MCPS301A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Members of IETF, In the spirit of continuing cooperation between IEEE 802 and IETF, the foll= owing letter addresses new work items for information and potential coordin= ation with the respective IEEE 802 WG. One of the first steps in the IEEE Standards Association's standards develo= pment process is the creation of a Study Group. Study groups are chartered = to create a formal Project Authorization Request (PAR) document that includ= es a description of the project's scope and purpose. The following Study Groups were approved at the July 2013 IEEE 802 Plenary = - 1. IEEE 802.3, "Power over Data Lines" Study Group 2. IEEE 802.15, "Spectrum Resources Usage in WPANs" Study Group 3. IEEE 802.15, "Beam Switchable Wireless Point-to-Point 40/100Gbps links= (GbW)" Study Group Further information about these Study Groups may be found at http://www.iee= e802.org/StudyGroups.shtml. Please note, per the IEEE 802 Policies and Procedures that a Study Group is= chartered to operate from plenary session-to-plenary session, a period of = four months and, if it wishes to continue, must request a charter extension= . Therefore, the Study Groups, listed above are chartered until the IEEE 80= 2 November 2013 Plenary Session. Study Groups may also terminate between pl= enary sessions if their proposed project is approved by the IEEE Standards = Association Standards Board. Additionally, within the IEEE 802 family of standards, there is a requireme= nt that each new project proposal attaches additional documentation that de= scribes its engineering feasibility, market potential, assurance of coexist= ence and distinct identity relative to previous standards (referred to as t= he "five criteria" in 802). The "five criteria" used by IEEE 802 can be fou= nd in document: https://mentor.ieee.org/802-ec/dcn/13/ec-13-0002-01-00EC-five-criteria-om-e= xtract-informative.doc Also please note that IEEE meetings are open and may be attended by any ind= ividuals who register and fulfill any registration fees. Details regarding = future IEEE 802 plenary meeting schedules may be found at http://802world.o= rg/plenary/future-plenary-sessions/. Please refer to individual working g= roups for their interim meeting schedules. A listing of all working groups = may be found at http://www.ieee802.org/. Sincerely, John D'Ambrosia Recording Secretary, IEEE 802 LMSC jdambrosia@ieee.org --_000_28616F4740DDF542AA1DB7C9F5979639078D50A432AUSX7MCPS301A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Members of= IETF,

= In the sp= irit of continuing cooperation between IEEE 802 and , the following letter addresses new work items for information and pot= ential coordination with the respective IEEE 802 WG.

<= p class=3DDefault style=3D'margin-top:9.0pt'>One of the first steps in the IEEE Stan= dards Association’s standards development process is the creation of = a Study Group. Study groups are chartered to create a formal Project Author= ization Request (PAR) document that includes a description of the project&#= 8217;s scope and purpose.

The following Study Groups were approved at the July 2013 IEEE 80= 2 Plenary –

  1. IEEE= 802.3, "Power over Data Lines" Study Group<= o:p>
  2. IEEE 802.15, “Spectrum Resources Usage in WPANs” Study Grou= p
  3. IEEE 802.15, “B= eam Switchable Wireless Point-to-Point 40/100Gbps links (GbW)” Study = Group

Furth= er information about these Study Groups may be found at http://www.ieee802.org/StudyGroups.shtml.=   

Ple= ase note, per the IEEE 802 Policies and Procedures that a Study Group is ch= artered to operate from plenary session-to-plenary session, a period of fou= r months and, if it wishes to continue, must request a charter extension. T= herefore, the Study Groups, listed above are chartered until the IEEE 802 N= ovember 2013 Plenary Session. Study Groups may also terminate between plena= ry sessions if their proposed project is approved by the IEEE Standards Ass= ociation Standards Board.

Additionally, within the IEEE 802 family of standards, there is a = requirement that each new project proposal attaches additional documentatio= n that describes its engineering feasibility, market potential, assurance o= f coexistence and distinct identity relative to previous standards (referre= d to as the “five criteria” in 802). The “five criteria&#= 8221; used by IEEE 802 can be found in document:

https:/= /mentor.ieee.org/802-ec/dcn/13/ec-13-0002-01-00EC-five-criteria-om-extract-= informative.doc 

Also please note that IEEE meetings are open and may be attended by= any individuals who register and fulfill any registration fees. Details re= garding future IEEE 802 plenary meeting schedules may be found at http://802world.org/= plenary/future-plenary-sessions/.   Please refer to individual = working groups for their interim meeting schedules. A listing of all workin= g groups may be found at http://www.ieee8= 02.org/. 

Sincerely,

 

John D= 217;Ambrosia

Recording Secretary, IEEE 802 LMSC

jdambrosia@ieee.org

&nbs= p;

= --_000_28616F4740DDF542AA1DB7C9F5979639078D50A432AUSX7MCPS301A_-- --===============3064974233060267074== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============3064974233060267074==-- From kivinen@iki.fi Thu Jul 25 09:02:50 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB4221F880F for ; Thu, 25 Jul 2013 09:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlEWdqxVSY-s for ; Thu, 25 Jul 2013 09:02:49 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 190D221F852D for ; Thu, 25 Jul 2013 09:02:48 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r6PG2kLX023568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 25 Jul 2013 19:02:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r6PG2j7B028485; Thu, 25 Jul 2013 19:02:45 +0300 (EEST) 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: <20977.19493.623188.411131@fireball.kivinen.iki.fi> Date: Thu, 25 Jul 2013 19:02:45 +0300 From: Tero Kivinen To: secdir@ietf.org X-Edit-Time: 2 min X-Total-Time: 1 min Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 16:02:50 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Magnus Nystrom is next in the rotation. For telechat 2013-08-15 Reviewer LC end Draft Dan Harkins T 2013-07-03 draft-ietf-multimob-pmipv6-ropt-07 Simon Josefsson TR2013-07-23 draft-merkle-tls-brainpool-04 Stephen Kent TR2013-05-27 draft-ietf-mpls-ldp-dod-09 Ben Laurie T 2013-07-25 draft-ietf-emu-crypto-bind-04 Matt Lepinski T 2013-08-13 draft-bormann-cbor-04 Kathleen Moriarty T 2013-07-29 draft-ietf-weirds-rdap-sec-04 Sandy Murphy T 2013-07-29 draft-ietf-weirds-using-http-07 Yoav Nir T - draft-ietf-manet-nhdp-olsrv2-sec-03 For telechat 2013-08-29 Warren Kumari T 2013-07-15 draft-ietf-lisp-deployment-09 Last calls and special requests: Rob Austein 2012-09-20 draft-ietf-sipcore-rfc4244bis-11 Dave Cridland - draft-ietf-httpbis-p5-range-23 Dave Cridland - draft-dunbar-armd-arp-nd-scaling-practices-07 Alan DeKok 2013-03-30 draft-ietf-roll-terminology-12 Donald Eastlake 2013-01-30 draft-ietf-bmwg-sip-bench-meth-08 Jeffrey Hutzelman 2013-07-16 draft-yusef-dispatch-ccmp-indication-04 Jeffrey Hutzelman - draft-ietf-drinks-spp-protocol-over-soap-04 Julien Laganier - draft-ietf-avtcore-rtp-security-options-04 Julien Laganier - draft-ietf-websec-key-pinning-08 Catherine Meadows 2013-07-31 draft-ietf-geopriv-res-gw-lis-discovery-05 Alexey Melnikov - draft-ietf-payload-rtp-howto-04 Alexey Melnikov 2013-07-31 draft-ietf-mpls-retire-ach-tlv-02 Vincent Roca 2013-06-11 draft-ietf-avtcore-idms-11 Sam Weiler 2013-04-26 draft-ietf-6man-stable-privacy-addresses-10 Glen Zorn 2012-11-27 draft-ietf-lisp-eid-block-04 -- kivinen@iki.fi From stephen.farrell@cs.tcd.ie Fri Jul 26 07:29:19 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA28821F99E1 for ; Fri, 26 Jul 2013 07:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WG1iqDAj2Bhe for ; Fri, 26 Jul 2013 07:29:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C46D521F8E79 for ; Fri, 26 Jul 2013 07:29:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B2274BE8F for ; Fri, 26 Jul 2013 15:28:45 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+0JMqn+oE4Y for ; Fri, 26 Jul 2013 15:28:41 +0100 (IST) Received: from [160.45.233.17] (e9-11.conference.fu-berlin.de [160.45.233.17]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E2816BE7B for ; Fri, 26 Jul 2013 15:28:40 +0100 (IST) Message-ID: <51F28798.7060108@cs.tcd.ie> Date: Fri, 26 Jul 2013 15:28:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "secdir@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir lunch usual Tuesday slot room is Tegel X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 14:29:19 -0000 This is either a reminder or an announcement, I don't recall;-) Regards, S. From leifj@sunet.se Fri Jul 26 07:39:13 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E31221F99A1 for ; Fri, 26 Jul 2013 07:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cauw2bfMQ03Z for ; Fri, 26 Jul 2013 07:39:13 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7E421F85EB for ; Fri, 26 Jul 2013 07:39:08 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6QEd3m7019846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 26 Jul 2013 16:39:03 +0200 Received: from [172.27.14.227] ([195.37.142.72]) (authenticated bits=0) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r6QEcuaP015907 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 26 Jul 2013 14:39:02 GMT Message-ID: <51F28A01.9040803@sunet.se> Date: Fri, 26 Jul 2013 16:38:57 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: secdir@ietf.org References: <51F28798.7060108@cs.tcd.ie> In-Reply-To: <51F28798.7060108@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, nordu-net:default, base:default, @@RPTN) X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=195.37.142.72; country=DE; latitude=51.0000; longitude=9.0000; http://maps.google.com/maps?q=51.0000,9.0000&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aK52D3Dd - e16e1eb9e1d3 - 20130726 X-Antispam-Training-Forget: https://mailfilter.nordu.net/canit/b.php?i=0aK52D3Dd&m=e16e1eb9e1d3&t=20130726&c=f X-Antispam-Training-Nonspam: https://mailfilter.nordu.net/canit/b.php?i=0aK52D3Dd&m=e16e1eb9e1d3&t=20130726&c=n X-Antispam-Training-Spam: https://mailfilter.nordu.net/canit/b.php?i=0aK52D3Dd&m=e16e1eb9e1d3&t=20130726&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: Re: [secdir] Secdir lunch usual Tuesday slot room is Tegel X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 14:39:13 -0000 On 07/26/2013 04:28 PM, Stephen Farrell wrote: > This is either a reminder or an announcement, I don't recall;-) > We have to go all the way to the airport for lunch ? ;-) From d3e3e3@gmail.com Sat Jul 27 13:10:08 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA5321F94FD; Sat, 27 Jul 2013 13:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4u6Idtm4+aX; Sat, 27 Jul 2013 13:10:07 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id C6C3421F944C; Sat, 27 Jul 2013 13:10:07 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id wc20so406687obb.0 for ; Sat, 27 Jul 2013 13:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=ISPJFGCxcG4sT+zhvBdoj7XB37PkSv2f9VtVNeVDTpw=; b=GH+9TeTYlhyxhTpMYYOd+ssgXNdhCGoyRLNueBZRtuQWyzuPvHvfSDGvilA1ScqDdN DTDRxp8YdGkja252UFG7LWTdzhuoM883mVYN03CqyhhXH0669msV3FUQDn7iLkRvYgJ+ Xre6MewHxKZ0s3lyDkzK+2JWRNZj5spIcr37uETz5I6+xfdD3/QFNwRwxyLpe+RykeNs 08h8Xt7Mpem7nPoisWnoDsZ5/ce3RzjPjuMRdqn+kZ93NUNt6Z95PqPCpJoEvg8SmUtI eeyBVGgs9EK4KifjdClgMfVGq7DP3uXw00FzDhtXiDt044MBdlWidrxnvPV4zmxwRBAl Ch0A== X-Received: by 10.182.181.42 with SMTP id dt10mr17697219obc.46.1374955807295; Sat, 27 Jul 2013 13:10:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.131.7 with HTTP; Sat, 27 Jul 2013 13:09:47 -0700 (PDT) From: Donald Eastlake Date: Sat, 27 Jul 2013 16:09:47 -0400 Message-ID: To: iesg@ietf.org, secdir@ietf.org, draft-ietf-bmwg-sip-bench-meth.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] draft-ietf-bmwg-sip-bench-meth-08 SECDIR Review X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jul 2013 20:10:08 -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. Sorry for how long it has taken me to get to this review. >From a Security Considerations perspective, I believe this draft is ready with relatively minor changes. This draft draft-ietf-bmwg-sip-bench-meth-08 ("Methodology for Benchmarking SIP Networking Devices") specifies methodology for benchmarking SIP performance and cannot be really understood or analyzed without reference to draft-ietf-bmwg-sip-bench-term-08 ("Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices"). That terminology draft also specified "Benchmarking Models", this is the network topology of various test cases, which is more than I would expect in a "terminology"draft. The Security Considerations sections of these two drafts are very similar. Both indicate that testing would normally be done isolated from the Internet or other production networks which eliminates security threats. While such isolation would be helpful, it is very hard to have truly isolated networks, at least if they are of any size or complexity, given wide variety of means by which malware propagates these days. I don't know anything about the prevalence of SIP related malware but if it existed in a test rig I think it would likely to corrupt benchmarking results. Some warning about this seems warranted such as "To improve the fidelity of SIP benchmarking, appropriate precautions should be taken against SIP related and other malware." The Security Considerations sections in both drafts reference the same other RFC Security Considerations Section: RFC 3261, RFC 3550, and RFC 3711. Those appear to be a good set of references and the Security Considerations in RFC 3261 are pretty thorough. The terminology draft Security Considerations section includes the following: "Packets with unintended and/or unauthorized DSCP or IP precedence values may present security issues. Determining the security consequences of such packets is out of scope for this document." If it was thought worthy to include that in the terminology draft, it seems like there is also a good case for including it in the methodology draft. Editorial It is not entirely clear what "this" means in the first line of the Security Considerations Section, I would suggest adding the words "Benchmarking methodology" so it reads "Benchmarking methodology documents of this type ..." The RFC reference strings ("RFC3261" etc.) in the Security Considerations section should be in square brackets. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From kent@bbn.com Sun Jul 28 06:54:26 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2300A21F940D for ; Sun, 28 Jul 2013 06:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHX9Z3ckKWsm for ; Sun, 28 Jul 2013 06:54:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2C42821F92E7 for ; Sun, 28 Jul 2013 06:54:20 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37667 helo=fritz.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1V3RQL-0000TO-B1; Sun, 28 Jul 2013 09:54:13 -0400 Message-ID: <51F52283.2070306@bbn.com> Date: Sun, 28 Jul 2013 09:54:11 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: secdir , Sean Turner , thomas.beckhaus@telekom.de, bruno.decraene@orange.com, kishoret@juniper.net, maciek@cisco.com, lmartini@cisco.com, Adrian Farrel , loa@pi.nu, rcallon@juniper.net, swallow@cisco.com References: <5199879B.5010701@bbn.com> In-Reply-To: <5199879B.5010701@bbn.com> Content-Type: multipart/alternative; boundary="------------040100000308030806090408" Subject: Re: [secdir] SECDIR review of draft-ietf-mpls-ldp-dod X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 13:54:26 -0000 This is a multi-part message in MIME format. --------------040100000308030806090408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I re-reviewed this documentas part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. I compared the -08 and -09 version of this document, using the IETF diff tool. The authors responded to my concern that there were many instances of what appeared to be normative text in Sections 3 and 4, yet almost all instances of the words "must" and "should" were lowercase. They removed all of the words in question. I'm surprised by this outcome, but if the WG chairs and ADs believe the resulting text is correct, with NO normative terms, so be it. The authors also revised the Security Considerations (Section 7) text, addressing all of my comments. --------------040100000308030806090408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I re-reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. 

I compared the -08 and -09 version of this document, using the IETF diff tool.

The authors responded to my concern that there were many instances of what appeared to be normative text in Sections 3 and 4, yet almost all instances of the words “must” and “should” were lowercase. They removed all of the words in question. I'm surprised by this outcome, but if the WG chairs and ADs believe the resulting text is correct, with NO normative terms, so be it.

The authors also revised the Security Considerations (Section 7) text, addressing all of my comments.


 --------------040100000308030806090408-- From catherine.meadows@nrl.navy.mil Sun Jul 28 09:39:06 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9D421F9C6E; Sun, 28 Jul 2013 09:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pr7cptU3OynK; Sun, 28 Jul 2013 09:38:55 -0700 (PDT) Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by ietfa.amsl.com (Postfix) with ESMTP id 20A0421F9C6C; Sun, 28 Jul 2013 09:38:53 -0700 (PDT) Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.14.4/8.13.6) with ESMTP id r6SGcqJ0016769; Sun, 28 Jul 2013 12:38:53 -0400 Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id r6SGcpvI017500; Sun, 28 Jul 2013 12:38:51 -0400 (EDT) Received: (from [IPv6:::1] [10.0.0.13]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2013072812385003773 ; Sun, 28 Jul 2013 12:38:51 -0400 From: Catherine A Meadows Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 28 Jul 2013 12:38:50 -0400 Message-Id: <9D29BF1C-6867-4379-8843-975D9BD5F906@nrl.navy.mil> To: iesg@ietf.org, secdir@ietf.org, draft-ietf-geopriv-res-gw-lis-discovery.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [secdir] secdir review of draft-ietf-geopriv-res-gw-lis-discovery-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 16:39:06 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This draft describes a method in which a device can discover a Location = Information Server when a residential gateway is present that does not support such discovery. Normally such = discovery is done by the device via an option is DHCP (described in = RFC5389 ), but this will not be possible if the gateway does not support this option in = DHCP. In both the DHCP-supported protocol and the protocol covered in this = draft the device provides a domain name to a DNS server, which uses it to discover the appropriate LIS. In the = DHCP-supported protocol the device uses the access network domain name = DHCP options as the preferred source of domain names. This draft provides ways in which the device = can determine likely candidates for domain names if the DHCP option is = not supported. The main security considerations for both the protocol described in this = draft and RFC 5986 arise from the fact that communication with the DNS server is not authenticated. This is = noted and discussed in the security considerations section. I have a couple of questions. The authors mention that RFC 5986 is the = preferred method whenever it is supported. I believe that this is = because it is more accurate. First question: am I correct in believing = this? Secondly, is there any way an attacker could a) cause a device to identify the wrong domain name and b) if a device identifies = an incorrect domain name (whether or not the attacker can cause this to happen) is there anyway an attacker can = exploit that? Question 2a) may be difficult to answer because the draft does not = mandate any particular solution. Indeed it cannot, because the solution = used will depend on what is supported locally. But if the answers to = questions 1 and 2b) are "yes" it might be worthwhile to point this out in the security considerations = section as an additional reason to use the solution given in RFC5389 whenever it is available. Cathy Meadows= From hartmans@mit.edu Mon Jul 29 06:31:18 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A634A21F9ED4 for ; Mon, 29 Jul 2013 06:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iASvxp6KcoVm for ; Mon, 29 Jul 2013 06:31:07 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id E27CD21F9D4A for ; Mon, 29 Jul 2013 06:31:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 1F67F201FA for ; Mon, 29 Jul 2013 09:30:31 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGW7udGBEBxv for ; Mon, 29 Jul 2013 09:30:30 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (dhcp-4332.meeting.ietf.org [130.129.67.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Mon, 29 Jul 2013 09:30:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AD0A887FB2; Mon, 29 Jul 2013 09:31:02 -0400 (EDT) From: Sam Hartman To: secdir@ietf.org Date: Mon, 29 Jul 2013 09:31:02 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [secdir] weirds and certificate naming X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:31:20 -0000 Hi. To the ADs and especially to the folks who have outstanding weirds reviews. Please chase down how a query name entered by a user makes its way into a URI and how weirds validates the certificate in that URI. I suspect that there are problems here. For example, I suspect insecure DNS queries may be used to find parts of that URI. Alternatively even if DNSsec is available, I suspect supporting DNSsec may not be a MTI for weirds clients. So, I'm dubious whether weirds will have an interoperable MTI security mechanism. From leifj@sunet.se Tue Jul 30 02:34:33 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA3D21F9966 for ; Tue, 30 Jul 2013 02:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id za4UjJztBTGN for ; Tue, 30 Jul 2013 02:34:32 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) by ietfa.amsl.com (Postfix) with ESMTP id B9C3B11E80C5 for ; Tue, 30 Jul 2013 02:32:22 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6U9WJIE003163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Jul 2013 11:32:19 +0200 Received: from [130.129.17.63] (dhcp-113f.meeting.ietf.org [130.129.17.63]) (authenticated bits=0) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r6U9WGL7000730 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 30 Jul 2013 09:32:19 GMT Message-ID: <51F78820.603@sunet.se> Date: Tue, 30 Jul 2013 11:32:16 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, nordu-net:default, base:default, @@RPTN) X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=130.129.17.63; country=CZ; latitude=49.7500; longitude=15.5000; http://maps.google.com/maps?q=49.7500,15.5000&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aK6xwjR0 - 71341c750a14 - 20130730 X-Antispam-Training-Forget: https://mailfilter.nordu.net/canit/b.php?i=0aK6xwjR0&m=71341c750a14&t=20130730&c=f X-Antispam-Training-Nonspam: https://mailfilter.nordu.net/canit/b.php?i=0aK6xwjR0&m=71341c750a14&t=20130730&c=n X-Antispam-Training-Spam: https://mailfilter.nordu.net/canit/b.php?i=0aK6xwjR0&m=71341c750a14&t=20130730&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: [secdir] bag-lunch options X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:34:33 -0000 There is a cafe "behind" the conference centre portion of the hotel (past the Charlottenbergs) that do wraps, sallads etc. Any other options that people know about and can recommend? Cheers Leif From kivinen@iki.fi Tue Jul 30 03:28:13 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C2721F9B12 for ; Tue, 30 Jul 2013 03:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4TucOXf7+L0 for ; Tue, 30 Jul 2013 03:28:12 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 63A6211E81C4 for ; Tue, 30 Jul 2013 03:28:03 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r6UAS0li008355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 30 Jul 2013 13:28:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r6UAS0s8001128; Tue, 30 Jul 2013 13:28:00 +0300 (EEST) 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: <20983.38192.343915.798602@fireball.kivinen.iki.fi> Date: Tue, 30 Jul 2013 13:28:00 +0300 From: Tero Kivinen To: secdir@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min Subject: [secdir] Secdir Area Review Tool (art) link X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 10:28:13 -0000 https://art.tools.ietf.org/tools/art/secdir/ You use your normal tools.ietf.org username (email) and password. -- kivinen@iki.fi From leifj@sunet.se Tue Jul 30 03:45:15 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD59521E80C0 for ; Tue, 30 Jul 2013 03:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4TFe-J3pL9Z for ; Tue, 30 Jul 2013 03:45:15 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) by ietfa.amsl.com (Postfix) with ESMTP id C0E2321E80C4 for ; Tue, 30 Jul 2013 03:45:04 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6UAiiVC014824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jul 2013 12:44:44 +0200 Received: from [130.129.10.34] (dhcp-9222.meeting.ietf.org [130.129.10.34]) (authenticated bits=0) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r6UAicC2025131 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 30 Jul 2013 10:44:41 GMT Message-ID: <51F79916.1000003@sunet.se> Date: Tue, 30 Jul 2013 12:44:38 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Linus Nordberg , Stephen Farrell , Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, nordu-net:default, base:default, @@RPTN) X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=130.129.10.34; country=CZ; latitude=49.7500; longitude=15.5000; http://maps.google.com/maps?q=49.7500,15.5000&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aK6yIIhW - caa48a77f4bf - 20130730 X-Antispam-Training-Forget: https://mailfilter.nordu.net/canit/b.php?i=0aK6yIIhW&m=caa48a77f4bf&t=20130730&c=f X-Antispam-Training-Nonspam: https://mailfilter.nordu.net/canit/b.php?i=0aK6yIIhW&m=caa48a77f4bf&t=20130730&c=n X-Antispam-Training-Spam: https://mailfilter.nordu.net/canit/b.php?i=0aK6yIIhW&m=caa48a77f4bf&t=20130730&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: Linus Nordberg , secdir@ietf.org Subject: [secdir] visitors from Tor X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 10:45:15 -0000 Linus is our PoC for the Tor-folks. I just brought up the idea of having a side meeting at secdir and folks here are really enthusiastic. I'll let Stephen and Sean figure out the details! Linus has told me that tomorrow after 10 is ideal, Thursday is a no-op (which means SaaG is out I guess) and Friday might also work. Cheers Leif From hannes.tschofenig@gmx.net Tue Jul 30 03:51:13 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223B911E810D for ; Tue, 30 Jul 2013 03:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.69 X-Spam-Level: X-Spam-Status: No, score=-102.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E6sFkArhwN1 for ; Tue, 30 Jul 2013 03:51:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 20DE421F9C38 for ; Tue, 30 Jul 2013 03:51:08 -0700 (PDT) Received: from dhcp-13ba.meeting.ietf.org ([130.129.19.186]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MK0ur-1V2kbl0cQX-001PbJ for ; Tue, 30 Jul 2013 12:51:04 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <51F79916.1000003@sunet.se> Date: Tue, 30 Jul 2013 12:50:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51F79916.1000003@sunet.se> To: Leif Johansson X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Provags-ID: V03:K0:TED70uf4GWe2UTlHTKzqH5aKtw+CMQN648xhmh6s52J/N+gydEl agSj55fOlXJiZR34e5u7PPncYy+pisrW+Jn6IFv22O6T4jN9qy9Bed1V487ENtdtNiWLPTX FIGFzopENSt7qfCEFoCE8WHe6fh6lTQU4blt3xJn6TAQ3w4S3/+nWKvziYF+Awim/xeZdlo lGGr7tGwsZe/zO8Q1DCZQ== Cc: Linus Nordberg , secdir@ietf.org, Linus Nordberg Subject: Re: [secdir] visitors from Tor X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 10:51:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Linus,=20 would it work for you to meet already at 9am since that's where the = meetings start.=20 Ciao Hannes On Jul 30, 2013, at 12:44 PM, Leif Johansson wrote: > Linus is our PoC for the Tor-folks. I just brought up the idea > of having a side meeting at secdir and folks here are really > enthusiastic. I'll let Stephen and Sean figure out the details! >=20 > Linus has told me that tomorrow after 10 is ideal, Thursday > is a no-op (which means SaaG is out I guess) and Friday > might also work. >=20 > Cheers Leif > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJR95qTAAoJEGhJURNOOiAteR8H/39aRIwTuo2MqUce9wguNV+G nHk3vwIM2GWsHp2EhgxomGsZfnHlD8/S/8P84rudZmARk0uX+oF3bmaNsgCll92X n8+2ukHScYok0OBS6ixTbxjucoF/UWv+2rZsxz/GafM9A6F+V/SNJPzZXkGYnlYd vxG+LO28c6Nvya0Xp6nugnmdxh4CavdbmABi4dAmkdXW6t0ItjP4E2VAdMgafrN0 OwAtrtFcNMuow44HUm8SzTRFzgVeY1Kt83vlWB0NtwJ0lOe0nqtRtbEUwhVAYgO3 8WEvLd9smZf5q1b/Ixhaq3lOSs8ZldQvYcJby9QnKCqzw8AoqmXWpBpbCR3JSG0=3D =3Dw8pj -----END PGP SIGNATURE----- From linus@nordberg.se Tue Jul 30 04:02:34 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA3911E81C4 for ; Tue, 30 Jul 2013 04:02:34 -0700 (PDT) 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_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0aSkRda2UhZ for ; Tue, 30 Jul 2013 04:02:29 -0700 (PDT) Received: from smtp.nordberg.se (smtp.nordberg.se [193.10.5.87]) by ietfa.amsl.com (Postfix) with ESMTP id A7C3111E810D for ; Tue, 30 Jul 2013 04:02:23 -0700 (PDT) Received: from amnesia.nordberg.se (politkovskaja.torservers.net [77.247.181.165]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.nordberg.se (Postfix) with ESMTPSA id DF77E11527; Tue, 30 Jul 2013 13:02:17 +0200 (CEST) From: Linus Nordberg To: Hannes Tschofenig References: <51F79916.1000003@sunet.se> Date: Tue, 30 Jul 2013 11:02:12 +0000 In-Reply-To: (Hannes Tschofenig's message of "Tue, 30 Jul 2013 12:50:59 +0200") Message-ID: <874nbcs43v.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 30 Jul 2013 04:21:36 -0700 Cc: secdir@ietf.org, Linus Nordberg Subject: Re: [secdir] visitors from Tor X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:02:34 -0000 Hannes, I can be there, not so sure about Jake. Investigating. So is there a particular meeting starting at 0900? Can't seem to find anything (except SEC/oauth). Hannes Tschofenig wrote Tue, 30 Jul 2013 12:50:59 +0200: | Linus, | | would it work for you to meet already at 9am since that's where the meetings start. | | Ciao | Hannes | | On Jul 30, 2013, at 12:44 PM, Leif Johansson wrote: | | > Linus is our PoC for the Tor-folks. I just brought up the idea | > of having a side meeting at secdir and folks here are really | > enthusiastic. I'll let Stephen and Sean figure out the details! | > | > Linus has told me that tomorrow after 10 is ideal, Thursday | > is a no-op (which means SaaG is out I guess) and Friday | > might also work. | > | > Cheers Leif | > _______________________________________________ | > secdir mailing list | > secdir@ietf.org | > https://www.ietf.org/mailman/listinfo/secdir> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From leifj@sunet.se Tue Jul 30 04:24:15 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A54D11E81D7 for ; Tue, 30 Jul 2013 04:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG4Db+hKojGc for ; Tue, 30 Jul 2013 04:24:14 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) by ietfa.amsl.com (Postfix) with ESMTP id A0BD811E81ED for ; Tue, 30 Jul 2013 04:24:13 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r6UBNu3n022232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jul 2013 13:23:56 +0200 Received: from [130.129.17.63] (dhcp-113f.meeting.ietf.org [130.129.17.63]) (authenticated bits=0) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r6UBNoeE003238 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 30 Jul 2013 11:23:53 GMT Message-ID: <51F7A246.7060905@sunet.se> Date: Tue, 30 Jul 2013 13:23:50 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Linus Nordberg References: <51F79916.1000003@sunet.se> <874nbcs43v.fsf@nordberg.se> In-Reply-To: <874nbcs43v.fsf@nordberg.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, nordu-net:default, base:default, @@RPTN) X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=130.129.17.63; country=CZ; latitude=49.7500; longitude=15.5000; http://maps.google.com/maps?q=49.7500,15.5000&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aK6znUBg - 289586c07eab - 20130730 X-Antispam-Training-Forget: https://mailfilter.nordu.net/canit/b.php?i=0aK6znUBg&m=289586c07eab&t=20130730&c=f X-Antispam-Training-Nonspam: https://mailfilter.nordu.net/canit/b.php?i=0aK6znUBg&m=289586c07eab&t=20130730&c=n X-Antispam-Training-Spam: https://mailfilter.nordu.net/canit/b.php?i=0aK6znUBg&m=289586c07eab&t=20130730&c=s X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: secdir@ietf.org, Linus Nordberg Subject: Re: [secdir] visitors from Tor X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:24:15 -0000 On 07/30/2013 01:02 PM, Linus Nordberg wrote: > Hannes, > > I can be there, not so sure about Jake. Investigating. > > So is there a particular meeting starting at 0900? Can't seem to find > anything (except SEC/oauth). > > Probably better to have this Wednesday night as a "regular" bar-bof. From stephen.farrell@cs.tcd.ie Tue Jul 30 04:26:02 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E6021F9EDF for ; Tue, 30 Jul 2013 04:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5j0W6hmsRY+k for ; Tue, 30 Jul 2013 04:25:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 624BB21F9EE5 for ; Tue, 30 Jul 2013 04:25:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D1DB4BE56; Tue, 30 Jul 2013 12:25:31 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUjq1VAXi0Lf; Tue, 30 Jul 2013 12:25:30 +0100 (IST) Received: from [130.129.34.253] (dhcp-22fd.meeting.ietf.org [130.129.34.253]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4F53CBE38; Tue, 30 Jul 2013 12:25:30 +0100 (IST) Message-ID: <51F7A2A8.3010802@cs.tcd.ie> Date: Tue, 30 Jul 2013 12:25:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Linus Nordberg References: <51F79916.1000003@sunet.se> <874nbcs43v.fsf@nordberg.se> In-Reply-To: <874nbcs43v.fsf@nordberg.se> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org, Linus Nordberg Subject: Re: [secdir] visitors from Tor X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:26:02 -0000 Hi Linus, Doing this sounds like a find thing. I'm sure we can figure some logistics. Let's try find a time/place offlist and then I'll send a mail to the secdir and saag lists announcing whatever. Cheers, Stephen. On 07/30/2013 12:02 PM, Linus Nordberg wrote: > Hannes, > > I can be there, not so sure about Jake. Investigating. > > So is there a particular meeting starting at 0900? Can't seem to find > anything (except SEC/oauth). > > > Hannes Tschofenig wrote > Tue, 30 Jul 2013 12:50:59 +0200: > > | Linus, > | > | would it work for you to meet already at 9am since that's where the meetings start. > | > | Ciao > | Hannes > | > | On Jul 30, 2013, at 12:44 PM, Leif Johansson wrote: > | > | > Linus is our PoC for the Tor-folks. I just brought up the idea > | > of having a side meeting at secdir and folks here are really > | > enthusiastic. I'll let Stephen and Sean figure out the details! > | > > | > Linus has told me that tomorrow after 10 is ideal, Thursday > | > is a no-op (which means SaaG is out I guess) and Friday > | > might also work. > | > > | > Cheers Leif > | > _______________________________________________ > | > secdir mailing list > | > secdir@ietf.org > | > https://www.ietf.org/mailman/listinfo/secdir> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > From stephen.farrell@cs.tcd.ie Wed Jul 31 14:47:35 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB76521E80A7 for ; Wed, 31 Jul 2013 14:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dc0-y05EdwyE for ; Wed, 31 Jul 2013 14:47:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D232F21E809C for ; Wed, 31 Jul 2013 14:47:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 66AF8BE55 for ; Wed, 31 Jul 2013 22:47:05 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOX-OKi66dnq for ; Wed, 31 Jul 2013 22:47:04 +0100 (IST) Received: from [130.129.34.253] (dhcp-22fd.meeting.ietf.org [130.129.34.253]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8FD5ABE4C for ; Wed, 31 Jul 2013 22:47:04 +0100 (IST) Message-ID: <51F985D8.9020705@cs.tcd.ie> Date: Wed, 31 Jul 2013 22:47:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "secdir@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] please remember to send you sec area wg summaries to saag X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 21:47:36 -0000 ... and thanks to those who've done so already. Cheers, S. From ynir@checkpoint.com Wed Jul 31 16:20:05 2013 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE12021E8085; Wed, 31 Jul 2013 16:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.526 X-Spam-Level: X-Spam-Status: No, score=-10.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5kej99ozTpR; Wed, 31 Jul 2013 16:19:59 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1021B21E805F; Wed, 31 Jul 2013 16:19:56 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6VNJpkx032767; Thu, 1 Aug 2013 02:19:51 +0300 X-CheckPoint: {51F99B97-5-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Thu, 1 Aug 2013 02:19:50 +0300 From: Yoav Nir To: "secdir@ietf.org" , IESG IESG , "draft-ietf-manet-nhdp-olsrv2-sec.all@tools.ietf.org" Thread-Topic: SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03 Thread-Index: AQHOjkRzWPcMempN206ICOIpPpticQ== Date: Wed, 31 Jul 2013 23:19:49 +0000 Message-ID: <332E771E-87A4-4C9F-83B7-CB96AB41D5A3@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.170] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 1158ae557a72b52e8ad5f2391fce785804ff27dc8f Content-Type: text/plain; charset="Windows-1252" Content-ID: <9C422FCAE932E2438969B53166558749@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [secdir] SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 23:20:05 -0000 Do not be alarmed. I have reviewed this document as part of the security d= irectorate's ongoing effort to review all IETF documents being processed by= the IESG. These comments were written primarily for the benefit of the se= curity area directors. Document editors and WG chairs should treat these c= omments just like any other last call comments. Summary: Has issues. This document needs some more work, both on the securi= ty considerations section and general terminology. This draft adds integrity protection and replay protection to the NHDP prot= ocol and the OLSRv2 protocol. These protocols use the TLV format defined in= RFC 5444. This draft specifies the use of the ICV and TIMESTAMP TLVs (both= defined in draft-ietf-manet-rfc6622-bis), the former for integrity protect= ion, and the latter for replay protection. I am not convinced by the suitability of a POSIX timestamp (32-bits with 1-= second resolution) to protect in general against replay. Within the same se= cond, a packet can be replayed. I don't know enough about the NHDP and OLSR= v2 protocols to say whether this is a problem. Its usefulness depends on sy= nchronized clocks, but this is well explained in the document, both in the = security considerations, and in the regular sections where timestamp is men= tioned. The biggest hole in this specification is that it is silent about key distr= ibution ("This framework does not...Specify how to distribute cryptographic= material (shared secret key(s))." This is the real hard problem, and the d= raft doesn't even reference some other specification that does have a suita= ble key distribution protocol. You can't do HMAC without key distribution b= eing in place. On to the security considerations section: This section is generally well-written, although it might have been clearer= to write the limitations along with the list of alleviated attacks. The se= ction does cover the dependency on clock synchronization, the limited time = in which replay is possible, the vulnerability to other routers who possess= the same shared key, and the reliance on another key distribution and key = revocation mechanism. About the general writing:=20 This document contains some examples of sloppy language: - Figure 1 shows messages being processed by "this specification". Specific= ations don't process messages. Hardware or software components do.=20 - Section 3 says that "[RFC6130] and [OLSRv2] enable extensions to recogniz= e=85". Extensions don't recognize, they're just a string of bytes. Implemen= tations recognize things. - Section 4 says something about "messages owned by [RFC6130] and [OLSRv2]"= . Again, RFCs define messages, they don't own them. - TC is used multiple times, but never expanded. Yoav=