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

Tim Bruijnzeels <tim@ripe.net> Wed, 13 September 2017 14:20 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 0A89A132F31; Wed, 13 Sep 2017 07:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 YVXA2cFH2G92; Wed, 13 Sep 2017 07:20:29 -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 62AB51321A0; Wed, 13 Sep 2017 07:20:29 -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 1ds8Wc-000Age-79; Wed, 13 Sep 2017 16:20:24 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-115.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 1ds8Wc-0002wh-2u; Wed, 13 Sep 2017 16:20:22 +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: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.com>
Date: Wed, 13 Sep 2017 16:20:21 +0200
Cc: The IESG <iesg@ietf.org>, Chris Morrow <morrowc@ops-netman.net>, sidr chairs <sidr-chairs@ietf.org>, draft-ietf-sidr-rpki-validation-reconsidered@ietf.org, sidr@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <631F9DFE-B24F-4263-949F-3DACA89A53DC@ripe.net>
References: <150397418491.13284.10399723034989597495.idtracker@ietfa.amsl.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: 784d7acfe6559f2a0b602ec6519a0719e826c1347a9c9e6f41cb806eb3450c0f
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/bJ43cmE6XUHeJ3Jt3vLs2YZX8Nc>
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: Wed, 13 Sep 2017 14:20:32 -0000

Hi,

My apologies for the delay - I am just back from a late summer holiday.

Let me address the DISCUSS is in this, and Terry Manderson’s email, first.

> On 29 Aug 2017, at 04:36, Ben Campbell <ben@nostrum.com> wrote:
> 
> Ben Campbell has entered the following ballot position for
> draft-ietf-sidr-rpki-validation-reconsidered-08: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/
> 
> 
> 
> ----------------------------------------------------------------------
> 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.

The current document leaves the OID as a per certificate choice and 4.2.2.4 provides a validation model that can be used in either case. In either case the VRS-IP/AS are calculated as described in item #7. Under item #8, the VRS-IP/AS is then compared again to the certificate to determine if it was ‘over-claiming’ compared to its acceptable VRS-IP/AS set. The OID choice determines whether this results in a warning about such over claiming resources, or rejecting. The algorithm defined here when only old OIDs are used is semantically equivalent to section 7.2 of RFC6847.

Note that item #7 does not have explicit text on the case where ‘inherit’ is used, but I believe that this is technically covered by the text in sections 2.2.3.5 and 3.2.3.3 of RFC3779. Essentially: the value of the signing certificate applies, use recursion if that also uses inherit.




> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Substantive:
> 
> - General: There's a lot of amending going on here--does this draft really not
> update any RFCs (e.g. 6487)?
> 
> - 4.2.4.4:
> -- "Any extension not thus identified MUST NOT appear in
>       certificate x." (Repeats multiple times)
> That seems to prevent future extensibility. Is that the intent?
> 
> -- "Certificate x MUST NOT have been revoked, i.e., it MUST NOT
>       appear on a CRL issued by the CA represented by certificate x-1"
> Is this intended as a requirement to check CRLs? If so, please say that
> explicitly.
> 
> Editorial:
> 
> -4.2.2.1: The third paragraph seems redundant to the first paragraph (pattern
> repeats in several sections.)he
> 
> - 4.2.4.3: "Either the IP Resources extension, or the AS Resources extension, or
>   both, MUST be present in all RPKI certificates, and if present, MUST
>   be marked critical."
> "... and if present..." seems redundant, since the previous clause said one
> MUST be present.
> 
> - 4.3.4.3: "... values are NOT supported..."
> a floating, capitalized "NOT" is not defined in RFC 2119. I suspect the
> all-caps is just for emphasis, but we typically reserve that for RFC 2119
> keywords.
> 
> - 4.2.4.4 :
> -- "Certificate validation requires verifying that all of the following
>   conditions hold, in addition to the certification path validation
>   criteria specified in Section 6 of [RFC5280]."
> 
> The "... in addition to..." part doesn't seem quite true. For example, making
> sure the current date fits in the active range, ensuring a cert is signed by
> the issuer, etc.  are already covered in 5280.
> 
> - - "...certificate MUST contain all
>       extensions defined in section 4.8 of [RFC6487] that must be
>       present."
> That seems tautologically true. If this is a statement of fact, then please
> avoid the MUST. If this is really a new normative requirement, then I'm
> confused at the intent.
> 
> -- "all extensions defined in section 4.8 of
>       [RFC6487], except sections 4.8.9, 4.8.10 and 4.8.10 MUST be
>       present. "
> It would be more reader-friendly to mention what extensions are defined in
> 4.8.9.
> 
> -- "7. Compute the VRS-IP and VRS-AS set values as indicated below:"
> Inconsistent voice.
> 
> -- list entry 7, 4th bullet: "If the IP Address Delegation extension is present
> in
>          certificate x and x=1, set the VRS-IP to the resources found
>          in this extension."
> That seems identical to the first bullet. Should it has said "AS Address
> Delegation extension"?
> 
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>