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

Tim Bruijnzeels <> Wed, 15 March 2017 09:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 44959129A0F; Wed, 15 Mar 2017 02:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t0Uv-u63osf2; Wed, 15 Mar 2017 02:24:42 -0700 (PDT)
Received: from ( [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9F10129A07; Wed, 15 Mar 2017 02:24:42 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1co5AX-0002mw-Ru; Wed, 15 Mar 2017 10:24:35 +0100
Received: from ([] by with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from <>) id 1co5AX-0002qe-Nm; Wed, 15 Mar 2017 10:24:33 +0100
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_C5394AF2-E4EC-4AEE-8F4B-848DC4C4F3A7"
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Wed, 15 Mar 2017 10:24:33 +0100
Cc:, Rob Austein <>, "" <>, "" <>, "" <>
Message-Id: <>
References: <> <> <> <> <> <>
To: Chris Morrow <>
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 0.0 HTML_MESSAGE BODY: HTML included in message 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719e8dd8a0a517714e754f0cb710ce62cf5
Archived-At: <>
Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07
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: Wed, 15 Mar 2017 09:24:44 -0000

Hi Chris,

> On 13 Mar 2017, at 15:21, Chris Morrow <> wrote:
> but, having 2 versions of the validation
> algorithm and seeing published data for both OID sets for a single
> prefix/publication bundle will be very problematic. There's no
> proscribed 'prefer new over old' action here, so a CA must only
> publish one version of their data.

Why is this a problem, really?

The OIDs are set on a per certificate basis by the issuing CA. FWIW, in our hosted set up we *will* be able to pro-actively re-issue everything using the new OIDs without user interaction, but there are cases in hosted CA deployments where a hosted CA can automatically re-issue manifests, but ROAs can only be re-issued by explicit user request, one by one.

So we may see hosted CAs with products like this:

1 CRL (validation algorithm does not apply)
1 MFT (new validation, although it won't matter because inherit is used)
1 ROA with new validation (which has been re-issued by the user)
1 ROA with old validation (which has NOT yet been re-issued)

This might seem confusing, but since the OIDs make it very explicit which algorithm the CA intended to use, I really do not see any ambiguity here.

My main concern is that we need to be quite confident that new RP code that understands the new OIDs has been available and is deployed. Because old RPs will reject EVERYTHING once CAs start using the new OIDs.

That is why I would have preferred to not need new OIDs, and just agree on a day that the new algorithm should be preferred. Rob seems adamant that the RFC3779 extension library code does not have access to the context of the full certificate with the RPKI CP OID - so there is no way to have something like:

if (FULL certificate has RPKI CP OID && Date is after 'switch' day) {
  do NEW on RFC3779 extension
} else {
  do OLD on RFC3779 extension

The impact of RP software not using the new library on 'switch' day is fairly limited. They would not reject the full repository, but only reject the exceptional cases where certificates ARE over-claiming. And of course the date check can be removed in releases of the library after 'switch' day..

It seems to me that this is a design issue with OpenSSL itself, but be that as it may - it may be unsurmountable. Rob knows this code much better than I do.

Still the consequence of all this is is that we will have to have a mix, and that despite our best efforts to warn everyone to upgrade their RP software I expect that we WILL see a number of operators that suddenly find that their old RP software has reject our full repository when start using the new OIDs.

If it can't be avoided than so be it, but I believe this perspective should be considered as well.