From nobody Thu Aug 24 06:55:07 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 2FD3713295E; Thu, 24 Aug 2017 06:54:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, aretana@cisco.com, Chris Morrow , sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150358289918.24287.6930264240208595572.idtracker@ietfa.amsl.com> Date: Thu, 24 Aug 2017 06:54:59 -0700 Archived-At: Subject: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-sidr-rpki-validation-reconsidered-08=3A_=28with_COMMENT=29?= 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: Thu, 24 Aug 2017 13:54:59 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-sidr-rpki-validation-reconsidered-08: No Objection 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Given this new mechanism seems to be the recommended way of doing things, I would expect that this draft updates RFC 6487. From nobody Fri Aug 25 05:31:34 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 79DBE132027; Fri, 25 Aug 2017 05:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 qwjXDXR9aEoK; Fri, 25 Aug 2017 05:31:25 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A8C132BE6; Fri, 25 Aug 2017 05:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=850; q=dns/txt; s=iport; t=1503664283; x=1504873883; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FNkY1FyPJkMKKvSUR2ImiIaMmhBQX4rnM7GDMrlVpws=; b=b2X08v0J/47Ilrm8x/RZlMJJyrFQbARMdhxMndUDxyXfNmAbw8OYhs31 c5dmsvmpL2N1kT/ufhowoAHwxwbEMwwEhhfYPXWGkfDL8OAgtscbVrCD2 x2Tf9oUxqdquMPShQzEeB44UaImRcbwvfR3oddB86Qmva/w+4CO9JUh19 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DpAgB/F6BZ/5hdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1qBeQeeJYFPkVuEbIIShUcCGoNGQBcBAgEBAQEBAQFrKIUZBiMRRRA?= =?us-ascii?q?CAQgaAh8HAgICMBUFCwIEAQ0FijGtV4Ini2EBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEdgQ2CHYICgU6CDguCcoR1gxMwgjEFigGOKIg4ApREgXqQbJY2ASABNoENdxV?= =?us-ascii?q?bAYU6gU52h3krgQWBDwEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,425,1498521600"; d="scan'208";a="285389304" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Aug 2017 12:31:21 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7PCVLbq008099 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Aug 2017 12:31:21 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 25 Aug 2017 07:31:21 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Fri, 25 Aug 2017 07:31:21 -0500 From: "Alvaro Retana (aretana)" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" , Chris Morrow , "sidr-chairs@ietf.org" , "sidr@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?B?LXNpZHItcnBraS12YWxpZGF0aW9uLXJlY29uc2lkZXJlZC0wODogKHdpdGgg?= =?utf-8?Q?COMMENT)?= Thread-Index: AQHTHOCW9IVrgGO4rUm00Ve5wwkDVKKVEx4A Date: Fri, 25 Aug 2017 12:31:21 +0000 Message-ID: <626DE792-2849-4257-AC5B-2574872D4253@cisco.com> References: <150358289918.24287.6930264240208595572.idtracker@ietfa.amsl.com> In-Reply-To: <150358289918.24287.6930264240208595572.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.236.208] Content-Type: text/plain; charset="utf-8" Content-ID: <13967404E490F446BBDCC19A62F0BF35@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-sidr-rpki-validation-reconsidered-08=3A_=28with_COMMENT=29?= 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, 25 Aug 2017 12:31:26 -0000 T24gOC8yNC8xNywgOTo1NSBBTSwgIk1pcmphIEvDvGhsZXdpbmQiIDxpZXRmQGt1ZWhsZXdpbmQu bmV0PiB3cm90ZToNCg0KTWlyamE6DQoNCkhpIQ0KDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVO VDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPiBHaXZlbiB0aGlzIG5ldyBtZWNoYW5pc20gc2VlbXMg dG8gYmUgdGhlIHJlY29tbWVuZGVkIHdheSBvZiBkb2luZyB0aGluZ3MsIEkNCj4gd291bGQgZXhw ZWN0IHRoYXQgdGhpcyBkcmFmdCB1cGRhdGVzIFJGQyA2NDg3Lg0KDQpQcmV2aW91cyB2ZXJzaW9u cyBvZiB0aGUgZHJhZnQgVXBkYXRlZCB0aGF0IGFuZCBvdGhlciBSRkNzLCBidXQgdGhlIGludGVu dCBpcyB0byBkZWZpbmUgYSBuZXcgbWVjaGFuaXNtLCBub3QgdG8gcmVwbGFjZSB0aGUgY3VycmVu dCBvbmUgeWV0LiAgQWZ0ZXIgZGlzY3Vzc2lvbiwgaXQgd2FzIGRlY2lkZWQgYWdhaW5zdCBVcGRh dGluZyBiZWNhdXNlIG9mIHRoYXQuDQoNClRoYW5rcyENCg0KQWx2YXJvLg0KDQoNCg== From nobody Sat Aug 26 12:46:42 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 0F0E4126E64; Sat, 26 Aug 2017 12:46:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, aretana@cisco.com, Chris Morrow , sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150377679405.25829.10187635753258337816.idtracker@ietfa.amsl.com> Date: Sat, 26 Aug 2017 12:46:34 -0700 Archived-At: Subject: [sidr] Eric Rescorla's No Objection on draft-ietf-sidr-rpki-validation-reconsidered-08: (with COMMENT) 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: Sat, 26 Aug 2017 19:46:34 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-sidr-rpki-validation-reconsidered-08: No Objection 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- TECHNICAL S 4.2.4.4. Point 5 says: Section 4.2.4.2 or Section 4.2.4.3, or both. The value(s) for each of these extensions MUST satisfy the constraints established for each extension in the respective sections. Any extension not thus identified MUST NOT appear in certificate x. Assuming I am reading this correctly, you are saying that no other extensions at all can be added? That seems contrary to the point of extensions. The 4th bullet of point 7 says: * If the IP Address Delegation extension is present in certificate x and x=1, set the VRS-IP to the resources found in this extension. I think you mean AS Identifier Delegation Can you please clarify whether the new syntax defined in 4.2.2.2 and 4.2.2.3 is just the same syntax as in 6487 with a new OID? If not, can you please describe the differences clearly in this document? EDITORIAL It would help if the abstract were more clear about the problem you were trying to solve. 8. If there is any difference in resources in the VRS-IP and the IP Address Delegation extension on certificate x, or the VRS-AS and This might read better if it were "difference in resources between the..." From nobody Sun Aug 27 15:11:58 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 C62B913219F; Sun, 27 Aug 2017 15:11:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, aretana@cisco.com, Chris Morrow , sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150387191180.9892.8436117265376778688.idtracker@ietfa.amsl.com> Date: Sun, 27 Aug 2017 15:11:51 -0700 Archived-At: Subject: [sidr] Spencer Dawkins' No Objection on draft-ietf-sidr-rpki-validation-reconsidered-08: (with COMMENT) 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: Sun, 27 Aug 2017 22:11:52 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-sidr-rpki-validation-reconsidered-08: No Objection 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I had the same question Mirja did. Thanks, Alvaro, for your response. From nobody Mon Aug 28 16:31:32 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 82F8C13219A; Mon, 28 Aug 2017 16:31:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, aretana@cisco.com, Chris Morrow , sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150396308653.13163.15900576854966389050.idtracker@ietfa.amsl.com> Date: Mon, 28 Aug 2017 16:31:26 -0700 Archived-At: Subject: [sidr] Adam Roach's No Objection on draft-ietf-sidr-rpki-validation-reconsidered-08: (with COMMENT) 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: Mon, 28 Aug 2017 23:31:26 -0000 Adam Roach has entered the following ballot position for draft-ietf-sidr-rpki-validation-reconsidered-08: No Objection 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This seems like a good change. Not knowing much about the deployment practicalities of BGP, I presume that the set of tools used for validation is sufficiently well-known that CAs will positively know when it is safe to start using the new OIDs? I found the lack of an introduction section to be odd. Please double-check this document against the I-D Nits document; and, in particular, section 2.2: I believe "Russ Housley" is misspelled section 8. Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - RPKI - Resource Public Key Infrastructure - AS - Autonomous System - ROA - Route Origin Authorization - CA - Certificate Authority - CRL - Certificate Revocation List From nobody Mon Aug 28 19:36:31 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 E14CA13213D; Mon, 28 Aug 2017 19:36:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, aretana@cisco.com, Chris Morrow , sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com> Date: Mon, 28 Aug 2017 19:36:24 -0700 Archived-At: Subject: [sidr] Ben Campbell'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 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 02:36:25 -0000 Ben Campbell has entered the following ballot position for draft-ietf-sidr-rpki-validation-reconsidered-08: Discuss 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is probably just a matter of me being dense, but I'd like to understand what I am missing: Is it legal to mix certificate policies in a given cert path? The last paragraph of section 5 implies that you can, but doesn't say so explicitly. If you _can_ mix policies, what happens if you do? If I read the rules in 4.2.4.4. correctly (and it's likely that I am not), if you run into a cert in the chain that does not follow this profile, it's likely to give a null VRS-IP or VRS-AS value, which would seem to invalidate an certificate further down the chain that _does_ follow this policy? So, I guess it comes down to the following: If mixed policies are allowed, how does that work? If mixed policies are not allowed, there needs to be text that says that. It's quite possible such text exists (here or elsewhere), and I missed it. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: - General: There's a lot of amending going on here--does this draft really not update any RFCs (e.g. 6487)? - 4.2.4.4: -- "Any extension not thus identified MUST NOT appear in certificate x." (Repeats multiple times) That seems to prevent future extensibility. Is that the intent? -- "Certificate x MUST NOT have been revoked, i.e., it MUST NOT appear on a CRL issued by the CA represented by certificate x-1" Is this intended as a requirement to check CRLs? If so, please say that explicitly. Editorial: -4.2.2.1: The third paragraph seems redundant to the first paragraph (pattern repeats in several sections.)he - 4.2.4.3: "Either the IP Resources extension, or the AS Resources extension, or both, MUST be present in all RPKI certificates, and if present, MUST be marked critical." "... and if present..." seems redundant, since the previous clause said one MUST be present. - 4.3.4.3: "... values are NOT supported..." a floating, capitalized "NOT" is not defined in RFC 2119. I suspect the all-caps is just for emphasis, but we typically reserve that for RFC 2119 keywords. - 4.2.4.4 : -- "Certificate validation requires verifying that all of the following conditions hold, in addition to the certification path validation criteria specified in Section 6 of [RFC5280]." The "... in addition to..." part doesn't seem quite true. For example, making sure the current date fits in the active range, ensuring a cert is signed by the issuer, etc. are already covered in 5280. - - "...certificate MUST contain all extensions defined in section 4.8 of [RFC6487] that must be present." That seems tautologically true. If this is a statement of fact, then please avoid the MUST. If this is really a new normative requirement, then I'm confused at the intent. -- "all extensions defined in section 4.8 of [RFC6487], except sections 4.8.9, 4.8.10 and 4.8.10 MUST be present. " It would be more reader-friendly to mention what extensions are defined in 4.8.9. -- "7. Compute the VRS-IP and VRS-AS set values as indicated below:" Inconsistent voice. -- list entry 7, 4th bullet: "If the IP Address Delegation extension is present in certificate x and x=1, set the VRS-IP to the resources found in this extension." That seems identical to the first bullet. Should it has said "AS Address Delegation extension"? From nobody Tue Aug 29 12:08:33 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 287D113248B; Tue, 29 Aug 2017 12:08:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Deborah Brungard To: "The IESG" Cc: draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, aretana@cisco.com, Chris Morrow , sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150403370616.29354.3222488918196340151.idtracker@ietfa.amsl.com> Date: Tue, 29 Aug 2017 12:08:26 -0700 Archived-At: Subject: [sidr] Deborah Brungard's No Objection on draft-ietf-sidr-rpki-validation-reconsidered-08: (with COMMENT) 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: Tue, 29 Aug 2017 19:08:26 -0000 Deborah Brungard has entered the following ballot position for draft-ietf-sidr-rpki-validation-reconsidered-08: No Objection 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I was confused also if this was an update based on the abstract and shepherd writeup. As it was decided not to be an update, but to be a new procedure, suggest tweaking the wording on update/modify, e.g. in the Abstract: updated procedure/s/procedure. From nobody Wed Aug 30 05:44:21 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 3C92A1331A7; Wed, 30 Aug 2017 05:44:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Will LIU To: Cc: draft-ietf-sidr-rpki-validation-reconsidered.all@ietf.org, ietf@ietf.org, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150409704619.21582.12831904999110291317@ietfa.amsl.com> Date: Wed, 30 Aug 2017 05:44:06 -0700 Archived-At: Subject: [sidr] Opsdir last call review of draft-ietf-sidr-rpki-validation-reconsidered-08 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: Wed, 30 Aug 2017 12:44:06 -0000 Reviewer: Will LIU Review result: Ready I have reviewed draft-ietf-sidr-rpki-validation-reconsidered-08 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. "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. The use of this updated procedure is signalled by form of a set of alternative Object Identifiers (OIDs) indicating that the alternative version of RFC 3779 X.509 Extensions for IP Addresses and AS Identifiers, and certificate policy for the Resource Public Key Infrastructure (RFC 6484) defined in this document should be used. Furthermore this document provides an alternative to ROA↓ (RFC 6482), and BGPSec↓ Router Certificate (BGPSec↓ PKI Profiles - publication requested) validation." My overall view of the document is 'Ready' for publication. One small comment is that we usually add a section for terminology for such a document with so many terms. This can also solve the issue that some of the acronyms were not given the full name. From nobody Wed Aug 30 11:47:31 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 B547D132386; Wed, 30 Aug 2017 11:47:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, aretana@cisco.com, Chris Morrow , sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150411884973.21541.5203291979052779718.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 11:47:29 -0700 Archived-At: Subject: [sidr] Alexey Melnikov's No Objection on draft-ietf-sidr-rpki-validation-reconsidered-08: (with COMMENT) 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: Wed, 30 Aug 2017 18:47:30 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-sidr-rpki-validation-reconsidered-08: No Objection 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am agreeing with Ben's comments and I am generally concerned about lack of certificate extensibility in SIDR. (But I've raised this question when reviewing an earlier SIDR document and the WG didn't change its mind.) In Section 4.2.4.4: 3. The Version, Issuer, and Subject fields of certificate x satisfy the constraints established in Section 4.1-4.7 of this specification. There is no section 4.7 in this draft, so I think this should point to the original RFC from which this text was copied. On page 16: * If the IP Address Delegation extension is present in certificate x and x=1, set the VRS-IP to the resources found in this extension. This looks like a cut & paste error. I think you meant "Identifier" and "VRS-AS" above? From nobody Wed Aug 30 20:29:43 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 A7E11124207; Wed, 30 Aug 2017 20:29:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Terry Manderson To: "The IESG" Cc: draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, aretana@cisco.com, Chris Morrow , sidr-chairs@ietf.org, morrowc@ops-netman.net, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150415018168.16876.13029068813873198020.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 20:29:41 -0700 Archived-At: Subject: [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 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 03:29:42 -0000 Terry Manderson has entered the following ballot position for draft-ietf-sidr-rpki-validation-reconsidered-08: Discuss 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for considering the stability of the internet's routing system during administrative changes to resources. 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. 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? 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? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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?