From nobody Fri Dec 1 13:29:49 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89031293D8; Fri, 1 Dec 2017 13:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 EL8mydro3crw; Fri, 1 Dec 2017 13:29:46 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A6D126D45; Fri, 1 Dec 2017 13:29:46 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 7A314B81645; Fri, 1 Dec 2017 13:29:17 -0800 (PST) To: nmalykh@gmail.com, gih@apnic.net, ggm@apnic.net, robertl@apnic.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aretana.ietf@gmail.com, iesg@ietf.org, sidr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171201212917.7A314B81645@rfc-editor.org> Date: Fri, 1 Dec 2017 13:29:17 -0800 (PST) Archived-At: Subject: [sidr] [Errata Held for Document Update] RFC6487 (5187) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 21:29:48 -0000 The following errata report has been held for document update for RFC6487, "A Profile for X.509 PKIX Resource Certificates". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5187 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Nikolai Malykh Date Reported: 2017-11-28 Held by: Alvaro Retana (IESG) Section: 7.1 Original Text ------------- encompass Given two IP address and AS number sets, X and Y, X "encompasses" Y if, for every contiguous range of IP addresses or AS numbers elements in set Y, the range element is either "more specific" than or "equal" to a contiguous range element within the set X. Corrected Text -------------- encompass Given two IP address or two AS number sets, X and Y, X "encompasses" Y if, for every contiguous range of IP addresses or AS numbers elements in set Y, the range element is either "more specific" than or "equal" to a contiguous range element within the set X. Notes ----- -------------------------------------- RFC6487 (draft-ietf-sidr-res-certs-22) -------------------------------------- Title : A Profile for X.509 PKIX Resource Certificates Publication Date : February 2012 Author(s) : G. Huston, G. Michaelson, R. Loomans Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Dec 1 13:31:04 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9EB127A91; Fri, 1 Dec 2017 13:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 R5ie7ZHy8G9D; Fri, 1 Dec 2017 13:30:56 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E70A126D45; Fri, 1 Dec 2017 13:30:56 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E5A42B81656; Fri, 1 Dec 2017 13:30:42 -0800 (PST) To: nmalykh@gmail.com, gih@apnic.net, ggm@apnic.net, robertl@apnic.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aretana.ietf@gmail.com, iesg@ietf.org, sidr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171201213042.E5A42B81656@rfc-editor.org> Date: Fri, 1 Dec 2017 13:30:42 -0800 (PST) Archived-At: Subject: [sidr] [Errata Held for Document Update] RFC6487 (5190) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 21:30:58 -0000 The following errata report has been held for document update for RFC6487, "A Profile for X.509 PKIX Resource Certificates". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5190 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Nikolai Malykh Date Reported: 2017-11-28 Held by: Alvaro Retana (IESG) Section: 8 Original Text ------------- 3) A randomly generated ASCII HEX encoded string of length 20 or greater: example: cn="0f8fcc28e3be4869bc5f8fa114db05e1"> (A string of 20 ASCII HEX digits would have 80-bits of entropy) Corrected Text -------------- 3) A randomly generated ASCII HEX encoded string of length 20 or greater: example: cn="0f8fcc28e3be4869bc5f8fa114db05e1" (A string of 20 ASCII HEX digits would have 80-bits of entropy) Notes ----- Typo -------------------------------------- RFC6487 (draft-ietf-sidr-res-certs-22) -------------------------------------- Title : A Profile for X.509 PKIX Resource Certificates Publication Date : February 2012 Author(s) : G. Huston, G. Michaelson, R. Loomans Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Dec 1 13:31:57 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB30E129412; Fri, 1 Dec 2017 13:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9KFaEhl-jVvu; Fri, 1 Dec 2017 13:31:46 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF3A1293D8; Fri, 1 Dec 2017 13:31:46 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8676EB81685; Fri, 1 Dec 2017 13:31:32 -0800 (PST) To: nmalykh@gmail.com, gih@apnic.net, ggm@apnic.net, robertl@apnic.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aretana.ietf@gmail.com, iesg@ietf.org, sidr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171201213132.8676EB81685@rfc-editor.org> Date: Fri, 1 Dec 2017 13:31:32 -0800 (PST) Archived-At: Subject: [sidr] [Errata Held for Document Update] RFC6487 (5191) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 21:31:50 -0000 The following errata report has been held for document update for RFC6487, "A Profile for X.509 PKIX Resource Certificates". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5191 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Nikolai Malykh Date Reported: 2017-11-28 Held by: Alvaro Retana (IESG) Section: 8 Original Text ------------- (The issuing CA may wish to be able to extract the database key or subscriber ID from the commonName. Since only the issuing CA would need to be able to parse the commonName, the database key and the source of entropy (e.g., a UUID) could be separated in any way that the CA wants, as long as it conforms to the rules for PrintableString. The separator Huston, et al. Standards Track [Page 21] RFC 6487 Resource Certificate Profile February 2012 could be a space character, parenthesis, hyphen, slash, question mark, etc. Corrected Text -------------- (The issuing CA may wish to be able to extract the database key or subscriber ID from the commonName. Since only the issuing CA would need to be able to parse the commonName, the database key and the source of entropy (e.g., a UUID) could be separated in any way that the CA wants, as long as it conforms to the rules for PrintableString. The separator Huston, et al. Standards Track [Page 21] RFC 6487 Resource Certificate Profile February 2012 could be a space character, parenthesis, hyphen, slash, question mark, etc). Notes ----- The closing parenthesis is missing. -------------------------------------- RFC6487 (draft-ietf-sidr-res-certs-22) -------------------------------------- Title : A Profile for X.509 PKIX Resource Certificates Publication Date : February 2012 Author(s) : G. Huston, G. Michaelson, R. Loomans Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Dec 5 07:36:52 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA9C12946C for ; Tue, 5 Dec 2017 07:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ktBnC6BKAudU for ; Tue, 5 Dec 2017 07:36:49 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FF412944E for ; Tue, 5 Dec 2017 07:36:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8F9E6B81D26; Tue, 5 Dec 2017 07:36:31 -0800 (PST) To: mlepinski@bbn.com, kent@bbn.com, akatlas@gmail.com, db3546@att.com, aretana.ietf@gmail.com, morrowc@ops-netman.net, sandy@tislabs.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: nmalykh@gmail.com, sidr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171205153631.8F9E6B81D26@rfc-editor.org> Date: Tue, 5 Dec 2017 07:36:31 -0800 (PST) Archived-At: Subject: [sidr] [Technical Errata Reported] RFC6480 (5196) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 15:36:50 -0000 The following errata report has been submitted for RFC6480, "An Infrastructure to Support Secure Internet Routing". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5196 -------------------------------------- Type: Technical Reported by: Nikolai Malykh Section: 6 Original Text ------------- 3. For each manifest, verify that certificates and CRLs issued under the corresponding CA certificate match the hash values contained in the manifest. Additionally, verify that no certificate or manifest listed on the manifest is missing from the repository. If the hash values do not match, or if any certificate or CRL is missing, notify the appropriate repository administrator that the repository data has been corrupted. Corrected Text -------------- 3. For each manifest, verify that certificates and CRLs issued under the corresponding CA certificate match the hash values contained in the manifest. Additionally, verify that no certificate or CRL listed on the manifest is missing from the repository. If the hash values do not match, or if any certificate or CRL is missing, notify the appropriate repository administrator that the repository data has been corrupted. Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6480 (draft-ietf-sidr-arch-13) -------------------------------------- Title : An Infrastructure to Support Secure Internet Routing Publication Date : February 2012 Author(s) : M. Lepinski, S. Kent Category : INFORMATIONAL Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Dec 8 12:46:37 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F32127241 for ; Fri, 8 Dec 2017 12:46:35 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 T_BXOg9KpIcP for ; Fri, 8 Dec 2017 12:46:31 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86DD712009C for ; Fri, 8 Dec 2017 12:46:31 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id DCF6D28B003B for ; Fri, 8 Dec 2017 15:46:30 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id D4E811F8036; Fri, 8 Dec 2017 15:46:30 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sandra Murphy In-Reply-To: <5990F5D0-B532-482E-BA4F-D20908F6B862@tislabs.com> Date: Fri, 8 Dec 2017 15:46:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <652C5AAD-50CD-4A03-9BF7-B7D00CE2A74D@tislabs.com> References: <150851896075.15465.7110696373396971840@ietfa.amsl.com> <68DEA77B-EB7C-4345-A60E-A134E5CAC2F7@sn3rd.com> <79137BEA-5FD8-4E08-8C49-215146A352F2@tislabs.com> <48765D76-8B14-492B-B444-9F895A920D89@tislabs.com> <260B2F04-6A90-464C-A6B1-7518AD68F7E6@tislabs.com> <5990F5D0-B532-482E-BA4F-D20908F6B862@tislabs.com> To: sidr list X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] comments needed (Re: I-D Action: draft-ietf-sidr-rtr-keying-14.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 20:46:35 -0000 The Secretariat has responded to my ticket about the attachment problem = noted below. > On Dec 7, 2017, at 5:17 PM, xxxxx via RT wrote: >=20 > Hi Sandy, >=20 > It turns out the archive did not have support for the "text/rtf" = mimetype. This > has now been added and the attachment appears in the messages you = referenced > below. So .rtf attachments, if anyone were so wise as to try one, should now = show up in the archive. =E2=80=94Sandy > On Nov 14, 2017, at 9:07 PM, Sandra Murphy wrote: >=20 > Wellllll. >=20 > The mail archive does not seem to show attachments. For me. I see do = see attachments on other messages. >=20 > It would be nice to know if anyone has seen attachments on my messages = in the last few weeks. >=20 > At any rate, for the mail archive, the comments are copied below the = signature. >=20 > =E2=80=94Sandy >=20 >=20 > Points that might get lost in the long detailed list that follows: >=20 > 1. RFC4271 (and RFC6286) and RFC8209 use the term =E2=80=9CBGP = Identifier=E2=80=9D. The main text says RouterID and the Appendix B = says =E2=80=9Cserial number=E2=80=9D. I believe both are talking about = what RFC8209 calls the =E2=80=9CBGP Identifier=E2=80=9D. Most of the = tech sites say router ID or router-id or routerid or RID or some such. = But I think consistency with the referenced text would be good. >=20 > 2. I was initially confused by the text in various places that talks = about the operator adding the AS and RouterID (sic) and sends to the CA. = I thought that meant the operator adds those to the CSR, which would be = hard since the CSR is signed. This occurs a couple of places. I = suggest a sentence early on that says the router certificate includes = the AS and router identifier but the CSR does not include such fields, = so the operator must include the AS and routerID when it sends the CSR = to the CA. >=20 > 3. =E2=80=9Ccorresponds=E2=80=9D - there are several places that say = the certificate must be validated to prove that the public key = corresponds with the private key. The main body does not say how that = correspondence is validated. The appendix suggests that the operator = could validate the signature on the CSR with the returned router cert in = order to validate the key. (a) When the operator generated the = public/private key pair, why not just do a comparison to the generated = public key, presuming it was retained? (b) When the operator passed the = CSR generated by the router to the CA, why not validate the public key = before sending it to the CA? The public key in the returned router = certificate could subsequently be validated by a comparison, presuming = the public key was retained. (c) When the router is supposed to = validate the public key of the router cert it receives, and the operator = generated the public/private key pair, it does not have a copy of the = CSR to validate the correspondence. Took me a bit to realize the router = could sign just any old bit of bytes and then validate the signature = with the received router cert. Right? >=20 > 4. =E2=80=9Ccorresponds=E2=80=9D again - there=E2=80=99s no mention = of a router verifying that the router cert it receives has an AS that is = configured on the router. There are lots of other checks and double = checks - why not this one? And if the router has multiple ASs and = multiple CSRs have been generated (either by the router or by the = operator), then the router uses the received router certificate to = associate the AS with the public/private key pair, so it knows which = private key to use over which session. Right? >=20 > 5. Section 8 on =E2=80=9CAdvanced Deployment Scenarios=E2=80=9D talks = about routers that already have pre-installed keys (with mentions of = types of crypto that are not known to me, and I did not dig up the refs, = so I might be missing something here). The first paragraph talks about = =E2=80=9Cpre-installed key material=E2=80=9D. I could understand why = these pre-installed keys might be useful in authenticating the router = directly to the CA. The =E2=80=9Cburdens=E2=80=9D 1 and 2 also talk = abut =E2=80=9Ckey material=E2=80=9D. It did not look to me like the = =E2=80=9Ckey material=E2=80=9D in 1 and 2 are talking about these = =E2=80=9Cpre-installed=E2=80=9D keys. But I admit to being very = confused by the way the term is used. >=20 > 6. Section 5.2.1 is titled =E2=80=9DUsing PKCS#8 to Transfer Public = Key=E2=80=9D. The text talks about using PKCS #8 in RFC5958, which = allows for including both the public and private key. But the text of = that section is talking about using PKCS #8 to transmit the private key = to the router. I presume the title should be Using PKCS#8 to Transfer = Private Key >=20 > 7. There is an early assumption that all the communication between = the operator and the router is over a protected channel. Section 5.2.1 = suggests using a CMS SignedData to transmit the PKCS#8. RFC5958 = suggests several different =E2=80=9CCMS protecting content types=E2=80=9D = for the PKCS#8 - EncryptedData, EnvelopedData, etc. I presume that the = encrypted versions are not used here because the protected channel = ensures confidentiality. So (a) Appendix A talks about the key strength = to be used for the different crypto algorithms (encryption, key = exchange, =E2=80=A6). That=E2=80=99s a big hint that the channel should = provide the related security protections. I think it would be good to = explicitly state the protections the protected channel must provide: = =E2=80=9CThe protected channel must provide confidentiality, = authentication, integrity and replay protection=E2=80=9D. (b) if the = protected channel provides authentication and integrity, why is the = protection of the CMS SignedData needed? One possible reason follows -> = (c) The AS EE certificate has an AS extension, not an IP extension, I = presume. So the AS EE certificate would be a second way for the router = to associate a private key with an AS and an appropriate BGP session = (see my comment 3c above). But this applies only when the operator = generated the public/private key pair. >=20 > 8. PKCS#7 needs a reference. I looked at RFC2315. RFC2315 defines = several types of content, e.g., signed-data, enveloped-data, = signed-and-enveloped-data, etc. Is there any reason to specify which = type? Is it operator choice? >=20 > 9. The term =E2=80=9Coperator=E2=80=9D is used to talk about = carbon-based units (who are forgetful), ISP organizations (who peer with = other operators), ASs (who have an AS EE certificates) and management = system stations (that receive CSRs from the router). It was a bit = unsettling, but after multiple reads through I=E2=80=99m getting used to = it. I=E2=80=99m not sure I could suggest a term that would fit all = those uses. Perhaps network operators (the ones with DNA) identify = personally with all those uses and think of their person in all cases. = =E2=80=9CI am the AS=E2=80=9D, =E2=80=9CI am the peering entity=E2=80=9D, = =E2=80=9CI am the management of the network=E2=80=9D, etc. >=20 > 10. I do not understand the last two paragraphs of section 7 at the = bottom of page 6. It sounds to me like they are out of place, like they = belong elsewhere in the text. >=20 > 11. There are some occurrences of =E2=80=9Cmust=E2=80=9D and only a = few of =E2=80=9CMUST=E2=80=9D - the draft is standards track, so how = much of the described behaviors are mandatory? >=20 > 12. Some consistency nits - PKCS sometimes followed by a space, = sometimes not. protected channel, secure channel, communications = channel, protected session, SSH session, . . . =20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > OK, so on to the detailed comments, sequentially through the document >=20 > p3, section 1: >=20 > two methods to provision new and existing routers. The methods > described involve the operator configuring the two end points and > acting as the intermediary. >=20 > What are the two endpoints? The router and the management station? = The router and the CA? I can imagine the operator configuring the = management station, but not the CA. I can imagine the operator acting = as the intermediary between the router and the CA, but not between the = router and the management station. >=20 > p3, section 1: (nit) >=20 > [RFC8208] > specifies the algorithms used to generate the signature. >=20 > If I read correctly, =E2=80=9Cthe=E2=80=9D signature in this text = would be the signature on the PKCS#10. =20 >=20 > suggest: >=20 > [RFC8208] > specifies the algorithms used to generate the PKCS#10 signature. >=20 >=20 > p4, section 2 >=20 > See Appendix A for security considerations > for this channel. >=20 > I think it is important to say what security protection are required = for this protected channel. > Appendix A talks about the strength of the key used in the various = crypto algorithms. I think a > sentence something like the following would be useful here or in = Appendix A. >=20 > =E2=80=9CThe protected channel must provide confidentiality, = authentication, integrity=E2=80=9D and replay protection.=E2=80=9D >=20 > p4, section 4 (nit) >=20 > appropriate RPKI Trust Anchor' Certificate (TA Cert) in the router. >=20 > suggest: >=20 > appropriate RPKI Trust Anchor Certificate (TA Cert) in the router. > or > appropriate RPKI Trust Anchor=E2=80=99s Certificate (TA Cert) in the = router. >=20 > p4, section 4 >=20 > The operator also configures the Autonomous System (AS) number to be > used in the generated router certificate. This may be the sole AS > configured on the router, or an operator choice if the router is > configured with multiple ASs. >=20 > There=E2=80=99s a hint here that the operator configures the router to = generate just one router certificate. > RFC8209 allows the router certificate to have one or more ASs, but = recommends that there be multiple router certificates with one AS each. = Does this paragraph intend to limit a router to one router certificate = or just to limit the router to one AS per router certificate? I have = questions later about what happens if the router wants a router = certificate for each of multiple ASs. >=20 > Perhaps =E2=80=9CA router with multiple ASs can be configured with = multiple router certificates=E2=80=9D, maybe also =E2=80=9Cby following = the process of this document for reach desired certificate=E2=80=9D. >=20 > The operator configures or extracts from the router the BGP RouterID >=20 > RFC4271 and RFC8209 say =E2=80=9CBGP Identifier=E2=80=9D. OSPF uses = RouterID, and lots of C/J commands use RouterID, or router-id, or router = id, or RID, or . . . But consistency with the referenced specs would a = good thing. >=20 > p4, section 5 >=20 > I think it would be great to add a sentence here explaining that the = PKCS#10 (CSR) format does not include the AS and RouterID (sic). = Therefore, the operator must transmit the AS and RouterID (sic) as well = when it sends the CSR to the CA. =20 >=20 > That sentence applies to both the router generated keys and the = operator generated keys, so maybe it could go here. >=20 > The PKCS#10 format does not include the AS and RouterID for the router = certificate. Therefore, the operator must include the AS it has chosen = for the router and the RouterID when it sends the CSR to the RPKI CA. >=20 > That should be a MUST, shouldn=E2=80=99t it? >=20 > p5, section 5.1 >=20 > The operator adds the chosen AS number and the RouterID to send to > the RPKI CA for the CA to certify. >=20 > My first reading was that the text meant the AS and RouterID were = added to the CSR. First, that=E2=80=99s not possible because of the = signature, unless there=E2=80=99s some key sharing going on. Second, = that=E2=80=99s not possible because the CSR format does not include the = AS and RouterID. Hence my comment above. >=20 > suggest: >=20 > The operator includes the chosen AS number and the RouterID when it = sends the CSR to >=20 > p4, section 5.1 (nit) >=20 > NOTE: If a router was to communicate directly with a CA to have the >=20 > suggest: >=20 > NOTE: If a router were to communicate directly with a CA to have the >=20 > p5, section 5.2 >=20 > and adds the chosen AS number and RouterID to be sent to the RPKI CA > for the CA to certify. >=20 > suggest: >=20 > and includes the chosen AS number and the RouterID when it sends the = CSR to the RPKI CA > for the CA to certify. >=20 > p5, section 5.2.1 >=20 > section title =E2=80=9CUsing PKCS#8 to Transfer Public Key=E2=80=9D >=20 > PKCS#8 in RFC5958 can transfer public keys. But the following text is = talking about transferring the private key to the router. =20 >=20 > I think this title should be =E2=80=9CUsing PKCS#8 to Transfer Private = Key=E2=80=9D >=20 >=20 > A private key encapsulated in a PKCS #8 [RFC5958] should be further > encapsulated in Cryptographic Message Syntax (CMS) SignedData > [RFC5652] and signed with the AS's End Entity (EE) private key. >=20 > Would =E2=80=9CA private key encapsulated in a PKCS #8=E2=80=9D be = followed by "OTOH, a private key that is not encapsulated in a = PKCS#8=E2=80=9D? :-) >=20 > Suggest: >=20 > A private key can be encapsulated in a PKCS #8 [RFC5958] and should = be further > (or =E2=80=9Cis=E2=80=9D encapsulated or =E2=80=9Cshould be=E2=80=9D = encapsulated)=20 >=20 > Section 3 suggests various ways to =E2=80=9Cexchange PKI-related = information with routers=E2=80=9D. Is this PKCS#8 just one more way, or = is it the recommended way? The intro to section 5 suggests that copy = and paste could also be used, but doesn=E2=80=99t say if that would be = copy and paste of the PKCS#8. If Section 5 is also talking about = straight copy and paste of the hex or the PEM block, then that=E2=80=99s = another alternative. >=20 > RFC5958 discusses several =E2=80=9CCMS protecting content types=E2=80=9D= to protect the AsymmetricKeyPackage. I presume that the = encryption/enveloping content types are not needed because = confidentiality is being provided by the protected channel. But then = why use the CMS SignedData - would not the protected channel provide the = authentication and integrity needed? (But see potential reason below) >=20 >=20 > [RFC5652] and signed with the AS's End Entity (EE) private key. >=20 > Does it matter which AS=E2=80=99s EE cert the operator uses to sign = the PKCS#8? I presume that the AS must match an AS with which the = router is configured. Should the router check that? Does a router that = is configured with multiple ASs use this communication to tie the = private key to the appropriate AS & BGPsec session? =20 >=20 > If the answer is yes to both questions, should those actions be = mentioned here? >=20 > (I admit to being a bit dizzy here, but maybe the mapping of private = key to AS happens in the receipt of the router certificate.) =20 >=20 > include in the SignedData the RPKI CA certificate and relevant AS's > EE certificate(s). =20 >=20 > Maybe this is the reason for using the SignedData - to be able to = include the AS=E2=80=99s EE cert and give the router the means to tie = the private key to the right AS. >=20 > The router SHOULD verify the signature of the encapsulated PKCS#8 to > ensure the returned private key did in fact come from the operator, >=20 > Then shouldn=E2=80=99t it be signed with the operator=E2=80=99s = personal cert? :-) =20 >=20 > include in the SignedData the RPKI CA certificate and relevant AS's > EE certificate(s). >=20 > Elsewhere (sections 6 & 7) it mentions including the entire cert = chain. Should that be mentioned here as well? >=20 > p5, section 6 (nit) >=20 > The operator uses RPKI management tools to communicate with the > global RPKI system to have the appropriate CA validate the PKCS#10 > request, sign the key in the PKCS#10 (i.e., certify it) and = generated > PKCS#7 response, as well as publishing the certificate in the Global > RPKI. >=20 > for symmetry, suggest: >=20 > The operator uses RPKI management tools to communicate with the > global RPKI system to have the appropriate CA validate the PKCS#10 > request, sign the key in the PKCS#10 (i.e., certify it) and generate = a > PKCS#7 response, as well as publish the certificate in the Global > RPKI. >=20 > p5, section 6=20 >=20 > External network connectivity may be needed if the = certificate > is to be published in the Global RPKI. >=20 > The previous sentence and the following paragraph do not hint that = there is any =E2=80=9Cif=E2=80=9D about the publication of the = certificate. Is there a case where the certificate is NOT =E2=80=9Cto = be published in the Global RPKI=E2=80=9D? >=20 > p6, section 6 (nit) >=20 > 2. Returns the certificate to the operator's management station, > packaged in a PKCS#7 >=20 > Needs a reference. RFC2315? >=20 > In the operator-generated method, the operator SHOULD extract the > certificate from the PKCS#7, and verify that the private key it = holds > corresponds to the returned public key. >=20 > =E2=80=9Cit=E2=80=9D means the operator, right? >=20 > You get to Appendix B before the verification of the correspondence is = explained. I think it should be explained here. >=20 > The Appendix B says the operator should verify the signature on the = PKCS#10 CSR to verify the correspondence. But the operator generated = the key - can=E2=80=99t the correspondence be verified by checking the = certificate=E2=80=99s public key against the operator generated public = key (presuming the key was retained)? That seems too easy - I fear I am = missing some important part here. >=20 > p6, section 7 >=20 > The router SHOULD extract the certificate from the PKCS#7 and verify > that the public key corresponds to the stored private key.=20 >=20 > I think more needs to be said about how the correspondence would be = verified.=20 >=20 > Appendix B says the operator should verify the signature on the = PKCS#10 with the certificate to verify the correspondence to the private = key. That would work for the router as well if the router generated the = PKCS#10, but not if the operator generated the key pair and the PKCS#10. = But the router could sign any random bunch of bits and verify the = signature with the certificate to verify the correspondence. Should = those things be said? >=20 > Also, in the router-driven method, the router can verify the = correspondence simply by matching the certificate=E2=80=99s public key = with one of the router=E2=80=99s stored public keys. (Right? What am I = missing here?) >=20 > Should the router also verify that the AS mentioned in the returned = router certificate is an AS with which it is configured? >=20 > For a router that is configured with multiple ASs, is this where the = router ties the private key to the AS & BGPsec session with which the = private key should be used? >=20 > The last two paragraphs of section 7 confuse me. >=20 > Even if the operator cannot extract the private key from the router, > this signature still provides a linkage between a private key and a > router. That is the operator can verify the proof of possession > (POP), as required by [RFC6484]. >=20 > What is =E2=80=9Cthis signature=E2=80=9D? And there=E2=80=99s been no = mention in this section of extracting the private key from the router. >=20 > This sounds to me like it belongs in section 5.1, maybe after:=20 > =E2=80=9Ct= o sign > the PKCS#10 with the private key. Once generated, the PKCS#10 is > returned to the operator over the protected channel. >=20 > And then: >=20 > NOTE: The signature on the PKCS#8 and Certificate need not be made = by > the same entity. Signing the PKCS#8, permits more advanced > configurations where the entity that generates the keys is not the > direct CA. >=20 > Maybe this belongs in section 5.2.1 where it is talking about the = PKCS#8? >=20 > Even so, I=E2=80=99m not sure what Certificate this text references. = The AS EE cert? >=20 > Both the router-driven method and the operator-driven method are not = the direct CA. Nowhere in this draft does it mention the CA generating = the keys. So the entire draft is one of these =E2=80=9Cadvanced = configurations=E2=80=9D. What am I missing here? >=20 > p7, section 8 (nit) >=20 > Transport" [RFC7030] or the original CMC transport protocol's >=20 > Is the possessive really needed here? I didn=E2=80=99t peruse the = RFC5273 thoroughly, but I can see that it defines a number of transport = methods, so maybe there is a =E2=80=9CCMC transport protocol=E2=80=99s = X=E2=80=9D missing here. >=20 > p7, section 8 >=20 >=20 > This section uses =E2=80=9Ckey material=E2=80=9D several places. But = I=E2=80=99m not certain each use is talking about the same key material. >=20 > When the operator first establishes a secure > communication channel between the management system and the router, > this pre-installed key material is used to authenticate the router. >=20 > So the router gets keys as part of the manufacturing, where the = =E2=80=9Cpre-installed key material=E2=80=9D can be used in = communication with the operator. >=20 > I can see that this might make it easier for the router to communicate = directly with the CA and authenticate itself using these keys. But = section 5.1 notes that the CA has no way to authenticate the router. I = don=E2=80=99t know that the pre-installed key material could provide = that way to authenticate the router, without the participation of the = operator at some point. >=20 > The operator burden shifts here to include: >=20 > I=E2=80=99m not sure how to read this. Maybe =E2=80=9CThe operator = burdens that shift here can/will include=E2=80=9D. >=20 > I=E2=80=99m also not sure if both 1 and 2 are presumed to be = shifted/lifted, or if it is either. >=20 >=20 > 1. Securely communicating the router's authentication material to > the CA prior to operator initiating the router's CSR. CAs use > authentication material to determine whether the router is > eligible to receive a certificate. Authentication material at a > minimum includes the router's AS number and RouterID as well as > the router's key material, but can also include additional > information. Authentication material can be communicated to the > CA (i.e., CSRs signed by this key material are issued > certificates with this AS and RouterID) or to the router (i.e., > the operator uses the vendor-supplied management interface to > include the AS number and routerID in the router-generated CSR). >=20 > Who is doing the communicating in =E2=80=9Csecurely communicating to = the CA=E2=80=9D and =E2=80=9Ccan be communicated to the CA=E2=80=9D? In = the following paragraph, the text says =E2=80=9Cthe router is = communicating directly with the CA=E2=80=9D - is the communication in = this part 1 text going from the router to the CA? >=20 > What is the =E2=80=9Crouter=E2=80=99s key material=E2=80=9D? I could = read it both ways: >=20 > The paragraph above says that the pre-installed key material is used = to authenticate the router, so maybe the =E2=80=9Crouter=E2=80=99s key = material=E2=80=9D is the pre-installed key material. The text says that = the CA =E2=80=9Cuses=E2=80=9D the authentication material, which = includes the router=E2=80=99s key material, to determine whether to = issue the certificate. I don=E2=80=99t know how the pre-installed key = material could assure the CA that the router could be issued a cert, = without some coordination with the operator about that particular key = material. >=20 > Then the text says =E2=80=9CCSRs signed by this key material=E2=80=9D = which implies that the =E2=80=9Crouter=E2=80=99s key material=E2=80=9D = is the public/private key pair. >=20 > So I=E2=80=99m not certain what is going on here, or how the = pre-installed key material is helping. >=20 >=20 > Once configured, the operator can begin the process of enrolling the > router. =20 >=20 > What does =E2=80=9Conce configured=E2=80=9D mean? configuring the = router-operator protected channel? Doing the communication of = authentication material in 1 and 2 above? Configuring the router with = AS and RouterID? >=20 > Because the router is communicating directly with the CA, > there is no need for the operator to retrieve the PKCS#10 from the > router or return the PKCS#7 to the router as in Section 6. Note = that > the checks performed by the router, >=20 > Section 5 says the router returns the PKCS#10 to the operator. > Section 7 says the operator sends the PKCS#7 to the router and the = router performs checks. >=20 > suggest: >=20 > Because the router is communicating directly with the CA, > there is no need for the operator to retrieve the PKCS#10 from the > router as in Section 5 or return the PKCS#7 to the router as in = Section 7. Note that > the checks performed by the router in Section 7, >=20 > When a router is so configured the communication with the CA SHOULD > be automatically re-established >=20 > what does =E2=80=9Cso configured=E2=80=9D mean here? configured with = pre-installed key material? configured by the operator with AS and = RouterID? >=20 > p8, section 9.1 (nit) >=20 > just for symmetry: >=20 > 4. Use some other kind of automated process to search for and track >=20 > suggest: >=20 > 4. The operator uses some other kind of automated process to search = for and track >=20 > p8, section 9.1 >=20 > Regardless of the technique used to track router certificate expiry > times, it is advisable to notify additional operators in the same > organization >=20 > =E2=80=9Cnotify additional operators=E2=80=9D =E2=80=94 In addition to = what? or after what? >=20 > I think you mean =E2=80=9Cmultiple=E2=80=9D operators, or I = misunderstand. >=20 > p9, section 9.3 (nits) >=20 > certificate to the router), and distributing the status takes time >=20 > Not sure what you mean by =E2=80=9Cstatus=E2=80=9D that needs to be = distributed. Are you talking about distributing the revocation = =E2=80=9Cstatus=E2=80=9D in the CRL? >=20 > Keeping the router operational and BGPsec-speaking is the ideal = goal, > but if operational practices do not allow this then reconfiguring = the > router to disabling BGPsec is likely preferred to bringing the = router > offline. >=20 > suggest: >=20 > router to disable BGPsec is likely preferred to bringing the router >=20 > p10, section 9.4 >=20 > To allow operators to quickly replace routers without requiring > update and distribution of the corresponding public keys in the = RPKI, > routers SHOULD allow the private BGPsec key to inserted via a > protected session, e.g., SSH, NetConf (see [RFC6470]), SNMP. This > lets the operator escrow the old private key via the mechanism used > for operator-generated keys, see Section 5.2, such that it can be = re- > inserted into a replacement router. >=20 > The topic here is routers that won=E2=80=99t allow off-loading of = their keys. =20 >=20 > =E2=80=9Crouters SHOULD allow the private BGPsec key to inserted=E2=80=9D= >=20 > is the router that is doing the allowing the old, soon to be replaced = routers, or the newly installed routers? >=20 > =E2=80=9Cto inserted=E2=80=9D - where? - in the newly installed = router or in the management station? >=20 > =E2=80=9CThis lets the operator escrow the old private key=E2=80=9D - = sounds like the old router is allowing the private key to be =E2=80=9Cinse= rted in=E2=80=9D (exported to?) the management station. Right? >=20 > Is there a suggestion of how to get the routers to allow export of the = key, which is currently not allowed? >=20 > I don=E2=80=99t see that section 5.2 says anything about a mechanism = for escrowing keys. It talks about installing a private key into a = router over the protected channel. If the citation to 5.2 is about the = =E2=80=9Csuch that it can be re-inserted=E2=80=9D part of the sentence, = then I get it. But the citation should move to the end of the = sentence. >=20 > p10, section 10 (nit) >=20 > After > familiarizing one's self with the capabilities of the router, > operators are encouraged >=20 > suggest: >=20 > After > familiarizing themselves with the capabilities of the router, > operators are encouraged >=20 >=20 > or >=20 > After > familiarizing one's self with the capabilities of the router, > an operator is encouraged >=20 > p11, section 10 (nit) >=20 > employees that no longer need access to > routers SHOULD be removed the router=20 >=20 > suggest >=20 > employees that no longer need access to > a router SHOULD be removed from the router=20 >=20 > or >=20 > employees that no longer need access to > a router SHOULD be removed from the router access [list] >=20 > p11, section 10 (nit) >=20 > The > operator MUST ensure that installed CA certificate is valid. >=20 > suggest: >=20 > The > operator MUST ensure that the installed CA certificate is valid. >=20 > p14, section Appendix A >=20 > x509v3-ecdsa-sha2-nistp256 [RFC6187] could be used for > authentication. >=20 > is that an example, or a recommendation? >=20 > p15, section Appendix B (nit) >=20 > that will generate the key pair for the algorithms noted in the main > body of this document; >=20 > the algorithms are not noted in the main body, but the end of section = 1 does cite RFC8208. =20 >=20 > the private key just generated to sign the certification request = with > the algorithms specified in the main body of this document; >=20 > the algorithms are not specified in the main body, but the end of = section 1 does cite RFC8208. >=20 > p16, Appendix B >=20 > Uses of =E2=80=9Cserial number=E2=80=9D: >=20 > the subject name and serial number for the router. The CA needs = this > and > CSR you sent; the certificate will include the subject name, serial > number, public key, and other fields > and > Create CSR and sign CSR with private key, and; o Step 3: Send CSR > file with the subject name and serial number to CA. >=20 > The first of these seem to mean the BGP Identifier aka RouterID. As = said before, RFC4271 and RFC8209 use the term BGP Identifier. >=20 > The second and third use of =E2=80=9Cserial number=E2=80=9D probably = also mean BGP Identifier aka RouterID (not the issued cert=E2=80=99s = serial number). >=20 > p17, section Appendix B (typo nit) >=20 > way through GPsec-enabling the router. >=20 > suggest: >=20 > way through BGPsec-enabling the router. >=20 > p17, section Appendix B >=20 > To avoid having routers with expired certificates > follow the recommendations in the Certification Policy (CP) = [RFC6484] >=20 > you could also mention section 9.1. >=20 >=20 >=20 >=20 >=20 >> On Nov 14, 2017, at 10:36 AM, Sandra Murphy = wrote: >>=20 >>=20 >>=20 >> Sorry, the reply did not pick up the original attachment. >>=20 >> Attached here. >>=20 >> Let me know if there are problems reading the comments. >>=20 >> =E2=80=94Sandy >>=20 >> >>=20 >>> On Nov 14, 2017, at 10:33 AM, Sandra Murphy = wrote: >>>=20 >>> Speaking as wg co-chair >>>=20 >>> Please, wg, do take a look at the comments attached. This draft was = requested by the operators and is important. >>>=20 >>> Some of the comments are about substance. Those at the very least = must be considered by the wg. >>>=20 >>> Please take advantage of focused attention and close proximity at = the IETF meeting to discuss. =20 >>>=20 >>> I unfortunately can not be there to button hole people and shove = printouts into their hands. >>>=20 >>> =E2=80=94Sandy, speaking as wg co-chair >>>=20 >>>> On Nov 5, 2017, at 9:25 PM, Sandra Murphy = wrote: >>>>=20 >>>> I=E2=80=99m attaching some comments and questions I found in the = -14 version. >>>>=20 >>>> =E2=80=94Sandy >>>>=20 >>>> >>>>=20 >>>>> On Oct 20, 2017, at 1:04 PM, Sean Turner wrote: >>>>>=20 >>>>> Chris, >>>>>=20 >>>>> This version includes changes to address Oliver=E2=80=99s and = Sriram=E2=80=99s comments. >>>>>=20 >>>>> spt >>>>>=20 >>>>>> On Oct 20, 2017, at 13:02, internet-drafts@ietf.org wrote: >>>>>>=20 >>>>>>=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 WG = of the IETF. >>>>>>=20 >>>>>> Title : Router Keying for BGPsec >>>>>> Authors : Randy Bush >>>>>> Sean Turner >>>>>> Keyur Patel >>>>>> Filename : draft-ietf-sidr-rtr-keying-14.txt >>>>>> Pages : 17 >>>>>> Date : 2017-10-20 >>>>>>=20 >>>>>> Abstract: >>>>>> BGPsec-speaking routers are provisioned with private keys in = order to >>>>>> sign BGPsec announcements. The corresponding public keys are >>>>>> published in the global Resource Public Key Infrastructure, = enabling >>>>>> verification of BGPsec messages. This document describes two = methods >>>>>> of generating the public-private key-pairs: router-driven and >>>>>> operator-driven. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ >>>>>>=20 >>>>>> There are also htmlized versions available at: >>>>>> https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-14 >>>>>> = https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rtr-keying-14 >>>>>>=20 >>>>>> A diff from the previous version is available at: >>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rtr-keying-14 >>>>>>=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 >>>>>=20 >>>>> _______________________________________________ >>>>> sidr mailing list >>>>> sidr@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sidr >>>>=20 >>=20 From nobody Fri Dec 8 12:47:42 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CFC128656 for ; Fri, 8 Dec 2017 12:47:40 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 w_zV-76svK-9 for ; Fri, 8 Dec 2017 12:47:39 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D5C127241 for ; Fri, 8 Dec 2017 12:47:39 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 1538A28B003B for ; Fri, 8 Dec 2017 15:47:39 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 1117A1F8036; Fri, 8 Dec 2017 15:47:39 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sandra Murphy In-Reply-To: <652C5AAD-50CD-4A03-9BF7-B7D00CE2A74D@tislabs.com> Date: Fri, 8 Dec 2017 15:47:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <150851896075.15465.7110696373396971840@ietfa.amsl.com> <68DEA77B-EB7C-4345-A60E-A134E5CAC2F7@sn3rd.com> <79137BEA-5FD8-4E08-8C49-215146A352F2@tislabs.com> <48765D76-8B14-492B-B444-9F895A920D89@tislabs.com> <260B2F04-6A90-464C-A6B1-7518AD68F7E6@tislabs.com> <5990F5D0-B532-482E-BA4F-D20908F6B862@tislabs.com> <652C5AAD-50CD-4A03-9BF7-B7D00CE2A74D@tislabs.com> To: sidr list X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] comments needed (Re: I-D Action: draft-ietf-sidr-rtr-keying-14.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 20:47:41 -0000 >=20 > So .rtf attachments, if anyone were so wise as to try one, should now = show up in the archive. >=20 Unwise! =E2=80=94Sandy From nobody Fri Dec 8 13:04:49 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BB31272E1; Fri, 8 Dec 2017 13:04:48 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5wc4t3GrezPx; Fri, 8 Dec 2017 13:04:47 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01A9128D40; Fri, 8 Dec 2017 13:04:46 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 43C5128B003B; Fri, 8 Dec 2017 16:04:46 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 3C3361F8036; Fri, 8 Dec 2017 16:04:46 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sandra Murphy In-Reply-To: <5990F5D0-B532-482E-BA4F-D20908F6B862@tislabs.com> Date: Fri, 8 Dec 2017 16:04:45 -0500 Cc: Sandra Murphy , sidr chairs , draft-ietf-sidr-rtr-keying@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0681C485-6A67-4B54-BD36-7695B0D74644@tislabs.com> References: <150851896075.15465.7110696373396971840@ietfa.amsl.com> <68DEA77B-EB7C-4345-A60E-A134E5CAC2F7@sn3rd.com> <79137BEA-5FD8-4E08-8C49-215146A352F2@tislabs.com> <48765D76-8B14-492B-B444-9F895A920D89@tislabs.com> <260B2F04-6A90-464C-A6B1-7518AD68F7E6@tislabs.com> <5990F5D0-B532-482E-BA4F-D20908F6B862@tislabs.com> To: sidr list X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [sidr] comments needed (Re: I-D Action: draft-ietf-sidr-rtr-keying-14.txt) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 21:04:48 -0000 Another thought about one point in my long list of comments. > On Nov 14, 2017, at 9:07 PM, Sandra Murphy wrote: >=20 >=20 > 4. =E2=80=9Ccorresponds=E2=80=9D again - there=E2=80=99s no mention = of a router verifying that the router cert it receives has an AS that is = configured on the router. There are lots of other checks and double = checks - why not this one? =20 Is it possible for a router to be configured with an AS before it = actually brings up a BGP/BGPsec session to a neighbor? (my guess: yes. = but IANAOp) If the router does not know its AS configuration unless it has already = started a BGP session, then the check of the AS in a received cert would = have to be done while BGP was active but BGPsec was not yet activated. Is there a way for a router to receive a cert and check the AS after it = has been configured with an AS, but before the session with the neighbor = actually starts? If the BGP session must be up before the configured AS is known, and the = desire was to check a received cert for a configured AS, then a session = could not start with BGPsec from the very beginning. So. Q1: Is the sequence (1) configure AS (2) check AS in received cert (3) start BGPsec session=20= possible? Q2: If the sequence needs to be (1) configure AS (2) start BGP (3) check AS in received cert (4) start = BGPsec is that acceptable? Q3: If the second sequence is necessary, then is that bad enough, = sufficient reason, to abandon the idea of checking the AS in the cert? =E2=80=94Sandy From nobody Fri Dec 8 14:34:00 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC43128990; Fri, 8 Dec 2017 14:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Lhdscxy34Zmv; Fri, 8 Dec 2017 14:33:57 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1B3127909; Fri, 8 Dec 2017 14:33:57 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C7230B80DCA; Fri, 8 Dec 2017 14:33:36 -0800 (PST) To: nmalykh@gmail.com, mlepinski@bbn.com, kent@bbn.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aretana.ietf@gmail.com, iesg@ietf.org, sidr@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171208223336.C7230B80DCA@rfc-editor.org> Date: Fri, 8 Dec 2017 14:33:36 -0800 (PST) Archived-At: Subject: [sidr] [Errata Held for Document Update] RFC6480 (5196) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 22:33:59 -0000 The following errata report has been held for document update for RFC6480, "An Infrastructure to Support Secure Internet Routing". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5196 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Nikolai Malykh Date Reported: 2017-12-05 Held by: Alvaro Retana (IESG) Section: 6 Original Text ------------- 3. For each manifest, verify that certificates and CRLs issued under the corresponding CA certificate match the hash values contained in the manifest. Additionally, verify that no certificate or manifest listed on the manifest is missing from the repository. If the hash values do not match, or if any certificate or CRL is missing, notify the appropriate repository administrator that the repository data has been corrupted. Corrected Text -------------- 3. For each manifest, verify that certificates and CRLs issued under the corresponding CA certificate match the hash values contained in the manifest. Additionally, verify that no certificate or CRL listed on the manifest is missing from the repository. If the hash values do not match, or if any certificate or CRL is missing, notify the appropriate repository administrator that the repository data has been corrupted. Notes ----- On the fourth line: it should read "certificate or CRL" instead of "certificate or manifest". -------------------------------------- RFC6480 (draft-ietf-sidr-arch-13) -------------------------------------- Title : An Infrastructure to Support Secure Internet Routing Publication Date : February 2012 Author(s) : M. Lepinski, S. Kent Category : INFORMATIONAL Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Fri Dec 8 14:36:51 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1F9127909; Fri, 8 Dec 2017 14:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 XA0UgY2zTJBk; Fri, 8 Dec 2017 14:36:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7EA126BF3; Fri, 8 Dec 2017 14:36:48 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1eNRG8-00033f-A9; Fri, 08 Dec 2017 22:36:44 +0000 Date: Fri, 08 Dec 2017 14:36:43 -0800 Message-ID: From: Randy Bush To: RFC Errata System Cc: nmalykh@gmail.com, mlepinski@bbn.com, kent@bbn.com, sidr@ietf.org, iesg@ietf.org In-Reply-To: <20171208223336.C7230B80DCA@rfc-editor.org> References: <20171208223336.C7230B80DCA@rfc-editor.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [sidr] [Errata Held for Document Update] RFC6480 (5196) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 22:36:50 -0000 > -------------- > 3. For each manifest, verify that certificates and CRLs issued > under the corresponding CA certificate match the hash values > contained in the manifest. Additionally, verify that no > certificate or CRL listed on the manifest is missing from > the repository. If the hash values do not match, or if any > certificate or CRL is missing, notify the appropriate > repository administrator that the repository data has been > corrupted. > > On the fourth line: it should read "certificate or CRL" instead of > "certificate or manifest". while you are at it, data are plural From nobody Fri Dec 8 14:43:40 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A643F126BF3; Fri, 8 Dec 2017 14:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 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, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TCLSCQbJ1TJW; Fri, 8 Dec 2017 14:43:33 -0800 (PST) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E389B12426E; Fri, 8 Dec 2017 14:43:32 -0800 (PST) Received: by mail-ot0-x242.google.com with SMTP id i1so10380768oth.9; Fri, 08 Dec 2017 14:43:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=vSCuZ5zbMHurnPAQ5QaDdxARnb/lviuxM8FuenIj5DM=; b=tO9NqxlhT5LFJoYcBZmDlT1iuR783fADH3q+X7eIMIxuHFMwJVpHI66zOWQ5PqjPqc +GloYk3hWPK+OUnDaKcDXio4/hjo8lU6rK2fykrnJYNoMf/2Lvcm1guaEA1usJ698CGK 46QqtTl9VgwhHjg1zQVMQ6NcPBhava47vdLUiWAPqK+TI94wGacH2S8YZ8/kSiE1LWvZ fjqadIcCaEH9jvnenT0e1uKO4dxh1ZGpI9yQWQBS5rj9tcQPljgq0EIKYcQ/yKk3M13e Nfch2INqGcHoehLT+xwKoaRrHvoRq2ptPCFvLKqcpF78CTHNWiXHOZBfTSUsXbggOE0A mM+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=vSCuZ5zbMHurnPAQ5QaDdxARnb/lviuxM8FuenIj5DM=; b=HQWbwVITEUSb0mf9KvnfGL5ulgcPayb5VLLNMIt6xr8j35OChBaLFHwkkpTH7y9FFF LbcdOUiCT9SDnCVuRssYoFZbyA9LIdHuYwZUofjhN+Tq0YtdL6a+c1MoSzbsVvvFwa3Y YtPX4OX7AKTq87NGHn1f/BH+S5q86YCwN/IosrK8EL68B/GjT8T/nGsGReWXT+w5XHwp oq3fAe/FFk3YBQysRqjESzVscVUMeyWCSbx5WA7/xfe2xpQDqBhXesqpDuiTrVI045p7 pObAxzNuQr7OC/HWvy/czyKEwmeMk1n7xaCP7E39paKxPQO5CExY9wnjoC5GXcDE7Q2F /YdA== X-Gm-Message-State: AKGB3mJ4umF8yj0Y8xOfbMNh2LzguFjQlUgrCbBWBjIRFRupQyNwaR1B /ZYLIJKeyohhzplkgYRmV/C6a7XE0O9yxVJjP6U= X-Google-Smtp-Source: AGs4zMam/PQoTWcui7BJRpPgiB/IlaQAmzkRxMOaZzPCzIzZL9zrYK3cCgXUURKPFGxJYzJCYmdLwdhJfo9IHE3dSwo= X-Received: by 10.157.58.66 with SMTP id j60mr19672154otc.289.1512773012244; Fri, 08 Dec 2017 14:43:32 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 8 Dec 2017 16:43:31 -0600 From: Alvaro Retana In-Reply-To: References: <20171208223336.C7230B80DCA@rfc-editor.org> X-Mailer: Airmail (461) MIME-Version: 1.0 Date: Fri, 8 Dec 2017 16:43:31 -0600 Message-ID: To: RFC Errata System , Randy Bush Cc: kent@bbn.com, mlepinski@bbn.com, iesg@ietf.org, sidr@ietf.org, nmalykh@gmail.com Content-Type: multipart/alternative; boundary="001a11492f88054ea5055fdbead5" Archived-At: Subject: Re: [sidr] [Errata Held for Document Update] RFC6480 (5196) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 22:43:35 -0000 --001a11492f88054ea5055fdbead5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On December 8, 2017 at 5:36:53 PM, Randy Bush (randy@psg.com) wrote: > -------------- > 3. For each manifest, verify that certificates and CRLs issued > under the corresponding CA certificate match the hash values > contained in the manifest. Additionally, verify that no > certificate or CRL listed on the manifest is missing from > the repository. If the hash values do not match, or if any > certificate or CRL is missing, notify the appropriate > repository administrator that the repository data has been > corrupted. > > On the fourth line: it should read "certificate or CRL" instead of > "certificate or manifest". while you are at it, data are plural https://www.merriam-webster.com/dictionary/data According to that, using =E2=80=9Cdata=E2=80=9D with a singular verb is ok= =E2=80=A6as is the plural construction. But English is not my first language, so feel free to file a report. ;-) Thanks! Alvaro. --001a11492f88054ea5055fdbead5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On December 8, 2017 at 5:36:53 PM, Randy Bush (randy@psg.com) wrote:

> ------------= --=C2=A0
> 3. For each m= anifest, verify that certificates and CRLs issued=C2=A0
> under the corresponding CA certificate ma= tch the hash values=C2=A0
&= gt; contained in the manifest. Additionally, verify that no=C2=A0
> certificate or CRL listed on th= e manifest is missing from=C2=A0
> the repository. If the hash values do not match, or if any=C2=A0
> certificate or CRL is= missing, notify the appropriate=C2= =A0
> repository administrator that the repository data has be= en=C2=A0
> corrupted.=C2=A0
>=C2=A0
> On the fourth line: it should read= "certificate or CRL" instead of=C2=A0
> "certificate or manifest".=C2=A0

while you are at it, data a= re plural=C2=A0

https://www.merriam-webster.com/dictionary/data=C2=A0

= According to that, using =E2=80=9Cdata=E2=80=9D with a singular verb is ok= =E2=80=A6as is the plural construction.

But English is not my first l= anguage, so feel free to file a report. ;-)

