Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)

Tim Bruijnzeels <tim@ripe.net> Thu, 14 September 2017 12:00 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 4C29F133020; Thu, 14 Sep 2017 05:00:50 -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] 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 emoo-Lul1JHr; Thu, 14 Sep 2017 05:00:48 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [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 ietfa.amsl.com (Postfix) with ESMTPS id 195D8132198; Thu, 14 Sep 2017 05:00:48 -0700 (PDT)
Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <tim@ripe.net>) id 1dsSoz-000BJ3-SL; Thu, 14 Sep 2017 14:00:43 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-254.ripe.net) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <tim@ripe.net>) id 1dsSoz-0006vD-Ms; Thu, 14 Sep 2017 14:00:41 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <BF1750C4-6D9C-4C3B-8B93-7165514711F6@nostrum.com>
Date: Thu, 14 Sep 2017 14:00:40 +0200
Cc: "Alvaro Retana (aretana)" <aretana@cisco.com>, Terry Manderson <terry.manderson@icann.org>, Chris Morrow <morrowc@ops-netman.net>, sidr chairs <sidr-chairs@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-sidr-rpki-validation-reconsidered@ietf.org" <draft-ietf-sidr-rpki-validation-reconsidered@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D2605E4-F0C8-477E-BBDB-CDD71057B483@ripe.net>
References: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com> <631F9DFE-B24F-4263-949F-3DACA89A53DC@ripe.net> <49091FA6-029F-4B40-9405-9EA8A31C4948@cisco.com> <BF1750C4-6D9C-4C3B-8B93-7165514711F6@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.3273)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: -------
X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07196577235a6631a2a92db2e5f4e8af5d34
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/eyo1IYcCXWX2GoV_vcSHUex43YQ>
Subject: Re: [sidr] Ben Campbell's Discuss on draft-ietf-sidr-rpki-validation-reconsidered-08: (with DISCUSS and COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 14 Sep 2017 12:00:50 -0000

Hi,

Sure. I also proceeded to discuss your and Terry’s points, but apparently not to the desired level of clarity. Let me try again here, and tackle both your and Terry’s discuss items since they are closely related.

> Is it legal to mix certificate policies in a given cert path? The last
> paragraph of section 5 implies that you can, but doesn't say so explicitly.

According to this document it is. Section 4.2.2.4 starts with the following:

   The following is an amended specification for path validation to be
   used in place of section 7.2 of [RFC6487] allowing for the validation
   of both certificates following the profile defined in [RFC6487], as
   well as certificates following the profile described above.

So the intent here is to describe a single validation algorithm that can be used to validate a chain of old OIDs only (in which case it’s semantically equivalent to the current spec in RFC6487), new OIDs only (as described in the example in 4.3), or indeed a mix - but no example is given on how that works out.


