5 ms·

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 (< 7 days).

by mholt 4y ago

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 (< 7 days). 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 lifetime. Works great. Every server should do this. And when an OCSP response is discovered to be Revoked, Caddy automatically replaces the certificate. Works great. Every server should do this. If every browser is independently going to decide which certificates to distrust, now I am not sure of a good, authoritative way to determine "revoked" and then replace certificates automatically. I'm worried this will hurt the TLS ecosystem unless we answer those questions first. Actually, let's just shorten certificate lifetimes and be done with it already. Main blockers to short cert lifetimes: - CA's uptime determines Web's uptime. Main solution: - Multiple redundant ACME CAs. If one goes down, try another. (This is what Caddy already does.) [0]: https://twitter.com/mholt6/status/1567559325949763588 https://twitter.com/mholt6/status/1567559325949763588

xoa 4y ago
Replying to this as it's on top, and first thanks for the reply (and sibling replies as well). The challenges of getting servers to update and implement being a practical roadblock makes sense, I was more surprised just to not see it mentioned at all. I'd have been fully prepared for a few sentences along the lines of "this would be ideal if doing it from scratch but it'd be hard to get everyone to go along now, the reverse perils of decentralization". What you write is also interesting.
OrvalWintermute 4y ago
I too found this troubling. Mainly because we are not talking about validation performance, and OCSP stapling is an excellent performance fix. Not to mention all the privacy issues that OCSP stapling really fixes.
coffee-- 4y ago
Another tool in the toolbox is ARI. https://datatracker.ietf.org/doc/draft-acme-ari/ https://datatracker.ietf.org/doc/draft-acme-ari/
- mholt 4y ago
  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.
  - deleted 4y ago
    [deleted]
  - coffee-- 4y ago
    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)
    - 4y ago

by mholt 4y ago

xoa 4y ago

Replying to this as it's on top, and first thanks for the reply (and sibling replies as well). The challenges of getting servers to update and implement being a practical roadblock makes sense, I was more surprised just to not see it mentioned at all. I'd have been fully prepared for a few sentences along the lines of "this would be ideal if doing it from scratch but it'd be hard to get everyone to go along now, the reverse perils of decentralization". What you write is also interesting.

OrvalWintermute 4y ago

I too found this troubling. Mainly because we are not talking about validation performance, and OCSP stapling is an excellent performance fix. Not to mention all the privacy issues that OCSP stapling really fixes.

coffee-- 4y ago

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

mholt 4y ago
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.
- deleted 4y ago
  [deleted]
- coffee-- 4y ago
  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)
  - 4y ago