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

[Geoff Huston <[e-mail]>]

Thanks indeed for this detailed review Steve. 

I have to admit to a certain sense of confusion over the evolution of this work - earlier "validation reconsidered” drafts which described the motivation in more detail triggered a WG consideration of transfers which to some extent was, in my view, heading off topic, while a trimmed draft that removed the motivational text and just described the mechanics of a revised validation algorithm apparently have headed too far in the other direction. In reviewing your review comments, and thinking about what this particular pair of drafts  was attempting to achieve, I also feel that the work as it stands is wide of the mark in terms of detail, terminology  and the revised algorithm could be defined differently to improve its clarity, which is largely consistent with your review comments.

However, that said, I think I have reached the end of my road with the "validation reconsidered” work. If others feel that this approach offers some aspects of increased operational robustness by slightly altering the pairwise condition of “encompassing” on the INRs in the ordered list of certificates in a validation path, then they should pipe up and take over the work, but its not something that I feel sufficiently motivated to push in the SIDR WG any more.

So if the WG Chairs still want to discuss this work at the SIDR WG meeting this week, my only contribution to the discussion on this topic would be something I can already say here on the mailing list: I’m no longer in a position to further develop this work, and I am happy for others to take the current state of the drafts, and Steve’s detailed review comments, and carry on the effort from this point.

thanks,

   Geoff
 





> On 31 Oct 2015, at 7:24 AM, Stephen Kent <[e-mail]> wrote:
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr