30 ms·

Sure, but then you can just use OCSP. If you care about privacy very much, support only stapled OCSP. CRL is better suited for "high-volume" exchanges, for exa

by ivanr 3y ago

Sure, but then you can just use OCSP. If you care about privacy very much, support only stapled OCSP. CRL is better suited for "high-volume" exchanges, for example for a CA to publish all their revocations [so that a system such as CRLite can be built].

woodruffw 3y ago
The comment I referenced before contains a talk by 'mcpherrim as well that explains OCSP stapling's own deficiencies. I think we all want a good solution here. But none of the currently widely deployed ones are that.
- ivanr 3y ago
  I am sorry, I can't watch someone else's talk to understand what you mean. If you're willing to engage in a conversation, could you say here what you think the problems with OCSP are? (If you're not, just ignore me.) As I see it, the main problem is that browsers don't want to do OCSP any more. Sure, we have a problem with how stapling is implemented in _some_ popular platforms (but not Caddy—hi Matt), but today maybe even those are fixed. The main problem IMO is that browsers won't support must-staple. In the interest of full transparency, I have a pet peeve about people saying revocation doesn't work. I appreciate that that's the current reality, but—again—only because browsers choose not to implement it. Things would change overnight if Chrome (obviously) changed their stance.
  - woodruffw 3y ago
    Sure! I'm happy to discuss, my reason for referencing the video is because I think 'mcpherrim explains this stuff better than I do :-). My understanding is that the primary concerns with OCSP (meaning non-stapled OCSP) are that it (1) leaks end user intent to CAs, such as sites being visited, and (2) in its original form with no transport security, it is no stronger than the adversary that it needs to protect TLS/the Web PKI against (i.e., any network adversary can block the OCSP request and everything will fail open). OCSP stapling avoids both of those concerns, but requires web server and other stack changes that are not on the "enforcement" path in the way that CAs and other "direct" parts of the PKI are. The talk infers that this is why OCSP adoption has been so sluggish (which I didn't realize was the case before). FWIW, I'm sorry if I came across as dogmatic here -- revocation is conceptually important, and I think it'd be great if we ended up in a Web PKI where revocation was more effective. But I can also see why browsers have fumbled and/or dragged their feet on the CRLs and OCSP for so long.
    - ivanr 3y ago
      Yes, agreed on the primary problem with "classic" OCSP. OCSP stapling and must-staple (for the benefit of other readers: a flag that's set on a certificate to indicate that it's only valid with an attached—stapled—fresh OCSP response) solves that. When must-staple initially came out, it came to light that web servers viewed OCSP stapling as a performance optimisation. When viewed from this perspective, it's not necessary to staple 100% correctly; if you don't, clients just go to the CA directly. Unfortunately, this breaks apart with must-staple and clients who refuse to talk to Cash for privacy reasons. Browsers refused to enforce must-staple because that would mean broken web sites and they didn't want to be blamed for it. As a result, web servers didn't have an incentive to fix their broken OCSP stapling implementations. There's also some politics involved. Browsers don't actually want CAs to be able to revoke certificates for reasons other than security. Think one government pressuring a CA in their country to revoke a certificate of an entity outside the country, for political reasons. (EDIT I don't really support this argument. Any organisation that cares about their availability should always have two active certificates from difference CAs. There's a variety of CA jurisdictions to choose from as well.) I don't like these long discussion chains as much as the next guy, but there's a lot of nuance and history when it comes to certificate revocation, and I sometimes take the opportunity to gently question people's beliefs. The line "revocation doesn't work" is very often repeated and technically it's not wrong, but I think it's important for people to understand how we got here.

by ivanr 3y ago

woodruffw 3y ago

The comment I referenced before contains a talk by 'mcpherrim as well that explains OCSP stapling's own deficiencies. I think we all want a good solution here. But none of the currently widely deployed ones are that.

ivanr 3y ago
I am sorry, I can't watch someone else's talk to understand what you mean. If you're willing to engage in a conversation, could you say here what you think the problems with OCSP are? (If you're not, just ignore me.) As I see it, the main problem is that browsers don't want to do OCSP any more. Sure, we have a problem with how stapling is implemented in _some_ popular platforms (but not Caddy—hi Matt), but today maybe even those are fixed. The main problem IMO is that browsers won't support must-staple. In the interest of full transparency, I have a pet peeve about people saying revocation doesn't work. I appreciate that that's the current reality, but—again—only because browsers choose not to implement it. Things would change overnight if Chrome (obviously) changed their stance.
- woodruffw 3y ago
  Sure! I'm happy to discuss, my reason for referencing the video is because I think 'mcpherrim explains this stuff better than I do :-). My understanding is that the primary concerns with OCSP (meaning non-stapled OCSP) are that it (1) leaks end user intent to CAs, such as sites being visited, and (2) in its original form with no transport security, it is no stronger than the adversary that it needs to protect TLS/the Web PKI against (i.e., any network adversary can block the OCSP request and everything will fail open). OCSP stapling avoids both of those concerns, but requires web server and other stack changes that are not on the "enforcement" path in the way that CAs and other "direct" parts of the PKI are. The talk infers that this is why OCSP adoption has been so sluggish (which I didn't realize was the case before). FWIW, I'm sorry if I came across as dogmatic here -- revocation is conceptually important, and I think it'd be great if we ended up in a Web PKI where revocation was more effective. But I can also see why browsers have fumbled and/or dragged their feet on the CRLs and OCSP for so long.
  - ivanr 3y ago
    Yes, agreed on the primary problem with "classic" OCSP. OCSP stapling and must-staple (for the benefit of other readers: a flag that's set on a certificate to indicate that it's only valid with an attached—stapled—fresh OCSP response) solves that. When must-staple initially came out, it came to light that web servers viewed OCSP stapling as a performance optimisation. When viewed from this perspective, it's not necessary to staple 100% correctly; if you don't, clients just go to the CA directly. Unfortunately, this breaks apart with must-staple and clients who refuse to talk to Cash for privacy reasons. Browsers refused to enforce must-staple because that would mean broken web sites and they didn't want to be blamed for it. As a result, web servers didn't have an incentive to fix their broken OCSP stapling implementations. There's also some politics involved. Browsers don't actually want CAs to be able to revoke certificates for reasons other than security. Think one government pressuring a CA in their country to revoke a certificate of an entity outside the country, for political reasons. (EDIT I don't really support this argument. Any organisation that cares about their availability should always have two active certificates from difference CAs. There's a variety of CA jurisdictions to choose from as well.) I don't like these long discussion chains as much as the next guy, but there's a lot of nuance and history when it comes to certificate revocation, and I sometimes take the opportunity to gently question people's beliefs. The line "revocation doesn't work" is very often repeated and technically it's not wrong, but I think it's important for people to understand how we got here.