Re: [sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)

Tim Bruijnzeels <tim@ripe.net> Fri, 22 December 2017 14:52 UTC

Return-Path: <tim@ripe.net>
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 <tim@ripe.net>) 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 <tim@ripe.net>) 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 <tim@ripe.net>
In-Reply-To: <150415018168.16876.13029068813873198020.idtracker@ietfa.amsl.com>
Date: Fri, 22 Dec 2017 15:52:08 +0100
Cc: The IESG <iesg@ietf.org>, draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, aretana@cisco.com, Chris Morrow <morrowc@ops-netman.net>, 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 <terry.manderson@icann.org>
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: <https://mailarchive.ietf.org/arch/msg/sidr/5C0IEJ4p65lf1FXTT3bSh9k3Bck>
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 <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=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 <terry.manderson@icann.org> wrote:
> 
> 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?
> 
> 
>