http-01 and dns-01 challenges: just use account key

[My1]

it's a bit frustrating when you cannot properly automate the challenges for whatever reason, and when having to do a large SAN cert it gets even more annoying (e.g. having 14 SANs and then having to copypaste 14 file names AND contents from SSH to the text editor and saving each file just so you can get your cert.
my Idea would be to make an authorised_keys style file (e.g. .well-known/acme-challenge/le-keys.txt) which contains the authorised lets encrypt accounts for http-01 and

adding the key hashes to TXT records like
_acme-challenge.example.com 120 IN TXT "key h53FF1QB43DZTQleR4VQQCxl7UQu1AgNAErm791z3DO3lrNMqfbLWsLw80RLHximiAFyY+i8nySyo7LJsbjpaw"
making a SHA512 in base64 takes up 86 characters, so you could make the record start with
key and a space before the hash, so it would be able to recognize old and new hashes alike.

(you could also, for lower data consumption add the key hashes to the key-file instead of the whole keys).

I would say that Sha512 should be used for generating the keys. in General SHA2 is a good hash family and longer sizes makes finding collisions harder.

The main point of this challenge is that you can just copypaste the same file to all the webroots, which also makes it easier on the LE side since it doesnt have to generate challenges since all API requests have to be signed with the account key anyway. verify those with the key file/records and finish.

this issue can be combined with #89 for DNS-01 as described there.

[hardie]

Proposed at IETF 95 to defer this into an extension specification.

[My1]

oh that is really nice to know, since it will make it a lot easier.

[joernheissler]

I've got doubts about this feature.

With challenges to obtain a certificate you need either access to the domain (e.g. DNS or webroot) or you need access to an account key that recently proved that it does have this access.

Without challenges you would need access to an account key that was permanently authorized to control a domain.

This allows for some new attacks:

• You could steal the account private key. Even if you aren't in control of the domain, you can have a cert issued to you.
• Publish a fancy web application on the internet which "accidentally" contains your public key. You as the holder of the private key could then issue certs for all domains that deployed your application.
• A lazy non-malicious web application developer might publish the private key too to make it even easier for the users to obtain certificates.

I agree that automating ACME challenges can be quite tricky. But from what I understand, automation is the primary reason why ACME exists. In my opinion, more work should be put into automation, not into weakening the protocol.

When this feature is specified, the Security Considerations should account for this.

[My1]

@joernheissler
regarding attack 1 and 3:
a key iirc already gets a life of 1 year after it has been authorised (at least on LE, I dunno whether this is acme in general or LE specific) and during that time it wouldnt need extra authorisation.

and unless the webmaster notices the key has been stolen, unless the LE client rotates the account key all the time (which would make using accounts with keys useless) the client would continue to auth the key over and over again allowing for an attacker to go with the known key.

attack 2:
okay, but we could make it so that key-based auth only works in DNS, that would migitate the issue.

[SkateScout]

Publish a fancy web application on the internet which "accidentally" contains your public key. You as the holder of the private key could then issue certs for all domains that deployed your application.
A lazy non-malicious web application developer might publish the private key too to make it even easier for the users to obtain certificates.

With the same argument you can say an non-malicious developer will publish the hard coded key for the dns server. And with an fancy web application you also can spoof the http-01 challenge. So also it is not worse than http-01 , tls-sni or the idea to delegate dns via CNAME to some dns server.

[jsha]

I'm going to close out this issue; for better or for worse, it's not compatible with the BRs, and so is not really practical to deploy.