Thanks!

Alvaro.

=



--001a11492f88054ea5055fdbead5-- From nobody Fri Dec 22 06:44:22 2017 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3543112EADD; Fri, 22 Dec 2017 06:44:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151395385619.28008.7578453053550569599@ietfa.amsl.com> Date: Fri, 22 Dec 2017 06:44:16 -0800 Archived-At: Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-validation-reconsidered-10.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 14:44:16 -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 WG of the IETF. Title : RPKI Validation Reconsidered Authors : Geoff Huston George Michaelson Carlos M. Martinez Tim Bruijnzeels Andrew Lee Newton Daniel Shaw Filename : draft-ietf-sidr-rpki-validation-reconsidered-10.txt Pages : 27 Date : 2017-12-22 Abstract: This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the RPKI, while retaining essential security features. Where the procedure specified in RFC 6487 requires that Resource Certificates are rejecting entirely if they are found to over-claim any resources not contained on the issuing certificate, the validation process defined here allows an issuing Certificate Authority to chose to communicate that such Resource Certificates should be accepted for the intersection of their resources and the issuing certificate. It should be noted that the validation process defined here considers validation under a single Trust Anchor only. In particular, concerns regarding over-claims where multiple configured Trust Anchors claim overlapping resources are considered out of scope for this document. This choice is signalled by form of a set of alternative Object Identifiers (OIDs) of RFC 3779 X.509 Extensions for IP Addresses and AS Identifiers, and certificate policy for the Resource Public Key Infrastructure (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a Trust Anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487 Furthermore this document provides an alternative to ROA (RFC 6482), and BGPSec Router Certificate (BGPSec PKI Profiles - publication requested) validation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-10 https://datatracker.ietf.org/doc/html/draft-ietf-sidr-rpki-validation-reconsidered-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-validation-reconsidered-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 Fri Dec 22 06:52:19 2017 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4714212AF6E; Fri, 22 Dec 2017 06:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.93 X-Spam-Level: X-Spam-Status: No, score=-6.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 uJAVN7THyGmB; Fri, 22 Dec 2017 06:52:16 -0800 (PST) Received: from molamola.ripe.net (molamola.ripe.net [193.0.19.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C86812D87A; Fri, 22 Dec 2017 06:52:16 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eSOgD-0000Nk-PI; Fri, 22 Dec 2017 15:52:10 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-100.ripe.net) by nene.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eSOgD-0006GQ-Jt; Fri, 22 Dec 2017 15:52:09 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Tim Bruijnzeels In-Reply-To: <150415018168.16876.13029068813873198020.idtracker@ietfa.amsl.com> Date: Fri, 22 Dec 2017 15:52:08 +0100 Cc: The IESG , draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, aretana@cisco.com, Chris Morrow , sidr-chairs@ietf.org, sidr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <45838C7F-F97B-4737-AC1F-CC6BB55BFC8A@ripe.net> References: <150415018168.16876.13029068813873198020.idtracker@ietfa.amsl.com> To: Terry Manderson X-Mailer: Apple Mail (2.3445.5.20) X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07192084a65bdcd53c53ceb2f92ec7d358f8 Archived-At: Subject: Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 14:52:18 -0000 Dear Terry, We just uploaded version -10 that we hope addresses your points. This version adds: - explicit text in the abstract stating that this document considers = validation under a Trust Anchor only, and that overlaps between multiple = TAs are out of scope - three examples using the validation algorithm in this document: 1- Old OID only 2- New OID only 3- A mix of old and new OIDs in a single RPKI tree - the deployment considerations section clearly says discussion still = needs to be had, but points at example 3 as a possible deployment = scenario Kind regards, Tim Bruijnzeels, and co-authors > On 31 Aug 2017, at 05:29, Terry Manderson = wrote: >=20 > Terry Manderson has entered the following ballot position for > draft-ietf-sidr-rpki-validation-reconsidered-08: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconside= red/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thank you for considering the stability of the internet's routing = system during > administrative changes to resources. >=20 > One thing isn't quite clear to me, so I'm balloting this as a DISCUSS = with the > plan that a small amount discussion will resolve it. >=20 > With the definition of the new validation OID (a idea that I like = BTW), at any > stage of the certificate issuance can the validation OID be switched? = That is a > TA has a particular OID and down the tree an issued certificate has a = different > OID? If that can't happen (and please make that clear in the document) = is there > plan to migrate the set of all issued certificates to the new OID? and > deprecate the old OID? >=20 > Logically speaking a trust anchor cannot be thought of as = over-claiming. (eg > you trust where the self signed cert came from, and its contents) = However the > new validation constructs suggest that a TA can over-claim, but it = seems like > there won't be any warning (as the example in S4.3) to highlight this = possible > eventuality when (in the model where all RIRs issue a TA) a resource = is > transferred from one RIR to another for the clients use. Is that = interpretation > correct? OR does this new model espouse the belief that all RIRs each = issue a > TA that covers 0/0 and ::/0 in perpetuity? In that construct does this = mean > that RFC6491 should be updated or made historic? >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I get the sense that many of the ramifications for this validation = change are > yet to be discovered. It worries me that from the shepherd writeup = "The > existing CA/RP code implementations will support this once published." = What > experiments have been done to identify any gaps and assumptions? >=20 >=20 >=20