Thanks for the detailed look at this. On 05/08/2017 03:21 PM, Zach Shepherd wrote: > The following feedback is based on cd7c5e9 (current HEAD of master). > > Section 8.3 states that the token value for HTTP validation "MUST have > at least 128 bits of entropy." > > Section 11.3 explains that one goal of this is that "the entropy > requirement prevents ACME clients from implementing a “naive” > validation server that automatically replies to challenges without > participating in the creation of the intial authorization request." > > However, because of the way the token is used in the validation > process, as a part of the request, this goal is not met. It is > possible to configure a webserver to respond to all requests under > .well-known/acme-challenge with the ASCII representation of the key > authorization. (See, e.g., > https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode > <https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode>.) I think this type of "stateless" validation server, as opposed to the "naive" validation server described in ACME, is fine. Though I am of course open to being convinced otherwise.
You're right that the second part of the token entropy requirement isn't quite correct. Specifically, the thing we want to avoid is that by setting up some ACME software on a server, someone accidentally allows a third party to come along and get a certificate for that server without actually controlling it, by exploiting that ACME software's willingness to automatically reply to challenges. This is why we include the account key thumbprint as part of the keyAuthorization. An attacker cannot get a certificate for a "stateless" validation server setup like the one you described because the account key thumbprint that server is echoing belongs to the actual administrator of the server, not the attacker. In practice we have seen this happen in non-malicious ways: recently I answered a question on Let's Encrypt's forum from someone who had a "stateless" validation server set up. They were actually getting validation failures, because they started trying to validate using a different client with a different account key, but the old stateless setup was taking precedence: https://community.letsencrypt.org/t/letsencrypt-vesta-client-error-the-key-authorization-file-from-the-server-did-not-match/32822/12?u=jsha.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
