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

"Alvaro Retana (aretana)" <> Thu, 15 June 2017 15:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0076312946F; Thu, 15 Jun 2017 08:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vFzpMhDinMKs; Thu, 15 Jun 2017 08:02:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E4C6128B93; Thu, 15 Jun 2017 08:02:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=16982; q=dns/txt; s=iport; t=1497538939; x=1498748539; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gUmxHRxoI+/9usCd5O3pmKJkWWODMsAL5Hhvjr0ju8A=; b=kc3t9c4SLeNnWCaE3R6gdPpUmn2csE8g7us9uOZTLNPsFdjvt/EQZH7Y RmxxgBXaA93oQdFbcNZaa40pAeqrtCOObpW6Zb3B+vbWDRAlU6CvSOKv6 RseCwWuJ9UktRcIicKr/xTH2EG7sm9c2G89TVqjpUmH6yyI5qy3MhK6Ue E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAQB5oEJZ/5pdJa1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm88LWKBDQeDb4oYkVWQb4U6ghGCboM2AhqCRT8YAQIBAQEBAQEBax0?= =?us-ascii?q?LhRkGI1YQAgEIPwMCAgIwFBECBA4FiUhkqlKCJiuLGAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2GYoFgKwuBYIEMhEaDNjCCMQWXDoc7ApNTkguUfgEfOIEKdBVbAYR?= =?us-ascii?q?6HIFmdocTAiQHgQWBDQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.39,343,1493683200"; d="scan'208,217";a="261229023"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jun 2017 15:02:18 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v5FF2IIb015937 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Jun 2017 15:02:18 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 15 Jun 2017 10:02:17 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Thu, 15 Jun 2017 10:02:17 -0500
From: "Alvaro Retana (aretana)" <>
To: "" <>
CC: "" <>, "" <>, Tim Bruijnzeels <>, Chris Morrow <>
Thread-Topic: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07
Date: Thu, 15 Jun 2017 15:02:17 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C1D1FDD298924EE086FF24F412AF6669ciscocom_"
MIME-Version: 1.0
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: Thu, 15 Jun 2017 15:02:22 -0000

Dear authors:


It’s been 3 months since this e-mail, which was the last of the thread started from my review.

I am expecting a revised ID – what are the plans to move forward?



On 3/15/17, 10:24 AM, "sidr on behalf of Tim Bruijnzeels" <<> on behalf of<>> wrote:

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.