From nobody Fri Apr 4 06:50:00 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCCE1A0192 for ; Fri, 4 Apr 2014 06:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN_bmlSjrc7V for ; Fri, 4 Apr 2014 06:49:55 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0084.outbound.protection.outlook.com [213.199.154.84]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5D21A018B for ; Fri, 4 Apr 2014 06:49:54 -0700 (PDT) Received: from DBXPRD0610HT005.eurprd06.prod.outlook.com (157.56.252.181) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.913.9; Fri, 4 Apr 2014 13:49:49 +0000 Message-ID: <00ed01cf500c$85241dc0$4001a8c0@gateway.2wire.net> From: t.petch To: Sandra Murphy , References: <24B20D14B2CD29478C8D5D6E9CBB29F694A07932@HSV-MB001.huntsville.ads.sparta.com> <030d01cf3d4e$cb933780$4001a8c0@gateway.2wire.net> Date: Fri, 4 Apr 2014 14:37:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.181] X-ClientProxiedBy: DBXPR07CA019.eurprd07.prod.outlook.com (10.141.8.177) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 01713B2841 X-Forefront-Antispam-Report: =?iso-8859-1?Q?SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(51704005)?= =?iso-8859-1?Q?(13464003)(189002)(377454003)(24454002)(47776003)(20776003?= =?iso-8859-1?Q?)(63696002)(77096001)(49866001)(47736001)(23756003)(509860?= =?iso-8859-1?Q?01)(44736004)(69226001)(76786001)(76796001)(47976001)(4396?= =?iso-8859-1?Q?001)(50226001)(99396002)(80022001)(66066001)(65816001)(809?= =?iso-8859-1?Q?76001)(14496001)(77156001)(50466002)(74876001)(77982001)(5?= =?iso-8859-1?Q?9766001)(98676001)(74706001)(83322001)(44716002)(90146001)?= =?iso-8859-1?Q?(62236002)(89996001)(62966002)(56816005)(92566001)(9494600?= =?iso-8859-1?Q?1)(85852003)(83072002)(61296002)(93916002)(88136002)(86362?= =?iso-8859-1?Q?001)(74662001)(74502001)(84392001)(47446002)(31966008)(954?= =?iso-8859-1?Q?16001)(85306002)(33646001)(53806001)(46102001)(42186004)(5?= =?iso-8859-1?Q?1856001)(94316002)(95666003)(87286001)(87266001)(195804050?= =?iso-8859-1?Q?01)(81342001)(93516002)(19580395003)(74366001)(79102001)(8?= =?iso-8859-1?Q?7976001)(76482001)(97186001)(56776001)(97336001)(54316002)?= =?iso-8859-1?Q?(81542001)(92726001)(93136001)(74416001)(7726001)(2101003)?= =?iso-8859-1?Q?;DIR:OUT;SFP:1101;SCL:1;SRVR:DB3PR07MB060;H:DBXPRD0610HT00?= =?iso-8859-1?Q?5.eurprd06.prod.outlook.com;FPR:883EF140.2F2F80F4.DFFF9F4F?= =?iso-8859-1?Q?.58E4ADE8.201AD;MLV:nov;PTR:InfoNoRecords;A:0;MX:1;LANG:en?= =?iso-8859-1?Q?;?= Received-SPF: None (: btconnect.com does not designate permitted sender hosts) X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/LTIzhvSj0MHjdMxNMRgv1IgEZ1Y Subject: Re: [sidr] IETF89 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 13:49:59 -0000 ----- Original Message ----- From: "Sandra Murphy" To: Cc: "Sandra Murphy" ; "t.petch" Sent: Friday, March 28, 2014 8:55 PM There were indeed two copies of the "Rsync considered harmful" slides, which was corrected easily. But I noticed no lacking presentations and I've not heard back from Tom. So unless someone can point to what is lacking, I'll consider this closed. Sandy Apologies, my mistake. As you say, two presentations had no slides and I had thought that one of them did. Tom Petch --Sandy On Mar 11, 2014, at 1:09 PM, t.petch wrote: > Sandy > > In the meeting materials for IETF89 for SIDR, 'Rsync considered harmful' > appears twice - probably about right! - but other presentations are > lacking. Can you fix, please? > > Tom Petch > > ----- Original Message ----- > From: "Murphy, Sandra" > To: > Sent: Friday, March 07, 2014 3:07 AM > /listinfo/sidr > From nobody Fri Apr 4 07:06:34 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999271A0195; Fri, 4 Apr 2014 07:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uk_f_jLNfI87; Fri, 4 Apr 2014 07:06:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D94721A014E; Fri, 4 Apr 2014 07:06:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140404140627.26110.44478.idtracker@ietfa.amsl.com> Date: Fri, 04 Apr 2014 07:06:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/IXzTUEM9SjrKkSb6_0RD-ZO6WRI Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-rfc6810-bis-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 14:06:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The Resource Public Key Infrastructure (RPKI) to Router Protocol Authors : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-rfc6810-bis-01.txt Pages : 30 Date : 2014-04-04 Abstract: In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-rtr-rfc6810-bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 4 07:16:06 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E881A01A5 for ; Fri, 4 Apr 2014 07:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idnOsVFupSdk for ; Fri, 4 Apr 2014 07:15:59 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3079B1A014E for ; Fri, 4 Apr 2014 07:15:59 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id B4F707304F for ; Fri, 4 Apr 2014 14:15:53 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 52F37171C5 for ; Fri, 4 Apr 2014 10:15:53 -0400 (EDT) Date: Fri, 04 Apr 2014 10:15:53 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <20140404140627.26110.44478.idtracker@ietfa.amsl.com> References: <20140404140627.26110.44478.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.4 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140404141553.52F37171C5@thrintun.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/6fb2dLCcsRapu7z-3RwcksBB9Xg Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-rfc6810-bis-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 14:16:04 -0000 This version includes the proposed change to the format of the Router Key PDU. The new format holds exactly one ASN per PDU, thus requiring multiple PDUs in the case where a single key is bound to more than one ASN. Inelegant, but simplifies the protocol semantics. Several minor changes originally slated for -01 were overtaken by the above (eg, the entire discussion about ordering of ASNs within a PDU becomes moot when there can be only one). Diffs from previous versions: http://subvert-ietf.hactrn.net/sidr-rpki-rtr-bis/draft-ietf-sidr-rpki-rtr-rfc6810-bis-01-from-00.diff.html http://subvert-ietf.hactrn.net/sidr-rpki-rtr-bis/draft-ietf-sidr-rpki-rtr-rfc6810-bis-01-from-rfc6810.diff.html From nobody Fri Apr 4 08:41:21 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837091A021E for ; Fri, 4 Apr 2014 08:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExeOuire6CYR for ; Fri, 4 Apr 2014 08:41:15 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.59.2]) by ietfa.amsl.com (Postfix) with ESMTP id B01C81A0152 for ; Fri, 4 Apr 2014 08:41:15 -0700 (PDT) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 23CE4E311822; Fri, 4 Apr 2014 10:41:11 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway06.websitewelcome.com (Postfix) with ESMTP id EBDF2E3117C6 for ; Fri, 4 Apr 2014 10:41:10 -0500 (CDT) Received: from [96.231.225.192] (port=51239 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1WW6Ev-0008CM-3o; Fri, 04 Apr 2014 10:41:09 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Sean Turner In-Reply-To: <530B7657.10806@bbn.com> Date: Fri, 4 Apr 2014 11:41:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <965AC70C-983A-4C9F-B555-4C5A7AAD3F91@ieca.com> References: <20140221233023.4ABC9170A4@thrintun.hactrn.net> <530B7657.10806@bbn.com> To: Stephen Kent , Rob Austein X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1WW6Ev-0008CM-3o X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:51239 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/v6SKa43eF8MO2-K5mLtJ0RZ6Gp4 Cc: sidr@ietf.org Subject: Re: [sidr] Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 15:41:19 -0000 On Feb 24, 2014, at 11:41, Stephen Kent wrote: > Rob, >=20 > Good catch. >> Obscure little conflict that only an implementor would notice: = there's >> a three-way conflict between the current rtr-keying draft, the = current >> bgpsec-pki-profile draft, and the base RPKI certificate profile RFC. >>=20 >> The problem is with router-ids and the subject field in the PKCS #10 >> request. >>=20 >> - draft-ietf-sidr-bgpsec-pki-profiles-06 3.1.1.1 (talking about >> certificates, not certificate requests) says router certificate >> names SHOULD be /commonName=3DROUTER-aaaaaaaa/serialNumber=3Drrrrrrrr= , >> where aaaaaaaa is the ASN and rrrrrrrr is the router-id, as 32-bits >> hex in both cases. OK, fine. >>=20 >> As far as I can tell, this is the only way in which the router-id = is >> encoded anywhere in the certificate. > yep. >> - draft-ietf-sidr-bgpsec-pki-profiles-06 3.2 says that the = certificate >> request profile matches RFC 6487 with a few specific differences, >> none of which have anything to do with subject names. > yep. >> - draft-ietf-sidr-rtr-keying-04 3.1 says that when a router is >> generating keys, it includes the router-id in the PKCS #10. > this seems to be the place where there is an error, given you = observation re 6487, 6.1.1. >> Given that the only place we have to encode the router-id is in the >> subject name (as opposed to, say, a newly-defined X.509v3 >> extension), this text would seem to imply that the PKCS #10 = includes >> a non-empty Subject field. >> - RFC 6487 6.1.1 says that the Subject field of the PKCS #10 MUST be >> absent or empty except when requesting reissuance of an existing = key >> and even then only if the CA's CPS allows reusing subject names. >>=20 >> I see no way to reconcile all of this without changing something. > a router cert is issued by an ISP to one if its routers. it's not = clear to > me that a PKCS #10 request is strictly required for this, as it is a = local process > within an AS. But, if one does use PKCS #10 then a CA operating within = an > AS context can probably determine the ID of the router making the = request. > I suggest this mismatch ought to be addressed in the rtr keying I-D. Finally getting back around to this. Two points I think need to be made: 1. Can you omit the subject name from a PKCS#10? I don=92t think so. The syntax for PKCS#10 is [1]: CertificationRequestInfo ::=3D SEQUENCE { version INTEGER { v1(0) } (v1,...), subject Name, subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, attributes [0] Attributes{{ CRIAttributes }} } Note there=92s no =93OPTIONAL=94 after Name. It could be pretty easily = argued that completely omitting the field would result in a = non-interoperable certificate request; that is a certificate request = that CAs might choke on because at a minimum they=92re expecting a NULL = subject name. Based on this I think the text in RFC 6487 might need to = be tweaked based on not being able to omit subject from PKCS#10: OLD: Subject This field MAY be omitted. If present, the value of this field SHOULD be empty (i.e., NULL), in which case the CA MUST generate a subject name that is unique in the context of certificates issued by this CA. NEW: Subject This field is mandatory and MUST be included; however, the value of this field SHOULD be empty (i.e., NULL), in which case the CA MUST generate a subject name that is unique in the context of certificates issued by this CA. 2. Is rtr-keying correct in stating the following in s3.1 because the = text there is about initial provisioning not rekey/renewal and it = contradicts the 2nd sentence about subject in RFC 6847? s3.1 rtr-keying: =85 to generate the PKCS#10 request that includes the router number = and public key ... s6.1 RFC 6487: This field is allowed to be non-empty only for a re-key/reissuance request, and only if the CA has adopted a policy (in its Certificate Practice Statement (CPS)) that permits reuse of names in these circumstances. I=92m wondering how the router is going to know what value to use. I = suspect its only going to know what value to use after it has been told = the value :) Not including a router # in the request is probably okay = if the request comes through the CLI session the operator is using to = talk to the router because it can capture the request and "tag it" in = someway to know what name ought to go in the subject field of the issued = certificate. But, say the CLI session isn=92t used and the router uses = its network connectivity to communicate with the CA. If there=92s no = name in the request, how will the CA know what name to include in the = issued certificate? Seems to me like for that scenario, we=92d actually = want the subject name present in the PKCS#10. Thoughts? spt [1] http://datatracker.ietf.org/doc/rfc2986/= From nobody Fri Apr 4 10:13:08 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1441A0211 for ; Fri, 4 Apr 2014 10:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuj573NMhvGX for ; Fri, 4 Apr 2014 10:13:00 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by ietfa.amsl.com (Postfix) with ESMTP id AB16F1A0227 for ; Fri, 4 Apr 2014 10:12:59 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 44D5A7304F for ; Fri, 4 Apr 2014 17:12:54 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id E2CF21721C for ; Fri, 4 Apr 2014 13:12:53 -0400 (EDT) Date: Fri, 04 Apr 2014 13:12:53 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <965AC70C-983A-4C9F-B555-4C5A7AAD3F91@ieca.com> References: <20140221233023.4ABC9170A4@thrintun.hactrn.net> <530B7657.10806@bbn.com> <965AC70C-983A-4C9F-B555-4C5A7AAD3F91@ieca.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.4 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20140404171253.E2CF21721C@thrintun.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/UNYyrE2hb3LQwh5G9w1dYP3iruo Subject: Re: [sidr] Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 17:13:05 -0000 At Fri, 4 Apr 2014 11:41:06 -0400, Sean P Turner wrote: >=20 > Finally getting back around to this. >=20 > Two points I think need to be made: >=20 > 1. Can you omit the subject name from a PKCS#10? >=20 > I don t think so. The syntax for PKCS#10 is [1]: >=20 > CertificationRequestInfo ::=3D SEQUENCE { > version INTEGER { v1(0) } (v1,...), > subject Name, > subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, > attributes [0] Attributes{{ CRIAttributes }} > } >=20 > Note there s no OPTIONAL after Name. It could be pretty easily > argued that completely omitting the field would result in a > non-interoperable certificate request; that is a certificate request > that CAs might choke on because at a minimum they re expecting a > NULL subject name. I agree. One might reasonably wonder why none of the existing implementations are choking on this. The answer appears to be that we are all quietly violating RFC 6487 on this point and nobody noticed. Oops. - My up-down client (which is, I think, the only client against which all of the up-down servers have been tested) includes a subject name in the PKCS #10 request, more by accident than by intent -- since, until router certificates came along, subject names in RPKI certificates were meaningless by design, the internal API constructs appropriate meaningless subject names as needed when the caller doesn't supply them, and I forgot to disable this for the specific case of PKCS #10 requests in the up-down protocol. - The fact that this has never caused an interoperability problem strongly suggests that none of the servers are checking for this (meaningless) subject name in the PKCS #10. I've confirmed that mine doesn't check: I do check all the required and forbidden extensions and so forth, but completely ignore the incoming PKCS #10 subject name (ie, neither check it nor use it for anything later). =20 I haven't done a code dive on any of the other implementations, but behavior on the wire to date suggests that we all ignore the subject name that RFC 6487 says should not be there. So, again: oops. But this does tend to support your analysis. > Based on this I think the text in RFC 6487 might need to be tweaked > based on not being able to omit subject from PKCS#10: >=20 > OLD: >=20 > Subject > This field MAY be omitted. If present, the value of this field > SHOULD be empty (i.e., NULL), in which case the CA MUST > generate a subject name that is unique in the context of > certificates issued by this CA. >=20 > NEW: >=20 > Subject > This field is mandatory and MUST be included; however, > the value of this field > SHOULD be empty (i.e., NULL), in which case the CA MUST > generate a subject name that is unique in the context of > certificates issued by this CA. This seems reasonable, and, given the current apparent behavior, seems unlikely to cause any problems. > 2. Is rtr-keying correct in stating the following in s3.1 because > the text there is about initial provisioning not rekey/renewal and > it contradicts the 2nd sentence about subject in RFC 6847? >=20 > s3.1 rtr-keying: >=20 > to generate the PKCS#10 request that includes the router number and > public key ... >=20 > s6.1 RFC 6487: >=20 > This field is allowed to be > non-empty only for a re-key/reissuance request, and only if the > CA has adopted a policy (in its Certificate Practice Statement > (CPS)) that permits reuse of names in these circumstances. >=20 > I m wondering how the router is going to know what value to use. I > suspect its only going to know what value to use after it has been > told the value :) Not including a router # in the request is > probably okay if the request comes through the CLI session the > operator is using to talk to the router because it can capture the > request and "tag it" in someway to know what name ought to go in the > subject field of the issued certificate. But, say the CLI session > isn t used and the router uses its network connectivity to > communicate with the CA. If there s no name in the request, how > will the CA know what name to include in the issued certificate? > Seems to me like for that scenario, we d actually want the subject > name present in the PKCS#10. Thoughts? The authors of RFC 6487 can speak for themselves, but I think their intent was to avoid requests for "vanity names" (CN=3D"Joe's Pizza" instead of CN=3D"4DF2D88957372FF9FDA05C70F2D9E8BA334CFF89"), which could be construed as eroding claims that the RPKI attests only to things like addresses and autonomous system numbers. From nobody Fri Apr 4 12:49:37 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B111A064A for ; Fri, 4 Apr 2014 12:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.801 X-Spam-Level: X-Spam-Status: No, score=-101.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPsEeqLQkJmL for ; Fri, 4 Apr 2014 12:49:31 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id F019F1A0653 for ; Fri, 4 Apr 2014 12:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=dU2cgESW9PjSZP277QozeNGIqNJAQ4N0FTy6AnfnY6o=; b=zd3PvsAj+TcEVwAE+niuNf7efhSoDqcviURgHYU0+g1yQ3OUHpxa1cPljYmiCBe7CBIggn65fwbkP cxheYr5UkS2wIO3HD0thhDvbXOzcFEBmZ5K22QFeE+RJ5951sEnW3zlPm6pYbYDLar2bzIhnMJhpwB P8FtSwgteI/XHqLQ= Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Sat, 5 Apr 2014 14:56:35 +1000 (EST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Sat, 5 Apr 2014 05:47:54 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Geoff Huston In-Reply-To: <20140404171253.E2CF21721C@thrintun.hactrn.net> Date: Sat, 5 Apr 2014 06:47:53 +1100 Content-Transfer-Encoding: 7bit Message-ID: References: <20140221233023.4ABC9170A4@thrintun.hactrn.net> <530B7657.10806@bbn.com> <965AC70C-983A-4C9F-B555-4C5A7AAD3F91@ieca.com> <20140404171253.E2CF21721C@thrintun.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/n0Id31ytn4MMuhpMxksa3ZWXBSA Cc: sidr@ietf.org Subject: Re: [sidr] Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 19:49:35 -0000 > > The authors of RFC 6487 can speak for themselves, but I think their > intent was to avoid requests for "vanity names" (CN="Joe's Pizza" > instead of CN="4DF2D88957372FF9FDA05C70F2D9E8BA334CFF89"), which could > be construed as eroding claims that the RPKI attests only to things > like addresses and autonomous system numbers. As I recall the discussion at the time was based around a desire to avoid any implication that the CA was attesting as to the identity of the subject. i.e. the CA was explicitly not saying that the holder of the public key was the individual described int subject field (section 4.5 of RFC6487). There was also some convenience in using a subject name that was linked to the subject's public key, in so far as when the subject rolled keys then the subject would request a new certificate and the issuer would use a different subject name (section 4.5 once more). Geoff From nobody Fri Apr 4 18:33:27 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8641A01FD for ; Fri, 4 Apr 2014 18:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLUoa7WHuZOU for ; Fri, 4 Apr 2014 18:33:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 056811A01D4 for ; Fri, 4 Apr 2014 18:33:17 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WWFTq-0007z7-Eu; Sat, 05 Apr 2014 01:33:11 +0000 Date: Sat, 05 Apr 2014 10:33:09 +0900 Message-ID: From: Randy Bush To: Geoff Huston In-Reply-To: References: <20140221233023.4ABC9170A4@thrintun.hactrn.net> <530B7657.10806@bbn.com> <965AC70C-983A-4C9F-B555-4C5A7AAD3F91@ieca.com> <20140404171253.E2CF21721C@thrintun.hactrn.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/5STgsGAXaeVc85tYVsxvpAElrYs Cc: sidr wg list Subject: Re: [sidr] Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 01:33:24 -0000 >> The authors of RFC 6487 can speak for themselves, but I think their >> intent was to avoid requests for "vanity names" (CN="Joe's Pizza" >> instead of CN="4DF2D88957372FF9FDA05C70F2D9E8BA334CFF89"), which >> could be construed as eroding claims that the RPKI attests only to >> things like addresses and autonomous system numbers. > As I recall the discussion at the time was based around a desire to > avoid any implication that the CA was attesting as to the identity of > the subject. i.e. the CA was explicitly not saying that the holder of > the public key was the individual described int subject field (section > 4.5 of RFC6487). except i vaguely remember a proposal to have there be special privileged names for the certs of the rirs. randy From nobody Mon Apr 7 06:50:42 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BE71A0708 for ; Mon, 7 Apr 2014 06:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWLEj922r91H for ; Mon, 7 Apr 2014 06:50:35 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D0AF31A0159 for ; Mon, 7 Apr 2014 06:50:35 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:43772 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WX9wc-000GbY-2h for sidr@ietf.org; Mon, 07 Apr 2014 09:50:38 -0400 Message-ID: <5342AD28.4030408@bbn.com> Date: Mon, 07 Apr 2014 09:50:32 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20140221233023.4ABC9170A4@thrintun.hactrn.net> <530B7657.10806@bbn.com> <965AC70C-983A-4C9F-B555-4C5A7AAD3F91@ieca.com> <20140404171253.E2CF21721C@thrintun.hactrn.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/BnKDiKP7JEw9aVSiPevQCKcrXok Subject: Re: [sidr] Conflict between rtr-keying, bgpsec-pki-profile, and RFC 6487 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 13:50:41 -0000 Randy, >>> The authors of RFC 6487 can speak for themselves, but I think their >>> intent was to avoid requests for "vanity names" (CN="Joe's Pizza" >>> instead of CN="4DF2D88957372FF9FDA05C70F2D9E8BA334CFF89"), which >>> could be construed as eroding claims that the RPKI attests only to >>> things like addresses and autonomous system numbers. >> As I recall the discussion at the time was based around a desire to >> avoid any implication that the CA was attesting as to the identity of >> the subject. i.e. the CA was explicitly not saying that the holder of >> the public key was the individual described int subject field (section >> 4.5 of RFC6487). > except i vaguely remember a proposal to have there be special privileged > names for the certs of the rirs. I floated that idea at one time, long, long, ago, but it is not in the RFC, and I don't believe it is true in practice (although I admit that I have not checked, personally). Steve From nobody Thu Apr 10 09:52:47 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B251A02FC for ; Thu, 10 Apr 2014 09:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82ugHq2cC6pb for ; Thu, 10 Apr 2014 09:52:40 -0700 (PDT) Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 530751A0277 for ; Thu, 10 Apr 2014 09:52:39 -0700 (PDT) Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id s3AGneAd015842; Thu, 10 Apr 2014 11:52:34 -0500 Received: from cva-mx004.sparta.com (cva-mx004.sparta.com [157.185.34.2]) by txdal11mx03.parsons.com with ESMTP id 1k5x4egeyx-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 10 Apr 2014 11:52:33 -0500 Received: from CVA-MXINT01.ads.sparta.com ([10.62.108.15]) by CVA-MX004.sparta.com (8.14.4/8.14.4) with ESMTP id s3AGqXwd020136; Thu, 10 Apr 2014 12:52:33 -0400 Received: from HSV-CAS004.huntsville.ads.sparta.com ([10.62.8.148]) by CVA-MXINT01.ads.sparta.com (8.14.4/8.14.4) with ESMTP id s3AGqWEG019222; Thu, 10 Apr 2014 12:52:32 -0400 Received: from HSV-MB002.huntsville.ads.sparta.com ([fe80::2521:a783:a30c:d057]) by HSV-CAS004.huntsville.ads.sparta.com ([fe80::d00f:c039:2622:2252%11]) with mapi id 14.02.0387.000; Thu, 10 Apr 2014 11:52:29 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: change of email address Thread-Index: Ac9U3UG6i7EdJI/+QneANwi/RTj1pg== Date: Thu, 10 Apr 2014 16:52:28 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F694B24EB2@HSV-MB002.huntsville.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-10_04:2014-04-10,2014-04-10,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=1 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=230.336 compositescore=0.0999549217732862 urlsuspect_oldscore=0.999549217732862 suspectscore=0 recipient_domain_to_sender_totalscore=4066 phishscore=0 bulkscore=0 kscore.is_spamscore=9.80579913270607e-05 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=12528 rbsscore=0.0999549217732862 spamscore=1 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1404100263 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/xD2181HfKxUYgLUTQSFi6YPxwas Cc: "rtg-ads@tools.ietf.org" Subject: [sidr] change of email address X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 16:52:45 -0000 My company has instituted a strict limit to the size of our mailboxes. I a= m changing my subscription to the ietf lists to sandy@tislabs.com. No chan= ge of company, just email address.=0A= =0A= So if you see mail from sandy@tislabs.com, don't be alarmed, it is still me= . (Actually has been me for a long while, now.)=0A= =0A= If you send a message to Sandra.Murphy@parsons.com, I will still see it. I= f you send a message to the even older Sandra.Murphy@sparta.com, it will ge= t to me for now, but will stop getting to me later this year.=0A= =0A= Safest thing when communicating about wg stuff is to send to sidr-chairs@ie= tf.org or sidr-chairs@tools.ietf.org.=0A= =0A= --Sandy= From nobody Mon Apr 14 06:22:16 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E356D1A0453 for ; Mon, 14 Apr 2014 06:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.527 X-Spam-Level: X-Spam-Status: No, score=0.527 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LvoWTHkiACR for ; Mon, 14 Apr 2014 06:22:11 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 21D641A01D4 for ; Mon, 14 Apr 2014 06:21:47 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id A029C28B0017 for ; Mon, 14 Apr 2014 09:21:44 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 59D181F8036; Mon, 14 Apr 2014 09:21:44 -0400 (EDT) From: Sandra Murphy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 14 Apr 2014 09:21:44 -0400 Message-Id: To: "sidr@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/QiCCJKbanZYKxLzF7RDT0OgcpoY Cc: Sandra Murphy Subject: [sidr] comments on draft-ietf-sidr-rfc6485bis X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 13:22:14 -0000 Speaking as regular ol' member Some comments on draft-ietf-sidr-rfc6485bis-01.txt Most of my comments are related to the attempt to add a new OID to RFC6485, which previously had only one to specify. * The signature algorithm used in certificates, CRLs, and signed objects is RSA Public-Key Cryptography Standards (PKCS) #1 Version 1.5 (sometimes referred to as "RSASSA-PKCS1-v1_5") from Section 5 of [RFC4055]. Except that the signed object signature algorithm OID will be rsaEncryption which I think is still PKCS#1v1.5, but is not in section 5 of rfc4055. Hashing algorithms are not identified individually in certificates and CRLs, ... For generating and verifying certificates, and CRLs the hashing and digital signature algorithms are referred to together, And the PKCS/CMRF signatures? See comment below. Locations for this OID are as follows: The previous text talks about three OIDs, so "this" OID is ambiguous. Perhaps you just meant "The places where OIDs appear are:". The text that follows would then say "an OID appears", not "the OID appears". Not only is there more than one OID to mention, in some of those messages, more than one OID appears in the message. [[I think this discussion of "where" could go better above the two prior paragraphs that talk about what-goes-in-the-where.]] In a certification request, the OID appears in the PKCS #10 signatureAlgorithm field [RFC2986], or in the Certificate Request Message Format (CRMF) POPOSigningKey signature field [RFC4211]. The PKCS and CRMF uses of crypto algorithms are not mentioned in the discussion preceding. I presume the "the OID" text is left over from the original RFC6485 and what was meant was the sha256WithRSAEncryption OID. It looks to me like RC2986 leaves that choice free, so this text need to say which For CMS SignedData, the object identifier and parameters for SHA-256 in [RFC5754] MUST be used for the SignedData digestAlgorithms field and the SignerInfo digestAlgorithm field when generating and verifying CMS SignedData objects. ... RPKI implementations MUST accept CMS SignedData objects that use the object identifier and parameters for either rsaEncryption or sha256WithRSAEncryption for the SignerInfo signatureAlgorithm field when verifying CMS SignedData objects. I presume accepting sha256WithRSAEncryption is backward compatibiilty - just in case some new implementation should appear that implements RFC6485, before this spec is published, right? Since all known implementations currently follow this spec? Personal opinion: maybe we should not permit the backward compatibility with some hypothetical implementation in this short interval, so future coding errors get caught? Or at least note the reason, so future readers are not confused? Nits: Repetition: Hashing algorithms are not identified individually in certificates and CRLs, as the identity of the hashing algorithm is combined with the identity of the digital signature algorithm. ... For generating and verifying certificates, and CRLs the hashing and digital signature algorithms are referred to together, I presume this is just repetition, right? I always wonder about repeated messages - is there a difference I did not notice? So for those similarly anxious, maybe a "as noted above"? (Or leave out the first mention - that section is talking about what algorithms there are to specify, you could leave it to later to talk about the format of expressing a particular choice of algorithm. Quibble.) For CMS SignedData, the object identifier and parameters for SHA-256 in [RFC5754] MUST be used for the SignedData digestAlgorithms field ... In CMS SignedData, the OID appears in each SignerInfo signatureAlgorithm field, the SignerInfo digestAlgorithm field, and in the SignedData digestAlgorithms [RFC5652]; and, I presume this is just repetition (reinforcement, for completeness), right? (There's no difference I just don't see?) truly nitty: FROM For generating and verifying certificates, and CRLs the hashing TO For generating and verifying certificates and CRLs, the hashing --Sandy, speaking as regular ol' member From nobody Mon Apr 14 07:43:24 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E4D1A044B for ; Mon, 14 Apr 2014 07:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFbq2PSdtNwz for ; Mon, 14 Apr 2014 07:43:20 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id E92ED1A0186 for ; Mon, 14 Apr 2014 07:43:18 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 8766928B0046 for ; Mon, 14 Apr 2014 10:43:16 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 397B41F803D; Mon, 14 Apr 2014 10:43:16 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Mon, 14 Apr 2014 10:43:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <60ECB09C-3502-48CD-A152-076AE5BF6E39@tislabs.com> References: To: "sidr@ietf.org" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/8v0TXp-Vx3uplprslU1Ps0fweT8 Cc: Sandra Murphy Subject: Re: [sidr] comments on draft-ietf-sidr-rfc6485bis X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 14:43:22 -0000 And one "I forgot": CAs and RPs SHOULD be capable of supporting a transition to allow for the phased introduction of additional encryption algorithms and key specifications, Is this any different than the algorithm agility in RFC6916? If so, I'd = think a reference would be good. If not, could you explain? --Sandy, speaking as regular ol' member On Apr 14, 2014, at 9:21 AM, Sandra Murphy wrote: > Speaking as regular ol' member >=20 > Some comments on draft-ietf-sidr-rfc6485bis-01.txt >=20 > Most of my comments are related to the attempt to add a new OID to > RFC6485, which previously had only one to specify. >=20 > * The signature algorithm used in certificates, CRLs, and signed > objects is RSA Public-Key Cryptography Standards (PKCS) #1 > Version 1.5 (sometimes referred to as "RSASSA-PKCS1-v1_5") = from > Section 5 of [RFC4055]. >=20 > Except that the signed object signature algorithm OID will be > rsaEncryption which I think is still PKCS#1v1.5, but is not in section > 5 of rfc4055. =20 >=20 > Hashing algorithms > are not identified individually in certificates and CRLs, > ... > For generating and verifying certificates, and CRLs the hashing and > digital signature algorithms are referred to together, >=20 > And the PKCS/CMRF signatures? See comment below. >=20 >=20 > Locations for this OID are as follows: >=20 > The previous text talks about three OIDs, so "this" OID is ambiguous. > Perhaps you just meant "The places where OIDs appear are:". > The text that follows would then say "an OID appears", not "the > OID appears". Not only is there more than one OID to mention, in some > of those messages, more than one OID appears in the message. >=20 > [[I think this discussion of "where" could go better above the two = prior > paragraphs that talk about what-goes-in-the-where.]] >=20 > In a certification request, the OID appears in the PKCS #10 > signatureAlgorithm field [RFC2986], or in the Certificate Request > Message Format (CRMF) POPOSigningKey signature field [RFC4211]. >=20 > The PKCS and CRMF uses of crypto algorithms are not mentioned in the > discussion preceding. I presume the "the OID" text is left over from > the original RFC6485 and what was meant was the = sha256WithRSAEncryption > OID. It looks to me like RC2986 leaves that choice free, so this > text need to say which >=20 > For CMS SignedData, the object identifier and parameters for SHA-256 > in [RFC5754] MUST be used for the SignedData digestAlgorithms field > and the SignerInfo digestAlgorithm field when generating and > verifying CMS SignedData objects. > ... > RPKI implementations MUST accept CMS SignedData objects that use the > object identifier and parameters for either rsaEncryption or > sha256WithRSAEncryption for the SignerInfo signatureAlgorithm field > when verifying CMS SignedData objects. >=20 > I presume accepting sha256WithRSAEncryption is backward compatibiilty > - just in case some new implementation should appear that implements > RFC6485, before this spec is published, right? Since all known > implementations currently follow this spec? Personal opinion: maybe > we should not permit the backward compatibility with some hypothetical > implementation in this short interval, so future coding errors get > caught? Or at least note the reason, so future readers are not = confused? >=20 > Nits: >=20 > Repetition: >=20 > Hashing algorithms > are not identified individually in certificates and CRLs, as > the identity of the hashing algorithm is combined with the > identity of the digital signature algorithm. > ... >=20 > For generating and verifying certificates, and CRLs the hashing and > digital signature algorithms are referred to together, >=20 > I presume this is just repetition, right? I always wonder about > repeated messages - is there a difference I did not notice? So for > those similarly anxious, maybe a "as noted above"? (Or leave out the > first mention - that section is talking about what algorithms there > are to specify, you could leave it to later to talk about the format = of > expressing a particular choice of algorithm. Quibble.) >=20 > For CMS SignedData, the object identifier and parameters for SHA-256 > in [RFC5754] MUST be used for the SignedData digestAlgorithms field > > ... > In CMS SignedData, the OID appears in each SignerInfo > signatureAlgorithm field, the SignerInfo digestAlgorithm field, > and in the SignedData digestAlgorithms [RFC5652]; and, >=20 > I presume this is just repetition (reinforcement, for completeness), > right? (There's no difference I just don't see?) >=20 > truly nitty: >=20 > FROM > For generating and verifying certificates, and CRLs the hashing > TO > For generating and verifying certificates and CRLs, the hashing >=20 > --Sandy, speaking as regular ol' member From nobody Mon Apr 14 07:46:56 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657AF1A044B for ; Mon, 14 Apr 2014 07:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1JU3OckN4H0 for ; Mon, 14 Apr 2014 07:46:48 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 53F991A03E7 for ; Mon, 14 Apr 2014 07:46:48 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id pv20so5747291lab.37 for ; Mon, 14 Apr 2014 07:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mgc1LYhNzCYZnDJV5ig0PZrJV5VeRixZ7JYU0l4UGW4=; b=Xab6kyxVIDjXrW8qmQzpFnXOnZREALA9H6LA3Zz62n3PcR9QSc3gO1N+bXK8UwZguC GiM/SetiLEndSW1J5CCQ16UgHYO0z8efyEwsyUzxqlTMMboAfMbrr0a0XGHEwYBaCnbK ejtalXRSN5PlOPLUvHZ7AjZFOK9OS0CGYm4zOWu8r3p3jz8jriR3qxYIme/eHekIUJf2 KE+L574R4PNN5pG+6q6Xtiw73VyBLsbj695I/8SCMtt50tx3QsIXZSAj8mR3CdLOPxqp 6YFJGkFryVmyQMC70FMDTfmq5z+LnFXs/Qxvb7IyoSQqOpBXrI47Kx57bTfgvfFkEsF8 3T5w== MIME-Version: 1.0 X-Received: by 10.152.37.137 with SMTP id y9mr29594062laj.8.1397486805150; Mon, 14 Apr 2014 07:46:45 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.152.45.196 with HTTP; Mon, 14 Apr 2014 07:46:45 -0700 (PDT) In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> Date: Mon, 14 Apr 2014 10:46:45 -0400 X-Google-Sender-Auth: T1Go49y8hDUn5ZwZGdp6AnVQL1U Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/3CcsDCCJTQjgKs0lRKQ2Q53Jomo Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 14:46:53 -0000 coming back to this discussion... On Fri, Feb 7, 2014 at 10:17 PM, Randy Bush wrote: > perhaps people should use a dictionary and look up "per se." (from dictionary.com, or wherever bing.com 'define per se' comes from) per se 1. by or in itself or themselves; intrinsically. so, as I read the original: "As noted in the threat model, [I-D.ietf-sidr-bgpsec-threats], this work is limited to threats to the BGP protocol. Issues of business relationship conformance, of which routing 'leaks' are a subset, while quite important to operators (as are many other things), are not security issues per se, and are outside the scope of this document. It is hoped that these issues will be better understood in the future." I could easily replace per se with 'intrinsically' like: "As noted in the threat model, [I-D.ietf-sidr-bgpsec-threats], this work is limited to threats to the BGP protocol. Issues of business relationship conformance, of which routing 'leaks' are a subset, while quite important to operators (as are many other things), are not intrinsically security issues, and are outside the scope of this document. It is hoped that these issues will be better understood in the future." Is there a reason to keep the mention of route-leaks in this document? Could we go with: "As noted in the threat model, [I-D.ietf-sidr-bgpsec-threats], this work is limited to threats to the BGP protocol. Issues of business relationship conformance, while quite important to operators, are not security issues per se, and are outside the scope of this document. It is hoped that these issues will be better understood in the future." I think this was in line with warren's suggestion, which wes agreed with as did stephen kent. This seems ok to me as well... I'd like to close the discussion sooner rather than later and send out a publication request. -chris From nobody Mon Apr 14 07:55:09 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB701A0489 for ; Mon, 14 Apr 2014 07:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhcmEkxUiVqX for ; Mon, 14 Apr 2014 07:55:07 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 826B21A0476 for ; Mon, 14 Apr 2014 07:55:07 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WZiHm-0006V0-Kl; Mon, 14 Apr 2014 14:55:03 +0000 Date: Mon, 14 Apr 2014 23:55:01 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/4pr3wQyu_MXhkRcVVXLgtIzYRx0 Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 14:55:08 -0000 > I could easily replace per se with 'intrinsically' like: yes. do we need to play synonyms when, ab definito, they mean the same thing? i chose my words. as you point out, they are correct. > Is there a reason to keep the mention of route-leaks in this document? i think it was shane who wanted them explicitly mentioned. it seems to be a fashionable term in grow this season, and i am not sure there is any benefit to pretending we don't see it. but i personally do not care. > "As noted in the threat model, [I-D.ietf-sidr-bgpsec-threats], this > work is limited to threats to the BGP protocol. Issues of business > relationship conformance, while quite important to operators, are > not security issues per se, and are outside the scope of this > document. It is hoped that these issues will be better understood in > the future." i can live with that > I think this was in line with warren's suggestion, which wes agreed > with as did stephen kent. This seems ok to me as well... I'd like to > close the discussion sooner rather than later and send out a > publication request. as none of the folk you just listed were those specifically asking for the term "route leaks," if you do not mind, it seems polite to wait a few days to give them a chance to speak. i can cut a new version if the dust settles. randy From nobody Mon Apr 14 08:00:53 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4537B1A04B4 for ; Mon, 14 Apr 2014 08:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZRGtzg_9YW6 for ; Mon, 14 Apr 2014 08:00:50 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id DD4701A04A9 for ; Mon, 14 Apr 2014 08:00:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WZiNI-0006WG-9X; Mon, 14 Apr 2014 15:00:44 +0000 Date: Tue, 15 Apr 2014 00:00:42 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/5qEkNanWl7PLlCWmVyghvQ-67OM Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 15:00:51 -0000 while checking the docco, i found 3.14 While the trust level of a route should be determined by the BGPsec protocol, local routing preference and policy MUST then be applied to best path and other routing decisions. Such mechanisms SHOULD conform with [I-D.ietf-sidr-ltamgmt]. ... 3.17 If a BGPsec design makes use of a security infrastructure, that infrastructure SHOULD enable each network operator to select the entities it will trust when authenticating data in the security infrastructure. See, for example, [I-D.ietf-sidr-ltamgmt]. those references would seem to be obe. dunno what to do with the first, drop it? the second might ref lta-use-cases. randy From nobody Mon Apr 14 08:24:13 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022301A02C7 for ; Mon, 14 Apr 2014 08:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQjdlxX2al5L for ; Mon, 14 Apr 2014 08:24:06 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3071A01A6 for ; Mon, 14 Apr 2014 08:24:06 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id w7so5726229lbi.20 for ; Mon, 14 Apr 2014 08:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iNKfDSrjHEM/1zlznc0+7Za2X4tdO99IMOjuWYuhhnI=; b=ckmBepDPkQwVbE3Y2fb0/IqnbO7eVtzScDikzbVgQNdG8Uz0P6GopeAwdSGHnadhpv DzSpaORTjXFxPRkUfTlFtXeyMFK1nFo2lzBlWdvtgsW97f3xSOKFZ42Ie0XFwBOuTWDs VwESm9Yd+vZHXw/mzRBIe9WOtCZOwNENtfIG+ifPhODPl0JKlqHxNdvEr+kxWfstLFnm fbmqBiaekIma+HyydNOcTqQK3Xep26JxpwrycMKsZrtkBNmZ/rbyfCqMM9r1PzMNvY5q KGGzvUd8gQy9Fd8ZU+qmZFT+lAH34CVjqOpR9iguO6bm/ve6TJ/VhCZ3hwxtwmTmgvFx +Hig== MIME-Version: 1.0 X-Received: by 10.112.199.99 with SMTP id jj3mr28679000lbc.22.1397489043171; Mon, 14 Apr 2014 08:24:03 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.152.45.196 with HTTP; Mon, 14 Apr 2014 08:24:03 -0700 (PDT) In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> Date: Mon, 14 Apr 2014 11:24:03 -0400 X-Google-Sender-Auth: ZsYm8dvMR-chpwiP1LDhBYj5LDU Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/ZuF0pGO2cjDpFnynHcUx_X5pTMQ Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 15:24:09 -0000 On Mon, Apr 14, 2014 at 10:55 AM, Randy Bush wrote: >> I could easily replace per se with 'intrinsically' like: > > yes. do we need to play synonyms when, ab definito, they mean the same > thing? i chose my words. as you point out, they are correct. > I'm not an english teacher :( I'm just trying to see if there's middle ground or if the already used wording is fine, given other possible wordings which may seem less clunky to others. >> Is there a reason to keep the mention of route-leaks in this document? > > i think it was shane who wanted them explicitly mentioned. it seems to > be a fashionable term in grow this season, and i am not sure there is > any benefit to pretending we don't see it. but i personally do not > care. I was looking for the explicit: "its here because X and Y and Z asked for it." (shane and a few others, yes.) So on the one hand keeping the mention of leaks seems still to be important. >> "As noted in the threat model, [I-D.ietf-sidr-bgpsec-threats], this >> work is limited to threats to the BGP protocol. Issues of business >> relationship conformance, while quite important to operators, are >> not security issues per se, and are outside the scope of this >> document. It is hoped that these issues will be better understood in >> the future." > > i can live with that > >> I think this was in line with warren's suggestion, which wes agreed >> with as did stephen kent. This seems ok to me as well... I'd like to >> close the discussion sooner rather than later and send out a >> publication request. > > as none of the folk you just listed were those specifically asking for > the term "route leaks," if you do not mind, it seems polite to wait a > few days to give them a chance to speak. i can cut a new version if the > dust settles. > waiting seems ok to me, can we agree to agree by ~4/23/2014 (next wednesday) ? From nobody Mon Apr 14 08:25:01 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7121A02CF for ; Mon, 14 Apr 2014 08:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKItBRUAap-E for ; Mon, 14 Apr 2014 08:24:57 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id BB2581A02C7 for ; Mon, 14 Apr 2014 08:24:56 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so5841933lbj.31 for ; Mon, 14 Apr 2014 08:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dqFe2YMeeZ5GQ13VIApV0WNx5W3nDFSGFl0WGe9QKys=; b=iocGbinvZrx2HK2Hw8DQeR66jwKW73hAbKjqTPdHQK0AJ9VDJ0i3mKqkV/8XRvA/Q8 2pw7Sg2CF3S5R8+2G86gTNPuPO4FipWf20WLnWm7Iw0oWIvDt6y51NuCYperG6cftG2s WAEMVI9cEG9x0Fi69EHdz8PBWafME5teYlRRoUO7ofcjxXz6crxJosp4wOpxgY38bAP9 Un/CVm72yAyAmUBYWbDLFROcB8X1luuPkVRAXZ8CYGCRH1FqWnSwdwU9Jwk1OikIk5nE Ufw40k5DdO5lwOGS7CbcAzQhIVvNhQ/8rdFoHxXYknO6/Ev6nMJxRRLUktVASkwxDeXS fJtw== MIME-Version: 1.0 X-Received: by 10.152.4.201 with SMTP id m9mr838003lam.61.1397489093455; Mon, 14 Apr 2014 08:24:53 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.152.45.196 with HTTP; Mon, 14 Apr 2014 08:24:53 -0700 (PDT) In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> Date: Mon, 14 Apr 2014 11:24:53 -0400 X-Google-Sender-Auth: GwlHdZeeAKji0gBA39SR0IxaARc Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/TUA9eski7hi8sPpCA-sfBrd7tcY Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 15:24:58 -0000 On Mon, Apr 14, 2014 at 11:00 AM, Randy Bush wrote: > while checking the docco, i found > > 3.14 While the trust level of a route should be determined by the > BGPsec protocol, local routing preference and policy MUST then > be applied to best path and other routing decisions. Such > mechanisms SHOULD conform with [I-D.ietf-sidr-ltamgmt]. > ... > 3.17 If a BGPsec design makes use of a security infrastructure, that > infrastructure SHOULD enable each network operator to select > the entities it will trust when authenticating data in the > security infrastructure. See, for example, > [I-D.ietf-sidr-ltamgmt]. > > those references would seem to be obe. dunno what to do with the first, > drop it? the second might ref lta-use-cases. losing the last sentence in the first seems ok. and the second moving to use-cases seems ok to me... -chris From nobody Mon Apr 14 12:21:44 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D391A06C9 for ; Mon, 14 Apr 2014 12:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.473 X-Spam-Level: X-Spam-Status: No, score=-4.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Kx-vQyZJ3od for ; Mon, 14 Apr 2014 12:21:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7F51A06C7 for ; Mon, 14 Apr 2014 12:21:41 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:36482 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WZmRv-000CyW-72 for sidr@ietf.org; Mon, 14 Apr 2014 15:21:47 -0400 Message-ID: <534C3542.6080209@bbn.com> Date: Mon, 14 Apr 2014 15:21:38 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: sidr@ietf.org References: <60ECB09C-3502-48CD-A152-076AE5BF6E39@tislabs.com> In-Reply-To: <60ECB09C-3502-48CD-A152-076AE5BF6E39@tislabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/TcuLKCEy8UjLVESubfDy1UEoZWU Subject: Re: [sidr] comments on draft-ietf-sidr-rfc6485bis X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 19:21:42 -0000 The CPS was written well before 6916 was finished. A reference to that RFC now makes sense. Steve On 4/14/14 10:43 AM, Sandra Murphy wrote: > And one "I forgot": > > CAs and RPs SHOULD be capable of supporting a transition to allow for > the phased introduction of additional encryption algorithms and key > specifications, > > Is this any different than the algorithm agility in RFC6916? If so, I'd think > a reference would be good. If not, could you explain? > > --Sandy, speaking as regular ol' member > From nobody Mon Apr 14 15:56:53 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2992F1A044C for ; Mon, 14 Apr 2014 15:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.172 X-Spam-Level: X-Spam-Status: No, score=-4.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFh-DHSLRa_G for ; Mon, 14 Apr 2014 15:56:49 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 8254E1A0440 for ; Mon, 14 Apr 2014 15:56:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WZpnx-0007yQ-Ry; Mon, 14 Apr 2014 22:56:46 +0000 Date: Tue, 15 Apr 2014 07:56:44 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <52D072F6.9030304@ops-netman.net> <52D0A0AC.5040903@ops-netman.net> <52E92B20.9060505@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/y7ol1WvurMT49_a6fVa32rLVJlc Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 22:56:51 -0000 >>> I could easily replace per se with 'intrinsically' like: >> yes. do we need to play synonyms when, ab definito, they mean the same >> thing? i chose my words. as you point out, they are correct. > I'm not an english teacher my paternal grandmother was. even when i was barely writing, she would return my letters with red ink corrections. i thought it normal. :) >> i think it was shane who wanted them explicitly mentioned. it seems >> to be a fashionable term in grow this season, and i am not sure there >> is any benefit to pretending we don't see it. but i personally do >> not care. > I was looking for the explicit: "its here because X and Y and Z asked > for it." (shane and a few others, yes.) So on the one hand keeping > the mention of leaks seems still to be important. or it could be obe. don't know. did someone see harm in mentioning route leaks? as i said, i have no dog in this fight. > waiting seems ok to me, can we agree to agree by ~4/23/2014 (next > wednesday) ? i will be on yet another journey, so please remind me if you would. i already cut your text into my emacs edit buffer. >> while checking the docco, i found >> >> 3.14 While the trust level of a route should be determined by the >> BGPsec protocol, local routing preference and policy MUST then >> be applied to best path and other routing decisions. Such >> mechanisms SHOULD conform with [I-D.ietf-sidr-ltamgmt]. >> ... >> 3.17 If a BGPsec design makes use of a security infrastructure, that >> infrastructure SHOULD enable each network operator to select >> the entities it will trust when authenticating data in the >> security infrastructure. See, for example, >> [I-D.ietf-sidr-ltamgmt]. >> >> those references would seem to be obe. dunno what to do with the first, >> drop it? the second might ref lta-use-cases. > > losing the last sentence in the first seems ok. and the second moving > to use-cases seems ok to me... anyone else have input on this one, well, these two? randy From nobody Tue Apr 15 15:00:53 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6CA1A07CE for ; Tue, 15 Apr 2014 15:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.063 X-Spam-Level: X-Spam-Status: No, score=-102.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qREqbf7anNf0 for ; Tue, 15 Apr 2014 15:00:20 -0700 (PDT) Received: from so-mailgw.apnic.net (so-mailgw.apnic.net [IPv6:2001:dd8:a:3::230]) by ietfa.amsl.com (Postfix) with SMTP id 032041A07C6 for ; Tue, 15 Apr 2014 15:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=/wXl2Hnrbu5mDvpEiYd1zhY1t8CUcGOLigNI+gUrkwM=; b=J0Q58ggszdtx6jMnjiuSlXQqbt9I1qudGaQ55c2ncgN2lPxXU14e9TNQegI8/HFAbfAZuuqcW5SaF GvUGyRL9YSUCPr97FhGwrDCe1n4wIYmP4OGvrZTDAnxDv31OMBTIcFUgA0vVo4Nuxx4VxSSlFGGEzm DVXi+PM4tqCps/98= Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by so-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Wed, 16 Apr 2014 17:08:11 +1000 (EST) Received: from dhcp179.potaroo.net (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 16 Apr 2014 08:00:13 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Geoff Huston In-Reply-To: <60ECB09C-3502-48CD-A152-076AE5BF6E39@tislabs.com> Date: Wed, 16 Apr 2014 08:00:12 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <60ECB09C-3502-48CD-A152-076AE5BF6E39@tislabs.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/7WjfCC7f0_79shrHjFwXmVjvFGI Cc: "sidr@ietf.org" Subject: Re: [sidr] comments on draft-ietf-sidr-rfc6485bis X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2014 22:00:35 -0000 On 15 Apr 2014, at 12:43 am, Sandra Murphy wrote: > And one "I forgot": >=20 > CAs and RPs SHOULD be capable of supporting a transition to allow = for > the phased introduction of additional encryption algorithms and key > specifications, >=20 > Is this any different than the algorithm agility in RFC6916? If so, = I'd think > a reference would be good. If not, could you explain? >=20 Yes, I could explain.=20 The RFC numbers should be a huge hint here. So why didn't RFC6485 have a reference to what was a non-existent = document at that time?=20 Do I really need to answer that question? So why doesn't RFC6485bis fix all this, as you are suggesting here? So should a reference to RFC6916 be included in this draft? Well on the one hand I can't see why not, but... All this started out as a potential erratum note to RFC6485, and following advice from that this constituted a technical = change that was beyond the scope of an erratum, a bis update to RFC6485 itself = was called for, with a narrow scope to address this particular issue. = Section 8 of the draft describes the nature of the change, to allow the IESG and = IETF LC review of this bis document to concentrate on precisely that change, as = advised in the WG meeting at the time from . But it seems that you are advocating an expanded brief for this bis = document and when cleaning up the references to related work then we should also = look=20 at the rest of the document to see how it meshes with later published RFCs as well. Right? (Parenthetically, the expanding scope of this work is a worry, and I = can't help but wonder if all this is productive use of everyone's time. Maybe = we should also be reflecting on = http://gigaom.com/2014/04/12/why-i-quit-writing-internet-standards/ and contemplate the nature of the difference between adequacy and a = quest for perfection.) Thanks, Geoff =20= From nobody Tue Apr 15 17:49:33 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5F91A0090 for ; Tue, 15 Apr 2014 17:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoHRjND7AFz6 for ; Tue, 15 Apr 2014 17:49:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id BB2571A008F for ; Tue, 15 Apr 2014 17:49:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WaE2U-0003mz-Aj; Wed, 16 Apr 2014 00:49:22 +0000 Date: Wed, 16 Apr 2014 09:49:20 +0900 Message-ID: From: Randy Bush To: Geoff Huston In-Reply-To: References: <60ECB09C-3502-48CD-A152-076AE5BF6E39@tislabs.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/JXAPQxaLAXllxTIimthZdYstg-k Cc: sidr wg list Subject: Re: [sidr] comments on draft-ietf-sidr-rfc6485bis X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 00:49:31 -0000 yes, the erratum exploded into a doc revision. and then, if we're (excuse the royal we when you are doing the heavy lifting) issuing a new doc, well of course it should be modern and correct. primrose path indeed. personally i have no dog in this fight. both directions have my sympathies. i do have sympathies if/where any of the modernizations have semantic impact. beyond that, well, i certainly have no claim to document flexibility per se :) randy From nobody Tue Apr 15 18:01:33 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD461A0092; Tue, 15 Apr 2014 18:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SehpA4ph14hM; Tue, 15 Apr 2014 18:01:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6EB1A008E; Tue, 15 Apr 2014 18:01:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140416010122.10297.57072.idtracker@ietfa.amsl.com> Date: Tue, 15 Apr 2014 18:01:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/l-RuwjE3Mv_6kK1e4OXjHogIpJE Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-reqs-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 01:01:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Security Requirements for BGP Path Validation Authors : Steven M. Bellovin Randy Bush David Ward Filename : draft-ietf-sidr-bgpsec-reqs-10.txt Pages : 9 Date : 2014-04-15 Abstract: This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-reqs/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-reqs-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-reqs-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 16 08:32:07 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1693D1A019B for ; Wed, 16 Apr 2014 08:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.274 X-Spam-Level: X-Spam-Status: No, score=-0.274 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCPkizDtAS9R for ; Wed, 16 Apr 2014 08:32:01 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id AADDC1A01E6 for ; Wed, 16 Apr 2014 08:31:40 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 7359628B003A; Wed, 16 Apr 2014 11:31:37 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 561901F8036; Wed, 16 Apr 2014 11:31:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Wed, 16 Apr 2014 11:31:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <072277B8-10B1-46ED-A4F0-94CE6A06C0E6@tislabs.com> References: <60ECB09C-3502-48CD-A152-076AE5BF6E39@tislabs.com> To: Geoff Huston X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/xXJzRhnCJwFZODw-giI0UAXebx4 Cc: "sidr@ietf.org" , Sandra Murphy Subject: Re: [sidr] comments on draft-ietf-sidr-rfc6485bis X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 15:32:06 -0000 Ruefully, I note that the chairs requested that the comments be limited = to those needed to introduce the correction. It is ironic that it was a discussion at IETF76 Nov 09 about this very = part of draft-ietf-sidr-rpki-algs-01 that led the Security AD to = instruct the wg to produce a transition plan that became RFC6916. I withdraw this comment. My other comments, however, were focussed on incomplete melding of the = correction with the existing text. RC6485 mentions only one OID and = algorithm so there was no question of what OID and algorithm should be = used wherever such things were mentioned. Now, with three OIDs and = algorithms, the text needs to be clear as to what is used where. --Sandy, speaking as regular ol' member On Apr 15, 2014, at 6:00 PM, Geoff Huston wrote: >=20 > On 15 Apr 2014, at 12:43 am, Sandra Murphy wrote: >=20 >> And one "I forgot": >>=20 >> CAs and RPs SHOULD be capable of supporting a transition to allow = for >> the phased introduction of additional encryption algorithms and key >> specifications, >>=20 >> Is this any different than the algorithm agility in RFC6916? If so, = I'd think >> a reference would be good. If not, could you explain? >>=20 >=20 >=20 > Yes, I could explain.=20 >=20 > > The RFC numbers should be a huge hint here. >=20 > So why didn't RFC6485 have a reference to what was a non-existent = document at that > time?=20 >=20 > Do I really need to answer that question? > >=20 > So why doesn't RFC6485bis fix all this, as you are suggesting here? >=20 > So should a reference to RFC6916 be included in this draft? Well on = the > one hand I can't see why not, but... >=20 > All this started out as a potential erratum note to RFC6485, > and following advice from that this constituted a = technical change > that was beyond the scope of an erratum, a bis update to RFC6485 = itself was > called for, with a narrow scope to address this particular issue. = Section 8 > of the draft describes the nature of the change, to allow the IESG and = IETF LC > review of this bis document to concentrate on precisely that change, = as advised > in the WG meeting at the time from . >=20 > But it seems that you are advocating an expanded brief for this bis = document > and when cleaning up the references to related work then we should = also look=20 > at the rest of the document to see how it meshes with later published > RFCs as well. Right? >=20 > (Parenthetically, the expanding scope of this work is a worry, and I = can't > help but wonder if all this is productive use of everyone's time. = Maybe we > should also be reflecting on = http://gigaom.com/2014/04/12/why-i-quit-writing-internet-standards/ > and contemplate the nature of the difference between adequacy and a = quest for > perfection.) >=20 > Thanks, >=20 > Geoff >=20 >=20 >=20 >=20 >=20 >=20 >=20 From nobody Wed Apr 16 12:36:44 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3751A02E9 for ; Wed, 16 Apr 2014 12:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.063 X-Spam-Level: X-Spam-Status: No, score=-102.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfq7dOPlqDTD for ; Wed, 16 Apr 2014 12:36:36 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id 262901A0306 for ; Wed, 16 Apr 2014 12:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=D8J0y7wtMBnpvJR8j/Y8ba37uVufyBVAOM+g4wCqy6c=; b=1i6+sl/7NVao66VaRA+wPUAdt37EET3HimlghWxQWOf0cqDLi2PHin9vlAaZjJ7pSbKQUjPiCy8VY 8kfyU93j8qM+mr5tgG7lYU/Z07EvcmCZ2hYFzNgj8GSQEMo5DdZcryx4HhMlSDF8GgFeFkFyUoQfV5 gXti7qxfWBKFQmnc= Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Thu, 17 Apr 2014 14:44:22 +1000 (EST) Received: from dhcp179.potaroo.net (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 17 Apr 2014 05:36:27 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Geoff Huston In-Reply-To: <072277B8-10B1-46ED-A4F0-94CE6A06C0E6@tislabs.com> Date: Thu, 17 Apr 2014 05:36:23 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <60ECB09C-3502-48CD-A152-076AE5BF6E39@tislabs.com> <072277B8-10B1-46ED-A4F0-94CE6A06C0E6@tislabs.com> To: Sandra Murphy X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/vj07VA4AytcyLL2uC66F1adXMKA Cc: "sidr@ietf.org" Subject: Re: [sidr] comments on draft-ietf-sidr-rfc6485bis X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 19:36:41 -0000 yes - I quite agree that your first set of comments were entirely within = scope for this update to RFC6485, and well made. I will get around to a = response to indicate how these issues will be integrated into the draft. Geoff On 17 Apr 2014, at 1:31 am, Sandra Murphy wrote: > Ruefully, I note that the chairs requested that the comments be = limited to those needed to introduce the correction. >=20 > It is ironic that it was a discussion at IETF76 Nov 09 about this very = part of draft-ietf-sidr-rpki-algs-01 that led the Security AD to = instruct the wg to produce a transition plan that became RFC6916. >=20 > I withdraw this comment. >=20 > My other comments, however, were focussed on incomplete melding of the = correction with the existing text. RC6485 mentions only one OID and = algorithm so there was no question of what OID and algorithm should be = used wherever such things were mentioned. Now, with three OIDs and = algorithms, the text needs to be clear as to what is used where. >=20 > --Sandy, speaking as regular ol' member >=20 >=20 > On Apr 15, 2014, at 6:00 PM, Geoff Huston wrote: >=20 >>=20 >> On 15 Apr 2014, at 12:43 am, Sandra Murphy wrote: >>=20 >>> And one "I forgot": >>>=20 >>> CAs and RPs SHOULD be capable of supporting a transition to allow = for >>> the phased introduction of additional encryption algorithms and key >>> specifications, >>>=20 >>> Is this any different than the algorithm agility in RFC6916? If so, = I'd think >>> a reference would be good. If not, could you explain? >>>=20 >>=20 >>=20 >> Yes, I could explain.=20 >>=20 >> >> The RFC numbers should be a huge hint here. >>=20 >> So why didn't RFC6485 have a reference to what was a non-existent = document at that >> time?=20 >>=20 >> Do I really need to answer that question? >> >>=20 >> So why doesn't RFC6485bis fix all this, as you are suggesting here? >>=20 >> So should a reference to RFC6916 be included in this draft? Well on = the >> one hand I can't see why not, but... >>=20 >> All this started out as a potential erratum note to RFC6485, >> and following advice from that this constituted a = technical change >> that was beyond the scope of an erratum, a bis update to RFC6485 = itself was >> called for, with a narrow scope to address this particular issue. = Section 8 >> of the draft describes the nature of the change, to allow the IESG = and IETF LC >> review of this bis document to concentrate on precisely that change, = as advised >> in the WG meeting at the time from . >>=20 >> But it seems that you are advocating an expanded brief for this bis = document >> and when cleaning up the references to related work then we should = also look=20 >> at the rest of the document to see how it meshes with later published >> RFCs as well. Right? >>=20 >> (Parenthetically, the expanding scope of this work is a worry, and I = can't >> help but wonder if all this is productive use of everyone's time. = Maybe we >> should also be reflecting on = http://gigaom.com/2014/04/12/why-i-quit-writing-internet-standards/ >> and contemplate the nature of the difference between adequacy and a = quest for >> perfection.) >>=20 >> Thanks, >>=20 >> Geoff >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 From nobody Thu Apr 17 08:35:36 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD2A1A01DE for ; Thu, 17 Apr 2014 08:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UAjq1sy3Gvl for ; Thu, 17 Apr 2014 08:35:29 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) by ietfa.amsl.com (Postfix) with ESMTP id 0D13F1A01C0 for ; Thu, 17 Apr 2014 08:35:29 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1WaoLT-000649-1x; Thu, 17 Apr 2014 17:35:25 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-110.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WaoLS-0005pS-SY; Thu, 17 Apr 2014 17:35:22 +0200 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Thu, 17 Apr 2014 17:35:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <519729f8a8c549ec98496c22fc6025a6@BLUPR09MB053.namprd09.prod.outlook.com>, <452C0EF8-8A6C-4E75-B7B3-DDF4FFD87691@apnic.net> <375b352964154d2eab003662a377c688@BLUPR09MB053.namprd09.prod.outlook.com>, <88BC9DDD-0F93-4041-A0DD-527DB61CD7D5@apnic.net> <6F99EFB3-6813-4D40-9AEA-B1A8557F06EA@apnic.net> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1510) X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.6 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07197e3c99fee0dee5764e531ddfe035fd19 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/JlzQeOl8sP2FJBjdkfbZy65LXso Cc: George Michaelson , sidr wg list Subject: Re: [sidr] Questions about draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 15:35:33 -0000 Hi, Sorry for the late reply, I have been very busy with other work. On Mar 18, 2014, at 9:09 PM, "Sriram, Kotikalapudi" = wrote: >>>=20 >>> That is good. But what I meant was (in your I-D under discussion) = does >>> the alternate validation algorithm for a ROA need slightly different >>> wording (as compared to that for certificates)? >>=20 >> I think not. RFC6482 did not define how the EE certificate is to be = validated. >> It simply states that the IP addresses listed in the ROA must also be = found in the >> resource extensions of the signing EE cert. This still holds. >>=20 >> i.e. no change is required there. >>=20 >=20 > I think you are saying that a ROA is "valid" for all prefixes listed = in it, if the signing EE cert is=20 > "valid" for each of those prefixes (in accordance with the alternate = validation method). > I.e., there is no such thing as 'the ROA is (partially) valid for some = of the listed prefixes'. > Does not harm to include some statement this effect in your I-D. I agree with the original observation made by Geoff and George about = brittleness wrt ROA validation and resources in the chain that are = irrelevant. If I could paraphrase the method B how I see it from a top-down = perspective, using a modified example where 'Certificate 2' has a mixup = of an AS resource: Certificate 1: {10.0.0.0/12, AS64501, AS64505, AS64509} (TA = certificate) Certificate 2: {10.0.0.0/22, AS64501, AS64505, AS64511} Certificate 3: {10.0.0.0/20, AS64501, AS64509} Currently we reject certificate 2 and everything under it..=20 But, the way I see it in the RPKI world is that these CA certificates = just tie a bunch of resources to a key pair. They don't actually try to = make any other authoritative statements over these resources. So in = other words I would be perfectly happy to take change the semantics and = *warn* about any over-claiming resources, and accept only the *union* of = resources between a certificate and its parent. In this case that would = result in: Certificate 1: {10.0.0.0/12, AS64501, AS64505, AS64509} (TA = certificate) Certificate 2: {10.0.0.0/22, AS64501, AS64505} (discard: AS64511) Certificate 3: {10.0.0.0/20, AS64501} (discard: AS64509) In the RPKI the more meaningful statements about resources are all done = with EE certificates. Signed objects like ROAs and Ghostbusters have a = corresponding EE certificate, and BGPSec certificates are also EE = certificates. These are the things that actually make the interesting = statements like "valid holder of resource X proclaims that.. etc". So, summarising I think the simplest approach here could be just accept = the union of resources for CA certificates, but insist that EE = certificates are not over-claiming. So this would then be perfectly valid: EE Certificate: {10.0.0.0/20}=20 For ROA: listing prefix 10.0.0.0/20 only Others can speak for themselves (Rob?, David?), but my impression was = that they were actually also open to this general idea although it needs = maturing. (as opposed to the joins below) > We discussed the possibility of ROA over-claiming earlier.=20 > The above is not accommodative of that. And I think that is also OK = for now. > We can revisit if robustness to ROA over-claiming is something=20 > that interests anyone else on this list. We are currently fate sharing authorisations for different prefixes and = the same ASN on ROAs. We have an average of about 3 prefixes per ROA, so = this allows us to reduce the number of ROAs we publish to about 1/3rd of = what we would need otherwise. There is a lot of complexity and controversy in partially accepting = ROAs, or even having splits and joins and accepting part here, part = there, or (more complicated) having to join validation paths. It becomes = difficult to troubleshoot issues and report meaningfully about errors. I = see some possibilities here, but I am not convinced. I think it would = mainly save in the number of certificates and objects needed, but in the = end this is all handled by tools. I don't think they (should) care too = much about these numbers (a factor of 3 or something) relative to the = other costs. So all in all, I think we're probably better off keeping things simpler = and in our case create more ROAs: i.e. one for each prefix. Tim > Thanks. > Sriram =20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Apr 21 20:55:12 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E78B1A004A for ; Mon, 21 Apr 2014 20:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.063 X-Spam-Level: X-Spam-Status: No, score=-102.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZowkrJMpw6h for ; Mon, 21 Apr 2014 20:55:06 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:b:98::120]) by ietfa.amsl.com (Postfix) with SMTP id 6BA051A004B for ; Mon, 21 Apr 2014 20:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=9jLAxIvgkPLe0a5H/7CxPwzCAZWlfv/NUr+GfE3Yzec=; b=YhCVgE1zptUbPx46l9G+gGmw/GMhXHDgdk1LXwoaUcasgLOxPIYtDPDFWESSugUy1XRKwzSvb137T YzmvBA1RD0E3sV7TmrRwbACR37o2ywo7xbekyENCY/U8hYQP/D9uYxi7AwiM5IoA1UTTPbL99ImH/M cylobandFqXxY8qg= Received: from NXMDA1.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Tue, 22 Apr 2014 13:54:58 +1000 (EST) Received: from [202.158.221.39] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 22 Apr 2014 13:54:58 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Geoff Huston In-Reply-To: Date: Tue, 22 Apr 2014 13:55:09 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: <5C076C44-9200-4A07-A1BE-3888DCC9BC36@apnic.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/2VKm1zaxGi1nuvDSsQssKchfe18 Cc: "sidr@ietf.org" Subject: Re: [sidr] comments on draft-ietf-sidr-rfc6485bis X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 03:55:11 -0000 On 14 Apr 2014, at 11:21 pm, Sandra Murphy wrote: > Speaking as regular ol' member >=20 > Some comments on draft-ietf-sidr-rfc6485bis-01.txt >=20 > Most of my comments are related to the attempt to add a new OID to > RFC6485, which previously had only one to specify. >=20 > * The signature algorithm used in certificates, CRLs, and signed > objects is RSA Public-Key Cryptography Standards (PKCS) #1 > Version 1.5 (sometimes referred to as "RSASSA-PKCS1-v1_5") = from > Section 5 of [RFC4055]. >=20 > Except that the signed object signature algorithm OID will be > rsaEncryption which I think is still PKCS#1v1.5, but is not in section > 5 of rfc4055. =20 I am unsure what you mean here. Perhaps if you send what you think the = text should say it would be helpful. >=20 > Hashing algorithms > are not identified individually in certificates and CRLs, > ... > For generating and verifying certificates, and CRLs the hashing and > digital signature algorithms are referred to together, >=20 > And the PKCS/CMRF signatures? See comment below. I think this was a failing in RFC6485 itself.=20 RFC6487 has forward pointers to RFC6485 in the algorithm section for = PKCS , but the text in RFC64845 refers to "certificates, CRLs and signed = objects". Do you have alternative text to suggest here? >=20 >=20 > Locations for this OID are as follows: >=20 > The previous text talks about three OIDs, so "this" OID is ambiguous. > Perhaps you just meant "The places where OIDs appear are:". > The text that follows would then say "an OID appears", not "the > OID appears". Not only is there more than one OID to mention, in some > of those messages, more than one OID appears in the message. what about: "The locations where algorithm object identifiers appear are:" >=20 > [[I think this discussion of "where" could go better above the two = prior > paragraphs that talk about what-goes-in-the-where.]] >=20 > In a certification request, the OID appears in the PKCS #10 > signatureAlgorithm field [RFC2986], or in the Certificate Request > Message Format (CRMF) POPOSigningKey signature field [RFC4211]. >=20 > The PKCS and CRMF uses of crypto algorithms are not mentioned in the > discussion preceding. The change in the bis draft were limited to the CMS issue. The addition = of explicit mention of PCKS #10 and CRMF would be a further change to = this document. It seems to me to be a logical change. > I presume the "the OID" text is left over from > the original RFC6485 and what was meant was the = sha256WithRSAEncryption > OID. Most of this draft is RFC6485, including this. I also presume that the = value of the OID in this case is sha256WithRSAEncryption. > It looks to me like RC2986 leaves that choice free, so this > text need to say which >=20 > For CMS SignedData, the object identifier and parameters for SHA-256 > in [RFC5754] MUST be used for the SignedData digestAlgorithms field > and the SignerInfo digestAlgorithm field when generating and > verifying CMS SignedData objects. > ... > RPKI implementations MUST accept CMS SignedData objects that use the > object identifier and parameters for either rsaEncryption or > sha256WithRSAEncryption for the SignerInfo signatureAlgorithm field > when verifying CMS SignedData objects. >=20 > I presume accepting sha256WithRSAEncryption is backward compatibiilty > - just in case some new implementation should appear that implements > RFC6485, before this spec is published, right? Since all known > implementations currently follow this spec? Personal opinion: maybe > we should not permit the backward compatibility with some hypothetical > implementation in this short interval, so future coding errors get > caught? Or at least note the reason, so future readers are not = confused? I am already hopelessly confused by this situation, and I'm in no = position to answer this. The issue was noted first by Andrew Chi and David Mandelberg, and Rob = Austein provided text, which formed the basis of this bis draft. As to = the precise nature of the backward compatibility, and what this spec = should or should not allow, I'm afraid that I have no useful opinion. I would like to hope that Rob, Andrew and David are carefully reading = this thread and will respond to your query better than I can. >=20 > Nits: >=20 > Repetition: >=20 > Hashing algorithms > are not identified individually in certificates and CRLs, as > the identity of the hashing algorithm is combined with the > identity of the digital signature algorithm. > ... >=20 > For generating and verifying certificates, and CRLs the hashing and > digital signature algorithms are referred to together, >=20 > I presume this is just repetition, right? I always wonder about > repeated messages - is there a difference I did not notice? So for > those similarly anxious, maybe a "as noted above"? (Or leave out the > first mention - that section is talking about what algorithms there > are to specify, you could leave it to later to talk about the format = of > expressing a particular choice of algorithm. Quibble.) This was text that was originally in RFC6485. I am unsure why there is = repetition, but I believe that the repetition is at worst gratuitous = rather than mutually inconsistent.=20 >=20 > For CMS SignedData, the object identifier and parameters for SHA-256 > in [RFC5754] MUST be used for the SignedData digestAlgorithms field > > ... > In CMS SignedData, the OID appears in each SignerInfo > signatureAlgorithm field, the SignerInfo digestAlgorithm field, > and in the SignedData digestAlgorithms [RFC5652]; and, >=20 > I presume this is just repetition (reinforcement, for completeness), > right? (There's no difference I just don't see?) >=20 I thought the first says what OID value is to be used and the second = says where this OID appears. > truly nitty: >=20 > FROM > For generating and verifying certificates, and CRLs the hashing > TO > For generating and verifying certificates and CRLs, the hashing yup! Geoff From nobody Fri Apr 25 09:05:42 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E231A0650 for ; Fri, 25 Apr 2014 09:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmWv_ERjQw4A for ; Fri, 25 Apr 2014 09:05:30 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 3586B1A0654 for ; Fri, 25 Apr 2014 09:05:22 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id CBEF328B0052 for ; Fri, 25 Apr 2014 12:05:15 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id B28DB1F803D; Fri, 25 Apr 2014 12:05:15 -0400 (EDT) From: Sandra Murphy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Apr 2014 12:05:14 -0400 Message-Id: To: "sidr@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/JPRnCK6aAFX3272NZ9U6cP44gvw Cc: Sandra Murphy Subject: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 16:05:33 -0000 The authors of draft-huston-rpki-validation-01.txt, RPKI Validation = Reconsidered, have requested wg adoption. See http://tools.ietf.org/html/draft-huston-rpki-validation-01. Please do respond to the list as to whether you support the wg adopting = this as a work item. You do not need to comment on the content of this = draft at this time. You are asked to indicate if you think that this is = work that the wg should be doing and whether this draft is an acceptable = starting point. Adding whether you can/will review or not is useful. Note that active support is required for adoption. Silence is a vote = against adoption. This adoption call will end on 9 May 2014. --Sandy, speaking as wg co-chair= From nobody Fri Apr 25 12:06:57 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07C21A06C3 for ; Fri, 25 Apr 2014 12:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axXxeSL8idcT for ; Fri, 25 Apr 2014 12:06:49 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 51F0E1A06D4 for ; Fri, 25 Apr 2014 12:06:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WdlSL-0003W4-He; Fri, 25 Apr 2014 19:06:41 +0000 Date: Fri, 25 Apr 2014 12:06:40 -0700 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/z72LZDUugRank7BMzCwqIPS8azs Cc: sidr wg list Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 19:06:53 -0000 i really hate to side with dr kent :) i am unsure of this is a useful work item. please explain how it is other than a complex (i.e. dangerous) patch to accommodate sloppy operational praactices by a CA. make the protocol complex and you are vulnerable forever. sloppy CA ops practices can always be remedied. so which is the worse problem? randy From nobody Fri Apr 25 16:53:27 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521C91A06DC for ; Fri, 25 Apr 2014 16:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Y4haIfgeRjh for ; Fri, 25 Apr 2014 16:53:21 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id D0D9C1A06B9 for ; Fri, 25 Apr 2014 16:53:21 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 5AFC828B003D for ; Fri, 25 Apr 2014 19:53:15 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 435B41F803D; Fri, 25 Apr 2014 19:53:15 -0400 (EDT) From: Sandra Murphy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Apr 2014 19:53:14 -0400 Message-Id: To: "sidr@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/EP1p_IQLRtgndPHKfVvvK2TqRqA Cc: Sandra Murphy Subject: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 23:53:23 -0000 The authors of BGP Prefix Origin Validation State Extended Community, = draft-ietf-sidr-origin-validation-signaling-04 have requested a WGLC. This message begins a two week WGLC, to end on 9 May 2014. =20 The draft is available at = http://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling. Please do send comments to the list, indicating whether you do or do not = believe that the draft is ready for publication. --Sandy, speaking as wg co-chair= From nobody Fri Apr 25 23:28:26 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598111A041A for ; Fri, 25 Apr 2014 23:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cWjHi3Arelk for ; Fri, 25 Apr 2014 23:28:23 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id E7C811A0456 for ; Fri, 25 Apr 2014 23:28:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1Wdw5s-0004nr-VH; Sat, 26 Apr 2014 06:28:13 +0000 Date: Fri, 25 Apr 2014 23:28:13 -0700 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/DWQXG44Z-CTlRX7bYPynoEzQDME Cc: sidr wg list Subject: Re: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Apr 2014 06:28:24 -0000 from a running router policy-statement rpki { term valid { from { protocol bgp; validation-database valid; } then { validation-state valid; community add whatever-the-heck-i-want; accept; } } there is an invalid drop policy-statement too, but no sense for it to set a community as it ain't goin' nowhere. randy From nobody Mon Apr 28 06:17:24 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E131A09E8 for ; Mon, 28 Apr 2014 06:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgkcoCJSbCCV for ; Mon, 28 Apr 2014 06:17:21 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 37A851A047C for ; Mon, 28 Apr 2014 06:17:21 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 88CE628B003D; Mon, 28 Apr 2014 09:17:20 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 642B31F8036; Mon, 28 Apr 2014 09:17:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Mon, 28 Apr 2014 09:17:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Randy Bush X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/T4KSTc6GZsh2pHY1HEdVD3uBNyw Cc: sidr wg list , Sandra Murphy Subject: Re: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 13:17:22 -0000 Could you say please whether this means you support publication or you = do not? --Sandy On Apr 26, 2014, at 2:28 AM, Randy Bush wrote: > from a running router >=20 > policy-statement rpki { > term valid { > from { > protocol bgp; > validation-database valid; > } > then { > validation-state valid; > community add whatever-the-heck-i-want; > accept; > } > } >=20 > there is an invalid drop policy-statement too, but no sense for it to > set a community as it ain't goin' nowhere. >=20 > randy From nobody Mon Apr 28 11:21:44 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F901A6FB5 for ; Mon, 28 Apr 2014 11:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEWcTPeeB74d for ; Mon, 28 Apr 2014 11:21:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7341A6FB2 for ; Mon, 28 Apr 2014 11:21:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WeqBP-0002AH-BQ; Mon, 28 Apr 2014 18:21:40 +0000 Date: Mon, 28 Apr 2014 21:21:36 +0300 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/CcDOMuACH7HxYQgsRB4BtpNZxrU Cc: sidr wg list Subject: Re: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 18:21:43 -0000 > Could you say please whether this means you support publication or you > do not? > >> from a running router >> >> policy-statement rpki { >> term valid { >> from { >> protocol bgp; >> validation-database valid; >> } >> then { >> validation-state valid; >> community add whatever-the-heck-i-want; >> accept; >> } >> } >> >> there is an invalid drop policy-statement too, but no sense for it to >> set a community as it ain't goin' nowhere. because the goal of this draft can already be reached simply through use of existing means, i do not support publication. i am not strongly opposed. it's just one more bit of ietf work that is not obviously needed. randy From nobody Mon Apr 28 12:25:40 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C236D1A6F42 for ; Mon, 28 Apr 2014 12:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAaO4afCm-7H for ; Mon, 28 Apr 2014 12:25:34 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) by ietfa.amsl.com (Postfix) with ESMTP id CF27F1A04F1 for ; Mon, 28 Apr 2014 12:25:33 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x48so6751770wes.38 for ; Mon, 28 Apr 2014 12:25:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qa4y1Wz78UlvMj1HvJVQPMfOqgjdmba/w2jG5ck8TXA=; b=O9k8Zop3+2zcnH6oJM9WSHYhtnn5DEnIfUx1UO2gjhTFoiFX0r04P+ht5z2Bl/rjZx 5H4vM+LB/GNebsJ4uC8JAE79TZ6t7/oriTNhq/MBYwlmv8mPuT3aDub18BUYGygn0JEk 5iR4p7NouX5wepwGXC7WKiJ9b2W2F0lZEilVvbwFHz3SrRtpLQEf57mboF7gjHL53Z4E 4ez2rUI4ravNEQxpHrN98SULyW5q6TCPp2y8nuWbaDff3dQ+6eq7FdgEvR0T73T9A82+ JfagdUPJEomdsJUFeq7Dxo4aXb+cVM0QLvXK83JiloSGZpXJMaEl8f3mOazOFM1xiLfL kfsw== X-Gm-Message-State: ALoCoQmnMKY36KhMaZn7mIWowUz+7Bldqvhluiky6F7IFyvmuI+s3TX7zCSTzvIaVXU8juEm56I8 MIME-Version: 1.0 X-Received: by 10.180.76.244 with SMTP id n20mr16913725wiw.4.1398713132558; Mon, 28 Apr 2014 12:25:32 -0700 (PDT) Received: by 10.194.54.162 with HTTP; Mon, 28 Apr 2014 12:25:32 -0700 (PDT) X-Originating-IP: [98.244.98.35] In-Reply-To: References: Date: Mon, 28 Apr 2014 15:25:32 -0400 Message-ID: From: Warren Kumari To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/1GpIJGHkCrh06O3hLqU5xknkbEY Cc: sidr wg list , Sandra Murphy Subject: Re: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 19:25:36 -0000 On Mon, Apr 28, 2014 at 2:21 PM, Randy Bush wrote: >> Could you say please whether this means you support publication or you >> do not? >> >>> from a running router >>> >>> policy-statement rpki { >>> term valid { >>> from { >>> protocol bgp; >>> validation-database valid; >>> } >>> then { >>> validation-state valid; >>> community add whatever-the-heck-i-want; >>> accept; >>> } >>> } >>> >>> there is an invalid drop policy-statement too, but no sense for it to >>> set a community as it ain't goin' nowhere. And from one of the IETF meeting routers: community RPKI_Invalid members 56554:102; community RPKI_Unknown members 56554:103; community RPKI_Valid members 56554:101; policy-statement RPKI-Primary { term valid { from { protocol bgp; validation-database valid; } then { local-preference 210; validation-state valid; community add RPKI_Valid; } } term invalid { from { protocol bgp; validation-database invalid; } then { local-preference 190; validation-state invalid; community add RPKI_Invalid; } } term unknown { from { protocol bgp; validation-database unknown; } then { local-preference 200; validation-state unknown; community add RPKI_Unknown; } } } I don't really see how the proposal (which is at least concise!) is better / makes my life easier -- it seems like syntactic sugar to me, but not actually harmful. I don't care if it gets published or not. > > because the goal of this draft can already be reached simply through use > of existing means, i do not support publication. > i am not strongly > opposed. it's just one more bit of ietf work that is not obviously > needed. ... and this is the bit I'm actually responding to -- it is unusual for an author to not support publication of their own document, and am a little confused what it means. How should the chairs interpret this -- It is a stronger statement if an author says that than if a random participant does? W > > randy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Apr 28 13:15:09 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6CB1A6FA8 for ; Mon, 28 Apr 2014 13:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f4t86CjGAbP for ; Mon, 28 Apr 2014 13:14:59 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 7B78C1A03FC for ; Mon, 28 Apr 2014 13:14:59 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id B1D5221363F; Mon, 28 Apr 2014 16:14:58 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 3307D213683; Mon, 28 Apr 2014 16:14:58 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 28 Apr 2014 16:14:58 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.7]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0347.000; Mon, 28 Apr 2014 16:14:57 -0400 From: Andy Newton To: Randy Bush Thread-Topic: [sidr] WG adoption poll for draft-huston-rpki-validation-01 Thread-Index: AQHPYKA/BuQnGyTcK0qX/VzTcqgRlZsi9McAgATKE4A= Date: Mon, 28 Apr 2014 20:14:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.30.37] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/Ddpr8wypYJaJH6lNy5-C9mPewLk Cc: sidr wg list , Sandra Murphy Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 20:15:02 -0000 I support the adoption of this draft, as it makes the operations of a CA le= ss problematic. I also 100% disagree with Randy=92s view that it adds complexity. To the co= ntrary, it lessens complexity, aids flexibility and decreases fragility. -andy On Apr 25, 2014, at 3:06 PM, Randy Bush wrote: > i really hate to side with dr kent :) >=20 > i am unsure of this is a useful work item. please explain how it is > other than a complex (i.e. dangerous) patch to accommodate sloppy > operational praactices by a CA. =20 >=20 > make the protocol complex and you are vulnerable forever. sloppy CA > ops practices can always be remedied. so which is the worse problem? >=20 > randy >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Apr 28 14:45:47 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6111A8831; Mon, 28 Apr 2014 14:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqxfWjKCbZUr; Mon, 28 Apr 2014 14:45:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE6F1A6FB7; Mon, 28 Apr 2014 14:45:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140428214539.3688.13293.idtracker@ietfa.amsl.com> Date: Mon, 28 Apr 2014 14:45:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/x0s6SDtNS2McpZnTXoWPTMAiBSw Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-cps-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 21:45:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) Authors : Stephen Kent Derrick Kong Karen Seo Filename : draft-ietf-sidr-cps-04.txt Pages : 44 Date : 2014-04-28 Abstract: This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-cps/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-cps-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-cps-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 28 17:11:24 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B776B1A8844 for ; Mon, 28 Apr 2014 17:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0M0wTWCwkDB for ; Mon, 28 Apr 2014 17:11:14 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id 58D341A8843 for ; Mon, 28 Apr 2014 17:11:14 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id fp1so4156815pdb.20 for ; Mon, 28 Apr 2014 17:11:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=SYdgWtsDJyyXbQtF2wV5A/JCDl5MaKYBFb7UenGjKnQ=; b=j/0aQvcxYixFU3rb/Myka4YEHoFFAs7/E16rKQmJFBbGHBaOWjsVp9VH5BKI7K2ZU9 qUe/Z8WBou9yvkXfplyKRY0Ejq4Q5wq97L4zE/ucOBPUkp4krpnn0haoJ9GSWNDpXB24 uyL/F2aizKuXJQiLmirYNkiDXDvj29yVkBC5B/YLi/4h6w6jAedsAw/+vpNNGx6eMd6X FH9CzDoQTWDiw0ogYC/Q/9uF9E8lokzx5g0d4ta4JMZ7Pq8SNZsp+mFhllnV/xqb4Zhu 8qd/eMSHnacCvJNp8sFJlx40F9fv1Sd8if/GkLBW/uh/b+CffhawfCL3b7vJUGYBM3u8 07rw== X-Gm-Message-State: ALoCoQkOWasMtCK9fKQdHndlt76LpE4B70PKvX96srWHhO//3MgLuIskVoo7vlhCW2OEfmX7tPA8 MIME-Version: 1.0 X-Received: by 10.66.230.193 with SMTP id ta1mr28938528pac.29.1398730273487; Mon, 28 Apr 2014 17:11:13 -0700 (PDT) Received: by 10.70.54.230 with HTTP; Mon, 28 Apr 2014 17:11:13 -0700 (PDT) X-Originating-IP: [2001:dc0:a000:4:c542:8fd7:d10a:b85c] In-Reply-To: References: Date: Tue, 29 Apr 2014 10:11:13 +1000 Message-ID: From: George Michaelson To: "sidr@ietf.org" Content-Type: multipart/alternative; boundary=047d7b15abb116924904f82345e8 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/agWLrhJnoKgdgpuZrPakxCTtyuE Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 00:11:20 -0000 --047d7b15abb116924904f82345e8 Content-Type: text/plain; charset=UTF-8 I would like to see the WG discuss validation. I think there are inherent risks in the current model, which could be avoided if we had a more nuanced understanding of the validity of any given resource under consideration. So as a co-author of this draft its hardly surprising I support adoption, because I want us to have a real conversation. -George, speaking as co-author of the draft. On Sat, Apr 26, 2014 at 2:05 AM, Sandra Murphy wrote: > The authors of draft-huston-rpki-validation-01.txt, RPKI Validation > Reconsidered, have requested wg adoption. > > See http://tools.ietf.org/html/draft-huston-rpki-validation-01. > > Please do respond to the list as to whether you support the wg adopting > this as a work item. You do not need to comment on the content of this > draft at this time. You are asked to indicate if you think that this is > work that the wg should be doing and whether this draft is an acceptable > starting point. Adding whether you can/will review or not is useful. > > Note that active support is required for adoption. Silence is a vote > against adoption. > > This adoption call will end on 9 May 2014. > > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --047d7b15abb116924904f82345e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would like to see the WG discuss validation. I think the= re are inherent risks in the current model, which could be avoided if we ha= d a more nuanced understanding of the validity of any given resource under = consideration.

