Geoff,
I have a major concern about the proposed change to the RPKI certificate
validation algorithm as described in draft-huston-sidr-validity-00, and
some detailed technical comments on that draft.
The major concern is that the proposed mechanism, even if modified to
address the problems I note below, seems to focus only on a few
sub-types of modification or injection actions targeting ROAs, CA
certificates, or router certificates. That’s a total of at most 6
adverse actions out of the 36 that Di Ma and I describe in
draft-kent-sidr-adverse-actions-01. I believe the WG should be pursuing
mechanisms that address a much larger set of the actions identified in
that I-D. I welcome your feedback on that draft; let us know if we’re
missing some actions or if you disagree with the characterization of the
impact of any of the actions.
With regard to the current draft, I agree with Sam and several other
folks who noted that draft-huston-sidr-validity-00 lacks an clear
background discussion. If there were detailed (but generic) examples of
the problems being addressed, a reader would be better able to
understand the motivations for the proposed change. A reader would be
able to evaluate whether he/she believes the change addresses the
problems. I suggest using the terms introduced in
draft-kent-sidr-adverse-actions-01 when discussing the problems.
The discussion of the proposed validation algorithm can be shortened
considerably, and made clearer at the same time. Specifically, since the
only change to the validation procedure from 6487 appears to be step 6,
it would seem preferable to state that, and describe the new step 6
(rather than reproducing all of the text from Section 7.2 of 6487 with
this one change).
The text in step 6 isn't clear to me. It refers to a “resource set” but
that phrase is not defined in this document. Looking at 6487, the phrase
appears twice, in Sections 4.8.10 and 4.8.11. In those sections it is
referring to the set of resources acquired from a parent when the
inherit bit is set. If the intent is to use this phrase to refer to the
set of resources extracted from an RPKI certificate, irrespective of
whether the inherit bit is set, the I-D should say so.
The security considerations section says “… the validation path
encompass the resources that are included in the validation query.” One
might read this and infer that a set of INRs is an input to the
validation algorithm. But 6487 does not say INRs are a separate input to
validation. A certificate to be validated is an input to this algorithm,
and I assume that was what is implied in step 6, and in the text quoted
above. If my assumption is correct, this should be stated clearly in
both places.
Thinking about this in more detail, I fear that the results from the
modified algorithm will not yield what you seem to want, at least not in
all cases. If one validates only router certificates and EE certificates
for (non-PKI) signed objects, e.g., for ROAs or Manifests, then the
outcome will yield what I think you want. However, when validating a CA
certificate that “over claims” the certificate will be considered
invalid by the revised step 6, just as with the current validation
algorithm. (The over claiming could result from some types of CA errors
or attacks, or during a resource transfer.)
RP software may validate each CA certificate that it initially acquires,
before fetching subordinate signed products. This is a reasonable
strategy to avoid DoS attacks based on returning bogus certificates to
an RP. Also, when a cached CA certificate is discovered to have changed,
an RP probably will validate it before adding the certificate to the
cache. In these cases, the revised step 6 will treat this certificate as
invalid, if it contains resources not present in all parent
certificates. Thus all certificates and signed products below it will
become invalid. So, I don’t believe the change to step 6, as described
in your I-D, and as interpreted above, will accommodate the motivations
described in the I-D that you plan to replace with this one.
If I have misunderstood the proposed change to step 6, or the set of
problems that it is intended to address, please let me know.
Steve
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
