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

[Tim Bruijnzeels <[e-mail]>]

Hi,

> On 25 Feb 2020, at 17:55, Stephen Kent <stkent=[e-mail]> wrote:
> 
>> Further, the CRL is included in the manifest. So you can’t even replay
>> an old CRL without also replaying the old manifest.
> The discussion (in 6486) of what an RP should do when a current Manifest is not available, or when there are some discrepancies between what  the Manifest says and what has been retrieved allows for a lot of local policy discretion. As a result, an RP might well accept an old CRL and corresponding Manifest even though the Manifest appears to be stale.

To me this is the core of the issue.

I have searched through RFC 5280, and RFC 6487, but I cannot find clear guidance on what to do when there is no valid CRL available at all, or if the only available CRL is stale. RFC 5280 seems to say that one should use the best and latest valid non-stale CRL information to make a list and consider certificates revoked only if they appear on that list. But the language is hard to parse to me. 

We have had discussion about this in past meetings, and my interpretation of the outcome was that stale CRLs should be handled in the spirit of stale Manifest. But there is no written guidance, so it remains pretty vague and as a result I can see any of the following becoming local policy:
- disregard invalid CRL and consider nothing as revoked
- disregard stale CRL and consider nothing as revoked
- disregard invalid CRL and consider everything revoked (because it is now unverifiable whether they are)
- disregard stale CRL and consider everything revoked (because it is now unverifiable whether they are)
- use stale CRL as normal

I have always had issues with the amount of local policy in the manifest RFC (6486). Inevitably this leads to differences between RP implementations and possibly even between installations if software provides configuration options to users.

Again, and again, I find that operators expect that the validation outcome is the same everywhere. This is not the case. I am not talking about local exceptions, routing policy, or temporary differences. They expect the same rules to apply.

And I agree. We would be in a better place if we did have one clearly defined way to deal with all this.

One possible interpretation of the Manifest RFC, one that is used by most RPs, is the following:
- Reject the manifest if it is invalid: its EE cert expired, wrong signature etc.
- Warn if the manifest is valid, but it is stale (here implementations differ, some reject)
- Only consider objects listed on a valid manifest
- Reject any object for which the hash does not match the manifest

I understand that as written today there is no consensus on this. But if we could, finally, agree on a way here then I believe that that would simplify everything greatly - without impacting security.

RFC 6481 (Repository Structure) says that all currently valid objects must be published, and that invalid objects must not be published. So using the manifests as a signed statement of what is current and what must be regarded seems like a very plausible approach to me. The manifest EE is signed by the same key as the CRL - so unless you want enforce security through pedantry - there is no point in checking the CRL for objects that a valid manifest says are current.

There would be a use case for CRLs for anything published outside of the RPKI infrastructure - so I still see a theoretical use case there. I think that it should be applicable to yet to be defined object types, defined by OIDs and all, that are not intended for publication inside the normal RPKI structure. The CRLs would be much smaller, and would not need to be updated whenever a new manifest is published.

With regards to stale vs expired manifests: we discussed this many meetings ago. I like the idea of having things go stale, resulting in warnings that can alert people to fix things, before expiration. This could mean: next update in X hours - after which RPs would see a warning that replay attacks could be a problem, expiration in X days giving CA/repo operators time to fix things, X days being a hard limit on the replay window. But, more importantly, I think we should aim to agree on a common way to deal with this for all RPs.


Tim