7 ms·

There's a reply from Ben Wilson (Mozilla) further down in the thread / the next day stating that Firefox as a client is not affected by the security issue (OCSP

by terom 6y ago

There's a reply from Ben Wilson (Mozilla) further down in the thread / the next day stating that Firefox as a client is not affected by the security issue (OCSP responses signed by these intermediate CAs would be rejected), and that Mozilla is not planning on enforcing the 7 day deadline for revocation of these intermediate certificates. The CAs will still need to replace these intermediate CAs, but with a more gradual timeline. https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg13537.html https://www.mail-archive.com/dev-security-policy@lists.mozil... > We are concerned that revoking these impacted intermediate certificates within 7 days could cause more damage to the ecosystem than is warranted for this particular problem. Therefore, Mozilla does not plan to hold CAs to the BR requirement to revoke these certificates within 7 days. However, an additional Incident Report for delayed revocation will still be required, as per our documented process[2]. We want to work with CAs to identify a path forward, which includes determining a reasonable timeline and approach to replacing the certificates that incorrectly have the id-kp-OCSPSigning EKU (and performing key destruction for them).

zenexer 6y ago
That’s about what I expected. It doesn’t make sense for any parties involved to enforce the 7 day deadline, including users. This is a reasonable solution.
- terom 6y ago
  It's just slightly disappointing that the CAs and browsers have agreed to operate under a policy that requires the CAs to revoke mis-issued subordinate CAs within 7 days (CA/B Forum BR 4.9.1.2), but that's not actually feasible in practice - at least not at this scale. Certificate issuance would need to be automated enough that it would be feasible to actually replace all certificates issued by the affected CAs within a 7-day period. Let's Encrypt represents the state of the art in terms of certificate automation, but last time they had an (impending) mass-revocation event, it turned out that even the ACME protocol / client implementations didn't really have any concept of an automated "this certificate is about to be revoked, please re-issue" process. As a result of that event, certbot at least got support for triggering renewal after revocation: https://github.com/certbot/certbot/issues/1028#issuecomment-593950500 https://github.com/certbot/certbot/issues/1028#issuecomment-... -> https://github.com/certbot/certbot/pull/7829 https://github.com/certbot/certbot/pull/7829
  - tialaramex 6y ago
    I think it's not so much that it isn't feasible as that it doesn't serve any useful purpose at least to Mozilla. The Firefox out-of-band revocation mechanism (OneCRL) certainly could revoke all these intermediates but Firefox isn't vulnerable to a problem here, so there's no obvious upside to doing that and it's disruptive.
tptacek 6y ago
Of course, the point is that by bylaws the CAs themselves agreed to, in their own BRs, they're required to revoke the certificates within 7 days. It's a SHALL requirement. The CAs can't have it both ways: a BR balloting process that they rely on for moral authority when disputing that the majority of deployed browsers have added new security requirements (like shorter-lived certificates), and BRs that they ignore when they screw up.
- peterwwillis 6y ago
  Can't they have it however they want as long as the vendors that matter go along with it? I feel like Ryan is sort of pointing that out, that an excuse of "oh well we needed to support vendor X" gives them carte blanche. It's not like customers are going to knock down their doors for not following BRs. At the end of the day, the biggest vendors are where their bread gets buttered. If Mozilla isn't the majority browser vendor, who cares what they insist on? And if all the CAs band together and say, sorry losers, we're gonna keep doing things our way, what are the browsers gonna do? Cut all their users off from the internet "because principles"? Apple is playing a dangerous game that I don't think will work out in different circumstances. They can't hide behind "protecting users" if their users end up unable to access the internet securely. We got into this mess because we wanted organizational independence and distributed trust, without considering what internal conflicts would mean to the end users. I'm going to call it and say that within a decade, you'll have to pick which CA you want to trust at browser install time (though you can guess which CA will be the default on which devices).
  - tptacek 6y ago
    This is a weird comment. Leave aside that anything the Mozilla root program does will, if history is a guide, likely be backed immediately by Google. Minority browser or not, if your CA isn't trusted by Mozilla, you will lose all your customers. Nobody is going to do business with the CA that offers "the majority of browser users" when the rest of the CAs offer all the browser users. The CAs have almost no cards to play here.
  - tialaramex 6y ago
smart_jackal 6y ago
Maybe I'm a bit uninformed but I feel that the whole certification system is quite convoluted and confusing. Couldn't there be a simpler solution of solving the simple trust problem that a user has over the authenticity of a website?
- joveian 6y ago
  There are technical issues involved and the system has evolved over the years, but part of the issue is that certificate companies make a vast amount of money doing very little and can spend a bunch of money resisting any change to the system that would cut them out of the loop. IMO, DANE might make sense if DNSSEC wasn't such a mess, although it is a very similar group of parasitic companies involved in DNS. In general, alternative name systems (such as the GNU Name System) could also potentially replace the certificate system and many name and certificate issues are related. Many of the hardest technical issues around certificates relate to revocation and the demonstrated inability of almost anyone to secure anything. Other options that make a lot of sense in many ways would have govenments or banks involved in identity in a direct way. This is resisted for a varity of reasons.
  - _-___________-_ 6y ago
    > if DNSSEC wasn't such a mess I hear this a lot, but in my experience (managing c. 1000 DNS zones all with DNSSEC enabled, using a strictly DNSSEC-validating resolver for >5 years, and having built DNSSEC infrastructure for DNS hosting providers), it is both reasonably well designed and generally quite well implemented. What is the mess that you perceive?
    - tatersolid 6y ago
      > What is the mess that you perceive? Not GP, but the mess is near-zero clients and few recursive resolvers are actually doing DNSSEC validation in practice, after 20 years of deployment. It’s like IPv6. Also I believe most active ZSKs are actually held and managed by the larger DNS providers on their customers’ behalf. This leads to very little assurance improvement over unsigned records, as credentials to update a web form is all that is needed to “sign” records. There are no real key management requirements for ZSKs as there are with browser CAs. The only additional assurance provided by a DNSSEC response is that there was likely no MITM between the authoritative server and validating resolver. Which is something, but that problem is more easily and completely solved by DoH which adds privacy as well as authenticity.

