On Wed, Sep 30, 2015 at 7:32 PM, Andrew Ayer <[email protected]> wrote: > On Mon, 28 Sep 2015 15:01:57 -0400 > Richard Barnes <[email protected]> wrote: > >> I opened a few PRs over the weekend that address recently-raised >> issues: >> >> * "Address signature reuse vulnerability" - >> https://github.com/ietf-wg-acme/acme/pull/6 > > I see that in all three challenges, the server now constructs the > authorized key object (previously, this detail was inconsistent among > the challenges). I think this is a bad idea, and that the client > should be exclusively responsible for constructing this object. > > The problem is that to be secure, the client has to check that the > server-provided object references the client's public key and not the > public key of an application-layer MitM. The spec says to do this, but > the protocol still works if the client omits the check, which some > lazy/careless implementers might do as a shortcut. This can be avoided > by having the client construct the object instead. > > The flow would be: > > 1. Server sends the client a challenge object containing the token. > > 2. Client constructs authorized key object containing its public key > and the token, and serializes it to a string. > > 3. Client writes serialized object to file (Simple HTTP) or computes its > hash and provisions the TLS cert (DVSNI) or TXT record (DNS) containing > the hash. (For uniformity, perhaps Simple HTTP should use a hash also.) > > 4. Client base64 encodes the serialized object and sends it to the > server in the challenge response. > > I think this is both simpler for the client and more robust. It moves > complexity and security-sensitive checks from the client to the server, > which is how it should be. There will be few server implementations > and they will be written by security-conscious developers. In > contrast, there will be relatively more client implementations and who > knows what kinds of developers will be writing them.
Sorry, I probably should have explained this better. The thinking here is actually to increase robustness by denying the client the opportunity to create hash collisions. The authorized key object is JSON, which means that the number of serializations for it is bounded only be the size of the object the server will accept. If a malicious client can generate an authorized key object that collides with a legitimate one (a second preimage), then he can authorize his own key. Having the server generate the object puts all of the entropy that goes into the digest under the control of the server. Let's also consider what the risk is if the client screws up, i.e., if he provisions a bad key authorization or digest. First, since ACME runs over HTTPS, the only entities that can attack are (1) the CA, who is completely trusted in any case, and (2) an entity such as a CDN that one end lets into the the HTTPS connection. So the only real risk is from the intermediary, who could possibly substitute in an authorized key object with a token and key of its choosing, and convince the client to provision it to the validation server. However, the client is required to parse the object and echo back the token under its signature. If the client holds off until the server accepts the response (i.e., returns a 2XX response) before provisioning the validation server, then the server can verify that the token is OK and if not, fail the validation. Then the attack would only work if the CA assigns the same token to the attacker's and victim's challenges, and we already require that the token uniquely identify the challenge. In other words, there's a trade-off here between a little more surety in the crypto and a little more protection against the CDN. Given that ambiguity about crypto bit us last time, I opted for the former. Would it help to clarify that the CA MUST verify the token before accepting the response, and the client MUST NOT provision the validation until after the response is accepted? --Richard _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
