I'm not convinced of a need to change the http-01 validation method here. > 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.)
As Ilari addressed, this assumption isn't correct. The token (provided in the request) alone isn't sufficient to implement a stateless response for http-01. -- Jehiah On Wed, May 10, 2017 at 11:00 PM, Zach Shepherd <[email protected]> wrote: > To make things more concrete, here is a PR that introduces a new version > of the HTTP challenge: https://github.com/ietf-wg-acme/acme/pull/312 > > > Regards, > > Zach > ------------------------------ > *From:* Zach Shepherd > *Sent:* Tuesday, May 9, 2017 9:13:37 AM > *To:* Logan Widick > > *Cc:* [email protected] > *Subject:* Re: [Acme] Bypassing the intended purpose of requiring 128 > bits of entropy for the http-01 token > > > I like the "hashed token for requests" pattern, assuming that the > [unhashed] token would be present as a part of the response. > > > I think the drawback of hash algorithm compromise can be mitigated by the > choice of hash algorithm; compromise of SHA-256 would already have > substantial impact on ACME such that the net impact of further use of it > would be relatively insignificant. > > > Regards, > > Zach > > ------------------------------ > *From:* Logan Widick <[email protected]> > *Sent:* Monday, May 8, 2017 4:37 PM > *To:* Zach Shepherd > *Cc:* [email protected] > *Subject:* Re: [Acme] Bypassing the intended purpose of requiring 128 > bits of entropy for the http-01 token > > 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-know > <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_.well-2Dknow&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=p7InnW2mQOs0PbG3CIC1CU7a5ElnIRQgh5Q0jlexC7Y&e=>n/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-know > <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_.well-2Dknow&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=p7InnW2mQOs0PbG3CIC1CU7a5ElnIRQgh5Q0jlexC7Y&e=> > n/acme-challenge/SHA256_hash_of_the_token" instead of " > http://example.com/.well-know > <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_.well-2Dknow&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=p7InnW2mQOs0PbG3CIC1CU7a5ElnIRQgh5Q0jlexC7Y&e=>n/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 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_.well-2Dknow&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=p7InnW2mQOs0PbG3CIC1CU7a5ElnIRQgh5Q0jlexC7Y&e=> > 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 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Neilpang_acme.sh_wiki_Stateless-2DMode&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=btrBKR5yx_x7Q_6OImGiTK6osiKun9UWrYmNvGluGt8&e=> >> .) >> >> 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 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=_aG2-51Ootcw6Q1nkZQwL2V5Xcf2U9t2fc1Y_iB_d80&e=> >> >> > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > > -- Jehiah
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