by terom 6y ago

zenexer 6y ago

That’s about what I expected. It doesn’t make sense for any parties involved to enforce the 7 day deadline, including users. This is a reasonable solution.

terom 6y ago
It's just slightly disappointing that the CAs and browsers have agreed to operate under a policy that requires the CAs to revoke mis-issued subordinate CAs within 7 days (CA/B Forum BR 4.9.1.2), but that's not actually feasible in practice - at least not at this scale. Certificate issuance would need to be automated enough that it would be feasible to actually replace all certificates issued by the affected CAs within a 7-day period. Let's Encrypt represents the state of the art in terms of certificate automation, but last time they had an (impending) mass-revocation event, it turned out that even the ACME protocol / client implementations didn't really have any concept of an automated "this certificate is about to be revoked, please re-issue" process. As a result of that event, certbot at least got support for triggering renewal after revocation: https://github.com/certbot/certbot/issues/1028#issuecomment-593950500 https://github.com/certbot/certbot/issues/1028#issuecomment-... -> https://github.com/certbot/certbot/pull/7829 https://github.com/certbot/certbot/pull/7829
- tialaramex 6y ago
  I think it's not so much that it isn't feasible as that it doesn't serve any useful purpose at least to Mozilla. The Firefox out-of-band revocation mechanism (OneCRL) certainly could revoke all these intermediates but Firefox isn't vulnerable to a problem here, so there's no obvious upside to doing that and it's disruptive.

tptacek 6y ago

Of course, the point is that by bylaws the CAs themselves agreed to, in their own BRs, they're required to revoke the certificates within 7 days. It's a SHALL requirement. The CAs can't have it both ways: a BR balloting process that they rely on for moral authority when disputing that the majority of deployed browsers have added new security requirements (like shorter-lived certificates), and BRs that they ignore when they screw up.

peterwwillis 6y ago
Can't they have it however they want as long as the vendors that matter go along with it? I feel like Ryan is sort of pointing that out, that an excuse of "oh well we needed to support vendor X" gives them carte blanche. It's not like customers are going to knock down their doors for not following BRs. At the end of the day, the biggest vendors are where their bread gets buttered. If Mozilla isn't the majority browser vendor, who cares what they insist on? And if all the CAs band together and say, sorry losers, we're gonna keep doing things our way, what are the browsers gonna do? Cut all their users off from the internet "because principles"? Apple is playing a dangerous game that I don't think will work out in different circumstances. They can't hide behind "protecting users" if their users end up unable to access the internet securely. We got into this mess because we wanted organizational independence and distributed trust, without considering what internal conflicts would mean to the end users. I'm going to call it and say that within a decade, you'll have to pick which CA you want to trust at browser install time (though you can guess which CA will be the default on which devices).
- tptacek 6y ago
  This is a weird comment. Leave aside that anything the Mozilla root program does will, if history is a guide, likely be backed immediately by Google. Minority browser or not, if your CA isn't trusted by Mozilla, you will lose all your customers. Nobody is going to do business with the CA that offers "the majority of browser users" when the rest of the CAs offer all the browser users. The CAs have almost no cards to play here.
- tialaramex 6y ago

smart_jackal 6y ago

Maybe I'm a bit uninformed but I feel that the whole certification system is quite convoluted and confusing. Couldn't there be a simpler solution of solving the simple trust problem that a user has over the authenticity of a website?

joveian 6y ago
There are technical issues involved and the system has evolved over the years, but part of the issue is that certificate companies make a vast amount of money doing very little and can spend a bunch of money resisting any change to the system that would cut them out of the loop. IMO, DANE might make sense if DNSSEC wasn't such a mess, although it is a very similar group of parasitic companies involved in DNS. In general, alternative name systems (such as the GNU Name System) could also potentially replace the certificate system and many name and certificate issues are related. Many of the hardest technical issues around certificates relate to revocation and the demonstrated inability of almost anyone to secure anything. Other options that make a lot of sense in many ways would have govenments or banks involved in identity in a direct way. This is resisted for a varity of reasons.
- _-___________-_ 6y ago
  > if DNSSEC wasn't such a mess I hear this a lot, but in my experience (managing c. 1000 DNS zones all with DNSSEC enabled, using a strictly DNSSEC-validating resolver for >5 years, and having built DNSSEC infrastructure for DNS hosting providers), it is both reasonably well designed and generally quite well implemented. What is the mess that you perceive?
  - tatersolid 6y ago
    > What is the mess that you perceive? Not GP, but the mess is near-zero clients and few recursive resolvers are actually doing DNSSEC validation in practice, after 20 years of deployment. It’s like IPv6. Also I believe most active ZSKs are actually held and managed by the larger DNS providers on their customers’ behalf. This leads to very little assurance improvement over unsigned records, as credentials to update a web form is all that is needed to “sign” records. There are no real key management requirements for ZSKs as there are with browser CAs. The only additional assurance provided by a DNSSEC response is that there was likely no MITM between the authoritative server and validating resolver. Which is something, but that problem is more easily and completely solved by DoH which adds privacy as well as authenticity.