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

[Louis Poinsignon <[e-mail]>]

Hello all,
We're internally reviewing this with the crypto team which have more
experience maintaining PKIs.

My opinion on an operational standpoint.
I don't think I'd like having our routers suddenly reprocessing the million
routes associated with 78000 ROAs leaving us with an increased surface of
attack and potential reroutings. The outage lasted 8 hours as well.
Even with a replayed certificate, I don't believe the impact would be as
critical. And it would leave traces.
If the impact of a mistake is more punitive than a proper misuse, it's bad.

While I believe Job is right on the discrepancy between validators, I agree
with the point of Martin on the added complexity.

OctoRPKI is tolerant on absent/invalid CRLs. But it does check it against
certificates when valid.
Manifests are more sensitive.

Even though browsers and RPKI are different, I think we can learn from the
experience. Which is to get away from CRLs.
https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/

> Certificate Revocation Lists (CRLs) quickly became large, and contained
> mostly irrelevant data, so web browsers didn’t download them;
> The Online Certificate Status Protocol (OCSP) was unreliable, and so web
> browsers had to assume if it didn’t work that the website was still valid.

And lead to alternative solutions:
https://www.theregister.co.uk/2020/02/20/apple_shorter_cert_lifetime/
https://letsencrypt.org/2015/11/09/why-90-days.html

Looking into the data:
rpki.ripe.net/repository/DEFAULT/KpSo3VVK5wEHIJnHC2QHVV3d5mk.crl is the
largest with 1MB and 22027 serials.
Most contain around 100-1000 serials and are a few KB.
The entirety of the 17127 CRLs is 70MB.

RPKI CA are already renewing, regenerating and distributing certificates
often. Why not reducing the maximum validity of certificates to one day?
This would relieve computing and storage as well as reducing the
importance/criticality of CRLs.

On Tue, 25 Feb 2020 at 15:51, Stephen Kent <stkent=
[e-mail]> wrote:

> Martin,
> > Job Snijders wrote:
> >> 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 :-) ).
> > Let me counter with a different strong statement: In the context of
> > RPKI, CRLs offer no additional value and can safely be ignored.
> I disagree.
> > The reason is the manifests. Unlike CRLs which only say "these
> > certificates are not to be considered valid anymore", manifests say
> > "this is the complete set of objects currently issued by this CA". They
> > also refer to concrete objects, identifying them both by URI and a hash
> > over their content. This is a much more powerful mechanism than CRLs.
> As a co-author of the manifest document I can assure you that these
> objects are not intended as a replacement for CRLs. To provide analogous
> functionality one would have to interpret the absence of a cert from a
> Manifest as evidence that it was revoked, or expired. There is a lot of
> experience in the broader PKI community that suggests Subjects are
> sloppy about expiration dates for certs, and some evidence that CAs are
> not much better :-).
> > What’s more, they offer a soft and a hard deadline for validity. Their
> > next update field is a soft deadline, much like with CRLs. But there’s
> > also a hard deadline in that the certificate they’ve been signed with
> > expires eventually. While the former has the same ambiguity as the next
> > update field of the CRL, the latter doesn’t. If the manifest is
> > expired, the CA is basically gone.
> I don't agree with the reasoning above. It's true that the cert used to
> verify (not sign) a Manifest will expire, but so will a CA cert. Why do
> you think that a CA will be better at maintaining a current Manifest vs.
> a current CRL? F or most RPKI CAs the trigger to generate a new Manifest
> will be the need to issue a new CRL (because many CAs have elected to
> issue CRLs on a daily basis).
> > 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.
> > Essentially, no information conveyed by the CRL isn’t also conveyed by
> > the manifest. The CRL solely serves to provide additional complexity
> > for the code generating and validating RPKI objects and, apparently,
> > creates ambiguity in the interpretation of the specification.
>
> I disagree.
>
> Steve
>
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops
>