On Mon, May 08, 2017 at 06:37:50PM -0500, Logan Widick wrote: > 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.
The way TLS-SNI-02 does it is to derive the challenge and response tokens out of the master random value. TLS-SNI-01 had a similar problem, but in that case, the problem was compounded by: - TLS-SNI not even weakly binding the hostname to validate into validation (-02 does not fix this), and - TLS-SNI-01 not binding the account key into validation (and even in -02, this is not verifiably done). (For these problems, I consider TLS-SNI-01/-02 to validate the underlying IP, not the domain itself... In CABForum BRs, this is known as method 8 validation. Method 10 was intended to cover TLS-SNI, but the definition looks just screwed up). Whereas HTTP-01 does (weakly) bind both the hostname and the account key into validation in verifiable way. This renders "stateless mode" quite a bit harder to exploit. And if one moved to challenge-response token scheme, most likely the response would not contain challenge at all. So the storage amount would remain the same, unless implementation backed things with database table. Some extra storage is unlikely to be an issue for such implementation. > 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? I don't think having it signed by account key would affect security. Rendering responses unpredictable to the CA and strongly binding the hostname could have some benefits tho. Also note that you can't assume that signature binds the key it was done using: For that, you need to include the public key in data to be signed. Yes, some signatures like Ed25519 do such binding anyway, but IIRC ECDSA doesn't. Signing with CSR key would have negative impact (cross-protocol attack possibility! Not to mention it would really interfere with properly protecting the TLS key). There actually was a message that was signed with TLS key in past versions, but it was removed because of cross-protocol attack possibilities and such problems. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