So as a co-author of this draft its hardly surprising I supp= ort adoption, because I want us to have a real conversation.

=
-George, speaking as co-author of the draft.


On Sat, Apr 26, 2014 at 2:05 AM, Sandra = Murphy <sandy@tislabs.com> wrote:
The authors of draft-huston-rpki-validation-01.txt, RPKI Validation Reconsi= dered, have requested wg adoption.

See http://tools.ietf.org/html/draft-huston-rpki-validation-0= 1.

Please do respond to the list as to whether you support the wg adopting thi= s as a work item. =C2=A0You do not need to comment on the content of this d= raft at this time. =C2=A0You are asked to indicate if you think that this i= s work that the wg should be doing and whether this draft is an acceptable = starting point. =C2=A0Adding whether you can/will review or not is useful.<= br>
Note that active support is required for adoption. =C2=A0Silence is a vote = against adoption.

This adoption call will end on 9 May 2014.

--Sandy, speaking as wg co-chair
_______________________________________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

--047d7b15abb116924904f82345e8-- From nobody Mon Apr 28 17:42:34 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1981A8852 for ; Mon, 28 Apr 2014 17:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6gtJGybFy3d for ; Mon, 28 Apr 2014 17:42:29 -0700 (PDT) Received: from so-mailgw.apnic.net (so-mailgw.apnic.net [IPv6:2001:dd8:a:3::230]) by ietfa.amsl.com (Postfix) with SMTP id 79A2A1A8844 for ; Mon, 28 Apr 2014 17:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=kugzfUKovPT+YnrHeOe7Qlv0mBdVlB6Z1zArAfd/oW8=; b=4sl/yjqvhbdr3FvgHdiyi8s86/0VDJx7DX6qNvIKIJNVfnwPTB7kbxLuSESF2UohRw74YTON9wgcs JKMAN2PlnVocyUB6aEmN7QuIYgcdMOXdIGHKYtbwBvVfXuLaqA8f6MBjD9mysbhM5lw/c06Xbdx0VH Hj7OKuLddFFk3nIk= Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by so-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Tue, 29 Apr 2014 10:40:56 +1000 (EST) Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 29 Apr 2014 10:42:24 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Geoff Huston In-Reply-To: Date: Tue, 29 Apr 2014 10:42:22 +1000 Content-Transfer-Encoding: quoted-printable Message-ID: <2962E43D-AD09-45FF-9854-12BE3E4C14A7@apnic.net> References: To: "sidr@ietf.org" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/eXwaSNtktCTVs9u-toCIUXydzBM Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 00:42:31 -0000 Obviously, I also support this call for adoption, for the reasons George = has outlined here. Geoff On 29 Apr 2014, at 10:11 am, George Michaelson wrote: > I would like to see the WG discuss validation. I think there are = inherent risks in the current model, which could be avoided if we had a = more nuanced understanding of the validity of any given resource under = consideration. >=20 > So as a co-author of this draft its hardly surprising I support = adoption, because I want us to have a real conversation. >=20 > -George, speaking as co-author of the draft. >=20 >=20 > On Sat, Apr 26, 2014 at 2:05 AM, Sandra Murphy = wrote: > The authors of draft-huston-rpki-validation-01.txt, RPKI Validation = Reconsidered, have requested wg adoption. >=20 > See http://tools.ietf.org/html/draft-huston-rpki-validation-01. >=20 > Please do respond to the list as to whether you support the wg = adopting this as a work item. You do not need to comment on the content = of this draft at this time. You are asked to indicate if you think that = this is work that the wg should be doing and whether this draft is an = acceptable starting point. Adding whether you can/will review or not is = useful. >=20 > Note that active support is required for adoption. Silence is a vote = against adoption. >=20 > This adoption call will end on 9 May 2014. >=20 > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Apr 29 07:10:54 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0881A0907; Tue, 29 Apr 2014 07:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nbj6XLFAvL4M; Tue, 29 Apr 2014 07:10:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA441A08E0; Tue, 29 Apr 2014 07:10:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140429141007.21954.23015.idtracker@ietfa.amsl.com> Date: Tue, 29 Apr 2014 07:10:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/YH2bLJd63NAAUHb5HmHv1y9YG14 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 14:10:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Router Keying for BGPsec Authors : Sean Turner Keyur Patel Randy Bush Filename : draft-ietf-sidr-rtr-keying-05.txt Pages : 10 Date : 2014-04-29 Abstract: BGPsec-speaking routers are provisioned with private keys to sign BGP messages; the corresponding public keys are published in the global RPKI (Resource Public Key Infrastructure) thereby enabling verification of BGPsec messages. This document describes two ways of provisioning the public-private key-pairs: router-driven and operator-driven. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 29 07:14:36 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532951A08F0 for ; Tue, 29 Apr 2014 07:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKUM8t0wSK0I for ; Tue, 29 Apr 2014 07:14:29 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [67.18.70.8]) by ietfa.amsl.com (Postfix) with ESMTP id 459191A08EE for ; Tue, 29 Apr 2014 07:14:29 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id E38631B0F29F0; Tue, 29 Apr 2014 09:14:27 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway15.websitewelcome.com (Postfix) with ESMTP id C913A1B0F29A6 for ; Tue, 29 Apr 2014 09:14:27 -0500 (CDT) Received: from [96.231.225.192] (port=60509 helo=192.168.1.4) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wf8ni-0000OF-2j for sidr@ietf.org; Tue, 29 Apr 2014 09:14:26 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Sean Turner In-Reply-To: <20140429141007.21954.23015.idtracker@ietfa.amsl.com> Date: Tue, 29 Apr 2014 10:14:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <99F6C803-C724-430F-AF95-461CBE778C05@ieca.com> References: <20140429141007.21954.23015.idtracker@ietfa.amsl.com> To: sidr@ietf.org X-Mailer: Apple Mail (2.1874) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.225.192 X-Exim-ID: 1Wf8ni-0000OF-2j X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.4) [96.231.225.192]:60509 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/8FFRpasGqaMUiCOiyHScRe2DPyg Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 14:14:30 -0000 Hi, This version includes a new section 4 that addresses key management = (i.e., keep a timer to make sure your cert doesn=92t expire). There=92s = also some editorial/readability corrections. Please review as the = authors think this version pretty much wraps up what we wanted to say. spt On Apr 29, 2014, at 10:10, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Secure Inter-Domain Routing Working = Group of the IETF. >=20 > Title : Router Keying for BGPsec > Authors : Sean Turner > Keyur Patel > Randy Bush > Filename : draft-ietf-sidr-rtr-keying-05.txt > Pages : 10 > Date : 2014-04-29 >=20 > Abstract: > BGPsec-speaking routers are provisioned with private keys to sign = BGP > messages; the corresponding public keys are published in the global > RPKI (Resource Public Key Infrastructure) thereby enabling > verification of BGPsec messages. This document describes two ways = of > provisioning the public-private key-pairs: router-driven and > operator-driven. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Apr 29 08:14:10 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A421A0564 for ; Tue, 29 Apr 2014 08:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C__32_r-Fstm for ; Tue, 29 Apr 2014 08:14:06 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id BD2B01A04AC for ; Tue, 29 Apr 2014 08:14:05 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 8D2391652E7; Tue, 29 Apr 2014 11:14:04 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id DECBB1652DA; Tue, 29 Apr 2014 11:14:03 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 29 Apr 2014 11:14:03 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.7]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 29 Apr 2014 11:14:03 -0400 From: Mark Kosters To: George Michaelson , "sidr@ietf.org" Thread-Topic: [sidr] WG adoption poll for draft-huston-rpki-validation-01 Thread-Index: AQHPYKA/gy6sGYZaQ06zPQCb3QPsEJsoAN2AgAC5I4A= Date: Tue, 29 Apr 2014 15:14:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.1.30.37] Content-Type: multipart/alternative; boundary="_000_CF8539D5F31FEmarkkarinnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/kU_6ZWFEo_77YCu-Bo-j78lfSG4 Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 15:14:07 -0000 --_000_CF8539D5F31FEmarkkarinnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Mark From: George Michaelson > Date: Monday, April 28, 2014 at 8:11 PM To: "sidr@ietf.org" > Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 I would like to see the WG discuss validation. I think there are inherent r= isks in the current model, which could be avoided if we had a more nuanced = understanding of the validity of any given resource under consideration. So as a co-author of this draft its hardly surprising I support adoption, b= ecause I want us to have a real conversation. -George, speaking as co-author of the draft. --_000_CF8539D5F31FEmarkkarinnet_ Content-Type: text/html; charset="us-ascii" Content-ID: <12DC53B4664294498279B068D6879915@corp.arin.net> Content-Transfer-Encoding: quoted-printable
+1

