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

Tim Bruijnzeels <tim@ripe.net> Mon, 13 March 2017 09:56 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 6E533129400; Mon, 13 Mar 2017 02:56:04 -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 nvg8CcTeVkYI; Mon, 13 Mar 2017 02:56:03 -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 DC181128AB0; Mon, 13 Mar 2017 02:56:02 -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 1cnMhp-0000Y6-6B; Mon, 13 Mar 2017 10:55:58 +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 1cnMho-0007Eu-Tl; Mon, 13 Mar 2017 10:55:57 +0100
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <6359B4B1-478D-4017-B259-7B60BA55FF39@zdns.cn>
Date: Mon, 13 Mar 2017 10:55:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <68C71545-48E4-40B8-91AC-88DE44C4125D@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>
To: Declan Ma <madi@zdns.cn>
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: 784d7acfe6559f2a0b602ec6519a0719d65889401546bb28a809f3eb9df848ea
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/vphvJ8mrX-YdmOASgndzXPvjo7U>
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>, Rob Austein <sra@hactrn.net>, "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 09:56:04 -0000

Hi,

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?

Cheers
Tim








> On 13 Mar 2017, at 07:16, Declan Ma <madi@zdns.cn> wrote:
> 
> Speaking as the representative of RPSTIR team,
> 
> We are working on RPSTIR update in order to make it use the new algorithm to do INR validation. 
> 
> Before RP performs the new validation process, it needs to get the INRs from certificates.  And we found a bug of OPENSSL library when using OPENSSL to get resource sets from certificates, so we wrote our own code to do so.  
> 
> It seems to me that the only concern on OID is about using OPENSSL to get resource sets for further validation process. If the WG has decided to deprecate the original by using the Validation Reconsidered, why bother to bring a new OID ?
> 
> Declan(Di) Ma
> 
> ZDNS 
> 
>> 在 2017年3月13日,02:28,Chris Morrow <morrowc@ops-netman.net> 写道:
>> 
>> At Sat, 11 Mar 2017 17:25:27 -0500,
>> Rob Austein <sra@hactrn.net> wrote:
>>> 
>>> At Thu, 9 Mar 2017 18:44:58 +0000, Alvaro Retana (aretana) wrote:
>>>> 
>>>> I just finished reading this document.  My review is predicated on
>>>> the assumption that the intent of the WG is to define an additional
>>>> validation process, and not amend/change/update/deprecate the
>>>> existing one?yet, which is why there are not only process changes
>>>> specified, but also new OIDs.
>>> 
>>> Alvaro,
>>> 
>>> I will let the WG chairs and authors speak to intent regarding the
>>> existing validation process.
>>> 
>> 
>> I think the intent of the WG is still to add the new validation
>> process, then deprecate the original once all users are on code which
>> supports the 'new' way.
>> 
>> -chris
>> 
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr