ok nevermind, my brain is slowly working (sorry Zach); this is different from the problems in tls-sni-01 where you could respond with a stateless response to all requests from any account (which confused me at first as i thought you were reporting the same type of stateless issue).
The issue here is you can provide a stateless response to all response for given account(s). I don't know if that's desirable but as it still requires some amount of authorization that seems like it might still be ok and at least isn't a security issue. -- Jehiah On Wed, May 10, 2017 at 11:12 PM, Jehiah Czebotar <[email protected]> wrote: > 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
