7 ms·

The ship has very much sailed now with ballot SC63, and this is the result, but I still don't think CRLs are remotely a perfect solution (nor do I think OCSP wa

by lol768 1y ago

The ship has very much sailed now with ballot SC63, and this is the result, but I still don't think CRLs are remotely a perfect solution (nor do I think OCSP was unfixable). You run into so many problems with the size of them, the updates not propagating immediately etc. It's just an ugly solution to the problem, that you then have to introduce further hacks (Bloom filters) atop of it all to make the whole mess work. I'm glad that Mozilla have done lots of work in this area with CRLite, but it does all feel like a bodge. The advantages of OCSP were that you got a real-time understanding of the status of a certificate and you had no need to download large CRLs which become stale very quickly. If you set security.ocsp.require in the browser appropriately then you didn't have any risk of the browser failing open, either. I did that in the browser I was daily-driving for years and can count on one hand the number of times I ran into OCSP responder outages. The privacy concerns could have been solved through adoption of Must-Staple, and you could then operate the OCSP responders purely for web-servers and folks doing research. And let's not pretend users aren't already sending all the hostnames they are visiting to their selected DNS server. Why is that somehow okay, but OCSP not?

ekr____ 1y ago
The problem with requiring OCSP stapling is that it's not practically enforceable without breakage. The underlying dynamics of any change to the Web ecosystem is that it has to be incrementally deployable, in the sense that when element A changes it doesn't experience breakage with the existing ecosystem. At present, approximately no Web servers do OCSP stapling, so any browser which requires it will just not work. In the past, when browsers want to make changes like this, they have had to give years of warning and then they can only actually make the change once nearly the entire ecosystem has switched and so you have minimal breakage. This is a huge effort an only worth doing when you have a real problem. As a reference point, it took something like 7 years to disable SHA-1 in browsers [0], and that was an easier problem because (1) CAs were already transitioning (2) it didn't require any change to the servers, unlike OCSP stapling which requires them to regularly fetch OCSP responses [1] and (3) there was a clear security reason to make the change. By contrast, with Firefox's introduction of CRLite, all the major browsers now have some central revocation system, which works today as opposed to years from now and doesn't require any change to the servers. [0] https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html https://security.googleblog.com/2014/09/gradually-sunsetting... [1] As an aside it's not clear that OCSP stapling is better than short-lived certs.
- lol768 1y ago
  I think you are correct. There were similar issues with Firefox rolling out SameSite=Lax by default, and I think those plans are now indefinitely on hold as a result of the breakage it caused. It's a hard problem to solve. > As an aside it's not clear that OCSP stapling is better than short-lived certs. I agree this should be the end goal, really.
  - catlifeonmars 1y ago
    Oh wow. I thought SameSite=Lax by default was a done deal. It shows how much I’ve been following in the past few years.
- dlenski 1y ago
  > The underlying dynamics of any change to the Web ecosystem is that it has to be incrementally deployable, in the sense that when element A changes it doesn't experience breakage with the existing ecosystem. Absolutely, this is important. But I don't understand why this should have any effect on OCSP-stapling vs. CRL. As you note, "approximately no Web servers do OCSP stapling, so any browser which requires it will just not work." But browsers also cannot rely on CRLs being 100% available and up-to-date. Enforcing OCSP stapling and enforcing a check against an up-to-date CRL would both require this kind of incremental or iterative deployment. > As an aside it's not clear that OCSP stapling is better than short-lived certs. This is equally applicable to CRL, though. The current plan for phased reduction of TLS cert lifespan is to stabilize at 47 days in 2029. If reducing cert lifetime achieves the goal of reducing the value of compromised certs, then any mechanism for revoking/invalidating certificates will be reduced in value.