Mark

From: George Michaelson <ggm@algebras.org>
Date: Monday, April 28, 2014 at 8:1= 1 PM
To: "sidr@ietf.org" <sidr@i= etf.org>
Subject: Re: [sidr] WG adoption pol= l for draft-huston-rpki-validation-01

I would like to see the WG discuss validation. I think the= re are inherent risks in the current model, which could be avoided if we ha= d a more nuanced understanding of the validity of any given resource under = consideration.

So as a co-author of this draft its hardly surprising I support adopti= on, because I want us to have a real conversation.

-George, speaking as co-author of the draft.


 --_000_CF8539D5F31FEmarkkarinnet_-- From nobody Tue Apr 29 08:48:46 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64C01A090B for ; Tue, 29 Apr 2014 08:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORcXyDTi359s for ; Tue, 29 Apr 2014 08:48:43 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 45F201A08F0 for ; Tue, 29 Apr 2014 08:48:43 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1WfAGt-0003Il-VJ; Tue, 29 Apr 2014 17:48:41 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-67.ripe.net) by nene.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WfAGt-0003qL-R8; Tue, 29 Apr 2014 17:48:39 +0200 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Tue, 29 Apr 2014 17:48:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54275034-A619-4228-ACD1-B99402649BBE@ripe.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1510) X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.6 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719b2b8be220e2ef88277b662b525607342 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/hXLvA4L5VWSJx-PKLEvVeaq5poY Cc: "sidr@ietf.org" Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 15:48:44 -0000 Hi, I read the draft and I support adoption. I think this addresses a real problem both in the transfer case = described in the document, and in fragility wrt unintended changes in = the hierarchical RPKI. This could be considered bad CA ops, but even = then I think the impact on the children should be reduced. Furthermore, = as a general approach I agree with the proposed model. I understand this is a deviation from the existing RFC3779 validation = algorithms that are currently implemented (obviously the point of this = proposal), but while this will therefore require work to implement I see = absolutely no problems doing so in the RP tool that we maintain. For = what it's worth I think our work for this can be counted in days tops. Tim On Apr 25, 2014, at 6:05 PM, Sandra Murphy wrote: > The authors of draft-huston-rpki-validation-01.txt, RPKI Validation = Reconsidered, have requested wg adoption. >=20 > See http://tools.ietf.org/html/draft-huston-rpki-validation-01. >=20 > Please do respond to the list as to whether you support the wg = adopting this as a work item. You do not need to comment on the content = of this draft at this time. You are asked to indicate if you think that = this is work that the wg should be doing and whether this draft is an = acceptable starting point. Adding whether you can/will review or not is = useful. >=20 > Note that active support is required for adoption. Silence is a vote = against adoption. >=20 > This adoption call will end on 9 May 2014. >=20 > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Apr 29 09:18:13 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C6A1A08DB for ; Tue, 29 Apr 2014 09:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3_tjCE3jfji for ; Tue, 29 Apr 2014 09:18:09 -0700 (PDT) Received: from mail.lacnic.net.uy (hermes.lacnic.net.uy [IPv6:2001:13c7:7001:4000::8]) by ietfa.amsl.com (Postfix) with ESMTP id 50C2F1A0776 for ; Tue, 29 Apr 2014 09:18:09 -0700 (PDT) Received: from hermes.lacnic.net.uy (localhost [127.0.0.1]) by mail.lacnic.net.uy (Postfix) with ESMTP id E7C7316B43A53 for ; Tue, 29 Apr 2014 13:18:05 -0300 (UYT) X-Virus-Scanned: amavisd-new at lacnic.net.uy Received: from mail.lacnic.net.uy ([127.0.0.1]) by hermes.lacnic.net.uy (mail.lacnic.net.uy [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB4gousjkFoH for ; Tue, 29 Apr 2014 13:18:05 -0300 (UYT) Received: from 87-7-200.lacnic.net.uy (unknown [IPv6:2001:13c7:7001:7000:f0d7:d8e3:86df:d7e1]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.lacnic.net.uy (Postfix) with ESMTPSA id 39C2816B43A4F for ; Tue, 29 Apr 2014 13:18:05 -0300 (UYT) Message-ID: <535FD0BD.9010304@lacnic.net> Date: Tue, 29 Apr 2014 13:18:05 -0300 From: =?ISO-8859-1?Q?Sof=EDa_Silva_Berenguer?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/IdBTemNE8naoqTtMglerEpdwJnI Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 16:18:11 -0000 I support the adoption of this draft. Kind regards, Ing. Sofía Silva Berenguer Senior SSR Engineer PGP Key ID: 0xAAD4EB5F LACNIC - www.lacnic.net Latin American and Caribbean Internet Address Registry Rambla República de México 6125 Montevideo - Uruguay +598 2604 2222 ext 4408 El 25/04/14 13:05, Sandra Murphy escribió: > The authors of draft-huston-rpki-validation-01.txt, RPKI Validation Reconsidered, have requested wg adoption. > > See http://tools.ietf.org/html/draft-huston-rpki-validation-01. > > Please do respond to the list as to whether you support the wg adopting this as a work item. You do not need to comment on the content of this draft at this time. You are asked to indicate if you think that this is work that the wg should be doing and whether this draft is an acceptable starting point. Adding whether you can/will review or not is useful. > > Note that active support is required for adoption. Silence is a vote against adoption. > > This adoption call will end on 9 May 2014. > > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Tue Apr 29 10:01:51 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085B41A04B6 for ; Tue, 29 Apr 2014 10:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTSrnsFaSjBI for ; Tue, 29 Apr 2014 10:01:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by ietfa.amsl.com (Postfix) with ESMTP id E89031A0290 for ; Tue, 29 Apr 2014 10:01:36 -0700 (PDT) Received: from BLUPR09MB104.namprd09.prod.outlook.com (10.255.212.24) by BLUPR09MB102.namprd09.prod.outlook.com (10.255.212.141) with Microsoft SMTP Server (TLS) id 15.0.929.12; Tue, 29 Apr 2014 17:01:34 +0000 Received: from BLUPR09MB104.namprd09.prod.outlook.com ([10.255.212.24]) by BLUPR09MB104.namprd09.prod.outlook.com ([10.255.212.24]) with mapi id 15.00.0929.001; Tue, 29 Apr 2014 17:01:34 +0000 From: "Sriram, Kotikalapudi" To: Sandra Murphy , "sidr@ietf.org" Thread-Topic: [sidr] WG adoption poll for draft-huston-rpki-validation-01 Thread-Index: AQHPYKBEpLgk+3/RrE24/zivQICaFpso1J3g Date: Tue, 29 Apr 2014 17:01:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] x-forefront-prvs: 0196A226D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(377454003)(51704005)(189002)(199002)(81342001)(81542001)(79102001)(99286001)(80976001)(561944002)(19580395003)(15975445006)(50986999)(20776003)(83322001)(76176999)(77982001)(54356999)(33646001)(77096999)(19580405001)(4396001)(99396002)(74662001)(31966008)(76482001)(46102001)(86362001)(92566001)(80022001)(101416001)(66066001)(87936001)(15202345003)(76576001)(2656002)(74316001)(74502001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR09MB102; H:BLUPR09MB104.namprd09.prod.outlook.com; FPR:ECDCF9B1.ACF64C26.7ADB3F07.8CE651F9.20233; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: nist.gov does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/pCUC-9rDVR6WjMufv2t8ty9e4F4 Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:01:42 -0000 I have read the draft, and offered extensive comments and discussed the con= tents with the authors on this list. I support adoption as a WG document, but would like to see=20 more discussion to further clarify the proposal and its pros/cons. Sriram >-----Original Message----- >From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of Sandra Murphy >Sent: Friday, April 25, 2014 12:05 PM >To: sidr@ietf.org >Cc: Sandra Murphy >Subject: [sidr] WG adoption poll for draft-huston-rpki-validation-01 > >The authors of draft-huston-rpki-validation-01.txt, RPKI Validation >Reconsidered, have requested wg adoption. > >See http://tools.ietf.org/html/draft-huston-rpki-validation-01. > >Please do respond to the list as to whether you support the wg adopting th= is as >a work item. You do not need to comment on the content of this draft at t= his >time. You are asked to indicate if you think that this is work that the w= g should >be doing and whether this draft is an acceptable starting point. Adding w= hether >you can/will review or not is useful. > >Note that active support is required for adoption. Silence is a vote agai= nst >adoption. > >This adoption call will end on 9 May 2014. > >--Sandy, speaking as wg co-chair >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Apr 29 10:21:51 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749171A092A for ; Tue, 29 Apr 2014 10:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3BdVC1AnQbA for ; Tue, 29 Apr 2014 10:21:48 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 856FC1A04AF for ; Tue, 29 Apr 2014 10:21:48 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id 10so458604ykt.30 for ; Tue, 29 Apr 2014 10:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QuOQ9DeDuQDAO2ESMPW9yzEar3lRerruJFLdkO1SLFo=; b=cxq4jP/1Ts9F+G/BVyZkDLhpPJJYIl6xs2ZAPD+LG2O6e52h0bU56Xrw7YvnNKZZDY JTDtmbIK2ytyvaniFgw6Rh0ZM0aS8I0pYH4NelBqFyEwGONFM9t8gE0dqDKwUJShb+qI RVgLhxsz9MnfO8nYDdyiGv4duMk0yb2F9Lekv9Ze5ztMrHJ8RWKmoH8ag5ykk9b/TqlZ iLqjFuA4CgSLNFw70rSZZW4ogjM4V3y+rlROSvdS9edd+k/Xab+ytQvgZQgBzQ8lbDlW USkcxoZdyxjwrnuk623VfHnibC4Q9LJW8RLn5PBS3h7BvnqpOd8JyLSh1UwN0wNfLXPn Es4A== X-Received: by 10.236.198.243 with SMTP id v79mr22640625yhn.87.1398792107311; Tue, 29 Apr 2014 10:21:47 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([2001:13c7:7001:7000:413a:6c5b:b970:f765]) by mx.google.com with ESMTPSA id j76sm37775732yhi.33.2014.04.29.10.21.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Apr 2014 10:21:45 -0700 (PDT) Message-ID: <535FDFA6.1010106@gmail.com> Date: Tue, 29 Apr 2014 14:21:42 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Andy Newton References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/B6oferUgbBY-rvmjIx541WnWemM Cc: Sandra Murphy , sidr wg list Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 17:21:49 -0000 I support adoption of this draft and I second all of Andy's comments. I do believe that we need to be tolerant in the operation of the CA's as we move forward in adoption of origin validation in routers. Cheers! ~Carlos On 4/28/14, 5:14 PM, Andy Newton wrote: > I support the adoption of this draft, as it makes the operations of a CA less problematic. > > I also 100% disagree with Randy’s view that it adds complexity. To the contrary, it lessens complexity, aids flexibility and decreases fragility. > > -andy > > On Apr 25, 2014, at 3:06 PM, Randy Bush wrote: > >> i really hate to side with dr kent :) >> >> i am unsure of this is a useful work item. please explain how it is >> other than a complex (i.e. dangerous) patch to accommodate sloppy >> operational praactices by a CA. >> >> make the protocol complex and you are vulnerable forever. sloppy CA >> ops practices can always be remedied. so which is the worse problem? >> >> randy >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Tue Apr 29 11:47:00 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1DE1A0515 for ; Tue, 29 Apr 2014 11:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.285 X-Spam-Level: ** X-Spam-Status: No, score=2.285 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1owdU0e0gsO for ; Tue, 29 Apr 2014 11:46:45 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id A00161A04AF for ; Tue, 29 Apr 2014 11:46:45 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,952,1389762000"; d="scan'208,217";a="283752097" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 29 Apr 2014 14:46:24 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 29 Apr 2014 14:46:44 -0400 From: "George, Wes" To: "sidr@ietf.org" Date: Tue, 29 Apr 2014 14:46:47 -0400 Thread-Topic: SIDR-AS-Migration updates? Thread-Index: Ac9j213Gqk3uMIsXT5GETUhl3eHaLw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF856BD719F32wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/beSpfoNSjbHVuYzWGrPRlCg3ZDs Subject: [sidr] SIDR-AS-Migration updates? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 18:46:46 -0000 --_000_CF856BD719F32wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGN1cnJlbnQgdmVyc2lvbiBvZiBkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uIGlzIGV4 cGlyZWQuIEJlZm9yZSBJIGp1c3QgcHVzaCBhIGtlZXBhbGl2ZSBkcmFmdCwgYW55IGNvbW1lbnRz IEkgbmVlZCB0byBpbmNvcnBvcmF0ZSwgb3IgZGlzY3Vzc2lvbiB0aGF0IHNob3VsZCBoYXBwZW4g aW4gVG9yb250bywgb3IgaXMgdGhpcyByZWFkeSBmb3IgYSBXR0xDPw0KDQpUaGFua3MsDQoNCldl cw0KDQpBbnl0aGluZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFu eeKAmXMgbWFpbCBzZXJ2ZXIsIEkgaGF2ZSBubyBjb250cm9sIG92ZXIgaXQuDQotLS0tLS0tLS0t LQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVGhpcyBFLW1haWwgYW5kIGFu eSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJp ZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Ig c3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlz IEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQg dGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24g dGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0 aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwg YW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= --_000_CF856BD719F32wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PlRoZSBjdXJyZW50IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi1zaWRyLWFzLW1pZ3JhdGlvbiBp cyBleHBpcmVkLiBCZWZvcmUgSSBqdXN0IHB1c2ggYSBrZWVwYWxpdmUgZHJhZnQsIGFueSBjb21t ZW50cyBJIG5lZWQgdG8gaW5jb3Jwb3JhdGUsIG9yIGRpc2N1c3Npb24gdGhhdCBzaG91bGQgaGFw cGVuIGluIFRvcm9udG8sIG9yIGlzIHRoaXMgcmVhZHkgZm9yIGEgV0dMQz88L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij5X ZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMTI3LCAxMjcsIDEyNyk7Ij5B bnl0aGluZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFueeKAmXMg bWFpbCBzZXJ2ZXIsIEkgaGF2ZSBubyBjb250cm9sIG92ZXIgaXQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMTI3LCAxMjcsIDEy Nyk7Ij4tLS0tLS0tLS0tLTwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+ DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPlRoaXMgRS1t YWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENh YmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRl bnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBD YWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5DQogZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJl Ynkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5n LCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRh Y2htZW50cyB0bw0KIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBi ZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRl IHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91 dC48YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CF856BD719F32wesleygeorgetwcablecom_-- From nobody Tue Apr 29 12:24:47 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7A01A09A2 for ; Tue, 29 Apr 2014 12:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0m2WE5flvqc for ; Tue, 29 Apr 2014 12:24:43 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 87D281A0987 for ; Tue, 29 Apr 2014 12:24:43 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WfDdv-000545-ST; Tue, 29 Apr 2014 19:24:40 +0000 Date: Tue, 29 Apr 2014 22:24:38 +0300 Message-ID: From: Randy Bush To: "George, Wes" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/iZx1Tr0Ds8lAzKf3kinogI-Ut8Q Cc: "sidr@ietf.org" Subject: Re: [sidr] SIDR-AS-Migration updates? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 19:24:44 -0000 > is this ready for a WGLC? yes From nobody Tue Apr 29 15:01:24 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED50D1A09CA for ; Tue, 29 Apr 2014 15:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldFsLYanil96 for ; Tue, 29 Apr 2014 15:01:21 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) by ietfa.amsl.com (Postfix) with ESMTP id 95AB91A09E6 for ; Tue, 29 Apr 2014 15:01:21 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-50-189-40-138.hsd1.ma.comcast.net [50.189.40.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 6D24F3A61F for ; Tue, 29 Apr 2014 22:01:20 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 47384C6B182 for ; Tue, 29 Apr 2014 18:01:19 -0400 (EDT) Date: Tue, 29 Apr 2014 18:01:19 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20140429220119.47384C6B182@minas-ithil.hactrn.net> Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/n8Wbwm_Fp9XssAFXqZmSn5kA8TE Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 22:01:23 -0000 Unfortunately, the binary adopt-or-not question is insufficiently nuanced for a case like this. I think the WG needs a work item to explore the issue of decoupling RFC-3779-style[*] path validation from certificate validation. It may be that at the end of that process we will decide not to change the base specification, but in addition to whatever sympathy the WG might feel for CA operators near the root of the tree, I think there may be some real issues lurking here with respect to out-of-order validation problems and we need to explore them further. I really do not know at this point whether the result of the work we need to do on this will be a publishable document or not. I do not support the addition of joins in the RPKI tree, full stop. The WG chairs asked a couple of specific questions: > You are asked to indicate if you think that this is work that the wg > should be doing Yes, with the proviso that the end result may be a decision to leave well enough alone, in which case the only thing we might publish would be a history of our decision not to change anything. > and whether this draft is an acceptable starting point. As a problem statement, yes. With no intent to give offense, it's nowhere near being suitable as an amended specification, but such a document would be premature at this stage in any case. Starting with a problem statement seems appropriate, so long as we retain the option of keeping the current specification. Yes, this might end up meaning that, after years of work, the WG concludes that we should not change the specification. Sometimes you have to work on something for a while before you know whether you should be doing it. [*] "RFC-3779-style" because, if we change it, it won't be RFC 3779 anymore. It might well reuse all of RFC 3779's syntax and most of RFC 3779's semantics, but since there is deployed code that thinks it knows how to validate with the current semantics, at minimum I would want the hypothetical new thing to use different extnID OID values to flag the change. So, strictly speaking, this would be a new set of X.509v3 extensions that just happen to look exactly like the ones from RFC 3779. From nobody Tue Apr 29 17:38:40 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC3E1A08EB for ; Tue, 29 Apr 2014 17:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTYQTS2pAcRl for ; Tue, 29 Apr 2014 17:38:32 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id F0DB61A07A0 for ; Tue, 29 Apr 2014 17:38:31 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 29 Apr 2014 17:38:30 -0700 From: Terry Manderson To: Sandra Murphy , "sidr@ietf.org" Date: Tue, 29 Apr 2014 17:38:35 -0700 Thread-Topic: [sidr] WG adoption poll for draft-huston-rpki-validation-01 Thread-Index: Ac9kDIGEp9bFi0akQtmOuRSyEY7huA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3481699115_8428372" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/t262W8d3xig66ep4FFgG2WUYvV0 Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 00:38:35 -0000 --B_3481699115_8428372 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I think there is a discussion here that needs to occur. I'm not convinced that this document is the complete embodiment of that which should be adopted or it's the sole answer to the problem space. However I do share the concerns that in the growing complexity of RPKI certificate structures any incorrect construction of the 3779 extensions affects all subordinate certificates, even if some other lineage of INRs in that certificate chain is pristine throughout, thus impacting the IN holder's / routing operator's attestations. My reading of this problem statement reaches the conclusion that the impact on a route degrades the security posture (invalid certificate hence invalid ROA) such that the RP's decision should interpreted as 'NotFound' (RFC6907/RFC6811). Clearly a degradation of the security posture isn't ideal, and may cause the litigious parts of the internet community to initiate action (clearly not a desirable thing for any CA operator) as it allows any permutation of routing attacks. But I also wonder if this is a facet of the tight binding of the secure routing operations to the RPKI hierarchy and in the efforts of reaching 'perfect' security attestations we have caused ourselves some disservice in introducing unacceptable[1] levels of operational fragility. [[1] I'm quite sure this is subjective.] Or perhaps (humour me for a minute) x.509 certificates might be the wrong tool to use. When I consider a pure view of an x.509 certificate I view it as "this certificate attests that all of it's contents are 100% correct". For me, changing that position is a slippery slope - I'm not allergic to it but I want the hiking boots on all the same. For me this is then conditional support, if the authors (and the WG) are willing to think of this document as the germination of the discussion (which I believe I saw in George's email), then I will support adoption. Cheers Terry On 26/04/2014 2:05 am, "Sandra Murphy" wrote: >The authors of draft-huston-rpki-validation-01.txt, RPKI Validation >Reconsidered, have requested wg adoption. > >See http://tools.ietf.org/html/draft-huston-rpki-validation-01. > >Please do respond to the list as to whether you support the wg adopting >this as a work item. You do not need to comment on the content of this >draft at this time. You are asked to indicate if you think that this is >work that the wg should be doing and whether this draft is an acceptable >starting point. Adding whether you can/will review or not is useful. > >Note that active support is required for adoption. Silence is a vote >against adoption. > >This adoption call will end on 9 May 2014. > >--Sandy, speaking as wg co-chair >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr --B_3481699115_8428372 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFHTvdIWo5JtC5aLJnlKkYvM+hzQGMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTE0MDQzMDAwMzgzNVowDQYJKoZIhvcNAQEBBQAEggEAmjVjKUr0 qiMen0ZCMe1rJh6mZC2wgzASTqZn77ve0kipZ1x3ES9wVRf5YXeaX+O2tX9Foqora19uWrqw 1wDBdHJYmrfZigKx0+ly71NgQlQXbKB/4nvLvpzQr9Az6sERXkk5M3zypShVM20ufjLYD3/X RKLEr63Wufo3brzikcALtvCzWf9ixMdXc/tf18WWMy0sLINMwvxrZsFAqP1yY151O4AbVc+m X9l1nkw0piSCp4TF/DBNMqF2OXqKExlv31QSntLe/F+zzzpC6qq9PKHcDp4bO3XNl5jzGdg0 YYoQ9CcMzMnMjnNgmCW44RKVgE4hzGtzdzNP9LcvEBjMfA== --B_3481699115_8428372-- From nobody Tue Apr 29 23:39:43 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466821A6EE2 for ; Tue, 29 Apr 2014 23:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lqbkd_T6jr-p for ; Tue, 29 Apr 2014 23:39:32 -0700 (PDT) Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:b:98::120]) by ietfa.amsl.com (Postfix) with SMTP id 482191A6EE0 for ; Tue, 29 Apr 2014 23:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:from:to:subject:thread-topic:thread-index:date:message-id: references:in-reply-to:accept-language:content-language:x-ms-has-attach: x-ms-tnef-correlator:x-originating-ip:content-type:content-id: content-transfer-encoding:mime-version; bh=+KUxt54IyQldSKy6jud66Zsylw3sG7wvOKmSeqb0Kpo=; b=20MyEcigXta5WsSgsOk1w6b9bxTIt5jsM/jXMYK0tve8shsbZrXphd38vXdzeF5rrMxtPnBEkJ782 OvvcsSbwbs04TWFODYHg84v4yZnm564NyfpdJt8du8Tmoy23uP6jlPAKCaHZE4wGF5ZaD1FhwkhCLf QrIPAHEEpCzlCVO4= Received: from iamda3.org.apnic.net (unknown [203.119.101.249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTP for ; Wed, 30 Apr 2014 16:39:27 +1000 (EST) Received: from NXMDA1.org.apnic.net ([fe80::c877:49c3:86f7:9d67]) by iamda3.org.apnic.net ([fe80::e195:c0e8:e814:db75%15]) with mapi id 14.01.0218.012; Wed, 30 Apr 2014 16:39:27 +1000 From: Byron Ellacott To: "sidr@ietf.org" Thread-Topic: [sidr] WG adoption poll for draft-huston-rpki-validation-01 Thread-Index: AQHPYKA/mZ9sImneMU+jiCnfmVZ3RJspvJkA Date: Wed, 30 Apr 2014 06:39:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.119.42.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <9DB495B1B526CA49B550F63B23689A07@apnic.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/VIKLqz4upgbJpOfVvucQ312F77g Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 06:39:35 -0000 I do support this draft, I am willing to review. Thanks, Byron On 26/04/2014 2:05 am, "Sandra Murphy" wrote: >The authors of draft-huston-rpki-validation-01.txt, RPKI Validation >Reconsidered, have requested wg adoption. > >See http://tools.ietf.org/html/draft-huston-rpki-validation-01. > >Please do respond to the list as to whether you support the wg adopting >this as a work item. You do not need to comment on the content of this >draft at this time. You are asked to indicate if you think that this is >work that the wg should be doing and whether this draft is an acceptable >starting point. Adding whether you can/will review or not is useful. > >Note that active support is required for adoption. Silence is a vote >against adoption. > >This adoption call will end on 9 May 2014. > >--Sandy, speaking as wg co-chair >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Apr 29 23:52:47 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E141A6EF0 for ; Tue, 29 Apr 2014 23:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIWjdfMJdkgA for ; Tue, 29 Apr 2014 23:52:35 -0700 (PDT) Received: from smtp.mu.afrinic.net (smtp.afrinic.net [196.6.0.202]) by ietfa.amsl.com (Postfix) with ESMTP id 319E11A6EE5 for ; Tue, 29 Apr 2014 23:52:35 -0700 (PDT) Received: from [2001:4290:10:250:6599:9e02:148d:6dd] (port=64336) by smtp.mu.afrinic.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1WfONZ-0005kO-T0 for sidr@ietf.org; Wed, 30 Apr 2014 06:52:29 +0000 From: Neriah Sossou Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_FD6E45C2-E08C-409B-BA03-BF33EB23A128"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Wed, 30 Apr 2014 11:08:20 +0400 In-Reply-To: To: sidr@ietf.org References: Message-Id: X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/dNHUzR1NnT-CeXDFX79Hy1cs4C8 Subject: Re: [sidr] WG adoption poll for draft-huston-rpki-validation-01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 06:52:40 -0000 --Apple-Mail=_FD6E45C2-E08C-409B-BA03-BF33EB23A128 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii In support of this draft. Neriah > > On 26/04/2014 2:05 am, "Sandra Murphy" wrote: > >> The authors of draft-huston-rpki-validation-01.txt, RPKI Validation >> Reconsidered, have requested wg adoption. >> >> See http://tools.ietf.org/html/draft-huston-rpki-validation-01. >> >> Please do respond to the list as to whether you support the wg adopting >> this as a work item. You do not need to comment on the content of this >> draft at this time. You are asked to indicate if you think that this is >> work that the wg should be doing and whether this draft is an acceptable >> starting point. Adding whether you can/will review or not is useful. >> >> Note that active support is required for adoption. Silence is a vote >> against adoption. >> >> This adoption call will end on 9 May 2014. >> >> --Sandy, speaking as wg co-chair >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_FD6E45C2-E08C-409B-BA03-BF33EB23A128 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTYKFkAAoJEPCssUFZ2owxQJ0IAJXW815Gj3NZaA0GR7hEY8bn fyhRA0X1pzvLoTNbOAVax+ptk+xWDgdGVZAgTBaUQ5UJYOl/uIfjseVdx+hUgPx2 6kWY41pS4xmSZiBOD73Hpqf+aVQyRM4VRfK2psm6/x3+ndodsBs1oIgDcv+bpgGN Ev+jo+r/BZXwtc3mtKELmvB/C99NmTsezl4iT/PVgMCIi1jiCf6sLTrHF4g8jJYe Wbodz0efupUNeX/1VDFw+NUWzrKh3Tc01QjaKKFL0KltZTVPSD3iqXxGXgRQxc2G HIVaH3YthtRQ071i59+CwOC4LebwOyFdDe0MGz9Hk/w3VOsBOVT4Zs/7mY3jcOQ= =hgzK -----END PGP SIGNATURE----- --Apple-Mail=_FD6E45C2-E08C-409B-BA03-BF33EB23A128-- From nobody Wed Apr 30 13:26:32 2014 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3C91A0973 for ; Wed, 30 Apr 2014 13:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.116 X-Spam-Level: X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmCy9MtAvcMG for ; Wed, 30 Apr 2014 13:26:28 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 243431A8893 for ; Wed, 30 Apr 2014 13:26:28 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,960,1389762000"; d="scan'208";a="293627706" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 30 Apr 2014 16:25:54 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Wed, 30 Apr 2014 16:26:18 -0400 From: "George, Wes" To: Sean Turner , "sidr@ietf.org" Date: Wed, 30 Apr 2014 16:26:17 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-05.txt Thread-Index: Ac9ksnC9tWu1xSnlT4+RfZqPCEF2KA== Message-ID: References: <20140429141007.21954.23015.idtracker@ietfa.amsl.com> <99F6C803-C724-430F-AF95-461CBE778C05@ieca.com> In-Reply-To: <99F6C803-C724-430F-AF95-461CBE778C05@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sidr/7fWtPlgDtfT5iQUshTreR3oJxPw Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 20:26:30 -0000 VGhpcyB1cGRhdGUgYWRkcmVzcyBteSBjb21tZW50cyBvbiB0aGUgZG9jdW1lbnQsIGFuZCBJIHRo aW5rIGl04oCZcyBpbiBnb29kDQpzaGFwZSBub3cuIFRoZSBuZXcgc2VjdGlvbiA0IGlzIHJlYWxs eSBnb29kLiBUaGUgb25lIHRoaW5nIEkgbWlnaHQNCnJlY29tbWVuZCBhZGRpbmcgZm9yIGNvbXBs ZXRlbmVzcyBpcyBhIGZldyBhZGRpdGlvbmFsIHdvcmRzIGFyb3VuZA0KcmV2b2NhdGlvbiBwcm9j ZXNzIGF0IHRoZSBlbmQgb2Ygc2VjdGlvbiA0LCBzcGVjaWZpY2FsbHkgaWYgdGhlcmUgaXMgYW55 DQpkaWZmZXJlbmNlIG9yIHJlY29tbWVuZGF0aW9uIGluIHByb2Nlc3MgZm9yIG1ha2UgYmVmb3Jl IGJyZWFrIChwcm92aXNpb24NCm5ldyBrZXksIHRoZW4gcmV2b2tlIG9sZCkgb3Igd2hlbiB0aGF0 IG1heSBub3QgYmUgYSBnb29kIGlkZWEgY29tcGFyZWQNCndpdGggdGhlIHJpc2sgb2Ygb3V0YWdl IGNhdXNlZCBieSByZXZva2luZyBhbmQgdGhlbiByZWtleWluZy4gSXQgbWF5IGJlIGFzDQpzaW1w bGUgYXMgc2F5aW5nIHNvbWV0aGluZyBzaW1pbGFyIHRvIHRoZSBhYm92ZSBhYm91dCB3aGV0aGVy IGEgcm91dGVyDQpzdXBwb3J0cyBtdWx0aXBsZSBwcml2YXRlIGtleXMgb3Igbm90LCBidXQgSeKA mW0gbm90IHN1cmUgaWYgdGhlcmUgYXJlDQphZGRpdGlvbmFsIGNvbnNpZGVyYXRpb25zIHRoYXQg bmVlZCB0byBiZSBkaXNjdXNzZWQuDQoNClRoYW5rcywNCg0KV2VzDQoNCg0KDQpPbiA0LzI5LzE0 LCAxMDoxNCBBTSwgIlNlYW4gVHVybmVyIiA8VHVybmVyU0BpZWNhLmNvbT4gd3JvdGU6DQoNCj5I aSwNCj4NCj5UaGlzIHZlcnNpb24gaW5jbHVkZXMgYSBuZXcgc2VjdGlvbiA0IHRoYXQgYWRkcmVz c2VzIGtleSBtYW5hZ2VtZW50DQo+KGkuZS4sIGtlZXAgYSB0aW1lciB0byBtYWtlIHN1cmUgeW91 ciBjZXJ0IGRvZXNu4oCZdCBleHBpcmUpLiAgVGhlcmXigJlzIGFsc28NCj5zb21lIGVkaXRvcmlh bC9yZWFkYWJpbGl0eSBjb3JyZWN0aW9ucy4gIFBsZWFzZSByZXZpZXcgYXMgdGhlIGF1dGhvcnMN Cj50aGluayB0aGlzIHZlcnNpb24gcHJldHR5IG11Y2ggd3JhcHMgdXAgd2hhdCB3ZSB3YW50ZWQg dG8gc2F5Lg0KPg0KPnNwdA0KPg0KPk9uIEFwciAyOSwgMjAxNCwgYXQgMTA6MTAsIGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCj4NCj4+DQo+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4+ZGlyZWN0b3Jp ZXMuDQo+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTZWN1cmUgSW50ZXItRG9t YWluIFJvdXRpbmcgV29ya2luZw0KPj5Hcm91cCBvZiB0aGUgSUVURi4NCj4+DQo+PiAgICAgICAg VGl0bGUgICAgICAgICAgIDogUm91dGVyIEtleWluZyBmb3IgQkdQc2VjDQo+PiAgICAgICAgQXV0 aG9ycyAgICAgICAgIDogU2VhbiBUdXJuZXINCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBL ZXl1ciBQYXRlbA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgIFJhbmR5IEJ1c2gNCj4+ICAg ICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1zaWRyLXJ0ci1rZXlpbmctMDUudHh0DQo+ PiAgICAgIFBhZ2VzICAgICAgICAgICA6IDEwDQo+PiAgICAgIERhdGUgICAgICAgICAgICA6IDIw MTQtMDQtMjkNCj4+DQo+PiBBYnN0cmFjdDoNCj4+ICAgQkdQc2VjLXNwZWFraW5nIHJvdXRlcnMg YXJlIHByb3Zpc2lvbmVkIHdpdGggcHJpdmF0ZSBrZXlzIHRvIHNpZ24gQkdQDQo+PiAgIG1lc3Nh Z2VzOyB0aGUgY29ycmVzcG9uZGluZyBwdWJsaWMga2V5cyBhcmUgcHVibGlzaGVkIGluIHRoZSBn bG9iYWwNCj4+ICAgUlBLSSAoUmVzb3VyY2UgUHVibGljIEtleSBJbmZyYXN0cnVjdHVyZSkgdGhl cmVieSBlbmFibGluZw0KPj4gICB2ZXJpZmljYXRpb24gb2YgQkdQc2VjIG1lc3NhZ2VzLiAgVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgdHdvIHdheXMgb2YNCj4+ICAgcHJvdmlzaW9uaW5nIHRoZSBw dWJsaWMtcHJpdmF0ZSBrZXktcGFpcnM6IHJvdXRlci1kcml2ZW4gYW5kDQo+PiAgIG9wZXJhdG9y LWRyaXZlbi4NCj4+DQo+Pg0KPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLXNpZHItcnRyLWtleWluZy8NCj4+DQo+PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2 ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtc2lkci1ydHIta2V5aW5nLTA1DQo+Pg0KPj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3Vz IHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1zaWRyLXJ0ci1rZXlpbmctMDUNCj4+DQo+Pg0KPj4gUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YN Cj4+c3VibWlzc2lvbg0KPj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+DQo+PiBJbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiBmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+PiBJLUQt QW5ub3VuY2VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaS1kLWFubm91bmNlDQo+PiBJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KPj4gb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNo YWRvdy1zaXRlcy50eHQNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPnNpZHIgbWFpbGluZyBsaXN0DQo+c2lkckBpZXRmLm9yZw0KPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcg0KDQoNClRoaXMgRS1tYWlsIGFuZCBh bnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3By aWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9y IHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhp cyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFs IG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVk IHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9u IHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8g dGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFs IGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K