Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A New Life for Certificate Revocation Lists

letsencrypt.org

Post reply on HN
Print view View original

51–60 of 72 posts

Re: A New Life for Certificate Revocation Lists

#51

Post by mholt »

coffee-- wrote: post #49
mholt wrote: post #7

Earlier quoted context omitted.

Yes, I noticed this too and asked the author about it [0]. IMO, OCSP stapling is the best overall solution until certificate lifetimes are shorter ( As a server developer I'm worried that the focus on independent CRLs will make it difficult to automate certificates in the face of revocation. Currently, Caddy staples OCSP for all certificates by default, caches the staples, and refreshes them halfway through their lif…

Another tool in the toolbox is ARI. https://datatracker.ietf.org/doc/draft-acme-ari/

I am lukewarm about ARI. It's nice that clients can know the most convenient time to renew a certificate to avoid overwhelming the server.

However, it is optional, so we will repeat the same mistake we made with optional OCSP stapling.

Only nice clients will implement ARI, but they are the clients that need it the least because if they go to the trouble to support ARI they probably already have friendly netizen programming.

As for revocations, ARI doesn't make much sense to me. If we know a certificate will be revoked soon, we might as well stop trusting it right now. Why continue to trust a certificate that we know is being revoked?

Maybe I'm totally missing the point of ARI.

Re: A New Life for Certificate Revocation Lists

#52

Post by mholt »

aaomidi wrote: post #27
xoa wrote: post #4

I was kind of surprised that OCSP stapling didn't get any mention at all. I thought that was a major improvement in both resource cost and privacy? Since the time stamped response is proxied by the site operator rather then going directly to the CA, the load is almost entirely switched to the site itself, and the site itself is the only one who knows a given IP is asking for it, which is fine because obviously the si…

OCSP stapling increases how large the first response from the server is, increasing the time to first useful byte.

It's on the order of a few hundred bytes, only happens on the first connection, and is still orders of magnitude faster and more effective than the alternative (no stapling, which requires the client to make separate round-trips to a third party service which has all sorts of other problems).

OCSP stapling is temporary, anyway: just until we get certificate lifetimes short enough to make revocation irrelevant.*

* This is how it should be, but the industry seems to be going the direction of keeping cert lifetimes longer.

Re: A New Life for Certificate Revocation Lists

#55

Post by [deleted] »

mholt wrote: post #51
coffee-- wrote: post #49

Earlier quoted context omitted.

Another tool in the toolbox is ARI. https://datatracker.ietf.org/doc/draft-acme-ari/

I am lukewarm about ARI. It's nice that clients can know the most convenient time to renew a certificate to avoid overwhelming the server. However, it is optional, so we will repeat the same mistake we made with optional OCSP stapling. Only nice clients will implement ARI, but they are the clients that need it the least because if they go to the trouble to support ARI they probably already have friendly netizen progr…

[deleted]

Re: A New Life for Certificate Revocation Lists

#56

Post by coffee-- »

mholt wrote: post #51
coffee-- wrote: post #49

Earlier quoted context omitted.

Another tool in the toolbox is ARI. https://datatracker.ietf.org/doc/draft-acme-ari/

I am lukewarm about ARI. It's nice that clients can know the most convenient time to renew a certificate to avoid overwhelming the server. However, it is optional, so we will repeat the same mistake we made with optional OCSP stapling. Only nice clients will implement ARI, but they are the clients that need it the least because if they go to the trouble to support ARI they probably already have friendly netizen progr…

Here's my pitch:

The worst revocations are mass ones that the site operator didn't request. ARI gives a heads-up to renew early, maybe because all certificates issued using HTTP-01 are getting revoked in two days.

Revocations aren't always about distrusting a specific certificate. There's likely nothing wrong with the certificate, but it needs replacement for ecosystem cleanliness. Regardless, 40M certs are being revoked in a 10 minute window on Saturday (oof, because that's the covenant with the BRs, not because Saturday is somehow not awful!). Reissuing 40M certs may take a dozen hours (1000/sec), even if all clients work optimally and begin immediately after OCSP changes status. During that dozen hours, those certs are all already revoked.

It'd be nice if clients could be told in advance: replace this certificate right away, regardless of its validity period. Get it done early before the crowd forms and replacement requires queuing up.

(Obviously using multiple CAs mitigates the downsides to waiting until revocation)

Re: A New Life for Certificate Revocation Lists

#59

Post by mholt »

coffee-- wrote: post #56
mholt wrote: post #51

Earlier quoted context omitted.

I am lukewarm about ARI. It's nice that clients can know the most convenient time to renew a certificate to avoid overwhelming the server. However, it is optional, so we will repeat the same mistake we made with optional OCSP stapling. Only nice clients will implement ARI, but they are the clients that need it the least because if they go to the trouble to support ARI they probably already have friendly netizen progr…

Here's my pitch: The worst revocations are mass ones that the site operator didn't request. ARI gives a heads-up to renew early, maybe because all certificates issued using HTTP-01 are getting revoked in two days. Revocations aren't always about distrusting a specific certificate. There's likely nothing wrong with the certificate, but it needs replacement for ecosystem cleanliness. Regardless, 40M certs are being rev…

If there was "nothing wrong" with the certificate, it shouldn't be revoked. I get that there's red tape, but the policy surely exists for a reason. I'm obviously familiar with LE's prior mass revocations where, for the most part, there was no security concern -- but the thing is, the policy exists because we can't be sure. Those revocations were out of an abundance of caution because we couldn't be sure.

So yes, if we're being strict like the policy is, an early renewal signal is a red flag that a certificate can't be trusted. There might not be anything wrong with it, but we can no longer be sure.

I mean, there's also nothing wrong with a certificate 2 seconds after it expires. Probably. But we can't be sure. And because of that, we immediately distrust the certificate when it expires. (There might be something wrong with it before it expires too. But that's less likely because less time has passed, so we allow it, I guess.)

I think the vision is nice. I really do. I just think the clients that need it most won't support it.

Re: A New Life for Certificate Revocation Lists

#60

Post by hinkley »

schoen wrote: post #3
tinus_hn wrote: post #2

Is certificate revocation really so common a crl of a normal authority is gigabyte sized?

No, not at all. The bad case would be if Let's Encrypt discovers a problem (like a security flaw or implementation error in a validation method, as happened with the TLS-ALPN-01 method before) and concludes that it has to mass-revoke a very large number of affected certificates.

Or perhaps if another CloudBleed style incident ever happens.
Post reply on HN