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.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
