Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07

Tim Bruijnzeels <tim@ripe.net> Mon, 13 March 2017 14:25 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 33ACB12969B; Mon, 13 Mar 2017 07:25:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 wSdRO42w7H9S; Mon, 13 Mar 2017 07:25:23 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 1D72812969A; Mon, 13 Mar 2017 07:25:22 -0700 (PDT)
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.88) (envelope-from <tim@ripe.net>) id 1cnQuS-0000sr-OM; Mon, 13 Mar 2017 15:25:18 +0100
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-195.ripe.net) by nene.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from <tim@ripe.net>) id 1cnQuS-00071W-IX; Mon, 13 Mar 2017 15:25:16 +0100
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=us-ascii
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <20170313131155.D22115DCF34@minas-ithil.hactrn.net>
Date: Mon, 13 Mar 2017 15:25:13 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E57BAB1-8241-495E-A201-D785FFF3AEC9@ripe.net>
References: <5821A5CF-EFF8-4CE3-9AA4-CFDB9C903D63@cisco.com> <20170311222527.324125ACF21@minas-ithil.hactrn.net> <yj9ok27upcws.wl%morrowc@ops-netman.net> <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn> <68C71545-48E4-40B8-91AC-88DE44C4125D@ripe.net> <20170313131155.D22115DCF34@minas-ithil.hactrn.net>
To: Rob Austein <sra@hactrn.net>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ------
X-RIPE-Spam-Report: Spam Total Points: -6.0 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071904ba42f6741bbe4d985c57319b0f9116
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/gfZu50TI935k3FC22avGeK0nKuE>
Cc: Chris Morrow <morrowc@ops-netman.net>, "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" <draft-ietf-sidr-rpki-validation-reconsidered@ietf.org>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 13 Mar 2017 14:25:24 -0000

Hi Rob, all,

> On 13 Mar 2017, at 14:11, Rob Austein <sra@hactrn.net> wrote:
> 
> At Mon, 13 Mar 2017 10:55:56 +0100, Tim Bruijnzeels wrote:
>> 
>> So, to me it seems that having new OIDs makes perfect sense as long
>> as there is a choice of two validation algorithms. Then having an
>> explicit flag set by CAs tells RPs decide which way to go. Because
>> of this I also do not see an immediate need to have a time line for
>> all CAs to use the new protocol for all its products. It's all
>> explicit.
>> 
>> Now, if the ambition is to have reconsidered as the only algorithm
>> for doing RPKI validation, then I think that the RPKI Certificate
>> Policy OID is enough (section 4.8.9 of RCF4587 - which delegates to
>> section 1.2 of RFC6484). I realise that RFC3779 section 2.3 has text
>> on path validation as well, but I think could can recognise that a
>> different algorithm should apply in the context of *RPKI*
>> validation.
>> 
>> If I understand Rob's concerns though he feels that this will cause
>> issues, and that therefore the RFC3779 OID cannot be used. Rob, is
>> this correct? Why can't RP/OpenSSL code just make the switch based
>> on the CA certificate profile?
> 
> The problem is that there are one or two things out there besides RPKI
> which use X.509, and it would be nice to avoid breaking them.

I understand that. I meant to say that the switch should be based on the RPKI CA certificate policy qualifier. That is specific to RPKI so, other applications would not break.

Non-RPKI use of RFC3779, would not have this same OID, and therefore would still have the path validation from section 2.3 in RFC3779.


> The OIDs which MUST be changed are the ones labeling the extensions
> themselves.  The semantics of X.509v3 critical extensions says,
> basically, "If you don't understand the meaning of this extension, you
> MUST consider this certificate invalid".  Changing the meaning of the
> extensions while retaining the existing OIDs would break this: there
> is code out there which thinks it does understand the RFC 3779
> extensions, but which would now be incorrect, because the RFC 3779
> OIDs would now be used to label things that are not RFC 3779
> extensions.
> 
> Granted, the probability that some random X.509 CA is going to include
> RFC 3779 extensions in certificates for any purpose other than RPKI is
> fairly low, but it would be nice to avoid creating a situation in
> which users of such certificates got inconsistent results depending on
> which version of a stock library they happened to use.  If this were
> OpenSSL doing something stupid I wouldn't care so much, but this was
> OpenSSL implementing an IETF proposed standard to the best of the
> author's ability, and you're talking about retroactively breaking that
> for gratuitous reasons.  This is irresponsible.  Don't do it.
> 
> I don't understand why we're wasting time debating this (again).  OIDs
> are cheap, and (I thought) this was a done deal.  Can we please just
> admit that we're talking about new extensions with new semantics which
> borrow syntax from the existing extensions, label them accordingly,
> and move on?

The reason why I keep talking about this, is because other people indicated that it could be desirable that validation reconsidered is not a choice (that would need flagging, so OIDs are appropriate) - but should become the default.

In that case it's much simpler to have a switch on the unique RPKI CP OID from section 1.2 of RFC6484. 

The proposed OIDs itself are cheap, and the code changes are simple. The difficulty is that we need a deployment plan:

1= RPs MUST support new OIDs, before
2= CAs MAY use new OIDs

and an open question still is whether there needs to be a later
3= CAs MUST use new OIDs and RPs MUST reject old OIDs

Step 2 has operational impact if operators did not upgrade their RP software. Step 3 has operational impact in case a CA cannot re-issue certain objects.

If we need to end up in a place where 'validation reconsidered' is the default, then these operational impacts can be minimised. It would boil down to deciding a date X by which RPs MUST use reconsidered when they encounter the RPKI CP OID, and a date Y (before X) that these should be available. Operators that don't upgrade before date X could find that they consider certain objects invalid, that would be (partially) valid.

In any case, I know that you know more about how the openssl code works. So if there is a reason why the switch cannot work on the RPKI CP OID without affecting non-RPKI use, or if there is a strong reason for having both algorithms alongside each other, than I am (still) open to the OIDs that I painstakingly added to the document.


Tim