woodruffw 1y ago
> Why is that somehow okay, but OCSP not? I think the argument isn’t that it’s okay, but that one bad thing doesn’t mean we should do two bad things. Just because my DNS provider can see my domain requests doesn’t mean I also want arbitrary CAs on the Internet to also see them.
- dogma1138 1y ago
  I never understood why they didn’t tried to push OSCP into DNS. You have to trust the DNS server more than you trust the server you are reaching out to as the DNS server can direct you anywhere as well as see everything you are trying to access anyhow.
  - woodruffw 1y ago
    How would that work in the current reality of the DNS? The current reality is that it’s unauthenticated and indeterminately forwarded/cached, neither of which screams success for timely, authentic OCSP responses.
    - dogma1138 1y ago
      Similarly to how OCSP stapling was supposed to work.
      - woodruffw 1y ago
        “Supposed to” being operative, I think!
  - cyphar 1y ago
    Because one of the main things TLS is intended to defend against is malicious / MITM'd DNS servers? If DNS was trustworthy then the entirety of TLS PKI would be entirely redundant...
    - jve 1y ago
      > then the entirety of TLS PKI would be entirely redundant... Don't think I agree with this. TLS is important against MITM scenarios - integrity, privacy. You don't need DNS for this to be abused but a man in the middle - whether that is some open wifi, ISP or tapped into your network any other way.
PunchyHamster 1y ago
It's funny that putting some random records in DNS is enough to have enough "ownership" to make a cert for one but we can't use same method for publishing revoking
- ocdtrekkie 1y ago
  The entire existence of CAs is a pointless and mystical venture to ensure centralized control of the Internet that, since now entirely domain-validated, provides absolutely no security benefits over DNS. If your domain register/name server provider is compromised, CAs are already a lost cause.
  - tptacek 1y ago
    The DNS is more centralized than the WebPKI.
    - ocdtrekkie 1y ago
      Three browser companies on the west coast of the US effectively control all decisionmaking for WebPKI. The entire membership of the CA/B is what, a few dozen? Mostly companies which have no reason to exist except serving math equations for rent. How many companies now run TLDs? Yeah, .com is centralized, but between ccTLDs, new TLDs, etc., tons. And domain registrars and web hosts which provide DNS services? Thousands. And importantly, hosting companies and DNS providers are trivially easy to change between. The idea Apple or Google can unilaterally decide what the baseline requirements should be needs to be understood as an existential threat to the Internet. And again, every single requirement CAs implement is irrelevant if someone can log into your web host. The entire thing is an emperor has no clothes thing.
      - tptacek 1y ago
        Incoherent. Browser vendors exert control by dint of controlling the browsers themselves, and are in the picture regardless of the trust system used for TLS. The question is, which is more centralized: the current WebPKI, which you say is also completely dependent on the DNS but involves more companies, or the DNS itself, which is axiomatically fewer companies? I always love when people bring the ccTLDs into these discussions, as if Google could leave .COM when .COM's utterly unaccountable ownership manipulates the DNS to intercept Google Mail.
gerdesj 1y ago
"And let's not pretend users aren't already sending all the hostnames they are visiting to their selected DNS server. Why is that somehow okay, but OCSP not?" Running your own DNS server is rather easier than messing with OCSP. You do at least have a choice, even if it is bloody complicated. SSL certs (and I refuse to call them TLS) will soon have a required lifetime of forty something days. OCSP and the rest becomes moot.
- dogma1138 1y ago
  You still are reaching out to authoritative servers for that domain so someone else other than the destination knows what you are looking for. The 47 day life expectancy isn’t going to come until 2029 and it might get pushed. Also 47 days is still too long if certificates are compromised.
  - cyberax 1y ago
    You can request 6-day certificates from Let's Encrypt. There's a clear path towards 24-hour certificates. This will be pretty much equivalent to the current status quo with the OCSP stapling.
    - akerl_ 1y ago
      Is that live yet? (Not asking to be critical; I was keeping an eye out because I wanted to migrate but last I saw, 6 day certs were still in testing-only).
      - cyberax 1y ago
        It's in a beta now, they are planning to release it very very soon.
  - the8472 1y ago
    The authoritative servers for a domain are likely to be operated by the same entity as the domain itself.
