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. -- Andrew _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
