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

Rob Austein <sra@hactrn.net> Mon, 13 March 2017 15:17 UTC

Return-Path: <sra@hactrn.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 438281294F9; Mon, 13 Mar 2017 08:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 opyiu0iw_c13; Mon, 13 Mar 2017 08:17:01 -0700 (PDT)
Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1D51294B1; Mon, 13 Mar 2017 08:16:58 -0700 (PDT)
Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 0F0B0139A2; Mon, 13 Mar 2017 15:16:57 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 281B65DDF63; Mon, 13 Mar 2017 11:16:57 -0400 (EDT)
Date: Mon, 13 Mar 2017 11:16:57 -0400
From: Rob Austein <sra@hactrn.net>
To: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <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> <4E57BAB1-8241-495E-A201-D785FFF3AEC9@ripe.net>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20170313151657.281B65DDF63@minas-ithil.hactrn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/fmjCC8pYmspMYRsHGxhM9fuLgGc>
Cc: "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" <draft-ietf-sidr-rpki-validation-reconsidered@ietf.org>, Chris Morrow <morrowc@ops-netman.net>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>, Rob Austein <sra@hactrn.net>
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 15:17:02 -0000

At Mon, 13 Mar 2017 15:25:13 +0100, Tim Bruijnzeels wrote:
> 
> 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.

The problem is that you're talking about applications, while I'm
talking about libraries.

> 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.

You are making assumptions about how the library code works.  As it
happens, those assumptions are incorrect for the OpenSSL case.

> 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.

I disagree.

> 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.

Old-policy-OID requires old-extension-OIDs.  New-policy-OID requires
new-extension-OIDs.  Simple, unambiguous, no magic required.

> If we need to end up in a place where 'validation reconsidered' is
> the default, then these operational impacts can be minimised.

Hiding the change does not solve the problem, it just makes it harder
to debug when it breaks.

> 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.

That's what I've been trying to tell you.

At least in OpenSSL's case, certificate extensions are processed down
in the guts of the library.  Certificates with critical extensions
which do not pass validation are rejected by the library, regardless
of any policy setting.  Policy OID constraints require cooperation by
the application.

So while your scheme sort of works for RPKI-aware applications which
enforce an RPKI policy OID, it does not work for non-RPKI applications
which encounter RFC 3997 extensions: you will get the same certificate
looking valid to one validation engine and invalid to another, because
the same OIDs trigger different processing in the two engines.

Don't go there.  Please, don't go there.  This is dangerous.

Please just keep the new separate extension OIDs and stop trying to
pretend that we can sweep the flag days for an incompatible change
under the rug.  We can't.  Accept that and move on.