If this sort of "stateless" server is acceptable, why do we require 128 bits of entropy for the token?
I'm not sure whether or not a "stateless" server like this is fine, but I do think requiring use of a high-entropy token which can essentially be ignored is inconsistent. It seems like it is either not serving its intended purpose (in which case we should revise the HTTP challenge to ensure the sever doesn't "give away" the token during the validation) or it's not actually necessary (in which case we should consider revising the HTTP challenge, and perhaps others*, to get rid of the requirements for the token). Regards, Zach * - If stateless http clients are acceptable, why not stateless DNS clients? I think allowing administrators to set a single TXT record containing the account key thumbprint and have it be re-used for multiple challenges would make it much more feasible to use the DNS challenge in environments where DNS management access is tightly controlled. ________________________________ From: Jacob Hoffman-Andrews <[email protected]> Sent: Thursday, May 11, 2017 2:03 PM To: Zach Shepherd; [email protected] Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Neilpang_acme.sh_wiki_Stateless-2DMode&d=DwMD-g&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=tLnXJDyIaDj0bKzE9u06X0JX1cdo4ztRNuoXNfI-bKA&s=pK0eJEAfMHRry2wiLazpWzC3OzUSlcuUJPFztuwoxVg&e=>.) 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.letsencrypt.org_t_letsencrypt-2Dvesta-2Dclient-2Derror-2Dthe-2Dkey-2Dauthorization-2Dfile-2Dfrom-2Dthe-2Dserver-2Ddid-2Dnot-2Dmatch_32822_12-3Fu-3Djsha&d=DwMD-g&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=tLnXJDyIaDj0bKzE9u06X0JX1cdo4ztRNuoXNfI-bKA&s=fi-VbyQUwwVsPadbbOfc1pTIg83uEWIQNK81g_cuJAc&e=>.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
