Let’s Encrypt’s Vulnerability As a Feature – AUTHZ Reuse and Eternal Account Key

Issuance Tech
4

There’s certainly validity in pointing out the powers of the account key but there are a couple things I would clarify:

  • As @serverco mentioned you can deactivate authorizations at-will. There’s nothing preventing a client from doing this immediately after a certificate is issued.
  • Another confusion is that the authz reuse feature linked by the author doesn’t actually have a material impact on the mismatched expectation they describe. You could issue a new certificate using an existing valid authz w/o solving a challenge before this feature existed. The reuse feature only addressed cases where the client asked for a new authz/challenge for a domain even though there already was a valid authz for that domain associated with the account. It was an optimization and did not change any security properties of the protocol or domain validation
  • The post originally said authz’s were valid for 300 days and we were increasing it. That’s since been updated to say the validity is 90 days and we are decreasing it. That’s more accurate to be sure, but as of last Thursday it’s now 60 days! Our goal is to eventually reduce this towards 7 days.
  • Using cached domain authorization for issuance isn’t specific to Let’s Encrypt :slight_smile: Other CAs do this as well but with less visibility/control into the mechanics.

I think the strongest take away from this post (for me at least!) is that we could do a better job explaining these aspects of ACME and Let’s Encrypt to help avoid confusion. I’ll spend some time thinking about the best way to accomplish this with respect to authorizations and the subscriber account key.

2 Likes