Re: [Sidrops] what to do when the CRL is hosed?

[Tim Bruijnzeels <[e-mail]>]

Steve,

> On 26 Feb 2020, at 18:03, Stephen Kent <stkent=[e-mail]> wrote:
> 
> Tim,
> 
> Thanks for your thoughtful analysis of the options. Her are some additional thoughts.
> 
> In general, a stale CRL still represents the best info re revoked certs available to an RP, so ignoring it does not seem appropriate, to me.

In general I agree. Which is why I mentioned the example of objects one might find published outside of the context of the RPKI repository, and *not* listed on a manifest. Such objects have yet to be invented but theoretically one can think of signed structures under an existing RPKI CA cert (e.g. using their own embedded EE) - which is shared out-of-band between parties.

> In the RPKI we also have Manifests, so if a Manifest is current but the CRL it references is stale, then that strongly suggests that the CA has encountered a problem generating a new CRL, but it's still the best revocation status info available, so use it and consider contacting the CA (via the GB record) to point out this problem.
> 
> A CRL is invalid if it's signature doesn't verify, or if it has a syntax error, even in the face of a valid sig. In this case I would ignore the CRL contents, contact the CA, and keep using the freshest CRL the RP has.
> 
> Because these CRLs MUST contain sequence numbers, receipt of a valid CRL that appears to be current, but has an older (or the same) serial number relative to a previously validated CRL is suspicious. I would definitively contact the CA to see if it just forgot to increment this field properly. I probably would stick with the freshest CRL info I had for that CA until the matter is resolved.
> 
> There are more cases one can analyze, but I think the basic approach is to stick with prior, validated CRLs and contact the CA that issued the questionable CRL, until the matter can be resolved.
> 
> As for the considerable leeway accorded to RPs in the Manifest document, I concur that it allows inconsistent local behavior. If the WG can agree on more proscriptive language, that would be good. When we wrote 6486 we were unable to agree on such, as we tried to balance robustness vs. responses to possible active attacks on repositories or communications between an RP and a repository.

What I am suggesting is that we *could* update 6486 and make validation more restrictive regarding manifests:
- all objects on a manifest must be present and accounted for (I agree with Job regarding partial withhold attacks)
- all objects on a manifest need to be validated
- objects that are not on a manifest can be considered invalid

This is in-line with the specifications defined in RFC 6481 (A Profile for Resource Certificate Repository Structure), which essentially says that all current objects must be published, and that no invalid objects may be published.

Then, if the manifest is already a signed statement of everything that is current, at least regarding the currently defined object types, as defined in RFC 6481, then what is gained by checking that CA was also capable of generating a CRL - using the same authoritative key and publication method - that confirms that the objects that are current according to the manifest are indeed not revoked?

Requiring the CRLs just feels like unnecessary brittleness to me (again in the context of RFC 6486). It creates multiple loci for bugs in CA implementations, and complicated error conditions that need to be checked by RPs. This is what I meant with the perhaps poorly chosen word 'pedantic'. Maybe I should have used the word 'redundancy'. Redundancy may seem like a good idea in general, but in this case it really only allows for the possibility of two conflicting signed messages. Thus it seems that this does not increase security, but provides more ways for things to break.

Don't get me wrong.. we *are* generating the CRLs in unison with the MFTs. And for this to change one would have to make update to the manifest RFC and restrict the validation rules in a manner like I am suggesting above.

I am just asking that we consider that.

Kind regards,
Tim




> 
> Steve
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops