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

[Job Snijders <[e-mail]>]

To reply myself: 

In case the CRL expired, or is otherwise somehow invalid; and the cache
validator continues to consider the entire validation tree to be valid
for some purpose, the validator is vulnerable to replay attacks because
the use of unencrypted transport such as rsync (which supported in all
validators, by mandate) give no support to trust anything anymore.  I
think ignoring the CRLs state goes against the entire RPKI trust-model
mindset.

A cache validator MUST consider the certificate have been appeared on
the Certificate Revocation List (CRL) issued by the CA represented by
certificate if the CRL is expired.

While one can argue in different contexts of the application of X509
technology different (more forgiving) policies can apply; in the use
case of RPKI I think we cannot tolerate anything less than to assume the
CA has failed when the CRL is inaccessible or expired. And those running
CA's will want to take careful note of this critical operational aspect.

Cache validator implementations which didn't stop parsing RIPE NCC's
tree today, should be aware they are have a security issue and consider
how to upgrade their validation strategy. I think OpenBSD's rpki-client
was the only one to get it right today.

Of course - in making strong statements like this one I can not afford
to assume I am right, so if you disagree - please tell me how I am wrong
(in detail :-) ).

Kind regards,

Job


On Mon, Feb 24, 2020 at 03:15:32PM +0000, Job Snijders wrote:
> Hi group,
> 
> It seems we need guidance and consensus on what to do when the CRL is
> hosed in some way or shape. We have two implementation discrepancies pop
> up recently:
> 
> https://github.com/NLnetLabs/routinator/issues/274
> RIPE NCC's top level CRL expired this weekend
> (https://www.ripe.net/support/service-announcements/rpki-infrastructure-issues) 
> 
> https://lists.nlnetlabs.nl/pipermail/rpki/2019-December/000109.html
> 
> OpenBSD's rpki-client uses the x509 certificate validation functions
> that come from libressl, which doesn't have a button to turn off only CRL
> timestamp verification. I was told that some nasty code would be
> required to work around that, so one can argue that rolling things by
> hand in X509 handling rarely is a great idea.
> 
> One could also argue that a softer landing is needed, unavailability of
> the CRL should mean that only the CRL itself is not available and
> proceed to validate the tree without the revocation list. I can see how
> that is helpful in some circumstances.
> 
> So, what to do? Whatever it is, ideally all validators follow a similar
> process.
> 
> Kind regards,
> 
> Job