dadrian 1y ago
OCSP stapling, when done correctly with fallback issuance, is just a worse solution than short-lived certificates. OCSP lifetimes are 10 days. I wrote about this some here [1]. [1]: https://dadrian.io/blog/posts/revocation-aint-no-thang/ https://dadrian.io/blog/posts/revocation-aint-no-thang/
dlenski 1y ago
> I still don't think CRLs are remotely a perfect solution (nor do I think OCSP was unfixable) > The privacy concerns could have been solved through adoption of Must-Staple Agreed. I haven't followed every bit of the play-by-play here, but OCSP (multi-)stapling appeared to me to be a good solution to both the end-user privacy concerns and to the performance concerns.

by lol768 1y ago

ekr____ 1y ago

The problem with requiring OCSP stapling is that it's not practically enforceable without breakage. The underlying dynamics of any change to the Web ecosystem is that it has to be incrementally deployable, in the sense that when element A changes it doesn't experience breakage with the existing ecosystem. At present, approximately no Web servers do OCSP stapling, so any browser which requires it will just not work. In the past, when browsers want to make changes like this, they have had to give years of warning and then they can only actually make the change once nearly the entire ecosystem has switched and so you have minimal breakage. This is a huge effort an only worth doing when you have a real problem. As a reference point, it took something like 7 years to disable SHA-1 in browsers [0], and that was an easier problem because (1) CAs were already transitioning (2) it didn't require any change to the servers, unlike OCSP stapling which requires them to regularly fetch OCSP responses [1] and (3) there was a clear security reason to make the change. By contrast, with Firefox's introduction of CRLite, all the major browsers now have some central revocation system, which works today as opposed to years from now and doesn't require any change to the servers. [0] https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html https://security.googleblog.com/2014/09/gradually-sunsetting... [1] As an aside it's not clear that OCSP stapling is better than short-lived certs.

lol768 1y ago
I think you are correct. There were similar issues with Firefox rolling out SameSite=Lax by default, and I think those plans are now indefinitely on hold as a result of the breakage it caused. It's a hard problem to solve. > As an aside it's not clear that OCSP stapling is better than short-lived certs. I agree this should be the end goal, really.
- catlifeonmars 1y ago
  Oh wow. I thought SameSite=Lax by default was a done deal. It shows how much I’ve been following in the past few years.
dlenski 1y ago
> The underlying dynamics of any change to the Web ecosystem is that it has to be incrementally deployable, in the sense that when element A changes it doesn't experience breakage with the existing ecosystem. Absolutely, this is important. But I don't understand why this should have any effect on OCSP-stapling vs. CRL. As you note, "approximately no Web servers do OCSP stapling, so any browser which requires it will just not work." But browsers also cannot rely on CRLs being 100% available and up-to-date. Enforcing OCSP stapling and enforcing a check against an up-to-date CRL would both require this kind of incremental or iterative deployment. > As an aside it's not clear that OCSP stapling is better than short-lived certs. This is equally applicable to CRL, though. The current plan for phased reduction of TLS cert lifespan is to stabilize at 47 days in 2029. If reducing cert lifetime achieves the goal of reducing the value of compromised certs, then any mechanism for revoking/invalidating certificates will be reduced in value.

woodruffw 1y ago

> Why is that somehow okay, but OCSP not? I think the argument isn’t that it’s okay, but that one bad thing doesn’t mean we should do two bad things. Just because my DNS provider can see my domain requests doesn’t mean I also want arbitrary CAs on the Internet to also see them.

dogma1138 1y ago
I never understood why they didn’t tried to push OSCP into DNS. You have to trust the DNS server more than you trust the server you are reaching out to as the DNS server can direct you anywhere as well as see everything you are trying to access anyhow.
- woodruffw 1y ago
  How would that work in the current reality of the DNS? The current reality is that it’s unauthenticated and indeterminately forwarded/cached, neither of which screams success for timely, authentic OCSP responses.
  - dogma1138 1y ago
    Similarly to how OCSP stapling was supposed to work.
    - woodruffw 1y ago
      “Supposed to” being operative, I think!
