Original text:
The string "http-01" A random value that uniquely identifies the challenge.  This value <del> MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). </del>  A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and The string "tls-sni-02" A random value that uniquely identifies the challenge.  This value <del> MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). </del>  A client responds to this challenge by constructing a self-signed certificate which the client MUST provision at the domain name The string "dns-01" A random value that uniquely identifies the challenge.  This value <del> MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). </del>  A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and unrecognized_name alert, then this is an indication that the server is not in a default virtual host configuration.  12.  References 12.1.  URIs

Reviewer comments:
Per feedback from Zach Shepherd[0] on the mailing list the justification for the 128 bits of required token entropy from section 8.2 is at odds with the actual rationale (as I understand it). This commit updates the justification for the entropy requirement to not mention being secret from an attacker, but instead not predictable by a naive challenge response server that would complete challenges without having been a party to the authz/chal creation.
It seems like whatever change is made should be applied to sections 8.2, 8.3, and 8.4.
Based on zjs' feedback, I think it makes more sense for the individual token fields to just say "MUST have 128 bits", and explain why in one place in the Security Considerations section.
NAME NAME Updated. Thanks for the feedback!

Revised text:
The string "http-01" A random value that uniquely identifies the challenge.  This value  <ins> MUST have at least 128 bits of entropy.  It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). </ins> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and The string "tls-sni-02" A random value that uniquely identifies the challenge.  This value  <ins> MUST have at least 128 bits of entropy.  It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). </ins> A client responds to this challenge by constructing a self-signed certificate which the client MUST provision at the domain name The string "dns-01" A random value that uniquely identifies the challenge.  This value  <ins> MUST have at least 128 bits of entropy.  It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). </ins> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and unrecognized_name alert, then this is an indication that the server is not in a default virtual host configuration. <ins> 11.3. The http-01, tls-sni-02 and dns-01 validation methods mandate the usage of a random token value to uniquely identify the challenge. The value of the token is required to contain at least 128 bits of entropy for the following security properties.  First, the ACME client should not be able to influence the ACME server's choice of token as this may allow an attacker to reuse a domain owner's previous challenge responses for a new validation request.  Secondly, 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. </ins> 12.  References 12.1.  URIs