For a moment I was having trouble understanding why, if DNSSEC is required for ACME-CAA, you couldn’t just use it for DV as well. Since others may have had the same thinko, I’ll share my current understanding: There are actually at least two MITM opportunities for DV:
Changing the A record response that a CA sees to an attacker-controlled one
Intercepting the traffic between the CA and the legitimate IP address
DNSSEC helps with the first, but not the second. ACME-CAA doesn’t prevent the second, but it does marginally protect against the second (based on the number of CAs that respect it).
This isn’t related to the article, but I wanted to say a public
thank-you for acmetool and all of
your other work in this area. I’ve been using acmetool for years and
love it.
Thank you. I really want to find the time to renovate acmetool which I feel is sorely needed. I just want to say it’s not forgotten and it continues to be the tool used to manage all my own certificates (and for this reason is is basically guaranteed to stay working).
If I have in DNS that only a certain letsencrypt account can make certs for my domain… Why do we still need dns-01 at all? Any requests for that name by that account should be a slam dunk yes.
In principle this is true, you could have something like ACME-CAA which acts as a sufficient condition rather than just a necessary condition for issuance. In practice this wasn’t pursued because from the perspective of complying with the industry rules for certificate issuance, getting signoff on the former is obviously harder than the latter. I’m not sure if my recollection is accurate, but I recall there being some discussion during the drafting of the ACME RFC about CA/Browser Forum rules requiring challenge strings to be random, precluding use of a deterministic identifier like an account ID. Changing those rules to allow this sort of thing would probably be a good idea, but would probably also have delayed deployment of this even further.
For a moment I was having trouble understanding why, if DNSSEC is required for ACME-CAA, you couldn’t just use it for DV as well. Since others may have had the same thinko, I’ll share my current understanding: There are actually at least two MITM opportunities for DV:
Arecord response that a CA sees to an attacker-controlled oneDNSSEC helps with the first, but not the second. ACME-CAA doesn’t prevent the second, but it does marginally protect against the second (based on the number of CAs that respect it).
This isn’t related to the article, but I wanted to say a public thank-you for acmetool and all of your other work in this area. I’ve been using acmetool for years and love it.
Thank you. I really want to find the time to renovate acmetool which I feel is sorely needed. I just want to say it’s not forgotten and it continues to be the tool used to manage all my own certificates (and for this reason is is basically guaranteed to stay working).
If I have in DNS that only a certain letsencrypt account can make certs for my domain… Why do we still need dns-01 at all? Any requests for that name by that account should be a slam dunk yes.
In principle this is true, you could have something like ACME-CAA which acts as a sufficient condition rather than just a necessary condition for issuance. In practice this wasn’t pursued because from the perspective of complying with the industry rules for certificate issuance, getting signoff on the former is obviously harder than the latter. I’m not sure if my recollection is accurate, but I recall there being some discussion during the drafting of the ACME RFC about CA/Browser Forum rules requiring challenge strings to be random, precluding use of a deterministic identifier like an account ID. Changing those rules to allow this sort of thing would probably be a good idea, but would probably also have delayed deployment of this even further.