James Kasten and I discussed this offline. He pointed out that you don't want to ask the client to sign a completely server-controlled token, even if that value is constrained, because of collision attacks. As illustrated by the forged root cert based on an MD5 collision, the server could ask you to sign a token:
acme-token-7e8ebcaef83c9f6a5ffa891934f4c79bebc8cdeea2fe17a314de79b50b1e040c After having offline found that that token collides with some other string, e.g. a handshake message for which they want to spoof a signature by your TLS private key. I proposed removing the client random string `s' largely because the current specification hard codes SHA-256(r || s). Ideally we should either specify algorithm agility for that hash, or remove it entirely. Proposal: Instead of having the client send its random string to the server and have the server perform the hash, replace Z = SHA-256(R || S) with Z = R || "." || S. When validating the provided certificate, the server should look for a subjectAltName of R.*.acme.invalid. This simplifies the spec so it doesn't have to hard-code SHA-256. It uses S in a similar method to CA-controlled serial numbers, to make collision attacks harder. Auxiliary proposal: In the DVSNI section, add: 3. Verify the following properties of the certificate provided by the TLS server: ... * Its hash algorithm and signing key type and size are acceptable by server policy. At a minimum, servers SHOULD reject MD5 and SHA1 self-signed certificates, and RSA signing keys shorter than 2048 bits. On 01/07/2015 11:29 AM, Jacob Hoffman-Andrews wrote: > In the current version of the spec, for SimpleHTTPS Validation, the > client can specify the path (under .well-known/acme-challenge) where > the server should expect to find a copy of the token. The goal as I > understand it is to allow a single client to manage multiple pending > authorization requests without file collisions. However, I think this > adds unnecessary complexity and risk. > > Proposal: For the SimpleHTTPS challenge, the client should not provide > a path. The server should always fetch > .well-known/acme-challenge/<token>.txt, and should expect the contents > to equal <token>. > > For DVSNI and DNS challenges, the client provides a random string `s', > to be hashed with the server's random string `r'. What sort of attack > does this protect against? It seems unnecessarily risky to allow the > client input into the hash, and leads to some issues like > https://github.com/letsencrypt/acme-spec/issues/12. > > Proposal: For the DVSNI and DNS challenges, the client should not > provide a random string `s', but should directly sign the server's > random string `r'.a > _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
