From dharkins@lounge.org Mon May 2 10:52:31 2011 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 BEE17E06A3; Mon, 2 May 2011 10:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOeKoiwtqVk9; Mon, 2 May 2011 10:52:30 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFF4E0678; Mon, 2 May 2011 10:52:30 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3AD051022400A; Mon, 2 May 2011 10:52:30 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 2 May 2011 10:52:30 -0700 (PDT) Message-ID: <315e69dc80b49e18950a478f6ab49972.squirrel@www.trepanning.net> Date: Mon, 2 May 2011 10:52:30 -0700 (PDT) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, draft-mavrogiannopoulos-ssl-version3.all@tools.ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [secdir] secdir review of draft-mavrogiannopoulos-ssl-version3 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, 02 May 2011 17:52:31 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft is a formal description of SSL 3.0 which was never formally published by the IETF. TLS has made it obsolete but having a stable reference would be valuable, so it's being published as historical. This is a very well-written draft (I wish more I-Ds were written this clearly, my own included). It notes, in the Foreward, that no changes from the original SSL 3.0 document were made except to remove portions that no longer apply and a few trivial editorial changes. I would like to suggest some changes that I believe would fall into those buckets as well. Trivial editorial changes to give normative behavior normative wording: - section 5.6.1.1 Hello request, "After sending a hello request, servers SHOULD NOT repeat the request...." - section 5.6.1.2 Client hello after description of the contents of the SessionID, "Warning: Servers MUST NOT place confidential information in session identifiers, and MUST NOT let the contents of fake session identifiers cause any breach of security." - section 5.6.4, Certificate request, "Note: An anonymous server requesting client information MUST result in a fatal handshake_failure alert." - section 5.6.9, Finished, "It SHALL be a fatal error if a finished message is not preceded [spelling?] by by a change cipher spec message at the appropriate point in the handshake." Removal of wording that no longer applies in the current environment (and was not really unique to the US anyway): - section 5.6.3, remove note about US export law restricting RSA moduli to 512 bits or less. - Appendix D.1, remove mention of US export restrictions limiting RSA keys used for encryption to 512 bits. Trivial editorial change to conform to RFC structure - make section 7 into section 8 and move Appendix F into a new section 7 entitled "Security Considerations". regards, Dan. From mundy@tislabs.com Mon May 2 19:49:03 2011 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 A42A5E0727; Mon, 2 May 2011 19:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBBI9nxELoYT; Mon, 2 May 2011 19:49:03 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 07DAFE06EF; Mon, 2 May 2011 19:49:02 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p432Ta3f021267; Mon, 2 May 2011 21:29:36 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p432TYZp011361; Mon, 2 May 2011 21:29:34 -0500 Received: from nermal.tislabs.com ([192.94.214.97]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 May 2011 15:58:16 -0400 From: Russ Mundy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 May 2011 15:58:16 -0400 Message-Id: To: secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 02 May 2011 19:58:16.0843 (UTC) FILETIME=[470C1DB0:01CC0903] Cc: draft-ietf-v6ops-v6-aaaa-whitelisting-implications.all@tools.ietf.org, iesg@ietf.org, Russ Mundy Subject: [secdir] secdir review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 02:49:03 -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 to be well written as well as providing sound = technical descriptions of the topic of DNS Whitelisting. =20 =46rom a security review perspective, I do have a suggestion for section = 10 Security Considerations. The section infers (at least to me) that = there is something different or unique for configuring DNS Whitelist = configuration protection from other configuration settings for name = servers. Unless I've misunderstood how servers actually implement = whitelisting, it uses the same configuration mechanisms and files as any = other name server ACL or many other name server configuration settings - = _all_ the configuration settings for a name server should be protected = so that only authorized individuals can change them. Modifying the = wording to say something to the effect of "Just as all configuration = settings for name servers should be protected by appropriate procedures = and systems ..." Russ Mundy From charliek@microsoft.com Mon May 2 22:36:48 2011 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 13DC8E06FE; Mon, 2 May 2011 22:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SFKsR24J0kf; Mon, 2 May 2011 22:36:46 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 0F157E06F1; Mon, 2 May 2011 22:36:46 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 2 May 2011 22:36:45 -0700 Received: from TK5EX14MBXC119.redmond.corp.microsoft.com ([169.254.10.87]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0289.008; Mon, 2 May 2011 22:36:45 -0700 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-dime-extended-naptr.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-dime-extended-naptr-06 Thread-Index: AcwJUP9jS00Dz04RS1qvYxOu4jn5AQ== Date: Tue, 3 May 2011 05:36:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_D80EDFF2AD83E648BD1164257B9B09122C4668B5TK5EX14MBXC119r_" MIME-Version: 1.0 Subject: [secdir] Secdir review of draft-ietf-dime-extended-naptr-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 05:36:48 -0000 --_000_D80EDFF2AD83E648BD1164257B9B09122C4668B5TK5EX14MBXC119r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document makes some straightforward extensions to the DNS records that= support the Diameter protocol (RFC 3588). The goal is to improve performan= ce over the previous approach where in some cases multiple servers would ha= ve to be contacted to determine which one(s) supported some particular appl= ication. As the document notes, there are no security issues beyond those t= hat apply to the base protocol (RFC 3588). So I found nothing objectionable in this document. Unfortunately, the story doesn't end there. To understand this spec, I had = to read the Diameter document. The approach that Diameter takes to configur= ation using DNS appears to leave a gaping security hole that should be exam= ined by whoever is reviewing RFC 3588bis (which is also in final stages of = approval). The problem is that TLS (or IPsec) is used to secure the Diamete= r connections themselves, and shared keys or certificates are used to authe= nticate the peer entities. But the DNS records appear to be used to learn t= he names of the peer entities which are subsequently authenticated. That me= ans if someone could update DNS they could indicate the Diameter server for= some domain was in fact some rogue server. So long as that rogue server co= uld be authenticated, it would be trusted to speak for the domain in the co= ntext of Diameter. I suspect common practice is to have Diameter server names be manually conf= igured, in which case there is no vulnerability. But without looking at thi= s in detail it would appear that the more flexible autoconfiguration via DN= S is not secure. If so (I could easily be missing something), there are sev= eral ways it could be fixed. DNSSEC would be the obvious solution, but not = necessarily the best. DNSSEC is still not widely deployed, and this protoco= l is unlikely to act as a forcing function. Better would be to put some sor= t of extension in the certificates of Diameter certificates that indicates = the domain(s) over which the server has jurisdiction in this context. Yet a= nother option would be some naming convention for finding the name of Diame= ter servers for a particular domain rather than looking them up in DNS. In any case, someone should have a look. --Charlie --_000_D80EDFF2AD83E648BD1164257B9B09122C4668B5TK5EX14MBXC119r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 

This document makes some straightforward extensions = to the DNS records that support the Diameter protocol (RFC 3588). The goal = is to improve performance over the previous approach where in some cases mu= ltiple servers would have to be contacted to determine which one(s) supported some particular application. As the do= cument notes, there are no security issues beyond those that apply to the b= ase protocol (RFC 3588).

 

So I found nothing objectionable in this document.

 

Unfortunately, the story doesn’t end there. To= understand this spec, I had to read the Diameter document. The approach th= at Diameter takes to configuration using DNS appears to leave a gaping secu= rity hole that should be examined by whoever is reviewing RFC 3588bis (which is also in final stages of approval). The = problem is that TLS (or IPsec) is used to secure the Diameter connections t= hemselves, and shared keys or certificates are used to authenticate the pee= r entities. But the DNS records appear to be used to learn the names of the peer entities which are subseq= uently authenticated. That means if someone could update DNS they could ind= icate the Diameter server for some domain was in fact some rogue server. So= long as that rogue server could be authenticated, it would be trusted to speak for the domain in the conte= xt of Diameter.

 

I suspect common practice is to have Diameter server= names be manually configured, in which case there is no vulnerability. But= without looking at this in detail it would appear that the more flexible a= utoconfiguration via DNS is not secure. If so (I could easily be missing something), there are several ways it cou= ld be fixed. DNSSEC would be the obvious solution, but not necessarily the = best. DNSSEC is still not widely deployed, and this protocol is unlikely to= act as a forcing function. Better would be to put some sort of extension in the certificates of Diameter cer= tificates that indicates the domain(s) over which the server has jurisdicti= on in this context. Yet another option would be some naming convention for = finding the name of Diameter servers for a particular domain rather than looking them up in DNS.

 

In any case, someone should have a look.<= /p>

 

        &nbs= p;       --Charlie

--_000_D80EDFF2AD83E648BD1164257B9B09122C4668B5TK5EX14MBXC119r_-- From kent@bbn.com Tue May 3 02:45:58 2011 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 CA551E06F2; Tue, 3 May 2011 02:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.305 X-Spam-Level: X-Spam-Status: No, score=-104.305 tagged_above=-999 required=5 tests=[AWL=2.294, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZNTGdx8hQC1; Tue, 3 May 2011 02:45:58 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8E6E06AA; Tue, 3 May 2011 02:45:58 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58447 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QHCB3-000K0y-7J; Tue, 03 May 2011 05:45:57 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> Date: Tue, 3 May 2011 05:05:01 -0400 To: Sam Hartman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 09:45:58 -0000 At 12:02 PM -0400 4/25/11, Sam Hartman wrote: >... > > >However, when I look at section 2.1.4 in the signed-object document , >the signer can only include one certificate. >How does that work during phase 2 when some of the RPs support the new >format and some only support the old format? >Your text above suggests that RPs grab the certificates from the RPKI >repository, but it seems at least for end entity certificates they are >included in the signed object. >What happens for end entity certificates during this form of upgrade? Sam, Yes, only one cert is associated with an RPKI signed object, and yes, this cert is embedded in the signed object format. So, when a new cert is issued, using a new format, the object itself is changed. Thus, the text describing Phase 2 is saying that there will be parallel instances of certs, CRLs, and signed objects in the RPKI repository system, associated with the old and new cert/CRL formats. I could add a sentence or two making this explicit, and referring the reader to the phased transition strategy used for algorithm transition in the RPKI, and described in draft-sidr-algorithm-agility. The reference would be informative, as this I-D is still in development and I don't want to hold up the progress of the rest of the SIDR docs. Let me know if this addresses your question. Steve From kent@bbn.com Tue May 3 02:46:02 2011 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 445ACE06F2; Tue, 3 May 2011 02:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.481 X-Spam-Level: X-Spam-Status: No, score=-104.481 tagged_above=-999 required=5 tests=[AWL=2.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYgdnBaLcPwd; Tue, 3 May 2011 02:46:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id CBAB3E07B5; Tue, 3 May 2011 02:46:01 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:58447 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QHCB1-000K0y-2Q; Tue, 03 May 2011 05:45:56 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1446DA6A65B664240D8AA4F9@PST.JCK.COM> References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> <1446DA6A65B664240D8AA4F9@PST.JCK.COM> Date: Tue, 3 May 2011 05:05:58 -0400 To: John C Klensin From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 09:46:02 -0000 At 9:27 AM -0400 4/17/11, John C Klensin wrote: >Steve, >Two things: > > >(1) Given the variable amount of time it takes to get RFCs >issued/ published after IESG signoff, are you and the WG sure >that you want to tie the phases of the phase-in procedure to RFC >publication? It probably would help if the IESG coordinated with the RFC Editor to try to avoid having any problems here. But, we anticipate that the durations for the phases will be long enough so that a few months in the RFC editor's queue can be managed. > >(2) There is an incomplete sentence at the end of (2): "This >allows CAs to issue certificates under" (more context below). > > john Whoops. The final sentence should be: This allows CAs to issue certificates under the new format before all relying parties are prepared to process that format. Steve From hartmans@mit.edu Tue May 3 08:05:25 2011 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 49480E0837; Tue, 3 May 2011 08:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.617 X-Spam-Level: X-Spam-Status: No, score=-103.617 tagged_above=-999 required=5 tests=[AWL=-1.352, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbcrtvLDR9Bd; Tue, 3 May 2011 08:05:24 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 66282E0830; Tue, 3 May 2011 08:05:24 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 68F882033D; Tue, 3 May 2011 11:01:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 90E1041F4; Tue, 3 May 2011 11:05:18 -0400 (EDT) From: Sam Hartman To: Stephen Kent References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> Date: Tue, 03 May 2011 11:05:18 -0400 In-Reply-To: (Stephen Kent's message of "Tue\, 3 May 2011 05\:05\:01 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 15:05:25 -0000 Let me make sure I'm understanding what you're saying. I can have multiple ROAs for the same set of prefixes in the repository and valid at the same time: one signed by a new certificate and one signed by a previous certificate? If so, I think I now begin to understand why the SIDR working group believes this is a reasonable strategy. I guess the only question I'd have remaining is whether ROAs or other signed objects are intended to be used in other protocols besides simply living in the SIDR repository? From kent@bbn.com Tue May 3 12:36:35 2011 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 65380E0863; Tue, 3 May 2011 12:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.878 X-Spam-Level: X-Spam-Status: No, score=-104.878 tagged_above=-999 required=5 tests=[AWL=1.721, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeFLCisf3HwZ; Tue, 3 May 2011 12:36:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id E1F42E066E; Tue, 3 May 2011 12:36:34 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:60540 helo=[10.27.179.212]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QHLOQ-00026p-Pp; Tue, 03 May 2011 15:36:25 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> Date: Tue, 3 May 2011 15:16:28 -0400 To: Sam Hartman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 19:36:35 -0000 At 11:05 AM -0400 5/3/11, Sam Hartman wrote: >Let me make sure I'm understanding what you're saying. I can have >multiple ROAs for the same set of prefixes in the repository and valid >at the same time: one signed by a new certificate and one signed by a >previous certificate? If so, I think I now begin to understand why the >SIDR working group believes this is a reasonable strategy. yes, that is correct. This is an essential part of the alg transition mechanism. > >I guess the only question I'd have remaining is whether ROAs or other >signed objects are intended to be used in other protocols besides simply >living in the SIDR repository? The RPKI repository is designed to support a specific, narrow set of apps. That's what the CP says, and we try to make these certs unattractive for other apps, e.g., by use of the non-meaningful names. Steve From hartmans@mit.edu Tue May 3 15:08:04 2011 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 599B3E07BD; Tue, 3 May 2011 15:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.504 X-Spam-Level: X-Spam-Status: No, score=-103.504 tagged_above=-999 required=5 tests=[AWL=-1.239, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bILJ3sLu+Uyv; Tue, 3 May 2011 15:08:03 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id CEA63E0747; Tue, 3 May 2011 15:08:03 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DFF9F20228; Tue, 3 May 2011 18:04:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C0F0A41F4; Tue, 3 May 2011 18:07:59 -0400 (EDT) From: Sam Hartman To: Stephen Kent References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> Date: Tue, 03 May 2011 18:07:59 -0400 In-Reply-To: (Stephen Kent's message of "Tue\, 3 May 2011 15\:16\:28 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 22:08:04 -0000 >>>>> "Stephen" == Stephen Kent writes: >> >> I guess the only question I'd have remaining is whether ROAs or >> other signed objects are intended to be used in other protocols >> besides simply living in the SIDR repository? Stephen> The RPKI repository is designed to support a specific, Stephen> narrow set of apps. That's what the CP says, and we try to Stephen> make these certs unattractive for other apps, e.g., by use Stephen> of the non-meaningful names. You had mentioned that about the PKI before. Now, though I'm focusing on the ROAs and other signed objects, not the certificates and CRLs. Do these narrow applications involve simply storing these objects in the repository, or are there plans to use ROAs or other signed objects as elements in protocols? At least years ago, for example, there was discussion of carrying signatures of objects in BGP. I understand that's not within SIDR's current charter, but is SIDR intended to support that style of use, or have things been narrowed to a point where that would require reworking details of the repository and PKI? If the answer is that those sorts of uses are not in scope for the SIDR architecture, then I think you've basically resolved my concerns. From kent@bbn.com Wed May 4 01:01:50 2011 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 A57D5E076E; Wed, 4 May 2011 01:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.98 X-Spam-Level: X-Spam-Status: No, score=-104.98 tagged_above=-999 required=5 tests=[AWL=1.619, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CfHf0Wjo9ZI; Wed, 4 May 2011 01:01:49 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id D19AEE06D4; Wed, 4 May 2011 01:01:49 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:37521 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QHX1o-0007sw-B6; Wed, 04 May 2011 04:01:48 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> Date: Wed, 4 May 2011 04:00:18 -0400 To: Sam Hartman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 08:01:50 -0000 At 6:07 PM -0400 5/3/11, Sam Hartman wrote: > >>>>> "Stephen" == Stephen Kent writes: > > > >> > >> I guess the only question I'd have remaining is whether ROAs or > >> other signed objects are intended to be used in other protocols > >> besides simply living in the SIDR repository? > > Stephen> The RPKI repository is designed to support a specific, > Stephen> narrow set of apps. That's what the CP says, and we try to > Stephen> make these certs unattractive for other apps, e.g., by use > Stephen> of the non-meaningful names. > >You had mentioned that about the PKI before. Now, though I'm focusing >on the ROAs and other signed objects, not the certificates and CRLs. Do >these narrow applications involve simply storing these objects in the >repository, or are there plans to use ROAs or other signed objects as >elements in protocols? At least years ago, for example, there was >discussion of carrying signatures of objects in BGP. I understand that's >not within SIDR's current charter, but is SIDR intended to support that >style of use, or have things been narrowed to a point where that would >require reworking details of the repository and PKI? > >If the answer is that those sorts of uses are not in scope for the SIDR >architecture, then I think you've basically resolved my concerns. Sam, You might want to look again at the SIDR charter, since it has just been revised to include BGP path validation. The path validation approach being pursued makes use of the RPKI, consistent with the scope of the CP, not surprisingly. The BGPSEC protocol being defined does not pass around ROAs or other RPKI repository objects. It defines two new, signed objects that are passed in UPDATE messages, and are not stored in the repository. These objects are verified using RPKI certs and CRLs, so there is a linkage. Does that answer your question? Steve From hartmans@mit.edu Wed May 4 04:48:55 2011 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 4671FE0748; Wed, 4 May 2011 04:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.409 X-Spam-Level: X-Spam-Status: No, score=-103.409 tagged_above=-999 required=5 tests=[AWL=-1.144, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jUNqyDuAkyA; Wed, 4 May 2011 04:48:54 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C7800E0708; Wed, 4 May 2011 04:48:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2AE862034A; Wed, 4 May 2011 07:45:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7F43441F4; Wed, 4 May 2011 07:48:44 -0400 (EDT) From: Sam Hartman To: Stephen Kent References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> Date: Wed, 04 May 2011 07:48:44 -0400 In-Reply-To: (Stephen Kent's message of "Wed\, 4 May 2011 04\:00\:18 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 11:48:55 -0000 >>>>> "Stephen" == Stephen Kent writes: Stephen> The BGPSEC protocol being defined does not pass around ROAs Stephen> or other RPKI repository objects. It defines two new, Stephen> signed objects that are passed in UPDATE messages, and are Stephen> not stored in the repository. These objects are verified Stephen> using RPKI certs and CRLs, so there is a linkage. OK, so how will the upgrade work for these signed objects? In particular during phase 2, when both old and new certs (under the old and new profile) are in use, what happens with these signed objects? Can a party generate both old and new signed objects? If so, will the protocol scale appropriately? If not, how does a party know which signed object to generate? From kent@bbn.com Wed May 4 06:14:52 2011 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 85B2EE070C; Wed, 4 May 2011 06:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.07 X-Spam-Level: X-Spam-Status: No, score=-105.07 tagged_above=-999 required=5 tests=[AWL=1.529, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSNfG7abgHFe; Wed, 4 May 2011 06:14:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0982EE06A4; Wed, 4 May 2011 06:14:51 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:45522 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QHbuj-000CvY-RU; Wed, 04 May 2011 09:14:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> Date: Wed, 4 May 2011 09:14:30 -0400 To: Sam Hartman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 13:14:52 -0000 At 7:48 AM -0400 5/4/11, Sam Hartman wrote: > >>>>> "Stephen" == Stephen Kent writes: > > Stephen> The BGPSEC protocol being defined does not pass around ROAs > Stephen> or other RPKI repository objects. It defines two new, > Stephen> signed objects that are passed in UPDATE messages, and are > Stephen> not stored in the repository. These objects are verified > Stephen> using RPKI certs and CRLs, so there is a linkage. > >OK, so how will the upgrade work for these signed objects? In >particular during phase 2, when both old and new certs (under the old >and new profile) are in use, what happens with these signed objects? >Can a party generate both old and new signed objects? If so, will the >protocol scale appropriately? If not, how does a party know which >signed object to generate? Sam, The BGPSEC protocol will have to accommodate changes in the algs used to validate BGPSEC signed objects, and changes in algs used to validate RPKI objects, and key (not alg) changes in the RPKI objects, especially the certs associated with routers. So, format changes are just another example of a change in the RPKI that BGPSEC will have to accommodate. This is a legitimate discussion point for the BGPSEC protocol design discussions that will take place in SIDR. It is out of scope for the current set of docs, since they deal only with origin AS validation. It would be inappropriate to suggest delaying this doc (or to suggest changes to it) based on discussions that will take place in the future, for a protocol that is just being adopted as a WG item now. Steve From hartmans@mit.edu Wed May 4 07:32:44 2011 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 2E5BEE0719; Wed, 4 May 2011 07:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.618 X-Spam-Level: X-Spam-Status: No, score=-103.618 tagged_above=-999 required=5 tests=[AWL=-1.353, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQeegOHWpULJ; Wed, 4 May 2011 07:32:43 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9C7E070C; Wed, 4 May 2011 07:32:43 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 261F52034A; Wed, 4 May 2011 10:28:55 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 415F841F4; Wed, 4 May 2011 10:32:36 -0400 (EDT) From: Sam Hartman To: Stephen Kent References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> Date: Wed, 04 May 2011 10:32:36 -0400 In-Reply-To: (Stephen Kent's message of "Wed\, 4 May 2011 09\:14\:30 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 14:32:44 -0000 >>>>> "Stephen" == Stephen Kent writes: Stephen> At 7:48 AM -0400 5/4/11, Sam Hartman wrote: >> >>>>> "Stephen" == Stephen Kent writes: >> Stephen> The BGPSEC protocol being defined does not pass around ROAs Stephen> or other RPKI repository objects. It defines two new, Stephen> signed objects that are passed in UPDATE messages, and are Stephen> not stored in the repository. These objects are verified Stephen> using RPKI certs and CRLs, so there is a linkage. >> >> OK, so how will the upgrade work for these signed objects? In >> particular during phase 2, when both old and new certs (under the >> old and new profile) are in use, what happens with these signed >> objects? Can a party generate both old and new signed objects? >> If so, will the protocol scale appropriately? If not, how does a >> party know which signed object to generate? Stephen> Sam, Stephen> The BGPSEC protocol will have to accommodate changes in the Stephen> algs used to validate BGPSEC signed objects, and changes in Stephen> algs used to validate RPKI objects, and key (not alg) Stephen> changes in the RPKI objects, especially the certs Stephen> associated with routers. So, format changes are just Stephen> another example of a change in the RPKI that BGPSEC will Stephen> have to accommodate. This is a legitimate discussion point Stephen> for the BGPSEC protocol design discussions that will take Stephen> place in SIDR. It is out of scope for the current set of Stephen> docs, since they deal only with origin AS validation. Let me see if I can summarize where we are: You've describe an upgrade strategey for the origin validation in the current set of docs. It depends on the ability to store multiple certs, ROAs and other objects in the repository. You agree that when SIDR looks at using RPKI objects in the newly adopted work it will need some upgrade strategy for format, keys and algorithms. There are probably a number of options for how to accomplish this. Even if the working group did decide to update processing of RPKI objects at that point, requiring new behavior from parties implementing a new protocol would be possible. Is that a reasonable summary? From kent@bbn.com Wed May 4 10:20:49 2011 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 1C3E8E0735; Wed, 4 May 2011 10:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.15 X-Spam-Level: X-Spam-Status: No, score=-105.15 tagged_above=-999 required=5 tests=[AWL=1.449, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bpiOpv0OX5t; Wed, 4 May 2011 10:20:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8E769E06DE; Wed, 4 May 2011 10:20:48 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49357 helo=[10.27.179.196]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QHfkg-000Dso-Bg; Wed, 04 May 2011 13:20:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> Date: Wed, 4 May 2011 13:20:38 -0400 To: Sam Hartman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 17:20:49 -0000 At 10:32 AM -0400 5/4/11, Sam Hartman wrote: > >... > >Let me see if I can summarize where we are: >You've describe an upgrade strategey for the origin validation in the >current set of docs. It depends on the ability to store multiple certs, >ROAs and other objects in the repository. requirements that already exist to accommodate key rollover and alg transition for the RPKI. We have a SIDR doc describing both key rollover, >You agree that when SIDR looks at using RPKI objects in the newly >adopted work it will need some upgrade strategy for format, keys and >algorithms. There are probably a number of options for how to >accomplish this. Even if the working group did decide to update >processing of RPKI objects at that point, requiring new behavior from >parties implementing a new protocol would be possible. I find your last sentence above confusing. I would say that the BGPSEC protocol will have to define how it deals with alg changes for the signed objects it defines, with key changes for RPKI certs, with alg changes for all RPKI objects, and with format changes for RPKI objects and for its own objects. Steve From hartmans@mit.edu Wed May 4 11:31:46 2011 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 29DD1E078F; Wed, 4 May 2011 11:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.607 X-Spam-Level: X-Spam-Status: No, score=-103.607 tagged_above=-999 required=5 tests=[AWL=-1.342, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsxK8ubcoUZs; Wed, 4 May 2011 11:31:45 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A55B1E0700; Wed, 4 May 2011 11:31:45 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A654D20222; Wed, 4 May 2011 14:27:57 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A52F141F4; Wed, 4 May 2011 14:31:39 -0400 (EDT) From: Sam Hartman To: Stephen Kent References: <4D791B26.8020001@vpnc.org> <4D79271E.6080707@vpnc.org> Date: Wed, 04 May 2011 14:31:39 -0400 In-Reply-To: (Stephen Kent's message of "Wed\, 4 May 2011 13\:20\:38 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 18:31:46 -0000 Steve, I'd like to thank you for working through these issues with me. I think the new texxt you added before approval is very helpful. You indicated you could add an additional sentence pointing out that multiple signed objects would need to be used in order to deal with phase 2 for end-entity certificates. While I think that would be reasonable to add, I also don't think it is necessary. I'm sorry the upgrade approach was not more obvious from the beginning. >>>>> "Stephen" == Stephen Kent writes: Stephen> I find your last sentence above confusing. I would say Stephen> that the BGPSEC protocol will have to define how it deals Stephen> with alg changes for the signed objects it defines, with Stephen> key changes for RPKI certs, with alg changes for all RPKI Stephen> objects, and with format changes for RPKI objects and for Stephen> its own objects. Excellent. Please consider it early input to the WG process that how the protocol deals with all of these issues should be documented. The sort of structure you adopted for the text added to cert profile seems like a fine style to use, although of course there are others that would also work. What I think is important is that the IESG and community at large be able to evaluate these transition issues when the protocol comes up for IETf review. In conclusion, thanks again for your help. I see you're giving a talk next Thursday on these issues at an ISOC chapter meeting; I hope to attend and better come up to speed. From gih@apnic.net Wed May 4 21:45:14 2011 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 18685E06C0; Wed, 4 May 2011 21:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDJRgp+cPasx; Wed, 4 May 2011 21:45:12 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE7AE06AE; Wed, 4 May 2011 21:45:11 -0700 (PDT) Received: from [192.168.49.35] (unknown [84.35.81.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 2F010B689A; Thu, 5 May 2011 14:45:04 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 5 May 2011 14:43:45 +1000 Message-Id: <7A33AE35-5B39-466E-BF31-28BFD36081C5@apnic.net> To: Nico Williams Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: sidr-chairs@tools.ietf.org, secdir@ietf.org, draft-ietf-sidr-rpki-manifests.all@tools.ietf.org, The IESG Subject: [secdir] SECdir review of draft-ietf-sidr-rpki-manifests ( and Stephen Farrell's Discuss on draft-ietf-sidr-rpki-manifests-10) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 04:45:14 -0000 Nico, Thanks for your review. Below are replies to the non-trivial comments (i.e., comments other than editing and reference versions): > A summary of my comments is: >=20 > - Text on versioning of the manifest ASN.1 would be useful. > - Handling of boundary conditions on manifest validation could use = some > improvement, such as regarding clock skew. See specific comments > below. > - Some "SHOULDs" could use some additional commentary regarding when > an implementation might act otherwise. >=20 >> 2. Manifest Scope >>=20 >> [...] > >> Where an EE certificate is placed in the Cryptographic Message = Syntax >> (CMS) wrapper of a published RPKI signed object >> [ID.sidr-signed-object] there is no requirement to separately = publish >> the EE certificate in the CA's repository publication point. >> [...] >=20 > Any guidance on when to place EE certs in CMS wrappers and when not = to? RESPONSE: The answers are "always" and "never" in that order. The general format=20= and top-level processing for all such RPKI signed objects is specified = in draft-ietf-sidr-signed-object. The text in the draft is less than clear in such guidance, and the following text is proposed in its place: "Every RPKI signed object includes, in the Cryptographic Message Syntax (CMS) [RFC3370] wrapper of the object, the EE certificate used to verify it [ID.sidr-signed-object]. Thus there is no requirement to separately publish that=20 EE certificate at the CA's repository publication point." >> 4.2. eContent >>=20 >> The content of a Manifest is defined as follows: >>=20 >> Manifest ::=3D SEQUENCE { >> version [0] INTEGER DEFAULT 0, >> manifestNumber INTEGER (0..MAX), >> thisUpdate GeneralizedTime, >> nextUpdate GeneralizedTime, >> fileHashAlg OBJECT IDENTIFIER, >> fileList SEQUENCE SIZE (0..MAX) OF FileAndHash >> } >>=20 >> FileAndHash ::=3D SEQUENCE { >> file IA5String, >> hash BIT STRING >> } >=20 > IA5String? Not UTF8String? What goes into file naming? RESPONSE: The authors asked the implementors and the likely users, including the RIRs, and nobody saw a need to support UTF-8 characters for file names. So the authors went with a simpler character set. If one supported UTF-8 here, one would incur a lot of potential complexity in UIs and there might be problems with other software. >> 4.2.1. Manifest >>=20 >> The data elements of the Manifest structure are defined as follows: >>=20 >> version: >> The version number of this version of the manifest specification >> MUST be 0. >=20 > Some text on how versioning is intended to be used would be nice. > Specifically, how might extensions be added? Or perhaps extensibility > here is seen as unnecessary? RESPONSE: This question is not clear. When a new version of the manifest specification is created, the version number of the new manifest specification will change. A new version of the manifest specification is the intended way of accommodating future extensions or changes to the manifest specification. The text referring to version 0 refers to this particular specification. Presumably the first update to this specification will have a version number of 1. > If extensibility is inteded to be done by turning the version field of > the above SEQUENCE into a CHOICE then say so -- implementors with > sufficiently capable ASN.1 compilers and runtimes may prefer to modify > the above to use an extensible CHOICE. RESPONSE: I am advised by a co-author of this draft that the version number syntax cited here is precisely what is used in most PKI objects, e.g., certificates and CRLs, and that CHOICE is not needed here either. > In general I would much prefer that we make use of ASN.1's explicit > extensibility features (namely, the extensibility marker in SEQUENCEs, > SETs, and CHOICEs) and/or typed-holes as appropriate. RESPONSE: The specification is following the CMS syntax model, to first order, as the Manifest data structure places this data inside a CMS wrapper. The authors Do not see much incremental benefit to the stylistic approach you suggest. >> manifestNumber: >> This field is an integer that is incremented each time a new >> manifest is issued for a given publication point. This field >> allows an RP to detect gaps in a sequence of published = manifests. >>=20 >> As the manifest is modeled on the CRL specification, the >> ManifestNumber is analogous to the CRLNumber, and the guidance = in >> [RFC5280] for CRLNumber values is appropriate as to the range of >> number values that can be used for the manifestNumber. Manifest >> numbers can be expected to contain long integers. Manifest >> verifiers MUST be able to handle number values up to 20 octets. >> Conforming Manifest issuers MUST NOT use number values longer = than >> 20 octets >=20 > Why not write that MAX value explicitly in the constraint for this > field? (Because it's a fairly long number?) RESPONSE: We could put in a MAX here, consistent with the 20 octet limit in the comment, but it is a BIG number. This is a style response, and the authors have obviously Preferred the style of describing the maximum value by the maximum octet length of the value. >> 5.1. Manifest Generation Procedure >>=20 >> 6. In the case of a key pair that is to be used only once, in >> conjunction with a "one-time-use" EE certificate, the private = key >> associated with this key pair SHOULD now be destroyed. >=20 > Any reason not to make this SHOULD a MUST? Any guidance as to when = one > might not heed this SHOULD? RESPONSE: One-time use certificates are a recommended implementation strategy, but are not mandated here. There was the view that the issuer's practices with respect to key management and destruction are appropriately described in the Certification Practice Statement. However changing a SHOULD to a MUST is reasonable in any case, and this change will be made to the document. >> 5.2. Considerations for Manifest Generation >>=20 >> A new manifest MUST be issued on or before the nextUpdate time. >=20 > Well, a new manifest must be published on or before the nextUpdate = time. > Since RPs clocks will have some skew, new manifests should really be > published some time ahead of the nextUpdate time. A few seconds or > minutes will do. See comments on section 6.2. RESPONSE: We'll change this to =93issued and published.=94 > What happens if an authority fails to publish a new manifest in a = timely > fashion? This would surely be an important operational = consideration... RESPONSE: Failure to publish a new manifest in a timely fashion will cause RPs to treat the manifest as stale, as discussed in the later sections. >>=20 >> 2. To verify completeness, an RP MAY check that every file at each >> publication point appears in one and only one current manifest, >> and that every file listed in a current manifest that is >> published at the same publication point as the manifest. >=20 > See comment on (4) below. >=20 >> 3. Check that the current time (translated to UTC) is between >> thisUpdate and nextUpdate. >>=20 >> If the current time does not lie within this interval then see >> Section 6.4, but still continue with the following tests. >=20 > This appears to be in conflict with (1) above. The manifest can't be > valid if the current time does not fall in the manifest's validity > period, so what's the point in continuing? I suppose I'll find out = when > I get to section 6.4! >=20 >> 4. Verify that listed hash value of every file listed in each >> manifest matches the value obtained by hashing the file at the >> publication point. >>=20 >> If the computed hash value of a file listed on the manifest = does >> not match the hash value contained in the manifest, then see >> Section 6.6. >=20 > Will the RP need to check every file? Why not just those that are of > interest? RESPONSE: Except during algorithm transition every file at a pub point is assumed to be of interest to every RP. During algorithm transition, an RP might skip pub points that hold objects that are signed under a new algorithm that the RP doesn=92t yet possess. But, that doesn=92t change the per-pub point behavior described here. >> For each signed object, if all of the following conditions hold: >>=20 >> [...] >>=20 >> then the RP can conclude that no attack against the repository = system >> has compromised the given signed object, and the signed object MUST >> be treated as valid. >=20 > No scope for local policy exemptions to the above MUST? RESPONSE: Not at this level of validity checking. The signed objects are subjected to additional checks that are object-specific (encompassed by the text you elided that includes the constraint "the signed object is valid"). The manifest check adds the additional constraint that "and the issuer of the signed object has a current intention that this is publically accessible via its publication". To remove ambiguity here we'll add "valid (relative to manifest checking)." to that sentence. >> 6.2. Missing Manifests >>=20 >> The absence of a current manifest at a publication point could = occur >> due to an error by the publisher or due to (malicious or = accidental) >> deletion or corruption of all valid manifests. >>=20 >> When no valid manifest is available, there is no protection against >> attacks that delete signed objects or replay old versions of signed >> objects. All signed objects at the publication point, and all >> descendant objects that are validated using a certificate at this >> publication point SHOULD be viewed as suspect, but MAY be used by = the >> RP, as per local policy. >=20 > I wonder if we shouldn't have a latestNextUpdate field specifying a = time > past which RPs MUST NOT accept expired manifests. Alternatively, = local > policy ought to specify how old an expired manifest may be accepted, > with RECOMMENDED guidance as to what that maximum age should be. RESPONSE: In the case of manifests with single use EE certificates, then the EE certificates notafter time coincides with the nextUpdate time of the Manifest (5.1, point 2), ergo there is no possibility of having a stale Manifest that is still valid if using a single use EE certificate. In the case of sequential use EE certificates to sign a manifest there is the potential to have stale manifests that are still valid in terms of the validity times of the EE cert. Section 6.4 describes the operational warnings that should be generated if a stale manifest is used in this fashion. > Additionally, CA operators should get guidance to publish new = manifests > somewhat sooner than the expiration of current manifests being = replaced > so as to have some time to cope with operations failures during = manifest > generation and publication. >=20 RESPONSE: The guidance to operators is in section 5.2: "A new manifest MUST be issued on or before the nextUpdate time." See the final comment about operational considerations and the RPKI distributed repository framework on the more general topic of operational considerations. >> The primary risk in using signed objects at this publication point = is >> that a superseded (but not stale) CRL would cause an RP to = improperly >> accept a revoked certificate as valid (and thus rely upon signed >> objects that are validated using that certificate). This risk is >> somewhat mitigated if the CRL for this publication point has a = short >> time between thisUpdate and nextUpdate (and the current time is >> within this interval). The risk in discarding signed objects at = this >> publication point is that an RP may incorrectly discard a large >> number of valid objects. This gives significant power to an >> adversary that is able to delete a manifest at the publication = point. >=20 > I.e., there's a trade-off between DoS and more severe attacks. = However, > we can't protect against DoS attacks here anyways, so might as well = give > guidance in preference of protecting against the other attacks. RESPONSE: There is a distinction to be drawn here between a standard specification and the minimal set of operational criteria to ensure the secure operation of the specification and the broader topic of operational best practices and various potential actions operators may take to mitigate some forms of attack and the potential trade-off such mitigations may entail. But such considerations are not comfortably positioned in a standard specification. The WG draft draft-ietf-sidr-origin-ops is one that the WG intends to hold operational considerations for the operation of the RPKI, and it is perhaps more appropriate that such=20 more general topics of operational best practices site within that document rather than be dispersed within various standard specification documents. > Additionally, guidance to interleave new manifest publication such = that > there's enough time to cope with operations failures and DoS attacks > should help. RESPONSE: I am confused by what is meant by "interleave new manifest publication". I am tempted, inter alia, to refer to the previous comment relating to = the distinction between a standard specification and an operational practice statement. >> Regardless of whether signed objects from this publication are = deemed >> fit for use by an RP, this situation SHOULD result in a warning to >> the effect that: "No manifest is available for , = and >> thus there may have been undetected deletions or replay = substitutions >> from the publication point." >=20 > I imagine this isn't a MUST because of log squelching considerations. > Right? RESPONSE: And the authors are considerate of minimizing mandatory requirements=20 to those that are strictly necessary as distinct from those that=20 are strongly desirable. >> In the case where an RP has access to a local cache of previously >> issued manifests that are valid, the RP MAY use the most recently >> previously issued valid manifests for this RPKI repository >> publication collection in this case for each entity that publishes = at >> this publication point. >=20 > Subject to the same considerations, surely. RESPONSE: I believe that this is reasonably inferred from the text and further elucidation is not necessary. > Any advice as to when to poll for new manifests ahead the current, > cached manifest's nextUpdate? RESPONSE: This does not make a lot of sense when referring to manifests in = isolation=20 from the RPKI distributed repository publication structure and the = actions of relying party actions. Again, the referral to an operational best practices draft being studid by the SIDR WG is appropriate here. >> 6.4. Stale Manifests >=20 > My comments on section 6.2 apply here as well. RESPONSE: As does the response >> Note that there is also the potential for the current time to be >> before the thisUpdate time for the manifest. This case could be = due >> to publisher error, or a local clock error, and in such a case this >> situation SHOULD result in a warning to the effect that: "A = manifest >> found at has an incorrect thisUpdate field. This >> could be due to publisher error, or a local clock error, and >> processing for this publication point will continue using this >> otherwise valid manifest." >=20 > This can also happen due to having a slow clock on the RP or a fast > clock at the CA, or both. Clock skew is hardly an error, since there > will always be some skew, even if only on the order of nanoseconds in > the case of good hardware setup with good time distribution mechanisms > and good hardware time sources. A bit more text (any!) regarding = clock > skew would be useful. RESPONSE: It is a good point, but I worry that it may be inappropriate to bury general considerations about validity and clock skew in the RPKI in the document specifically describing manifests. I would prefer to see this operational consideration about using the = RPKI=20 and clock skew be placed in a document that considered operational = practices and the RPKI, as referred to above. kind regards, Geoff From weiler+secdir@watson.org Sat May 7 01:21:07 2011 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 CEE56E065A for ; Sat, 7 May 2011 01:21:07 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weTjeisqeKGq for ; Sat, 7 May 2011 01:21:06 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 89CA4E06B4 for ; Sat, 7 May 2011 01:21:05 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p478L5S6041953 for ; Sat, 7 May 2011 04:21:05 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p478L4ZD041950 for ; Sat, 7 May 2011 04:21:04 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 7 May 2011 04:21:04 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sat, 07 May 2011 04:21:05 -0400 (EDT) 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: Sat, 07 May 2011 08:21:07 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Tina TSOU is next in the rotation. For telechat 2011-05-12 Reviewer LC end Draft Uri Blumenthal T 2011-04-18 draft-ietf-idr-bgp-identifier-14 David McGrew T 2011-05-09 draft-lear-iana-timezone-database-03 Magnus Nystrom T 2011-05-02 draft-ietf-genarea-datatracker-iana-rfced-extns-01 Vincent Roca T 2011-02-07 draft-reed-urn-dgiwg-02 Sam Weiler T 2011-03-24 draft-ietf-sidr-roa-format-11 For telechat 2011-05-26 Reviewer LC end Draft Rob Austein T 2011-05-03 draft-haleplidis-forces-implementation-experience-02 Love Hornquist-Astrand T 2011-05-12 draft-daboo-et-al-icalendar-in-xml-08 Matt Lepinski T 2011-04-20 draft-ietf-vcarddav-vcardxml-09 Vincent Roca T 2011-05-18 draft-ietf-savi-threat-scope-05 Juergen Schoenwaelder T 2011-05-18 draft-ietf-savi-fcfs-09 Last calls and special requests: Reviewer LC end Draft Alan DeKok 2011-02-23 draft-ietf-isis-reg-purge-01 Dan Harkins 2011-05-03 draft-mavrogiannopoulos-ssl-version3-03 Sam Hartman 2011-04-23 draft-shin-augmented-pake-05 Jeffrey Hutzelman 2011-04-26 draft-ietf-avtext-multicast-acq-rtcp-xr-04 Julien Laganier 2011-03-04 draft-ietf-xcon-examples-08 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-24 Sandy Murphy 2011-04-29 draft-ietf-grow-geomrt-01 Radia Perlman 2011-05-20 draft-hoffman-alt-streams-tracker-13 Tim Polk 2011-05-11 draft-ietf-vrrp-unified-mib-09 Eric Rescorla 2011-05-12 draft-ietf-mmusic-ice-options-registry-01 Joe Salowey 2011-05-18 draft-ietf-sidr-repos-struct-07 Stefan Santesson 2011-05-18 draft-ietf-sidr-keyroll-06 Yaron Sheffer 2011-05-20 draft-ietf-pwe3-fat-pw-05 Ondrej Sury 2011-05-18 draft-ietf-ccamp-gmpls-vcat-lcas-13 From stephen.farrell@cs.tcd.ie Sat May 7 03:50:22 2011 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 6DA75E0663; Sat, 7 May 2011 03:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3T0pcTTMKnA7; Sat, 7 May 2011 03:50:11 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 882D2E0693; Sat, 7 May 2011 03:50:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 35FA1171C3C; Sat, 7 May 2011 11:50:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1304765409; bh=OYVL/o7fXT/jct 5RjGEY9SPu+30k4FaCmGq2dCfxDHI=; b=QjdtdJCohZvuOevRreKNP2ivO6+PUQ QlwhI/0NOHf8qqeuV2WPTMLrsGKMnpp5ERFeUwmPLcRIPThJv9NRh+Tz4FwX6sji utG96AvSh3wtBfor2AfrnHeKoa1XkMJ1W4bmoS4Zv0cR4Ibd1QzrqUj7+HZyOeJf iBq0K8BKGhze3+KWtN+tzmSHNWC8g+vziq60SrD9UYJ5AAj33Fn/EMaKmN1q6Hd/ sYzla9wePMjjI29gc0DQV54SZ6NIiOj4rmgp/LzPwECDAL2Wln+oJp1sA69m9LUA K1bvYoq4a6bX47lmy8KcRYiKzuJRUV+atHDdWhPfNr53aiP4lI+1RWoA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id fkHetV-GPhG5; Sat, 7 May 2011 11:50:09 +0100 (IST) Received: from [10.87.48.9] (unknown [86.41.10.88]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B7F0B171C3B; Sat, 7 May 2011 11:50:07 +0100 (IST) Message-ID: <4DC523DF.4010803@cs.tcd.ie> Date: Sat, 07 May 2011 11:50:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Geoff Huston References: <7A33AE35-5B39-466E-BF31-28BFD36081C5@apnic.net> In-Reply-To: <7A33AE35-5B39-466E-BF31-28BFD36081C5@apnic.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: sidr-chairs@tools.ietf.org, secdir@ietf.org, draft-ietf-sidr-rpki-manifests.all@tools.ietf.org, The IESG Subject: Re: [secdir] SECdir review of draft-ietf-sidr-rpki-manifests ( and Stephen Farrell's Discuss on draft-ietf-sidr-rpki-manifests-10) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 10:50:22 -0000 Folks, I've updated my discusss to reflect the points below basically just asking for the changes that Geoff indicates they want to make. I agree that most of the rest will be addressed in other sidr docs. (Nico - if you see a major problem with that, let me know please.) Thanks all, S. On 05/05/11 05:43, Geoff Huston wrote: >>> 5.2. Considerations for Manifest Generation >>> >> >>> >> A new manifest MUST be issued on or before the nextUpdate time. >> > >> > Well, a new manifest must be published on or before the nextUpdate time. >> > Since RPs clocks will have some skew, new manifests should really be >> > published some time ahead of the nextUpdate time. A few seconds or >> > minutes will do. See comments on section 6.2. > RESPONSE: > > We'll change this to “issued and published.” > From magnusn@gmail.com Sat May 7 11:31:32 2011 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 839D0E071E; Sat, 7 May 2011 11:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEUMMgfD4YIw; Sat, 7 May 2011 11:31:24 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7528CE06BA; Sat, 7 May 2011 11:31:24 -0700 (PDT) Received: by gyf3 with SMTP id 3so1851434gyf.31 for ; Sat, 07 May 2011 11:31:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=1eKm6MSwIZkLmN39iRB00sjB/hGLHC3Ogq/Z3gwK/hQ=; b=rQuk8uZCMGiREvOpuQeqDE+HJ/k3k9HTwF0Tf1lAzBM/qjuCg4c4QradPl38UiiO0C OWBR3yduFbrAr3Tpy63vC+Cj9rSCFr/FvoAoVYn99jrUB47KXFr/P3/53hVu/TFYCHWq /hRtdJ1OibWKmOST8Mlcy9wH3kOyfG2OvS34I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=XgN6qUk/gE2Pae7SMzfurSl/3l2xBitFdN3o7jV8EX5NENtvdCe2LArO81XNMBUc1Z CghPLbJPYmMcFrBIEomQYkKdBaxu76B/cizsamWnxt5Jru51tn58x4BUfs9gtkFoiNE3 Yx3/dKYRUbKGVox++REmqELlTiwDz5XiIhVSA= MIME-Version: 1.0 Received: by 10.150.73.20 with SMTP id v20mr4355627yba.368.1304793083092; Sat, 07 May 2011 11:31:23 -0700 (PDT) Received: by 10.150.195.18 with HTTP; Sat, 7 May 2011 11:31:23 -0700 (PDT) Date: Sat, 7 May 2011 11:31:23 -0700 Message-ID: From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= To: iesg@ietf.org, secdir@ietf.org, draft-ietf-genarea-datatracker-iana-rfced-extns@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [secdir] Secdir review of draft-ietf-genarea-datatracker-iana-rfced-extns-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2011 18:31:32 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. =A0These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is not about proposing any new Internet protocol or mechanism, rather it is about extending the IETF Datatracker to include increased IANA and RFC Editor state information for internet drafts, so that the Datatracker covers the lifetime of an I-D from version -00 to RFC publication. As such, I do not have any security-specific comments on this draft. -- Magnus From vincent.roca@inrialpes.fr Mon May 9 03:29:46 2011 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 30D5EE07AF; Mon, 9 May 2011 03:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYHSTl+YIrcH; Mon, 9 May 2011 03:29:45 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 12286E068D; Mon, 9 May 2011 03:29:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,339,1301868000"; d="scan'208";a="82640942" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 09 May 2011 12:28:32 +0200 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 9 May 2011 12:28:32 +0200 Message-Id: <5FADE82E-A84E-4D9D-A8DD-B337C06D5EA4@inrialpes.fr> To: IESG , secdir@ietf.org, draft-reed-urn-dgiwg.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] Secdir review of draft-reed-urn-dgiwg-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 10:29:46 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document introduces a new namespace for the DGI Working Group (http://www.dgiwg.org) and has a very light security considerations section (1 sentence only), as is usually the case with such documents (see http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml). That being said, since the goal of the DGIWG is to facilitate the exchange of geospatial information between countries, in particular in context of military cooperations, security is critical. Therefore the author could perhaps elaborate a little bit more. For instance one or two sentences highlighting the importance of having secure methods to access locations once the URN resolution has taken place (i.e. after the name to location resolution) could be added, with a few pointers. Regards, Vincent From lars.eggert@nokia.com Mon May 9 03:44:58 2011 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 F2398E07AF; Mon, 9 May 2011 03:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.74 X-Spam-Level: X-Spam-Status: No, score=-102.74 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5si+SPtDQ4UH; Mon, 9 May 2011 03:44:57 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E673CE071F; Mon, 9 May 2011 03:44:56 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p49AirPw026330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 May 2011 13:44:55 +0300 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-1-213170627; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 9 May 2011 13:44:44 +0300 Message-Id: <2CB29B1A-9590-424F-8CCC-1E7181278E96@nokia.com> To: irsg@irtf.org, rtg-dir@ietf.org, ipdir@ietf.org, tsv-dir@ietf.org, ops-dir@ietf.org, secdir@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.fit.nokia.com); Mon, 09 May 2011 13:44:50 +0300 (EEST) X-Nokia-AV: Clean Subject: [secdir] looking for ANRP reviewers X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: anrp@isoc.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 10:44:58 -0000 --Apple-Mail-1-213170627 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, you may have seen the call for nominations for the Applied Networking = Research Prize that the IRTF and ISOC are sponsoring. Basically, it's an = offer to the research community to get a travel grant and an invited = talk with the intent to stimulate new IRTF and IETF work, or otherwise = bring value to the IETF week. The details are at = http://www.irtf.org/anrp. The nomination period just ended, and we received 22 nominations. I'd = like to ask for some (5-10) volunteers to help select the winning = submissions. The intent is to pick two for Quebec City, and possibly two = more for Taiwan. The notification deadline for the awards is May 31, and = I'd like to finish the selection be Friday, May 27. In other words, = you'd need to spend a few cycles during the next 2-3 weeks. I'm looking for folks with a research and engineering background in the = topics below. Routing and other layer-3 topics were very common, so = experience in those areas is especially needed: LISP P2P traffic localization traffic classification impact of packet sizes NetFlow PMTUD measurements BGP (churn, update reductions) path computation inter-ISP connectivity tracking Ethernet scalability push messaging Internet of things routing (new approaches, FIB aggregation) TCP (over MANET, wireless) IPv6 transition HIP congestion notification energy-aware traffic engineering broadband Internet performance Note that we're NOT doing an academic peer review here. These papers = were already published - and hence peer reviewed - at more or less = prestigious journals, conferences and workshops. What the selection = process will need to determine is which of these submissions are = especially interesting to the IRTF and IETF community, whether they may = lead to new work, if they get a well-known research name to attend, etc. = In other words, the process is more like selecting a "best paper award" = than deciding on whether a paper should be accepted. Since this is the first time we're awarding ANRPs, we're making the = process up as we go. My current intention is to get 3-4 folks to look at = each of the submissions, do a pre-selection by email this week and next, = and do the final selection based on the preselection shortlist during a = phone call sometime between May 23-27. If you'd like to volunteer or have questions, please email = anrp@isoc.org. Thanks, Lars= --Apple-Mail-1-213170627 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDUwOTEwNDQ0NVowIwYJKoZIhvcNAQkE MRYEFGDZJGA3JoLhf6Yp43nn6CvKPloGMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AKjLCx/4eKbunfu7Tx/JCroctGRIqiSOEQ9Bke7V+nG4F3YpuAA2dLYYsV+i7u1wFhre0xQRs6n2 Y1sfOyOSd1mM+PCDCQfRQITHrsXgtNWRdS9eIXh8AXGu6tJLMwiD/BFYtgXKbrIEcCxZCgT15lVK eA2+mt19o8nwi4JqrmmwEg/uPhqT5NWouptjq2W6ZgUwCCzOvtd36De/rfWwM/CovnqWVOIx+8v1 gaoY94XWCPMmE0uaMVyXK0MGrflCkvjDZoNrf/w9iNdAAwGBLguOGzP3SR8gltUm1oUVVV+fdvbe ioYLFPEs2B4kOvmc/T4GuP/fmScES1wcKgspvAUAAAAAAAA= --Apple-Mail-1-213170627-- From j.schoenwaelder@jacobs-university.de Mon May 9 06:46:34 2011 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 90490E0692; Mon, 9 May 2011 06:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.186 X-Spam-Level: X-Spam-Status: No, score=-103.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnU0LuDY7SWB; Mon, 9 May 2011 06:46:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9CBE0659; Mon, 9 May 2011 06:46:30 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B952620BDD; Mon, 9 May 2011 15:46:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id R5STOA8ANXCg; Mon, 9 May 2011 15:46:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE21720BDB; Mon, 9 May 2011 15:46:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 171EE1871160; Mon, 9 May 2011 15:46:21 +0200 (CEST) Date: Mon, 9 May 2011 15:46:21 +0200 From: Juergen Schoenwaelder To: iesg@ietf.org, secdir@ietf.org, draft-ietf-savi-fcfs.all@tools.ietf.org Message-ID: <20110509134619.GA38866@elstar.local> Mail-Followup-To: iesg@ietf.org, secdir@ietf.org, draft-ietf-savi-fcfs.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [secdir] secdir review of draft-ietf-savi-fcfs-09.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 13:46:34 -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. -- My first question was triggered by text on page 8: [...] Before creating a SAVI binding in the local SAVI database, the SAVI device will send a NSOL message querying for the address involved. Should any host reply to that message with a NADV message, the SAVI device that sent the NSOL will infer that a binding for that address exists in another SAVI device and will not create a local binding for it. Now, that sounded like it is easy to DoS new devices simply by generating fake NADV messages. Later in section 3, it seems you only accept NADV messages from trusted ports. If my reading is correct, then a better wording might be: [...] Before creating a SAVI binding in the local SAVI database, the SAVI device will send a NSOL message querying for the address involved. Should any host _on a trusted port_ reply to that message with a NADV message, the SAVI device that sent the NSOL will infer that a binding for that address exists in another SAVI device and will not create a local binding for it. But then I am not sure whether it is really practical to assume that NADV messages always come from a trusted port. -- My second question concerns the construction of the prefix list. One option is to learn prefixes by listening to Router Advertisements. Is there a way to make SAVI do bad things by announcing bogus prefixes? -- My third question concerns this statement in the security considerations: The other type of attack is when an attacker manages to create state in the SAVI device that will result in blocking the data packets sent by the legitimate owner of the address. In IPv6 these attacks are not an issue thanks to the 2^64 addresses available in each link. The second sentence makes this sound like a non-issue but it seems to be correct only if devices uniformly pick random addresses out of the full 2^64 address space. If for whatever reason I can guess with a decent likelihood an address, it looks like SAVI becomes a tool to help me with denying service for such an address. -- Editorial nits: - p10: s/because the connect/because they connect/ (twice) - p10: s/through validating port/through validating ports/ - p11: s/prefixes.A/prefixes. A/ - p13: s/may due/may be due/ - p13: s/packets has been/packets have been/ - p18: s/relay/rely/ - p24: s/coalition/collision/ - p26: s/case fixed/case of fixed/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From weiler@watson.org Wed May 11 19:43:43 2011 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 2C5FDE0681; Wed, 11 May 2011 19:43:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWj1DpT1Az9A; Wed, 11 May 2011 19:43:42 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9CFE0662; Wed, 11 May 2011 19:43:42 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p4C2hfen073937; Wed, 11 May 2011 22:43:41 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p4C2heUq073932; Wed, 11 May 2011 22:43:40 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 11 May 2011 22:43:40 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org, iesg@ietf.org, draft-ietf-sidr-roa-format.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 11 May 2011 22:43:41 -0400 (EDT) Subject: [secdir] secdir review of draft-ietf-sidr-roa-format X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 02:43:43 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Disclaimer: I'm active in the SIDR WG and have reviewed this draft before. In the big picture, this draft is fine. I have three little requests: -- I would very much like to see an informational reference to the roa-validation draft (already approved for publication), which explains more about how ROAs should be interpreted. -- I made a suggestion in WG last call that appears not to have been addressed by the editors. That was: It might be worthwhile to repeat in section 3 (validation) [now section 4] the requirement from section 7.2 [now 7.3] of the architecture draft that "...a relying party must fetch new ROAs from the repository system before taking any routing action in response to a ROA revocation." -- The Address Family Identifier appears to come out of nowhere in section 3.3. Another mention of RFC3779 is needed when the AFI is introduced. (Previous versions of this draft (07 and earlier) at least told readers which of the allowed values corresponded to IPv4 and IPv6, but even that has been taken out of this version.) From yaronf.ietf@gmail.com Wed May 11 22:32:26 2011 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 5501EE06A4; Wed, 11 May 2011 22:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbTG6ppBwgPb; Wed, 11 May 2011 22:32:25 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 74FB8E0689; Wed, 11 May 2011 22:32:25 -0700 (PDT) Received: by wwa36 with SMTP id 36so920177wwa.13 for ; Wed, 11 May 2011 22:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=r50tHU+tSzN1zG6fxhBkGEldrHEfq2v1fQAWkD6YSA8=; b=Zgvh2fFbx05u4JyAhOEeyD4GeOGj4f8/tGgLDXSmx7VcHR/ve8QdMoNcuaWcg40VCp 0X0e9Oee1BKytD52YBCxrDS+uHssweYSns7T+4K46ccJUNtbdac8GILl0dj4KC5JsDrY U6gGy6x2LoBvBXBUqiNlr3tJi7XZTsLA4knjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=oUZ4DHOXpeJQ1p3aSRwD4Jj6Ayxwkh1caD+V2FieX1iBBZkwPM+sRf9q3jaSNYpLDA 6TzwDJjYHpIIgwsDQYULe8UTYgCUjv+3PYXcztllfpbEISngQra9hHnmTSWeXxwS/BsV azUKLBwSMRLoCBmVAEakJPqlCZki9Vz90p+eg= Received: by 10.227.170.200 with SMTP id e8mr10650963wbz.50.1305178344636; Wed, 11 May 2011 22:32:24 -0700 (PDT) Received: from [192.168.1.180] (192.117.25.34.static.012.net.il [192.117.25.34]) by mx.google.com with ESMTPS id s20sm512046wbh.6.2011.05.11.22.32.23 (version=SSLv3 cipher=OTHER); Wed, 11 May 2011 22:32:24 -0700 (PDT) Message-ID: <4DCB70E5.8090906@gmail.com> Date: Thu, 12 May 2011 08:32:21 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Security Area Directorate , The IESG , draft-ietf-pwe3-fat-pw.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-pwe3-fat-pw-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 05:32:26 -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 proposes the addition of MPLS flow labels, to enable multiplexing of a single pseudowire (PW) over multiple paths, while retaining the packet order within each IP flow. The document's security considerations simply reference several former MPLS documents. I believe this is appropriate in this case. Nits: although very readable, the document needs another round of proofreading. The following is from the abstract and the first sentence of the Introduction (!): - Abstract: "most forwarding engines": the sentence is unclear - hash what? Also a dangling "END" at the end of the abstract. - Intro first sentence: exit -> exist, equipments -> equipment/devices. Thanks, Yaron From stbryant@cisco.com Thu May 12 01:13:51 2011 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 546A0E0734; Thu, 12 May 2011 01:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFA1ePsYIo8y; Thu, 12 May 2011 01:13:47 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id D8D79E0669; Thu, 12 May 2011 01:13:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=2196; q=dns/txt; s=iport; t=1305188027; x=1306397627; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=zbelBxDd8pZTP64ZXiSFQ3NtqJLzp2+J+onvF8bQQ/w=; b=N0Btl/kqMUqM/FlEJz80XoqBCYdRPmSkv4nJ5wDJUT7+3W727Bd5H2wp 0Cz0v8JrfKVQIsPK25+EiW+lh+Ykz8qaIYKTf+oltwl3Og75+4vGtvk2d uLvUT1etoJGwL4lmmhlf8yIJMZ7mG+wWXdEsW6iOYXL5alyUtGeUGuWDX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUDAHaVy02Q/khRgWdsb2JhbAClcRQBARYmJatggngPAZsihhMEj3aOZw X-IronPort-AV: E=Sophos;i="4.64,357,1301875200"; d="scan'208";a="88103928" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 12 May 2011 08:13:45 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p4C8DfHv004820; Thu, 12 May 2011 08:13:44 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id p4C8DbU09758; Thu, 12 May 2011 09:13:37 +0100 (BST) Message-ID: <4DCB96B0.1040005@cisco.com> Date: Thu, 12 May 2011 09:13:36 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Yaron Sheffer References: <4DCB70E5.8090906@gmail.com> In-Reply-To: <4DCB70E5.8090906@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-pwe3-fat-pw.all@tools.ietf.org, The IESG , Security Area Directorate Subject: Re: [secdir] SecDir review of draft-ietf-pwe3-fat-pw-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 08:13:51 -0000 Yaron Thank you for the review. The Abstract should read: Abstract Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to hash at least part of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs. This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. The "END" is a cut and paste error from a review comment. s/(ECMP) exit/(ECMP) exist/ Adrian, please let me know whether you want a new version. - Stewart On 12/05/2011 06:32, Yaron Sheffer wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these > comments just like any other last call comments. > > > This document proposes the addition of MPLS flow labels, to enable > multiplexing of a single pseudowire (PW) over multiple paths, while > retaining the packet order within each IP flow. > > > The document's security considerations simply reference several former > MPLS documents. I believe this is appropriate in this case. > > > Nits: although very readable, the document needs another round of > proofreading. The following is from the abstract and the first > sentence of the Introduction (!): > > > - Abstract: "most forwarding engines": the sentence is unclear - hash > what? Also a dangling "END" at the end of the abstract. > > > - Intro first sentence: exit -> exist, equipments -> equipment/devices. > > > Thanks, > > Yaron > > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From n.mavrogiannopoulos@gmail.com Wed May 11 06:00:00 2011 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 C67D2E080C; Wed, 11 May 2011 06:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjDM7Wa7mw3j; Wed, 11 May 2011 05:59:59 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id D2933E07EB; Wed, 11 May 2011 05:59:59 -0700 (PDT) Received: by pzk5 with SMTP id 5so312964pzk.31 for ; Wed, 11 May 2011 05:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HldC8fAj+e+9S0pey/O5igSVxMdTZKZAjPJxc9AFuJM=; b=VQm8lSaLcTpcsqPbXIzM9kT2G8zyAT078OCFJFvOvy6ffAbIKFrgrFinafyFH8ciCP gFekQJro3NO8sgbYECEDPcnFXtjNDK9VDHXaG68NrRB5qtfCYyCVJuJxVEzu6p5xGwTj LQw0McDgufCLpD9j5ioawoDz9PNHRhn0AmJ/4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=SECyS+GBAa3HOFVELbr7GaEgqY/bgXZF6Zqz8nhAKPnOJYMwr9FUYA8Cg3IVJYA7Ie sAffKvT1K4igswGZ7f0kVMRphcIpD/mwJmDG1F2+nVn60ZSrqSQqOYiBWKFM+xz9rEyD uQYHqZcX5VPnfIOzWAuDZhlN0N/Bu7Swxb9c8= MIME-Version: 1.0 Received: by 10.68.71.233 with SMTP id y9mr7995512pbu.150.1305118799492; Wed, 11 May 2011 05:59:59 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.68.59.70 with HTTP; Wed, 11 May 2011 05:59:59 -0700 (PDT) In-Reply-To: <315e69dc80b49e18950a478f6ab49972.squirrel@www.trepanning.net> References: <315e69dc80b49e18950a478f6ab49972.squirrel@www.trepanning.net> Date: Wed, 11 May 2011 14:59:59 +0200 X-Google-Sender-Auth: LZAs4QOqSCFmdHQ3MGCZFbM9wp0 Message-ID: From: Nikos Mavrogiannopoulos To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 14 May 2011 10:50:11 -0700 Cc: draft-mavrogiannopoulos-ssl-version3.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-mavrogiannopoulos-ssl-version3 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, 11 May 2011 13:00:00 -0000 On Mon, May 2, 2011 at 7:52 PM, Dan Harkins wrote: > =C2=A0Hello, > =C2=A0I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. =C2=A0These comments were written primarily for the benefit of the > security area directors. =C2=A0Document editors and WG chairs should trea= t > these comments just like any other last call comments. Hello and thank you for reviewing the document. [...] > =C2=A0Trivial editorial changes to give normative behavior normative word= ing: [applied] > =C2=A0Removal of wording that no longer applies in the current environmen= t > =C2=A0(and was not really unique to the US anyway): > =C2=A0 - section 5.6.3, remove note about US export law restricting RSA > =C2=A0 =C2=A0 moduli to 512 bits or less. > =C2=A0 - Appendix D.1, remove mention of US export restrictions limiting > =C2=A0 =C2=A0 RSA keys used for encryption to 512 bits. I think it is essential to the document the US export restrictions to be ke= pt as it is. My reasoning would be: 1. To keep the discussion in context, and answer to the question why the ex= port ciphersuites are defined? 2. To show that cryptography at that time (1998) was driven from political decisions. For this reason I suggest instead the following text to the foreword: "The US export rules discussed in the document do not apply today but are kept intact for to provide context for the discussion of the EXPORT cipher-suites." > =C2=A0Trivial editorial change to conform to RFC structure > =C2=A0 - make section 7 into section 8 and move Appendix F into a new > =C2=A0 =C2=A0 section 7 entitled "Security Considerations". Although this is today the current format, it was not in 1998 and this document is already widespread through copies such as www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt. For this reason I'd like to keep the differences between the two documents as minimal as possible. best regards, Nikos From new-work-bounces@ietf.org Thu May 12 14:48:30 2011 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C07E07D6; Thu, 12 May 2011 14:48:30 -0700 (PDT) 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 694F9E07D6 for ; Thu, 12 May 2011 14:48:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZFWKzp2qAZv for ; Thu, 12 May 2011 14:48:28 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2B2E066E for ; Thu, 12 May 2011 14:48:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1QKdkA-0006aF-IE; Thu, 12 May 2011 17:48:26 -0400 From: Ian Jacobs Date: Thu, 12 May 2011 16:48:25 -0500 To: new-work@ietf.org Message-Id: <29579778-72D5-4D39-825C-22513D860983@W3.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Sat, 14 May 2011 10:50:11 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Device APIs Working Group (until 2011-06-09) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 21:48:30 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise = the Ubiquitous Web Applications Activity [0] (see the W3C Process Document = description of Activity Proposals [1]). This proposal includes a draft char= ter for the Device APIs Working Group: http://www.w3.org/2010/11/DeviceAPICharter.html As part of ensuring that the community is aware of proposed work at W3C, th= is draft charter is public during the Advisory Committee review period. W3C invites public comments through 2011-06-09 on the proposed charter. Ple= ase send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Repr= esentatives, W3C cannot guarantee a response to comments. If you work for a= W3C Member [2], please coordinate your comments with your Advisory Committ= ee Representative. For example, you may wish to make public comments via th= is list and have your Advisory Committee Representative refer to it from hi= s or her formal review comments. If you should have any questions or need further information, please contac= t Dominique Haza=EBl-Massieux, Team Contact . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/2007/uwa/Activity.html [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From gwz@net-zen.net Sun May 15 00:35:17 2011 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 54190E0658 for ; Sun, 15 May 2011 00:35:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+nZlUpC7SAX for ; Sun, 15 May 2011 00:35:16 -0700 (PDT) Received: from p3plsmtpa07-01.prod.phx3.secureserver.net (p3plsmtpa07-01.prod.phx3.secureserver.net [173.201.192.230]) by ietfa.amsl.com (Postfix) with SMTP id B5B10E06AB for ; Sun, 15 May 2011 00:35:16 -0700 (PDT) Received: (qmail 4348 invoked from network); 15 May 2011 07:28:36 -0000 Received: from unknown (124.122.83.151) by p3plsmtpa07-01.prod.phx3.secureserver.net (173.201.192.230) with ESMTP; 15 May 2011 07:28:36 -0000 Message-ID: <4DCF809D.6040605@net-zen.net> Date: Sun, 15 May 2011 14:28:29 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Charlie Kaufman References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------080508050003040009020404" Cc: "draft-ietf-dime-extended-naptr.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-dime-extended-naptr-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2011 07:35:17 -0000 This is a multi-part message in MIME format. --------------080508050003040009020404 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 5/3/2011 12:36 PM, Charlie Kaufman wrote: ... > Unfortunately, the story doesn’t end there. To understand this spec, I > had to read the Diameter document. The approach that Diameter takes to > configuration using DNS appears to leave a gaping security hole that > should be examined by whoever is reviewing RFC 3588bis (which is also in > final stages of approval). The problem is that TLS (or IPsec) is used to > secure the Diameter connections themselves, and shared keys or > certificates are used to authenticate the peer entities. But the DNS > records appear to be used to learn the names of the peer entities which > are subsequently authenticated. That means if someone could update DNS > they could indicate the Diameter server for some domain was in fact some > rogue server. So long as that rogue server could be authenticated, it > would be trusted to speak for the domain in the context of Diameter. I don't think that that is actually true (see below). > > > > I suspect common practice is to have Diameter server names be manually > configured, in which case there is no vulnerability. But without looking > at this in detail it would appear that the more flexible > autoconfiguration via DNS is not secure. If so (I could easily be > missing something), there are several ways it could be fixed. DNSSEC > would be the obvious solution, but not necessarily the best. DNSSEC is > still not widely deployed, and this protocol is unlikely to act as a > forcing function. > Better would be to put some sort of extension in the > certificates of Diameter certificates that indicates the domain(s) over > which the server has jurisdiction in this context. >From draft-ietf-dime-rfc3588bis, Section 5.2: If the server is using a site certificate, the domain name in the NAPTR query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS/TCP and DTLS/SCTP or IKE exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior, or the result of an attack. Also, the Diameter Peer MUST check to make sure that the discovered peers are authorized to act in its role. Authentication via IKE or TLS/TCP and DTLS/SCTP, or validation of DNS RRs via DNSSEC is not sufficient to conclude this. For example, a web server may have obtained a valid TLS/TCP and DTLS/SCTP certificate, and secured RRs may be included in the DNS, but this does not imply that it is authorized to act as a Diameter Server. Authorization can be achieved for example, by configuration of a Diameter Server CA. Alternatively this can be achieved by definition of OIDs within TLS/TCP and DTLS/SCTP or IKE certificates so as to signify Diameter Server authorization. This seems to address the issue, the only problem I can see is that the last sentence of the second paragraph quoted above might not be specific enough; maybe change "authorized to act as a Diameter Server." to "authorized to act as a Diameter Server for the given realm."? > Yet another option > would be some naming convention for finding the name of Diameter servers > for a particular domain rather than looking them up in DNS. I think that that was discussed at some point thousands of years ago but rejected; I don't recall why. ... --------------080508050003040009020404 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------080508050003040009020404-- From radiaperlman@gmail.com Mon May 16 16:17:42 2011 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 E9EBCE06F1; Mon, 16 May 2011 16:17:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t18KppInVYNT; Mon, 16 May 2011 16:17:42 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46575E06EC; Mon, 16 May 2011 16:17:42 -0700 (PDT) Received: by iwn39 with SMTP id 39so5588350iwn.31 for ; Mon, 16 May 2011 16:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=D9/FZd/8/14q1VGaJrQ1FogAW/vtMcItXZhTLuEFUrk=; b=S5TJ9vySP7ImlgLUeEdg8TOPdQLqfO0XEauEaasjw/LLwlwdcFX1lBqvlEHYDLfaKV H5Ub7nzHOJOwEs6zeio9lhyu3s46x4umU5mZhOqFJN6ZQy9HtYzvWw4Vz1KZT7YZUhSv 60eIr+8Z9lLUC65ilhjbzhG+MN6oinXfGw708= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=agC7MjvcpiZbQ2tayl6smsviSEuXFt/nHlBRFhwlqlnss/bENfkF3Y/I2ftmDiNwVk IAT5S/TTMLImuMSLG6lu8huGNEP3XGxyzOfkSmX/VvtA7I4m2oEgPGPVaUsRovvqhVWZ O4toxaq9iUU5qms3mr697uehIAWvMnur+z58o= MIME-Version: 1.0 Received: by 10.42.163.8 with SMTP id a8mr5225449icy.525.1305587861752; Mon, 16 May 2011 16:17:41 -0700 (PDT) Received: by 10.42.220.138 with HTTP; Mon, 16 May 2011 16:17:41 -0700 (PDT) Date: Mon, 16 May 2011 16:17:41 -0700 Message-ID: From: Radia Perlman To: iesg@ietf.org, secdir@ietf.org, draft-hoffman-alt-streams-tracker.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] secdir review of draft-hoffman-alt-streams-tracker-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 23:17:43 -0000 This document describes more states for the document tracker. As the document accurately states, " Changing the states in the Data Tracker does not affect the security of the Internet in any significant fashion." I found no problems with this document. From simon@josefsson.org Tue May 17 23:42:44 2011 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 C6B3EE0806; Tue, 17 May 2011 23:42:44 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCAc-dogu0wU; Tue, 17 May 2011 23:42:44 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5F081E0822; Tue, 17 May 2011 23:42:38 -0700 (PDT) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p4I6gNoC000734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 May 2011 08:42:25 +0200 From: Simon Josefsson To: Chris Lonvick References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110518:draft-josefsson-gss-capsulate.all@tools.ietf.org::6Ux4xI3P7ObB/Hlk:0n4A X-Hashcash: 1:22:110518:secdir@ietf.org::ntTVd2Z8AnmYILhg:BUrr X-Hashcash: 1:22:110518:iesg@ietf.org::QT75CiVLexIAuu3i:HV3T X-Hashcash: 1:22:110518:clonvick@cisco.com::93CtUh5j5A26piKa:pj84 Date: Wed, 18 May 2011 08:42:23 +0200 In-Reply-To: (Chris Lonvick's message of "Wed, 20 Apr 2011 16:29:49 -0700 (PDT)") Message-ID: <87liy4se5s.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97 at yxa-v X-Virus-Status: Clean Cc: draft-josefsson-gss-capsulate.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-josefsson-gss-capsulate-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 06:42:44 -0000 Hi Chris, Thanks for review! I agree with all your suggestions, and have published -05 that should address them. Please verify. /Simon Chris Lonvick writes: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Overall, I find the document to be of good quality and ready to progress. > > One editorial suggestion I'd make would be to either include or > directly reference the security section of RFC 2743 in your own > security considerations section. > > Also, I'm just not partial towards the use of "otherwise" to describe > a return code from gss_oid_equal. Personally, I think it should be > directly specified. > > Finally, I think you have a formatting inconsistency in Section 4.1; > the "otherwise" should be tabbed out to line up in the other column. > > Regards, > Chris From jsalowey@cisco.com Wed May 18 21:42:42 2011 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 D87A0E06C8; Wed, 18 May 2011 21:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxyrXZ4F2WqB; Wed, 18 May 2011 21:42:35 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id B0FD2E06C3; Wed, 18 May 2011 21:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1448; q=dns/txt; s=iport; t=1305780155; x=1306989755; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=0eB0d7HsWkwGzNFCCTJY9NhZxxEYlwz226F4XEwbFNw=; b=gdkQtoUMDJQ+hmKQ/MFbuB4UEIDWhiYhfZDFp33cO7DJGq9tYFAnrbqc Zpkk1vQO9lAuZOefPBbM5b4L8Ed1NNfA6nXMlhnTj43cz21BS4owi4DFa G21vIkFhWWuwsVIUfhoYPEqSnBxvyM1uMKL82ccQNLZbDN7/+82+Grr30 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMCe1E2rRDoJ/2dsb2JhbACmHHeqDp1+hhkEhlCJQYQvimY X-IronPort-AV: E=Sophos;i="4.65,235,1304294400"; d="scan'208";a="450511012" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 19 May 2011 04:42:35 +0000 Received: from [10.33.249.93] ([10.33.249.93]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4J4gXsP013018; Thu, 19 May 2011 04:42:34 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 18 May 2011 21:42:44 -0700 Message-Id: <427D4174-E04F-4C2B-BBFA-D445A4682601@cisco.com> To: secdir@ietf.org, The IESG , draft-ietf-sidr-repos-struct.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] Secdir review of draft-ietf-sidr-repos-struct-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 04:42:43 -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. In general the draft looks useful, but I think there are a few things = that need to be addressed before publication. =20 1. The document asks for a registration for the extension .roa for = Route Origination Authorization, but the discussion of this type is = absent from the rest of the document. =20 2. In section 2.2 under certificates it would probably be good to = specify the encoding of the certificate since there are different = encodings in use (DER, Base64,etc). =20 3. The document is not very specific on what signed objects may = consist of. The security considerations section points out that the = repository itself does not provide integrity protection. The security = considerations section should probably also mention that confidentiality = is also not provided by the repository or by the signed objects (unless = there is some mechanism used to ensure the confidentiality of the data = which would need to be specified) and that data that requires = controlled access should not be included in signed objects in the = repository. Thanks, Joe From weiler@watson.org Wed May 18 21:59:27 2011 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 472A2E06F9 for ; Wed, 18 May 2011 21:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkAJW15GxpTJ for ; Wed, 18 May 2011 21:59:26 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8FDE0691 for ; Wed, 18 May 2011 21:59:26 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p4J4xPN9073087 for ; Thu, 19 May 2011 00:59:25 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p4J4xPS0073084 for ; Thu, 19 May 2011 00:59:25 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 19 May 2011 00:59:25 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 19 May 2011 00:59:25 -0400 (EDT) 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, 19 May 2011 04:59:27 -0000 Glen Zorn is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview The last assignment message was on May 7th. For telechat 2011-05-26 Reviewer LC end Draft Rob Austein T 2011-05-03 draft-haleplidis-forces-implementation-experience-02 Love Hornquist-Astrand T 2011-05-12 draft-daboo-et-al-icalendar-in-xml-09 Jeffrey Hutzelman T 2011-04-26 draft-ietf-avtext-multicast-acq-rtcp-xr-04 Stephen Kent TR2011-03-04 draft-ietf-xcon-ccmp-13 Tero Kivinen TR2011-03-04 draft-ietf-xcon-common-data-model-27 Julien Laganier T 2011-03-04 draft-ietf-xcon-examples-08 Matt Lepinski T 2011-04-20 draft-ietf-vcarddav-vcardxml-09 Chris Lonvick TR2011-03-17 draft-giralt-schac-ns-05 Sandy Murphy T 2011-04-29 draft-ietf-grow-geomrt-01 Eric Rescorla T 2011-05-12 draft-ietf-mmusic-ice-options-registry-02 Vincent Roca T 2011-05-18 draft-ietf-savi-threat-scope-05 For telechat 2011-06-09 Reviewer LC end Draft Ondrej Sury T 2011-05-18 draft-ietf-ccamp-gmpls-vcat-lcas-13 Sam Weiler T 2011-06-01 draft-ietf-dhc-duid-uuid-03 Brian Weis T 2011-06-01 draft-ietf-dhc-dhcpv6-relay-supplied-options-06 Last calls and special requests: Reviewer LC end Draft Alan DeKok 2011-02-23 draft-ietf-isis-reg-purge-01 Dan Harkins 2011-05-03 draft-mavrogiannopoulos-ssl-version3-04 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-24 Tim Polk 2011-05-11 draft-ietf-vrrp-unified-mib-09 Stefan Santesson 2011-05-18 draft-ietf-sidr-keyroll-06 Tina TSOU 2011-04-23 draft-shin-augmented-pake-06 Carl Wallace 2011-05-30 draft-ietf-mpls-p2mp-lsp-ping-16 Nico Williams 2011-05-26 draft-ietf-dkim-mailinglists-10 Tom Yu 2011-05-30 draft-ietf-l3vpn-ibgp-07 Kurt Zeilenga 2011-05-30 draft-ietf-mpls-lsp-ping-enhanced-dsmap-09 Larry Zhu 2011-05-26 draft-ietf-mpls-mp-ldp-reqs-07 From lha@kth.se Wed May 18 22:12:23 2011 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 12562E06F6; Wed, 18 May 2011 22:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGISTgLyCDUO; Wed, 18 May 2011 22:12:22 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by ietfa.amsl.com (Postfix) with ESMTP id EF88FE06D1; Wed, 18 May 2011 22:12:21 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id A03A5156B42; Thu, 19 May 2011 07:11:49 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id T+KtXCbnGEZz; Thu, 19 May 2011 07:11:48 +0200 (CEST) Received: from EXHUB1.ug.kth.se (exhub1.ug.kth.se [130.237.32.134]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 456411551FC; Thu, 19 May 2011 07:11:46 +0200 (CEST) Received: from EXDB1.ug.kth.se ([169.254.1.64]) by EXHUB1.ug.kth.se ([130.237.32.134]) with mapi id 14.01.0289.001; Thu, 19 May 2011 07:11:46 +0200 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= To: IESG , Security-Directorat Directorat Thread-Topic: secdir review: draft-daboo-et-al-icalendar-in-xml Thread-Index: AQHMFeM/aMgPriRT30a0VKLBVTS49Q== Date: Thu, 19 May 2011 05:11:45 +0000 Message-ID: <1F0345B0-0507-4D5D-97D7-9002CC198A44@kth.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [99.52.202.108] Content-Type: multipart/signed; boundary="Apple-Mail-26-1057190162"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "draft-daboo-et-al-icalendar-in-xml.all@tools.ietf.org" Subject: [secdir] secdir review: draft-daboo-et-al-icalendar-in-xml X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 05:12:23 -0000 --Apple-Mail-26-1057190162 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello all, I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. I find the document be have appropriate security consideration section and have no additional comment. The document should have the same properties as existing documents documenting ical and xml and should from a security perspective not be = so scary. Love --Apple-Mail-26-1057190162 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWjCCBWQw ggRMoAMCAQICEF/yv3iUOGg5xP614ejUMEUwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA0MzAwMDAwMDBaFw0x MjA0MjkyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMR8wHQYDVQQDFBZMb3ZlIEj2cm5xdWlzdCDFc3RyYW5kMRkwFwYJKoZIhvcNAQkBFgpsaGFA a3RoLnNlMIIBIDALBgkqhkiG9w0BAQEDggEPADCCAQoCggEBAOVPH/5M22Cw8ABsUHXKgXPKKxtr UJzfEKUW9a8a8dp+CAtIhVe8pqa+CKtu4l87iiXhgOYOwH4RUahmP9XEa1xkXjQnUeZ9O+RMyZQu 1wCXM5lXzfS0Srtzq2rjD4/l5WJhuw7UsCPKUgqRS81eVejHhiXH5s8ODVTvdh7/sRCT4m5lvqxu jok/Hl5esNnYeHELb76t6mXKOGOCl1T6kMGhbvYQltau0C7xB0ew6IwerbH22OSxyao2MXFOmusU cAsDAcU2teE7x+7atyrO8ex3g8R0ACmTtHL5r+Xg14fctKywgPdKS11ppvhbBTd0fDUBB/ePjOFw 1l+KafRU5AUCAwEAAaOB6DCB5TAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEw KjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMBQGCmCGSAGG+EUBBgcEBhYETm9uZTBQBgNV HR8ESTBHMEWgQ6BBhj9odHRwOi8vaW5kYzFkaWdpdGFsaWQtZzMtY3JsLnZlcmlzaWduLmNvbS9J bmRDMURpZ2l0YWxJRC1HMy5jcmwwDQYJKoZIhvcNAQEFBQADggEBAHD683nJ4SQqs1URlB32Zr62 OggDyFikp74BZj6RZ9uTB+gp/hMhHrN+bkYbW6IgsAOkAXGFFkf48T7LLF2G0r93yBi8ffq6XhzZ 9Ut433u/C/kPbHq4dV+w5cEes3AACO3aNkmSk15bA5NRd1vSorfk4RB+4YaSOq/KdNGpuI0XzIVo iJzyDiVpQkUCwb+DN6ZnkIrpWQaEXWW9bEgOJ7JrHT1gAL6K/q3g8/VbXbNfcTJD4eZtdUTMYu3P vRBfOjmPJcOHU7MZLHxkbsK/GlPnZx+QTxJKVepIkkHELxRRIdgcQ3K5EK1Ff6Ffq0LJMwRqMpbw PaoEzh87HISNvFUwggbuMIIF1qADAgECAhBxFWYFSuSRIU3pvET5rNPcMA0GCSqGSIb3DQEBBQUA MIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9y IGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA1MDEwMDAwMDBaFw0xOTA0 MzAyMzU5NTlaMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtxEffKigdfAZru9chMslsE4/p sY1BTjT32gvjavpliCALERPpm+BJTotv1QHQXw1HkYpaTHQ+P8aRCbtMNJ6NbqGCUWL3aXZYlgev nhQYB09avZ/SMbJUGXNGahlCEewScyGN9dwwzeXZVgoxxTZtKRSXvS3aiUcZiNhLBD3rtjxnHnQA Ew3QhtqTZ/gzA64aPGtpePbALI7hgz93+Zn//p9SWsK0hwrYbKlHwVQpZUM+SsCWH8Gt93evbLEE Xr7BtpQtl5AtJ9K7HumDaoT2xLKuIwZlJqUnWCsHIrRvpmJIGnfy1VAnminTlvso9bokdmLjjFnr +27VQsS+Qcf1AgMBAAGjggK5MIICtTA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEAMHAGA1UdIARpMGcwZQYLYIZI AYb4RQEHFwEwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL2NwczAqBggr BgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1UdHwQtMCswKaAnoCWG I2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEtZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjBuBggr BgEFBQcBDARiMGChXqBcMFowWDBWFglpbWFnZS9naWYwITAfMAcGBSsOAwIaBBRLa7kolgYMu9BS OJsprEsHiyEFGDAmFiRodHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvMS5naWYwLgYDVR0R BCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0OC0xMTgwHQYDVR0OBBYEFHlHYQhB /TgEokvntcz1Q/ZJKxH4MIHxBgNVHSMEgekwgeahgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgG A1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFF MEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFAAOCAQEAOU3PQZmB takFtVI46TmEiWzkNKha59hsCUwkGrpZpIc7cyHxk4HPv2hjWmf+NYUrocNdo0rCOhndMNbMTe/x 0oGXylRaQ783i3qOGY0PQ6iM8q9gsxWKs5WcPOCesyeYpDVyF+X8Kl2H04oNwtFFKvjA9KwqkzrV rhJwCOv7O+J37OgrZDV2zbra4NHLFNZxWJu+1T59ttnoJMUkZkxdkR92sxc+fw3GIYkvsze4of9c sm1J3mVSQvsOiNLtSh2/S+P4zHL6SA5ljknI1viZmDu3lD4xcQaH+mxZUy7X3yvtX2MArBXtA7hV FozGaAPnIqhzC7G8oNpSWN0KDn/BgjGCBIswggSHAgEBMIHyMIHdMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5 BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5 MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNz IDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEF/yv3iUOGg5xP614ejUMEUwCQYFKw4D AhoFAKCCAm0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwNTE5 MDUxMTQ0WjAjBgkqhkiG9w0BCQQxFgQULi6fJDgmnAfqDAArdFu6RxOnYCEwggEDBgkrBgEEAYI3 EAQxgfUwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0Eg LSBHMwIQX/K/eJQ4aDnE/rXh6NQwRTCCAQUGCyqGSIb3DQEJEAILMYH1oIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEF/yv3iUOGg5xP614ejU MEUwDQYJKoZIhvcNAQEBBQAEggEASRyUrcVRArn8MfTWzUyE06Ga3DCVF0NtocHGRabs0qWVbM8v hfx5FH77bJpvVFC3T4q/P9Q1EI9NyWxJc+5qj2MbeDW0ywkbSxPJGrjR0ffEEsDAxvOoJ26YYjXS uUsfp34ihwrd78x/n3qu1BVmPukrGpySd/d3Trc71cR9nHFO2TyQ0irQM0r3Hrd2B62EoF1V2x6L KAkFbRV2Gt3PqFfaRwH59jFYJWQb/B7LsQknrvtAG/1dxHGJ5Gc1lKs7oGtxNt3IhhlniYTrUu8S HJtJXIlU4tfvtgwXE+TUvckwRSlbRnjPCj75+l20XT82BlqGSVuSwu7rptspBcTvFAAAAAAAAA== --Apple-Mail-26-1057190162-- From kent@bbn.com Thu May 19 07:44:16 2011 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 E17E1E07C4; Thu, 19 May 2011 07:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sydkZdW7CEZk; Thu, 19 May 2011 07:44:16 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0C070E075E; Thu, 19 May 2011 07:44:16 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:57968 helo=[207.248.65.214]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QN4SU-00064k-FD; Thu, 19 May 2011 10:44:15 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <427D4174-E04F-4C2B-BBFA-D445A4682601@cisco.com> References: <427D4174-E04F-4C2B-BBFA-D445A4682601@cisco.com> Date: Thu, 19 May 2011 10:42:59 -0400 To: Joe Salowey From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: draft-ietf-sidr-repos-struct.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-ietf-sidr-repos-struct-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 14:44:17 -0000 Joe, I'm not a co-author, but ... >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat >these comments just like any other last call comments. > >In general the draft looks useful, but I think there are a few >things that need to be addressed before publication. > >1. The document asks for a registration for the extension .roa >for Route Origination Authorization, but the discussion of this type >is absent from the rest of the document. good point. the doc should contain a cite of the ROA format I-D. >2. In section 2.2 under certificates it would probably be good to >specify the encoding of the certificate since there are different >encodings in use (DER, Base64,etc). god point, although the same concern applies to CRLs too. DER is the mandated encoding for certs and CRLs when they are signed, but storage encodings do need to be specified. >3. The document is not very specific on what signed objects may >consist of. The security considerations section points out that >the repository itself does not provide integrity protection. The >security considerations section should probably also mention that >confidentiality is also not provided by the repository or by the >signed objects (unless there is some mechanism used to ensure the >confidentiality of the data which would need to be specified) and >that data that requires controlled access should not be included in >signed objects in the repository. A cite of the signed objects I-D should be included, as that addresses you question. Steve From kent@bbn.com Thu May 19 09:34:55 2011 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 E6127E06B8 for ; Thu, 19 May 2011 09:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAAu7Iq-wpM4 for ; Thu, 19 May 2011 09:34:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7E6E069C for ; Thu, 19 May 2011 09:34:54 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49189 helo=[207.248.65.214]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QN6BZ-0001oL-11 for secdir@ietf.org; Thu, 19 May 2011 12:34:53 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 19 May 2011 10:58:06 -0400 To: secdir@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [secdir] SECDIR review of draft-ietf-xcon-ccmp-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 16:34:56 -0000 I previously reviewed and earlier version of this document, and raised a few concerns that dealt with the structure of the secruity considerations section, as well as a few questions about technical security details. Mary Barnes replied to my comments (in March). I am satisfied that her replies, and the changes that have been made to create version 13 of this doc, address all of my comments. Steve From victoriano@uma.es Wed May 18 07:57:18 2011 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 5B08EE06FB; Wed, 18 May 2011 07:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEK6R1JEPZJp; Wed, 18 May 2011 07:57:17 -0700 (PDT) Received: from cartero1.uma.es (unknown [150.214.47.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7F5E06B8; Wed, 18 May 2011 07:57:15 -0700 (PDT) Received: from correo1.uma.es (vesta1.sci.uma.es [192.168.23.8]) by cartero1.uma.es (Postfix) with ESMTP id BBEBB570001; Wed, 18 May 2011 16:57:12 +0200 (CEST) Received: from wifi-eduroam-96.tnc2011.org (wifi-eduroam-96.tnc2011.org [78.128.224.96]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by correo1.uma.es (Postfix) with ESMTP id 722BD6C8B98; Wed, 18 May 2011 16:57:08 +0200 (CEST) Message-ID: <4DD3DE43.7030103@uma.es> Date: Wed, 18 May 2011 16:57:07 +0200 From: Victoriano Giralt User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Chris Lonvick References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Fri, 20 May 2011 08:21:44 -0700 Cc: draft-giralt-schac-ns.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-giralt-schac-ns-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 14:57:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On 7/3/11 22:46, Chris Lonvick wrote: > The only security concern I have is that the registration URN is not yet > active and that it is limited to HTTPS. While I think it is still going > to take some time for this ID to become an RFC, I'd just like to see the > web site set up sooner rather than later so the kinks may be ironed out. This has been a long time on the writing queue, but I wanted to iron out all kinks. > Beyond that, I think that it would be better to state that it will always > be a "secure web site" which will offer credentials signed by such-n-such, > and will require the latest secure methods for accessing a web site; that > currently being http [reference] with the latest TLS transport > [reference]. My issue with this is that "https" can still reference SSLv2 > and I don't think that's the intent of the statement in this ID. > > I don't have any concerns about the Security Considerations section other > than the statement about using "HTTPS" as noted above. I totally agree with you. SSLv2 is a no-no. I had not properly grasped the meaning of your comment and started to think about a domain expert that could help me to address your concerns. With the present formulation I have fully understood your concern, thanks for enlightening this old web dinosaur. > The terms TERENA and TF-EMC2 are used without first defining them. Maybe > some changes in Section 1. Addressed > I think that the second paragraph of the Abstract could use some > polishing. Polished > CML> I see that this paragraph is been duplicated into the Introduction. > I don't think that's necessary. Removed from the intro. > In Section 4, the word "Anyhow" is ambiguous. I'd suggest replacing it > with a more definite word such as "Regardless", or with the term "In any > case". You are right. I've gone for "In any case". > In Section 5, the term "NREN" is not defined before it is used. I'd > suggest: That was changed after other reviewer's comments. > CML> I see that this version does use the term "National Research and > Education Network" but it's not associated with the acronym. I hope the acronym is now associated. > In the third paragraph of Section 5, remove the term "as soon as > practical". ...just get it done. :-) Done. It was suffering the "we have a lot of work, will take care of this once the namespace is granted" syndrome. It is up, though not running in full swing. > Could you add a URL to reference [4]? > > CML> Could you also add a URL for reference [5]? I swear all references have URLs in the XML version, the xml2rf tool eats those references when doing the transformation. They are not had inserted again. > Best regards, > Chris Thank you very much, Victoriano. - -- Victoriano Giralt Systems Manager Central ICT Services University of Malaga SPAIN - - A: Yes. > > Q: Are you sure ? >> >> A: Because it reverses the logical flow of conversation. >>> >>> Q: Why is top posting annoying in email ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFN095DV6+mDjj1PTgRAz+NAJ0expp5KF7EWKG8rZNkHlF5fbqizQCfSJx3 wSmQJfxlnqLloKkcImx0AlE= =sJd/ -----END PGP SIGNATURE----- From simon.perreault@viagenie.ca Thu May 19 06:31:32 2011 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 1A589E0656; Thu, 19 May 2011 06:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TScwLhNi+L2P; Thu, 19 May 2011 06:31:31 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 2A872E066A; Thu, 19 May 2011 06:31:29 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D4A0520D2C; Thu, 19 May 2011 09:31:27 -0400 (EDT) Message-ID: <4DD51BAF.7070505@viagenie.ca> Date: Thu, 19 May 2011 09:31:27 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 20 May 2011 08:21:45 -0700 Cc: apps-review@ietf.org, secdir@ietf.org, iesg@ietf.org, vcarddav@ietf.org, draft-ietf-vcarddav-vcardrev.all@tools.ietf.org Subject: Re: [secdir] secdir/apps-area/last-call review of draft-ietf-vcarddav-vcardrev-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2011 13:31:32 -0000 On 2011-04-18 12:59, Barry Leiba wrote: > ------------------------------ > 3.1. Character Set > > The character set for vCard is UTF-8 as defined in [RFC3629]. There > is no way to override this. It is invalid to specify a different > character set in the "charset" MIME parameter (see Section 10.1). > > This isn't consistent with section 10.1. UTF-8 is an encoding, not a > character set. Section 10.1 says this, in reference to parameters on > the media type: > > "charset": as defined for text/plain [RFC2046]; encodings other > than UTF-8 [RFC3629] MUST NOT be used. > > That is the correct characterization. The problem is that this is > used inconsistently in general, and there's been an extended > controversy in EAI about this very thing. RFC 3536 specifies > internationalization terminology, and that's currently being updated > by draft-hoffman-rfc3536bis. From that document: > > charset > > A charset is a method of mapping a sequence of octets to a > sequence of abstract characters. A charset is, in effect, a > combination of one or more CCSs with a CES. Charset names are > registered by the IANA according to procedures documented in > [RFC2978]. > > Many protocol definitions use the term "character set" in their > descriptions. The terms "charset" or "character encoding scheme" > and "coded character set" are strongly preferred over the term > "character set" because "character set" has other definitions in > other contexts and this can be confusing. > > I suggest re-wording 3.1 thus (and an informative reference to RFC > 3536 would be reasonable): > > NEW > 3.1. Charset > > The charset [see RFC3536 for internationalization terminology] for vCard > is UTF-8 as defined in [RFC3629]. There is no way to override this. It is > invalid to specify a value other than "UTF-8" in the "charset" MIME > parameter (see Section 10.1). Yes, more precise wording is better. Applied verbatim. > ------------------------------ > > 3.3. ABNF Format Definition > > OLD > ; When parsing a content line, folded lines must first > ; be unfolded according to the unfolding procedure > ; described above. > ; When generating a content line, lines longer than 75 > ; characters SHOULD be folded according to the folding > ; procedure described above. > > NEW > ; When parsing a content line, folded lines must first > ; be unfolded according to the unfolding procedure > ; described in section 3.2. > ; When generating a content line, lines longer than 75 > ; characters SHOULD be folded according to the folding > ; procedure described in section 3.2. > > OLD > A line that begins with a white space character is a continuation of > the previous line, as described above. > > NEW > A line that begins with a white space character is a continuation of > the previous line, as described in section 3.2. Applied. > ------------------------------ > > Section 3.3 says this: > Parameter values > MAY be case sensitive or case insensitive, depending on their > definition. Based on experience with vCard 3 interoperability, it is > RECOMMENDED that property and parameter names be upper-case on > output. > > Some of the parameter definitions ("value" (5.2) and "type" (5.6), for > example) use text strings for their values, and give no guidance on > case. I suggest changing the paragraph in section 3.3: > > NEW > Parameter values > MAY be case-sensitive or case-insensitive, depending on their > definitions. Parameter values that are not explicitly defined > as being case-sensitive are case-insensitive. Based on > experience with vCard 3 interoperability, it is RECOMMENDED > that property names and parameter names be upper-case on output. Added. > ------------------------------ > > 3.4. Property Value Escaping > > OLD > Finally, BACKSLASH characters in values MUST be escaped with a > BACKSLASH character. NEWLINE (ASCII decimal 10) characters in values > MUST be encoded by two characters: a BACKSLASH followed by an 'n' > (ASCII decimal 110). > > This is inconsistent with section 4.1. > > NEW > Finally, BACKSLASH characters in values MUST be escaped with a > BACKSLASH character. NEWLINE (ASCII decimal 10) characters in values > MUST be encoded by two characters: a BACKSLASH followed by either an > 'n' (ASCII decimal 110) or an 'N' (ASCII decimal 78). Fixed. > ------------------------------ > > 4.5. INTEGER > > I note that the ABNF allows "-0" (and, in fact, "-00000000") as a > valid integer. If that's intended, that's fine; I just wanted to > point it out. Yeah it looks like it's allowed in XML Schema (not exactly sure though), and I know it's parsed correctly by just about any programming language standard library, so I'd prefer to leave it the way it is. > ------------------------------ > > 5.9. SORT-AS > > Is this parameter value intended to be case-sensitive? I think so, > and that should be specified. Let's fix the "less/fewer" error, while > we're here. > > OLD > This parameter's value is a comma-separated list which MUST have as > many or less elements as the corresponding property value has > components. > > NEW > This parameter's value is a comma-separated list which MUST have as > many or fewer elements as the corresponding property value has > components. This parameter's value is case-sensitive. Fixed. > ------------------------------ > > 6.3.1. ADR > > Special notes: The structured type value consists of a sequence of > address components. The component values MUST be specified in > their corresponding position. The structured type value > corresponds, in sequence, to the post office box; the extended > address (e.g. apartment or suite number); the street address; the > locality (e.g., city); the region (e.g., state or province); the > postal code; the country name (full name in the language specified > in Section 5.1). When a component value is missing, the > associated component separator MUST still be specified. > > SUGGESTION: > I think this would be easier to read and get right as a compact list, > rather than as a paragraph of text. Maybe like this: > > NEW > Special notes: The structured type value consists of a sequence of > address components. The component values MUST be specified in > their corresponding position. The structured type value > corresponds, in sequence, to > the post office box; > the extended address (e.g. apartment or suite number); > the street address; > the locality (e.g., city); > the region (e.g., state or province); > the postal code; > the country name (full name in the language specified in > Section 5.1). > When a component value is missing, the associated component > separator MUST still be specified. Agreed, but I don't know how to create such formatting with xml2rfc. So I just created a regular, non-compact list: Special notes: The structured type value consists of a sequence of address components. The component values MUST be specified in their corresponding position. The structured type value corresponds, in sequence, to * the post office box; * the extended address (e.g. apartment or suite number); * the street address; * the locality (e.g., city); * the region (e.g., state or province); * the postal code; * the country name (full name in the language specified in Section 5.1). When a component value is missing, the associated component separator MUST still be specified. > ------------------------------ > > 8. Example: Authors' vCards > > There's nothing wrong with leaving Pete Resnick's vCard in there as an > example, but I'll point out that he hasn't been a document editor > since -16 was posted. I'll also point out that these are not > "authors", but "editors". Just sayin'.... HA! I'll remove it. It contained an example of the URL property that was not in my vCard, so I just added a URL property to my vCard. > ------------------------------ > > 9. Security Considerations > > I believe the specified security considerations are adequate, and I > have no issues with them. :) > ------------------------------ > > 10.1. MIME Type Registration > > Person & email address to contact for further information: Simon > Perreault > > Section 10.2.1 specifies the creation of a mailing list, > . Perhaps that should be the contact email address > for the MIME type registration as well. Agreed. I put "vCard discussion mailing list ". > ------------------------------ > > 10.2.1. Registration Procedure > > Nit: change "Standard Tracks RFC" to "Standards Track RFC", throughout. Fixed. > ------------------------------ > > That's all.... Thanks a lot! Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From vincent.roca@inrialpes.fr Mon May 23 03:08:41 2011 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 13E25E06E6; Mon, 23 May 2011 03:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olsH5fOKyrSK; Mon, 23 May 2011 03:08:39 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id A0E38E06A7; Mon, 23 May 2011 03:08:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,255,1304287200"; d="scan'208";a="83716137" Received: from unknown (HELO [131.254.253.76]) ([131.254.253.76]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 23 May 2011 12:08:35 +0200 From: Vincent Roca Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 23 May 2011 09:58:17 +0200 Message-Id: To: IESG , secdir@ietf.org, draft-ietf-savi-threat-scope.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [secdir] Secdir review of draft-ietf-savi-threat-scope-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, 23 May 2011 10:08:41 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The security section, though small, provides a good discussion of what can or cannot be expected from the SAVI approach. I appreciate this effort. A few comments: ** The second paragraph explains that identifying the host that originated a packet is not the same as identifying the end user. I agree. It seems to me that the goal of the third paragraph is to further elaborate on the idea that identifying the end user is complex (and sometimes meaningless). However this is not clearly stated. ** It is said (last paragraph): "...source addresses must not be used as an authentication mechanism." I suggest using an uppercase "MUST NOT". ** It is said (last sentence): "The only technique to unquestionably verify source addresses of a received datagram are cryptographic authentication mechanisms such as IPsec." Well, IPsec per se does not check the source address of a packet but provides an authentication service of the remote IPsec entity (e.g. the other IPsec tunnel endpoint). The packet integrity guarranty provided is only limited to the path secured by IPsec and this path may not encompass the effective packet sender. Regards, Vincent From mlepinski@bbn.com Mon May 23 13:47:22 2011 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 BD455E07E0; Mon, 23 May 2011 13:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpMPcSLwDi2N; Mon, 23 May 2011 13:47:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id EEE00E079C; Mon, 23 May 2011 13:47:21 -0700 (PDT) Received: from [128.89.255.131] (port=3431) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QOc25-000J9P-9F; Mon, 23 May 2011 16:47:21 -0400 Message-ID: <4DDAC7F7.10207@bbn.com> Date: Mon, 23 May 2011 16:47:51 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: secdir@ietf.org, iesg@ietf.org, draft-ietf-vcarddav-vcardxml@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review of draft-ietf-vcarddav-vcardxml-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 20:47:22 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines an XML schema for representing a VCARD. The XML representation is semantically equivalent to the text-based format specified in draft-ietf-vcarddav-vcard-rev. In the security considerations section of this document, the authors claim that the security considerations for XML VCARDs are identical to the security considerations for text VCARDs. I agree with the document authors that the translation from text to XML introduces no additional security considerations. Minor Nit: On page 8: "... whose default value is not know MUST be converted using the value type XML element ..." Replace "know" with "known" - Matt Lepinski From clonvick@cisco.com Thu May 26 17:16:19 2011 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 D09E7E07A8; Thu, 26 May 2011 17:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W41IC6g6PWTx; Thu, 26 May 2011 17:16:18 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id E329DE06ED; Thu, 26 May 2011 17:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=586; q=dns/txt; s=iport; t=1306455378; x=1307664978; h=date:from:to:subject:message-id:mime-version; bh=xNZAKKIJENs38r7NWr6cMJlAOtRIM5M+oABsZCrfudo=; b=ZXFkHCPZ/03Fzie1MwItxl9rnrDrqg0zLADwJ2TAjyKXBoAJrTK15yIX 61kH4XK67NV2+Rf8mXhjbojVly6uLpMTBPApReylamH/u57HA7oFXnNHJ eQBUHsKubTffhH9rRyBzHUIeeKaZjWqaGOqMhCxaB/3PYSm5i5LXzOvlj g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokFAOns3k2rRDoJ/2dsb2JhbABUmCkBjgt4p2edY4YcBIZhmQg X-IronPort-AV: E=Sophos;i="4.65,277,1304294400"; d="scan'208";a="324524123" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 27 May 2011 00:16:17 +0000 Received: from sjc-cde-032.cisco.com (sjc-cde-032.cisco.com [171.69.29.20]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4R0GHu6024303; Fri, 27 May 2011 00:16:17 GMT Date: Thu, 26 May 2011 17:16:17 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-giralt-schac-ns-05.all@tools.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [secdir] SECDIR review of draft-giralt-schac-ns-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: Fri, 27 May 2011 00:16:20 -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. As Victoriano noted in his response to my last review, all issues that I raised have been addressed. I am satisfied with the quality and integrity of this document and feel that it is ready for publication. :-) Best regards, Chris From clonvick@cisco.com Thu May 26 17:33:10 2011 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 89550E0739; Thu, 26 May 2011 17:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sXHBD-I9lAX; Thu, 26 May 2011 17:33:09 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id DD4EBE0697; Thu, 26 May 2011 17:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=911; q=dns/txt; s=iport; t=1306456389; x=1307665989; h=date:from:to:subject:in-reply-to:message-id:references: mime-version; bh=UN+sfL20/RCMAOPNag0JwtzwrbqVjeeuRFA6msZ4C7Q=; b=el9jNrKvPJ88zD5DhMWKzZvPYydOjWDnt2vbYCxMnYenJUTeCvAWutpc 9QmpVLudxjI970NOgCXTrrQlKh47hyMF/MzVEvQUSKzC7QLzAUOYLLau6 qSOKxYR976h35sueh5A5murGhIVW63UhH7/KhNUw5NzJwMjw5pDedIgKa w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMHw3k2rRDoH/2dsb2JhbABUpjV4iHCfEp1fhhwEhmGZCA X-IronPort-AV: E=Sophos;i="4.65,277,1304294400"; d="scan'208";a="365158088" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 27 May 2011 00:33:08 +0000 Received: from sjc-cde-032.cisco.com (sjc-cde-032.cisco.com [171.69.29.20]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4R0X80I002074; Fri, 27 May 2011 00:33:08 GMT Date: Thu, 26 May 2011 17:33:08 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, draft-giralt-schac-ns.all@tools.ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [secdir] SECDIR review of draft-giralt-schac-ns-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: Fri, 27 May 2011 00:33:10 -0000 Bahh.. I keep forgetting to leave the "-NN" off of the .all@tools.ietf.org list. Regards, Chris On Thu, 26 May 2011, Chris Lonvick wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > As Victoriano noted in his response to my last review, all issues that I > raised have been addressed. > > I am satisfied with the quality and integrity of this document and feel that > it is ready for publication. :-) > > Best regards, > Chris > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > > From clonvick@cisco.com Fri May 27 04:06:23 2011 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 5410FE069A; Fri, 27 May 2011 04:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPlp5FW8iUf3; Fri, 27 May 2011 04:06:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id AD839E0688; Fri, 27 May 2011 04:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=clonvick@cisco.com; l=1474; q=dns/txt; s=iport; t=1306494382; x=1307703982; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=wyEdtNUGstsfn04Q7sIDn9uidwMki0roA23dd5ivJaQ=; b=YeZEJZ4a17zs5u0AVrPddktfECwpPVs+ph96q+wP33Evth3bm3vCskRR D9jGe0yFOZj56tSQtDXKyP6/wJccXKGdNYQs3MYsNEQn6IYg2zNunS0S+ hOATpdz06FT9VvrBFQ48W3jTgAj+oNnqJR3TwTfPe0oboSzsqxhIAPqrw 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAmF302rRDoJ/2dsb2JhbABUEKYmd4hwnX6dZ4YeBIZjmEBV X-IronPort-AV: E=Sophos;i="4.65,279,1304294400"; d="scan'208";a="455384838" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 27 May 2011 11:06:19 +0000 Received: from sjc-cde-032.cisco.com (sjc-cde-032.cisco.com [171.69.29.20]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4RB6JZM016834; Fri, 27 May 2011 11:06:19 GMT Date: Fri, 27 May 2011 04:06:16 -0700 (PDT) From: Chris Lonvick To: Simon Josefsson , secdir-secretary@mit.edu In-Reply-To: <87liy4se5s.fsf@latte.josefsson.org> Message-ID: References: <87liy4se5s.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: draft-josefsson-gss-capsulate.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] SECDIR review of draft-josefsson-gss-capsulate-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 11:06:23 -0000 Hi Simon, I like it. :-) Hopefully we can get ahead of a request for re-review and I can add my comments about the -05 version here: I find the document to be of good quality and recommend that it be published. Regards, Chris On Wed, 18 May 2011, Simon Josefsson wrote: > Hi Chris, > > Thanks for review! I agree with all your suggestions, and have > published -05 that should address them. Please verify. > > /Simon > > Chris Lonvick writes: > >> Hi, >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> Overall, I find the document to be of good quality and ready to progress. >> >> One editorial suggestion I'd make would be to either include or >> directly reference the security section of RFC 2743 in your own >> security considerations section. >> >> Also, I'm just not partial towards the use of "otherwise" to describe >> a return code from gss_oid_equal. Personally, I think it should be >> directly specified. >> >> Finally, I think you have a formatting inconsistency in Section 4.1; >> the "otherwise" should be tabbed out to line up in the other column. >> >> Regards, >> Chris > From kivinen@iki.fi Fri May 27 05:08:41 2011 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 1E60BE070E; Fri, 27 May 2011 05:08:41 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+5I2DFlzy1J; Fri, 27 May 2011 05:08:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0B4E068F; Fri, 27 May 2011 05:08:39 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p4RC8Zgp014658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 May 2011 15:08:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p4RC8X3M021721; Fri, 27 May 2011 15:08:33 +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: <19935.37953.301024.987227@fireball.kivinen.iki.fi> Date: Fri, 27 May 2011 15:08:33 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 9 min Cc: draft-ietf-xcon-common-data-model.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-xcon-common-data-model-27.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 12:08:41 -0000 This is re-review of the draft I already reviewed at 2011-03-03. The current draft contains some small changes done since, but I do not think it solves the issues I raised in my previous review: 1) The confidentiality is not mandatory even in the cases where the database contains sensitive elements (passwords), it is only SHOULD. 2) The privacy issues is not covered enough. The current version added specific pointer to the section 11.2 of RFC5239, but that only covers one very small privacy issue, i.e. anonymous access. It does not cover gathering sensitive privacy information in the database, i.e. who participated which conferences and with whom. My previous review can be found in http://www.ietf.org/mail-archive/web/secdir/current/msg02482.html -- kivinen@iki.fi From kivinen@iki.fi Fri May 27 06:11:19 2011 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 77C7AE07CF; Fri, 27 May 2011 06:11: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL2tH3U9yhVR; Fri, 27 May 2011 06:11:18 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185EBE072E; Fri, 27 May 2011 06:11:17 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p4RDBCXr018662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 May 2011 16:11:12 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p4RDBBUI028481; Fri, 27 May 2011 16:11:11 +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: <19935.41711.849950.705575@fireball.kivinen.iki.fi> Date: Fri, 27 May 2011 16:11:11 +0300 From: Tero Kivinen To: Oscar Novo In-Reply-To: <58E207308662A748A4AC1ECB4E8856140815CDED51@ESESSCMS0355.eemea.ericsson.se> References: <19935.37953.301024.987227@fireball.kivinen.iki.fi> <58E207308662A748A4AC1ECB4E8856140815CDED51@ESESSCMS0355.eemea.ericsson.se> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 13 min Cc: "draft-ietf-xcon-common-data-model.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Review of draft-ietf-xcon-common-data-model-27.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 13:11:19 -0000 Oscar Novo writes: > 1) The confidentiality is not mandatory even in the cases where the > database contains sensitive elements (passwords), it is only > SHOULD. > > [ON] In the new version of the draft (28) I have changes the text a bit: > > "The confidentiality of the database SHOULD be protected from > unauthorized users, given that the data model contains a set of > sensitive elements (e.g., passwords), and it is RECOMMENDED the > database uses encryption mechanisms if the information is stored in > long term storage (e.g., disk)." I would think that SHOULD (or MAY) is ok if there is no sensitive elements in the database, but if the database actually do contain sensitive elements like password do you really think confidentiality is not needed? If so in which scenarios it would be ok to not use confidentiality and not protect the sensitive data from unauthorized users? Saying that data SHOULD be encrypted when stored to the disk is actually ok, as I do think SHOULD is acceptable there, as I can see several valid scenarios where the long term storage access can be secure enough that encryption is not needed. I do not see any real scnearios where unauthorized users needs to given access to the sensitive elements. > 2) The privacy issues is not covered enough. The current version added > specific pointer to the section 11.2 of RFC5239, but that only > covers one very small privacy issue, i.e. anonymous access. It does > not cover gathering sensitive privacy information in the database, > i.e. who participated which conferences and with whom. > > [ON] We don't think this document should solve questions as "who > participated which conferences and with whom?". And in the working > group was agree to leave the policy outside this document for future > documents. I do not think there is really problem to solve, but I think by nature this database will have such information, and that information might be stored to long term storage. I.e. if someone makes conferences about the "human rights problems in country X", and invites people to participate such conference, then that information is stored to the database. By keeping that information in database this database now contains sensitive privacy information, which is not pointed out in this draft. I think security considerations section should point out that some information stored in the data model might be sensitive in addition to obious things like passwords and identity of the anonymoys users. This may include the information about identities of the people participating specific conferences or who is communicating with who (i.e. telecommuniations data retentation: http://en.wikipedia.org/wiki/Telecommunications_data_retention). The current data model for example is quite vague about how long the information is stored. I.e. how long will the list of participants given in the system. When will it be deleted etc. If this only assumes that all information only covers the currently on-going events then that is good, but in most cases I think some information might be stored before the event even starts etc. I do not think there is need to modify the actual data model, more likely point out that there might be issues there which some people might not even see immediately (as can be seen how hard it has been for me to try to express what my concern is). -- kivinen@iki.fi From oscar.novo@ericsson.com Fri May 27 05:46:50 2011 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 D86F6E07C9; Fri, 27 May 2011 05:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lOHcmr18ina; Fri, 27 May 2011 05:46:50 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A689BE0786; Fri, 27 May 2011 05:46:49 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ff-4ddf9d389723 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F1.69.20773.83D9FDD4; Fri, 27 May 2011 14:46:48 +0200 (CEST) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.1.151]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 27 May 2011 14:46:48 +0200 From: Oscar Novo To: Tero Kivinen , "iesg@ietf.org" , "secdir@ietf.org" Date: Fri, 27 May 2011 14:46:47 +0200 Thread-Topic: Review of draft-ietf-xcon-common-data-model-27.txt Thread-Index: AcwcZtxeUrDOGf+5SyWl2w+gF7dnXAABEzpQ Message-ID: <58E207308662A748A4AC1ECB4E8856140815CDED51@ESESSCMS0355.eemea.ericsson.se> References: <19935.37953.301024.987227@fireball.kivinen.iki.fi> In-Reply-To: <19935.37953.301024.987227@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Fri, 27 May 2011 06:34:01 -0700 Cc: "draft-ietf-xcon-common-data-model.all@tools.ietf.org" Subject: Re: [secdir] Review of draft-ietf-xcon-common-data-model-27.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2011 12:46:51 -0000 Hi Tero, Comment inline:=20 -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: 27. toukokuuta 2011 15:09 To: iesg@ietf.org; secdir@ietf.org Cc: draft-ietf-xcon-common-data-model.all@tools.ietf.org Subject: Review of draft-ietf-xcon-common-data-model-27.txt This is re-review of the draft I already reviewed at 2011-03-03. The curren= t draft contains some small changes done since, but I do not think it solve= s the issues I raised in my previous review: 1) The confidentiality is not mandatory even in the cases where the database contains sensitive elements (passwords), it is only SHOULD. [ON] In the new version of the draft (28) I have changes the text a bit: "The confidentiality of the database SHOULD be protected from unauthorized users, given that the data model contains a set of sensitive elements (e.g., passwords), and it is RECOMMENDED the database uses encryption mechanisms if the information is stored in long term storage (e.g., disk)."=20 2) The privacy issues is not covered enough. The current version added specific pointer to the section 11.2 of RFC5239, but that only covers one very small privacy issue, i.e. anonymous access. It does not cover gathering sensitive privacy information in the database, i.e. who participated which conferences and with whom. [ON] We don't think this document should solve questions as "who participat= ed which conferences and with whom?". And in the working group was agree to= leave the policy outside this document for future documents.=20 My previous review can be found in http://www.ietf.org/mail-archive/web/secdir/current/msg02482.html -- kivinen@iki.fi From jason_livingood@cable.comcast.com Sun May 29 11:44:27 2011 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 79904E0736; Sun, 29 May 2011 11:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.436 X-Spam-Level: X-Spam-Status: No, score=-108.436 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8GHfs7PSXCH; Sun, 29 May 2011 11:44:26 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9A93EE0679; Sun, 29 May 2011 11:44:25 -0700 (PDT) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.127904555; Sun, 29 May 2011 14:44:22 -0400 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0289.001; Sun, 29 May 2011 14:44:21 -0400 From: "Livingood, Jason" To: Russ Mundy , "secdir@ietf.org" Thread-Topic: secdir review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 Thread-Index: AQHMCTn9fR3di036FkigKoxmcb9XeZSkTl2A Date: Sun, 29 May 2011 18:44:21 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [24.40.55.70] Content-Type: multipart/alternative; boundary="_000_CA080B2E28969jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 29 May 2011 12:18:43 -0700 Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-v6-aaaa-whitelisting-implications.all@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 18:44:27 -0000 --_000_CA080B2E28969jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for your review, Russ. I'll be posting an updated =9604 revision soo= n, once I make it through all the bits of other feedback in my queue. Some = specific responses are inline below. Thank you! JL On 5/2/11 3:58 PM, "Russ Mundy" > 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 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 any= other last call comments. I found the document to be well written as well as providing sound technica= l descriptions of the topic of DNS Whitelisting. >From a security review perspective, I do have a suggestion for section 10 S= ecurity Considerations. The section infers (at least to me) that there is = something different or unique for configuring DNS Whitelist configuration p= rotection from other configuration settings for name servers. Unless I've = misunderstood how servers actually implement whitelisting, it uses the same= configuration mechanisms and files as any other name server ACL or many ot= her name server configuration settings - _all_ the configuration settings f= or a name server should be protected so that only authorized individuals ca= n change them. Modifying the wording to say something to the effect of "Ju= st as all configuration settings for name servers should be protected by ap= propriate procedures and systems ..." [JL] Great suggestion =97 and that has been added to the upcoming update. Russ Mundy --_000_CA080B2E28969jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <879C5D45CCCA6D44B1EA095AED59746F@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
Thanks for your review, Russ. I'll be posting an updated =9604 revisio= n soon, once I make it through all the bits of other feedback in my queue. = Some specific responses are inline below.

Thank you!
JL

On 5/2/11 3:58 PM, "Russ Mundy" <mundy@tislabs.com> wrote:


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

I found the document to be well written as well as providing sound tec= hnical descriptions of the topic of DNS Whitelisting.  

From a security review perspective, I do have a suggestion for section= 10 Security Considerations.  The section infers (at least to me)= that there is something different or unique for configuring DNS Whitelist = configuration protection from other configuration settings for name servers.  Unless I've misunderstood how server= s actually implement whitelisting, it uses the same configuration mechanism= s and files as any other name server ACL or many other name server configur= ation settings - _all_ the configuration settings for a name server should be protected so that only authorized individuals = can change them.  Modifying the wording to say something to the e= ffect of "Just as all configuration settings for name servers should b= e protected by appropriate procedures and systems ..."

[JL] Great suggestion =97 and that has been added to the upcoming upda= te. 



Russ Mundy



--_000_CA080B2E28969jasonlivingoodcablecomcastcom_-- From weiler+secdir@watson.org Tue May 31 08:52:37 2011 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 AC8E4E07D6 for ; Tue, 31 May 2011 08:52:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-KL4LrOwGVo for ; Tue, 31 May 2011 08:52:33 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 992ECE0755 for ; Tue, 31 May 2011 08:52:33 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id p4VFqWfZ082591 for ; Tue, 31 May 2011 11:52:32 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id p4VFqW82082588 for ; Tue, 31 May 2011 11:52:32 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 31 May 2011 11:52:32 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 31 May 2011 11:52:32 -0400 (EDT) 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: Tue, 31 May 2011 15:52:37 -0000 There are several new assignments scheduled for the telechat next week. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Paul Hoffman is next in the rotation. For telechat 2011-06-09 Reviewer LC end Draft Derek Atkins T 2011-06-03 draft-ietf-tcpm-persist-04 Rob Austein T 2011-06-06 draft-faltstrom-5892bis-04 Richard Barnes T 2011-06-09 draft-ietf-dnsext-dnssec-registry-fixes-08 Dave Cridland T 2011-06-06 draft-ietf-sieve-external-lists-09 Alan DeKok T 2011-06-08 draft-ietf-pppext-trill-protocol-06 Ondrej Sury T 2011-05-18 draft-ietf-ccamp-gmpls-vcat-lcas-13 Sam Weiler T 2011-06-01 draft-ietf-dhc-duid-uuid-03 Brian Weis T 2011-06-01 draft-ietf-dhc-dhcpv6-relay-supplied-options-06 Larry Zhu T 2011-05-26 draft-ietf-mpls-mp-ldp-reqs-08 For telechat 2011-06-23 Reviewer LC end Draft Alan DeKok TR2011-06-22 draft-ohba-pana-relay-03 Last calls and special requests: Reviewer LC end Draft Uri Blumenthal 2011-06-06 draft-ietf-sipcore-location-conveyance-08 Alan DeKok 2011-02-23 draft-ietf-isis-reg-purge-01 Donald Eastlake 2011-06-03 draft-ietf-behave-ftp64-10 Shawn Emery 2011-06-06 draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01 Tobias Gondrom 2011-06-03 draft-ietf-dime-ikev2-psk-diameter-06 Phillip Hallam-Baker 2011-06-14 draft-ietf-dime-local-keytran-10 Steve Hanna 2011-06-09 draft-ietf-dnsext-rfc2672bis-dname-22 Dan Harkins 2011-06-10 draft-ietf-pcn-cl-edge-behaviour-08 Sam Hartman 2011-06-10 draft-ietf-pcn-sm-edge-behaviour-05 Catherine Meadows R2011-04-13 draft-ietf-speechsc-mrcpv2-24 Tim Polk 2011-05-11 draft-ietf-vrrp-unified-mib-09 Stefan Santesson 2011-05-18 draft-ietf-sidr-keyroll-06 Tina TSOU 2011-04-23 draft-shin-augmented-pake-06 Carl Wallace 2011-05-30 draft-ietf-mpls-p2mp-lsp-ping-16 Nico Williams 2011-05-26 draft-ietf-dkim-mailinglists-10 Tom Yu 2011-05-30 draft-ietf-l3vpn-ibgp-07 Kurt Zeilenga 2011-05-30 draft-ietf-mpls-lsp-ping-enhanced-dsmap-09 Glen Zorn 2011-06-28 draft-li-pwe3-ms-pw-pon-03 From paul.hoffman@vpnc.org Tue May 31 11:55:05 2011 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 3CF9BE0761 for ; Tue, 31 May 2011 11:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HAXSc93IYrq for ; Tue, 31 May 2011 11:55: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 DE802E066A for ; Tue, 31 May 2011 11:55:03 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p4VIt0k1063907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 May 2011 11:55:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <19935.37953.301024.987227@fireball.kivinen.iki.fi> Date: Tue, 31 May 2011 11:55:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0821F1E5-4020-492D-BA08-64D71B5203A3@vpnc.org> References: <19935.37953.301024.987227@fireball.kivinen.iki.fi> To: secdir X-Mailer: Apple Mail (2.1084) Cc: carlsonj@workingcode.com Subject: [secdir] Review of draft-ietf-pppext-trill-protocol 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, 31 May 2011 18:55:05 -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 = ADs. Document editors and WG chairs should treat these comments just = like any other last call comments. This document describes how PPP can support TRILL. The security = considerations section of this very short document says, in essence, = that there are innumerable security considerations brought into play by = the layering interactions between PPP and IS-IS, and that seems about = right. I do not see any particular new security considerations for this = particular mixture of the two. --Paul Hoffman