I think that this may require revising the challenge. Would a "two-token" challenge pattern help mitigate the risk of stateless clients for the HTTP challenge and for future challenges that may otherwise have similar issues? For example, assume that the challenge has two tokens, which I will call "tokenA" and "tokenB", TokenA would be used to make request parameters, and tokenB would be used only for responses. The key authorization would include both tokens to ensure that the tokens were received correctly. For example, the key authorization could be tokenA || tokenB || account key thumbprint. The ACME server could perform HTTP validation by sending a request to "http://example.com/.well-known/acme-challenge/tokenA"; and get back the revised key authorization (or anything else with tokenB in it). Since tokenB was not sent with the request, the server would have to have known tokenB somehow. One possible drawback of this approach is the increased storage required for the extra token.
An alternate approach may be to require that a request parameter sent during validation for any type of challenge (now existing or later developed) must include a hash of something containing the challenge token rather than something containing the token itself. For example, the HTTP challenge could be revised by having the validation go to " http://example.com/.well-known/acme-challenge/SHA256_hash_of_the_token"; instead of "http://example.com/.well-known/acme-challenge/token";. The TLS-SNI challenge uses this "hashed token for requests" pattern already. In the TLS-SNI challenge, SAN A (the one requested in the TLS SNI extension during challenge verification) is constructed by hashing the token, while the response is constructed with the (hash of) the key authorization. One possible drawback of having challenges to use this "hashed token for requests" pattern is that hashing would become such an integral part of the challenge process that if a hash algorithm is compromised, new versions of all challenges will need to be released. In both ideas above, I suggested applying the same general "pattern" (of what should be used for making validation requests and what should be used for making validation responses) to all challenges. Although this statelessness issue solely affects the HTTP challenge at this time, adding text in the specification (probably in a "security considerations" subsection) to require or recommend all challenges to use the same pattern (or choose from a list of multiple approved patterns) would prevent future challenges from having similar issues. On a different note, would requiring the provisioned challenge resource (in this case, the response to the "http://example.com/.well-know n/acme-challenge/some_token_or_hash_of_the_token" request) to be digitally signed by the account JWK and/or the CSR key (most likely by having the response be a JWS containing the key authorization rather than the key authorization itself) improve security, worsen security, or have no impact on security? If it would improve security, would this be feasible for each type of challenge? Sincerely, Logan Widick On Mon, May 8, 2017 at 5:21 PM, Zach Shepherd <[email protected]> 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.) > > Essentially, the server informs the client of the token during the > validation process, removing any need for the client to have known it. > > If this is acceptable, the entropy requirement should be removed. If this > is unacceptable, the challenge and validation should be revised. > > Regards, > Zach Shepherd > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
