Re: [sidr] comments on validation reconsidered -03

[Tim Bruijnzeels <[e-mail]>]

Dear Steve, WG

Thank you for the review. I haven't had much time unfortunately, but I finally managed to upload a new version -04 that I believe addresses most of the comments you made.

Generally speaking this new version:
- Updates existing standards
- We restructured somewhat to avoid back and forward referencing within this document. We now have:
    Section 2: Certificate Validation in the RPKI (current status)
    Section 3: Operational Considerations (why we believe there is an issue to address)
    Section 4: An Amended RPKI Certification Validation Process (the proposal)
- Uses documentation prefixes for IPv6, IPv4 and ASNs
- Introduces concept of "Verified Resource Set" and "overclaims" more explicitly 
- Uses overclaims in IPv4 space only in example to make it clear that this is unrelated to address family.

Some specific replies inline below, but I would kindly ask to comment on -04 going forward.

Finally, since this document attempts to update existing standards, can we change it from "Informational" to "Proposed Standard"?

Thanks
Tim


> On 08 Apr 2016, at 17:15, Stephen Kent <[e-mail]> wrote:
> 
> First, let me say this this version of the document is much improved relative to previous versions. I do have a few observations about this version, and some suggested changes. 
>  
> Abstract:
>  
> There are 2 typos, and I think you want to assert that the revisions don’t undermine security, right?
>  
>    This document proposes an alternative to the certificate validation
>    procedure specified in RFC 6487 that reduces aspects of operational
>    fragility in the management of certificates in the RPKI, while retaining
>    essential security features.
>  
> 
> Also, presumably, this is not really "an alternative" but a proposal to
> UPDATE 6487 so that all RPs use the new pat validation  algorithm, right?

indeed, updated accordingly

> 
> Section 2:
>  
> The final sentence here says: 
>  
> The roa "ROA1" is also considered valid here in this regard 
> - the prefix is encompassed by the embedded EE certificate.
>  
> The example ROA is valid, but the final check on ROA validation is specified in RFC 6482, not in 6488. Thus the text might say:
>  
> The ROA “ROA1” is valid because the specified prefix is encompassed by the embedded EE certificate, as required by RFC 6487.
>  
> Similar wording should  be used when discussing the validity of ROAs in other examples throughout the document.

Ok, I modified the examples and should reference the correct RFCs.


> Section 3:
>  
> The motivation cited here “resource allocations can change in the RPKI” is so terse as to be not very persuasive. Previous versions of the draft mentioned resource transfers, for example. We have no standard for how to perform a transfer, however one could state that the proposed change  would reduce the constraints imposed on the order in which the CAs involved in a transfer re-issue certificates. Also, if you believe that the proposed change will help minimize the impact of some types of operational errors, then that too could be said. For example:
>  
> The allocations recorded in the RPKI change as a result of resource transfers and some types of operational errors. For example, the CAs involved in transfer might choose to modify CA certificates in an order that causes some of these certificates to “over-claim” temporarily. Some types of operational errors that may occur during management of RPKI databases also may create CA certificates that, temporarily, no longer encompass all of the resources in subordinate certificates.

Okay, I hope the new text is easier to parse.

That being said, the point of this section is not to enumerate all the possible ways that an "overclaim" can occur. The point is that an "overclaim" can have an impact on other resources. And it's this collateral damage that we wish to address.

> The proposed changes (Section 4) to the validation procedure in [RFC6487] are intended to avoid causing CA certificates to be treated as invalid during transfers and as the result of some types of operational errors. However, these changes are designed to not degrade the security offered by the RPKI. Specifically, no ROAs or router certificates will be treated as valid if they contain resources that are not encompassed by all superior certificates along a path to a trust anchor.
>  
> If you believe this text matches your intent, I think it provides a better rationale for making the proposed changes.

I updated section 4 and included some of your text.


> 
>  
> The text at the top of page 4 says:
>  
>    It should be noted that CA2 is not claiming any resources on ROA1
>    that it cannot receive on a new Certificate 3.  
>  
> I expected you to say that the EE certificate in ROA1 does not make use of any of the address resources that were removed from CA1’s certificate, and thus it would be desirable if ROA1 could still be viewed as valid. This motivates the goal of the proposed  changes, i.e., to avoid having a ROA become “collateral damage” due to over-claiming by a superior CA certificate. Saying that a new Cert3 can be issued to fix this problem is true, but fails to focus on the goal of minimizing the impact of an operational error of this sort. 
>  
> The paragraph that discusses how one might modify the text in 6492 to avoid over-claiming by subordinate CAs, when resources are removed from a CA certificate is problematic. Nothing prevents a CA from unilaterally re-issuing a certificate to subordinate CAs with reduced resource sets, when the CA itself requests (or is given) a certificate with a reduced resource set. The next paragraph seems to say that, indirectly, but it’s confusing (at least to me). The final paragraph of this section introduces the notion that the reason for the reduction in scope of CA1’s certificate is a dispute between the TA and that CA. This is pretty late in the section to suggest that this is why the CA certificate was reissued with reduced resources. And it doesn’t align with the rationale you provided or that I suggested above. 
> I suggest these paragraphs need to be revised.

