3 ms·

Any chance you could expand on "In practice, they're both operationally complicated and an unreliable source of truth about certificate validity."?

by ivanr 3y ago

woodruffw 3y ago
I'm thinking about CRL update windows: a lot of CAs run weekly updates, meaning that CRL changes don't propagate to end users for up to a week at a time. That's well into "security theater" territory for me, given that a compromised CA or EE only needs to fool me for a matter of seconds, once.
- 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.
ak217 3y ago
[Not OP] CRL/OCSP (which are the only revocation mechanisms close to being generally used standards today) require either online verification (which is unsuitable or unsafe for many applications) or CRL distribution with CA trust root bundles, which is always in danger of being stale. You can read more in https://en.wikipedia.org/wiki/Certificate_revocation_list#Problems_with_certificate_revocation_lists https://en.wikipedia.org/wiki/Certificate_revocation_list#Pr..., https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol#Privacy_concerns https://en.wikipedia.org/wiki/Online_Certificate_Status_Prot... Revocation in PKI is a hard problem that exposes a fundamental tradeoff between time to revoke and privacy/offline capability.
- ivanr 3y ago
  Not quite. OCSP responses can be stapled to TLS handshakes to provide fresh revocation information. Online is needed if you want 100% fresh information, of course.
  - ak217 3y ago
    PKI uses are not limited to TLS, and TLS uses are not limited to those where revocation information is readily accessible (due to proxying/distribution/compartmentalization/federation constraints). There is a variety of signature standards and protocols out there that rely on PKI to manage trust, and whose users are not at all keen on calling an untrusted URL to check an intermediate cert.
    - ivanr 3y ago
      That's a fair point [PKI without TLS], but I'd argue that 99.9% of situations will be with TLS. Thus supporting revocation can provide value for those. Out of curiosity, what without-TLS use cases do you have in mind?
      - ak217 3y ago
        Most SSO runs on SAML, which uses XML Signature, which uses PKI certificate chains without TLS. Even if you think all SSO will migrate to OIDC, the EU has enacted laws around electronic signatures that basically enshrine the use of XML Signature (with all its problems) for the foreseeable future. A lot of countries beyond the EU (many LatAm countries, for example) have followed suit. There are other signature protocols that use certificate chains as well, and devices and networks that should not be making network calls when validating such signatures. And as I mentioned, TLS uses are not limited to those where revocation information is readily accessible.

Any chance you could expand on "In practice, they're both operationally complicated and an unreliable source of truth about certificate validity."?

by ivanr 3y ago

Any chance you could expand on "In practice, they're both operationally complicated and an unreliable source of truth about certificate validity."?

woodruffw 3y ago

I'm thinking about CRL update windows: a lot of CAs run weekly updates, meaning that CRL changes don't propagate to end users for up to a week at a time. That's well into "security theater" territory for me, given that a compromised CA or EE only needs to fool me for a matter of seconds, once.

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.

ak217 3y ago

[Not OP] CRL/OCSP (which are the only revocation mechanisms close to being generally used standards today) require either online verification (which is unsuitable or unsafe for many applications) or CRL distribution with CA trust root bundles, which is always in danger of being stale. You can read more in https://en.wikipedia.org/wiki/Certificate_revocation_list#Problems_with_certificate_revocation_lists https://en.wikipedia.org/wiki/Certificate_revocation_list#Pr..., https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol#Privacy_concerns https://en.wikipedia.org/wiki/Online_Certificate_Status_Prot... Revocation in PKI is a hard problem that exposes a fundamental tradeoff between time to revoke and privacy/offline capability.

ivanr 3y ago
Not quite. OCSP responses can be stapled to TLS handshakes to provide fresh revocation information. Online is needed if you want 100% fresh information, of course.
- ak217 3y ago
  PKI uses are not limited to TLS, and TLS uses are not limited to those where revocation information is readily accessible (due to proxying/distribution/compartmentalization/federation constraints). There is a variety of signature standards and protocols out there that rely on PKI to manage trust, and whose users are not at all keen on calling an untrusted URL to check an intermediate cert.
  - ivanr 3y ago
    That's a fair point [PKI without TLS], but I'd argue that 99.9% of situations will be with TLS. Thus supporting revocation can provide value for those. Out of curiosity, what without-TLS use cases do you have in mind?
    - ak217 3y ago
      Most SSO runs on SAML, which uses XML Signature, which uses PKI certificate chains without TLS. Even if you think all SSO will migrate to OIDC, the EU has enacted laws around electronic signatures that basically enshrine the use of XML Signature (with all its problems) for the foreseeable future. A lot of countries beyond the EU (many LatAm countries, for example) have followed suit. There are other signature protocols that use certificate chains as well, and devices and networks that should not be making network calls when validating such signatures. And as I mentioned, TLS uses are not limited to those where revocation information is readily accessible.