> If you _can_ mix policies, what happens if you do? If I read the rules in 4.2.4.4.
> correctly (and it's likely that I am not), if you run into a cert in the chain
> that does not follow this profile, it's likely to give a null VRS-IP or VRS-AS
> value, which would seem to invalidate an certificate further down the chain
> that _does_ follow this policy?


The “Validated Resource Sets” (VRS-*) are always calculated, regardless of whether the old or new OIDs are used.

If no ‘over-claims’ are found (still very much the intended normal) the validation result will be the same whether old OIDs only, new OIDs only, or a mix of OIDs are used.

In case over-claims do exist then it depends on whether the certificate under inspection uses the new OIDs or not. In case it doesn’t, it will be rejected and things behave as in RFC6487. In case it does, then the intersection of resources is still accepted. Any certificates issued further down the tree that also include these over-claimed resource would then be rejected if they happen to use the old OIDs, or if they use the new OIDs the intersection of quoted resources and the VRS-* of the issuing certificate would be accepted. 

I can illustrate by example, and if desired extend section 4.3 with this:


   Consider the following example where a mix of old and new OIDs are used in the RPKI tree:


     Certificate 1 (TA):
      OID: NEW
      Issuer TA,
      Subject TA,
      Resources 192.0.2.0/24, 198.51.100.0/24,
                2001:db8::/32, AS64496-AS64500

       Verified Resource Set: 192.0.2.0/24, 198.51.100.0/24,
                              2001:db8::/32, AS64496-AS64500
       Warnings: none

       NOTE: The choice of OID is irrelevant for the TA. By definition, it cannot be over-claiming.


     Certificate 2 (CA1):
      Issuer TA,
      Subject CA1,
      OID: OLD
      Resources 192.0.2.0/24, 2001:db8::/32, AS64496

       Verified Resource Set: 192.0.2.0/24,
                              2001:db8::/32, AS64496
       Warnings: none


     Certificate 3 (CA2):
      Issuer CA1,
      Subject CA2,
      OID: NEW
      Resources 192.0.2.0/24, 198.51.100.0/24, AS64496

       Verified Resource Set: 192.0.2.0/24, AS64496
       Warnings: over-claim for 198.51.100.0/24

       NOTE: Even though Certificate 2 used the old OIDs, Certificate 3 can be accepted with a reduced VRS since it uses the new OIDs.


     Certificate 4 (CA3):
      Issuer CA2,
      Subject CA3,
      OID: NEW
      Resources 192.0.2.0/24

       Verified Resource Set: 192.0.2.0/24
       Warnings: none


     Certificate 5 (CA4):
      Issuer CA2,
      Subject CA4
      OID: NEW
      Resources 198.51.100.0/24

       Verified Resource Set: empty
       Warnings: 198.51.100.0/24

       Note: The accepted VRS-* contains no resources. So even if the certificate itself is accepted, its key cannot be used
                 to make valid assertions about any resources.


     ROA 1 for CA3 (valid):
      Embedded Certificate R1 (EE certificate):
       Issuer CA4,
       Subject R1,
       OID: OLD
       Resources 192.0.2.0/24

        Verified Resource Set: 192.0.2.0/24
        Warnings: none

        Prefix 192.0.2.0/24, Max Length 24, ASN 64496

       ROA1 is considered valid because the prefix matches the Verified
       Resource Set on the embedded EE certificate.


     ROA 2 for CA3 (invalid):
      Embedded Certificate R2 (EE certificate invalid):
       Issuer CA2,
       Subject R2,
       OID: OLD
       Resources 198.51.100.0/24

        Verified Resource Set: none (certificate is rejected)
        Warnings: none (certificate rejected)

        Prefix 198.51.100.0/24, Max Length 24, ASN 64496

       ROA2 is considered invalid because the embedded EE certificate is
       considered invalid.

     ROA 3 for CA4 (invalid):
      Embedded Certificate R3 (EE certificate invalid):
       Issuer CA2,
       Subject R3,
       OID: NEW
       Resources 198.51.100.0/24

        Verified Resource Set: empty
        Warnings: 198.51.100.0/24

        Prefix 198.51.100.0/24, Max Length 24, ASN 64496

       ROA3 is considered invalid because the prefix is not included in the
       empty VRS.

       Note: since all ROA Prefixes need to be in the VRS-* for the
                ROA to be valid, it might make sense to simply mandate
                old OIDs on ROA EE certificates.


I hope this clarifies. But please let me know if it doesn’t, and thank you for helping to clarify the document.

Tim





> On 13 Sep 2017, at 23:18, Ben Campbell <ben@nostrum.com> wrote:
> 
> Alvaro’s interpretation is indeed what I meant. My concern is with what works and what doesn’t work with the basic mechanism. How it will get used in practice is a related, but different, issue.
> 
> Thanks!
> 
> Ben.
> 
>> On Sep 13, 2017, at 10:57 AM, Alvaro Retana (aretana) <aretana@cisco.com> wrote:
>> 
>> [Explicitly adding Terry…]
>> 
>> Tim:
>> 
>> Hi!
>> 
>> As I think you understand from the response below, there are two parts to consider when deploying: what can be done, and what will be done.  Interpreting what Ben and Terry wrote…what I think they are asking is for you to clarify in this document the considerations around mixing policies.  For example (to borrow from Terry), if a “TA has a particular OID and down the tree an issued certificate has a different OID”, what are the implications/problems/etc.?
>> 
>> Note that this question is different from the document defining how things may end up being deployed later (“whether this is an acceptable deployment model”).  The actual deployment discussions (as in, this is what we’re going to do and when) should happen in sidrops.
>> 
>> Thanks!
>> 
>> Alvaro.
>> 
>> 
>> On 9/13/17, 10:20 AM, "sidr on behalf of Tim Bruijnzeels" <sidr-bounces@ietf.org on behalf of tim@ripe.net> wrote:
>> 
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> This is probably just a matter of me being dense, but I'd like to understand
>>> what I am missing:
>>> Is it legal to mix certificate policies in a given cert path? The last
>>> paragraph of section 5 implies that you can, but doesn't say so explicitly. If
>>> you _can_ mix policies, what happens if you do? If I read the rules in 4.2.4.4.
>>> correctly (and it's likely that I am not), if you run into a cert in the chain
>>> that does not follow this profile, it's likely to give a null VRS-IP or VRS-AS
>>> value, which would seem to invalidate an certificate further down the chain
>>> that _does_ follow this policy?
>>> So, I guess it comes down to the following: If mixed policies are allowed, how
>>> does that work? If mixed policies are not allowed, there needs to be text that
>>> says that. It's quite possible such text exists (here or elsewhere), and I
>>> missed it.
>> 
>> First of all it was my understanding that there was an agreement with the AD that actual deployment should be discussed in sidrops. So this document serves as a benchmark to describe the alternative algorithm. In my opinion a mix is supported by this document, but the choice whether this is an acceptable deployment model can be discussed later.
>> 
>> 
>> 
>