I removed forward and backward references between the sections of the document that led to some imprecise text about current status, motivation for change, and impact of change.


>  
> Section 4:
>  
> I don’t feel the revised text here is precise enough to provide clear guidance to implementers. RFC 6487 does not mention the term intersection in discussing path validation, so introducing that term in one sentence seems too terse. The text I provided a few months ago provided a more thorough discussion of the revised algorithm. For example, it noted the need to maintain two sets of resource data as part of the algorithm (one for addresses and one for ASNs), something not specified here. Also, the paragraph describing how to interpret the inherit flag is true, but I think it belongs as the beginning of the description of the revised procedure, with the introduction of the two working resource sets. In the current description its location of the two paragraphs below is very confusing.
>  
>      For any of the resource extensions that use the "inherit"
>        element as described in sections 2.2.3.5 and 3.2.3.3 of
>        [RFC3779], the corresponding resources of this type should be
>        taken from the parent certificate, where this issuer is the
>        subject.
>  
>      For any other resources the intersection of the quoted
>        resources on this certificate and the parent certificate is
>        kept.  If any resources were found on this certificate that
>        were not present on the parent certificate a warning SHOULD be
>        issued to help operators rectify this situation.
>  
> The second paragraph exempts the resources specified by an inherit flag from the intersection operation. Do you really want that to happen? Also, the term “quoted” isn’t well-defined in this context. Do you mean the resources specified in the certificate?
>  
> The last sentence/paragraph in the revised path validation description says:
>  
>       If the the [sic] set of verified resources obtained this way is empty,
>       then the certificate MUST be considered invalid.
>  
> It’s unclear fro  this statement whether a certificate is invalid if either the address or ASN extensions yield an empty intersection, or only if both intersections are empty, or what. This is another example of why I think the proposed path validation algorithm needs to include additional details.
>  
> Overall, I think you need to expand the description of the validation  algorithm  revisions. The revised text should establish the fact that there are two working sets and say that these sets are to be used in lieu of the
> 3779 extensions in a certificate (after performing the intersection operation). If you don’t want to also revise RFC 6482, then  you
> need to state that the working set is to be used in lieu of the 3779
> extensions when performing further validation operations, and cite 6482 as an example. 

We revised section 4 quite a bit. We introduced an explicit "Verified Resource Set" and provide text on how to use this in existing standards.


> Section 5:
>  
> It’s nice to begin with a note stating that the concerns that motivate the proposed revision to 6487 have not yet surfaced. However, referring to over-claiming as an “inconsistency” seems needless indirect. You refer to over-claiming as the problem throughout the document, so why not here? 
>  
> The next paragraph again refers to the over-claimed resources as being “under dispute.” I think this is too narrow a characterization of the circumstance that might result in a over-claiming certificate being issued. Please revise this sentence to better characterize the range of situations that might result in over-claiming, or provide a back pointer to a section of the document where that topic is discussed.
>  
> I find the opening sentence of the last paragraph here to be a bit confusing:
>  
>    It should be noted that although this is a problem with a low
>    probability today this is largely due to the fact that most current
>    RPKI systems use their own Trust Anchor and do not support any large
>    number of delegated CAs. …
>  
> By “RPKI systems” do you the RIRs as high-tier CAs? Relying parties select Trust Anchors, so this sentence is not quite consistent with usual PKI terminology. How about this phrasing:
>  
>    Although the concerns that motivates this revision to RPKI path validation
>    has not yet been observed in practice, this may be largely due to the fact
>    that most of the certificates have been issued directly by the RIRs. Each
>    RIR operates its own Trust Anchor (or set of Trust Anchors) and there are 
>    few (non-RIR) CAs that have established subordinate CAs with distinct
>    resource holdings. When more CAs receive certificates from non-RIR parents,
>    and when more transfers of resources involve more than three CAs (source,
>    target, and common ancestor), the authors anticipate that these concerns 
>    will become more commonplace.

We shortened the security consideration section.

The point we tried to make about how our proposal does not change the probability of this problem, but aims to change this from a potentially high impact to a *lower* impact problem, has been moved to the section where we describe our proposal.

>  
>  
>  
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr