7 ms·

Is Ryan Sleevi in https://bugzilla.mozilla.org/show_bug.cgi?id=1715455#c1 https://bugzilla.mozilla.org/show_bug.cgi?id=1715455#c1 really suggesting that Let's E

Is Ryan Sleevi in https://bugzilla.mozilla.org/show_bug.cgi?id=1715455#c1 https://bugzilla.mozilla.org/show_bug.cgi?id=1715455#c1 really suggesting that Let's Encrypt revoke 185 million certificates forcing people to get new ones because the certificates have a lifetime that is 1 second too long? 1 measly second is going to break WebPKI?!

pdpi 5y ago
Certificates were mis-issued. Even if the answer is "no, definitely not", the question of whether to revoke them has to be asked.
tyingq 5y ago
Thankfully, there seems to be guidance that allows for common sense to intervene. "Mozilla recognizes that in some exceptional circumstances, revoking the affected certificates within the prescribed deadline may cause significant harm, such as...when the volume of revocations in a short period of time would result in a large cumulative impact to the web." He does have a good point that something quite similar happened a month ago[1], and should have trigged a deeper dive that would have exposed this as well. You could interpret that as LE needing some better discipline around process. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1708965 https://bugzilla.mozilla.org/show_bug.cgi?id=1708965
SuchAnonMuchWow 5y ago
You are supposed to be able to revoke the certificate you misissue. LetsEncrypt automated the certificate creation, which resulted in very large number of certificate issued. But at the same time, it should be possible to revoke them all. If the revocation mechanism doesn't scale as much as the creation, this is a huge problem. This time, the misissued certificates probably won't cause large issues. But they are misissued nevertheless and should be revoked. If they are not revoked because it would be too complex and will break WebPKI, then what will happen when a larger issue happen that require the revocation ?
- ceejayoz 5y ago
  > If they are not revoked because it would be too complex and will break WebPKI, then what will happen when a larger issue happen that require the revocation ? As here, the severity of the issue should be weighed against the severity of revocation. "Half the internet needs to manually renew some certs early" is a reasonable approach if there's something risking exposure of sensitive data. It's not for "the certificate is valid for an extra second".
  - schoen 5y ago
    By the way, following an earlier issue that did result in revocations, Certbot added logic where the certificate will automatically be renewed early if an OCSP check shows it is no longer valid. That means that early revocations may not cause outages for sites that are successfully using automated renewal with Certbot. Of course, those sites are a minority and possibly not even a plurality, but in theory revocation can be made a smaller burden over time as more sites are using automation successfully. I also know there are tons of Let's Encrypt users who are still using a completely manual workflow. Some of them just don't understand some part of the automation concept, while others have devices and/or operating systems where they simply can't automate certificate renewal, because they couldn't install any software that would facilitate it.
    - lilyball 5y ago
      Doesn’t that mean the cert is already invalid by the time certbot notices, so you already have an outage? And if certbot is running daily then that outage could be up to 24 hours.
      - mholt 5y ago
        Not if the last valid OCSP response is stapled to the certificate. Of course, clients can ignore that and use their own revocation lists/logic, which sometimes get pushed faster than OCSP responses. (Or clients can just block any certificates/CAs they want to, really.)
      - 5y ago
nebulous1 5y ago
That's not my take. He's just saying that the linked document states > If your CA will not be revoking the certificates within the time period required by the BRs, our expectations are that: > The decision and rationale for delaying revocation will be disclosed to Mozilla in the form of a preliminary incident report immediately; preferably before the BR-mandated revocation deadline. The rationale must include an explanation for why the situation is exceptional. Responses similar to “we do not deem this non-compliant certificate to be a security risk” are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis. However, letsencrypt's report neglected to do any of this, so he queried them on this

pdpi 5y ago

Certificates were mis-issued. Even if the answer is "no, definitely not", the question of whether to revoke them has to be asked.

tyingq 5y ago

Thankfully, there seems to be guidance that allows for common sense to intervene. "Mozilla recognizes that in some exceptional circumstances, revoking the affected certificates within the prescribed deadline may cause significant harm, such as...when the volume of revocations in a short period of time would result in a large cumulative impact to the web." He does have a good point that something quite similar happened a month ago[1], and should have trigged a deeper dive that would have exposed this as well. You could interpret that as LE needing some better discipline around process. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1708965 https://bugzilla.mozilla.org/show_bug.cgi?id=1708965

SuchAnonMuchWow 5y ago

You are supposed to be able to revoke the certificate you misissue. LetsEncrypt automated the certificate creation, which resulted in very large number of certificate issued. But at the same time, it should be possible to revoke them all. If the revocation mechanism doesn't scale as much as the creation, this is a huge problem. This time, the misissued certificates probably won't cause large issues. But they are misissued nevertheless and should be revoked. If they are not revoked because it would be too complex and will break WebPKI, then what will happen when a larger issue happen that require the revocation ?

ceejayoz 5y ago
> If they are not revoked because it would be too complex and will break WebPKI, then what will happen when a larger issue happen that require the revocation ? As here, the severity of the issue should be weighed against the severity of revocation. "Half the internet needs to manually renew some certs early" is a reasonable approach if there's something risking exposure of sensitive data. It's not for "the certificate is valid for an extra second".
- schoen 5y ago
  By the way, following an earlier issue that did result in revocations, Certbot added logic where the certificate will automatically be renewed early if an OCSP check shows it is no longer valid. That means that early revocations may not cause outages for sites that are successfully using automated renewal with Certbot. Of course, those sites are a minority and possibly not even a plurality, but in theory revocation can be made a smaller burden over time as more sites are using automation successfully. I also know there are tons of Let's Encrypt users who are still using a completely manual workflow. Some of them just don't understand some part of the automation concept, while others have devices and/or operating systems where they simply can't automate certificate renewal, because they couldn't install any software that would facilitate it.
  - lilyball 5y ago
    Doesn’t that mean the cert is already invalid by the time certbot notices, so you already have an outage? And if certbot is running daily then that outage could be up to 24 hours.
    - mholt 5y ago
      Not if the last valid OCSP response is stapled to the certificate. Of course, clients can ignore that and use their own revocation lists/logic, which sometimes get pushed faster than OCSP responses. (Or clients can just block any certificates/CAs they want to, really.)
    - 5y ago

nebulous1 5y ago

That's not my take. He's just saying that the linked document states > If your CA will not be revoking the certificates within the time period required by the BRs, our expectations are that: > The decision and rationale for delaying revocation will be disclosed to Mozilla in the form of a preliminary incident report immediately; preferably before the BR-mandated revocation deadline. The rationale must include an explanation for why the situation is exceptional. Responses similar to “we do not deem this non-compliant certificate to be a security risk” are not acceptable. When revocation is delayed at the request of specific Subscribers, the rationale must be provided on a per-Subscriber basis. However, letsencrypt's report neglected to do any of this, so he queried them on this