[sidr] draft-huston-sidr-validity-00

[Stephen Kent <[e-mail]>]

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