- cyphar 1y ago
  Because one of the main things TLS is intended to defend against is malicious / MITM'd DNS servers? If DNS was trustworthy then the entirety of TLS PKI would be entirely redundant...
  - jve 1y ago
    > then the entirety of TLS PKI would be entirely redundant... Don't think I agree with this. TLS is important against MITM scenarios - integrity, privacy. You don't need DNS for this to be abused but a man in the middle - whether that is some open wifi, ISP or tapped into your network any other way.

PunchyHamster 1y ago

It's funny that putting some random records in DNS is enough to have enough "ownership" to make a cert for one but we can't use same method for publishing revoking

ocdtrekkie 1y ago
The entire existence of CAs is a pointless and mystical venture to ensure centralized control of the Internet that, since now entirely domain-validated, provides absolutely no security benefits over DNS. If your domain register/name server provider is compromised, CAs are already a lost cause.
- tptacek 1y ago
  The DNS is more centralized than the WebPKI.
  - ocdtrekkie 1y ago
    Three browser companies on the west coast of the US effectively control all decisionmaking for WebPKI. The entire membership of the CA/B is what, a few dozen? Mostly companies which have no reason to exist except serving math equations for rent. How many companies now run TLDs? Yeah, .com is centralized, but between ccTLDs, new TLDs, etc., tons. And domain registrars and web hosts which provide DNS services? Thousands. And importantly, hosting companies and DNS providers are trivially easy to change between. The idea Apple or Google can unilaterally decide what the baseline requirements should be needs to be understood as an existential threat to the Internet. And again, every single requirement CAs implement is irrelevant if someone can log into your web host. The entire thing is an emperor has no clothes thing.
    - tptacek 1y ago
      Incoherent. Browser vendors exert control by dint of controlling the browsers themselves, and are in the picture regardless of the trust system used for TLS. The question is, which is more centralized: the current WebPKI, which you say is also completely dependent on the DNS but involves more companies, or the DNS itself, which is axiomatically fewer companies? I always love when people bring the ccTLDs into these discussions, as if Google could leave .COM when .COM's utterly unaccountable ownership manipulates the DNS to intercept Google Mail.

gerdesj 1y ago

"And let's not pretend users aren't already sending all the hostnames they are visiting to their selected DNS server. Why is that somehow okay, but OCSP not?" Running your own DNS server is rather easier than messing with OCSP. You do at least have a choice, even if it is bloody complicated. SSL certs (and I refuse to call them TLS) will soon have a required lifetime of forty something days. OCSP and the rest becomes moot.

dogma1138 1y ago
You still are reaching out to authoritative servers for that domain so someone else other than the destination knows what you are looking for. The 47 day life expectancy isn’t going to come until 2029 and it might get pushed. Also 47 days is still too long if certificates are compromised.
- cyberax 1y ago
  You can request 6-day certificates from Let's Encrypt. There's a clear path towards 24-hour certificates. This will be pretty much equivalent to the current status quo with the OCSP stapling.
  - akerl_ 1y ago
    Is that live yet? (Not asking to be critical; I was keeping an eye out because I wanted to migrate but last I saw, 6 day certs were still in testing-only).
    - cyberax 1y ago
      It's in a beta now, they are planning to release it very very soon.
- the8472 1y ago
  The authoritative servers for a domain are likely to be operated by the same entity as the domain itself.

dadrian 1y ago

OCSP stapling, when done correctly with fallback issuance, is just a worse solution than short-lived certificates. OCSP lifetimes are 10 days. I wrote about this some here [1]. [1]: https://dadrian.io/blog/posts/revocation-aint-no-thang/ https://dadrian.io/blog/posts/revocation-aint-no-thang/

dlenski 1y ago

> I still don't think CRLs are remotely a perfect solution (nor do I think OCSP was unfixable) > The privacy concerns could have been solved through adoption of Must-Staple Agreed. I haven't followed every bit of the play-by-play here, but OCSP (multi-)stapling appeared to me to be a good solution to both the end-user privacy concerns and to the performance concerns.