3 ms·

Aren't revocations a pretty important part of certificates, considering the whole point of this is security? I don't understand the rationale for skipping.

woodruffw 3y ago
Revocations are a great idea. In practice, they're both operationally complicated and an unreliable source of truth about certificate validity. In practice, a lot of implementations (including Go's) simply ignore them. 'mcpherrim posted a comment below[1] with some additional information, including changes to the Web PKI and CRL distribution techniques that may eventually make them more useful. [1]: https://news.ycombinator.com/item?id=39132430 https://news.ycombinator.com/item?id=39132430
- 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.
  - 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.
deleted 3y ago
[deleted]

woodruffw 3y ago

Revocations are a great idea. In practice, they're both operationally complicated and an unreliable source of truth about certificate validity. In practice, a lot of implementations (including Go's) simply ignore them. 'mcpherrim posted a comment below[1] with some additional information, including changes to the Web PKI and CRL distribution techniques that may eventually make them more useful. [1]: https://news.ycombinator.com/item?id=39132430 https://news.ycombinator.com/item?id=39132430

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.
- 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.

deleted 3y ago

[deleted]