[sidr] comments on validation reconsidered -03

[Stephen Kent <[e-mail]>]

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?

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 shouldbe used when discussing the validity of ROAs in 
other examples throughout the document.

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

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.

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

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 frothis 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 
validationalgorithmrevisions. 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, thenyou

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.

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.