I can live with this, but I'm not enthusiastic. tl;dr: Makes things more complicated, security benefit debatable.
It makes me sad to lose the clean layering between cryptographic verification and verification of identity. Before, the need to provide a valid signature provided some minimal validation of the request that could be performed totally statelessly by the server. Now, the request validation logic needs access to the account DB. I guess whether you see this as a loss depends on whether you regard signature verification or DB access as more expensive; I am far more wary of DB access, and state coupling in general. I also don't think the attribution gains here are quite as big as are being suggested. For all requests where the account tied to the key matters, the account is identified by the key. So the error case here isn't like an HTTPS client that doesn't check the server's cert and proceeds with the connection anyway; an ACME server that doesn't look up the account for a key is unable to proceed. I'll grant that the "kid" approach is somewhat harder to attack than the "jwk" approach. In order to get the server to recognize a bad key pair, the attacker needs to get a confusable account URI, and account URIs are issued by the server. So you basically need two bugs instead of one (URI allocation + comparison, vs. key comparison). Nonetheless, key comparison does not seem that risky to me -- it's what undergirds every TLS and SSH session you've ever engaged in, after all, and I don't recall ever hearing about a major vuln in an implementation of these protocols due to a key comparison flaw. I don't have the same confidence in URL allocation and comparison routines, which will have much more variability. On Tue, Sep 27, 2016 at 9:24 AM, Daniel McCarney <[email protected]> wrote: > I'm also strongly in favour of this change. I think the minimal increase > in client > state/complexity is offset by the gain of knowing that the category of > potential > bugs that Jacob mentions are avoided. > > > On Tue, Sep 27, 2016 at 1:01 AM, Martin Thomson <[email protected]> > wrote: > >> I am inclined to think that this is a good change, on the basis that >> it means that the server is minting the identifiers that the client >> uses. I think that Jacob is probably understating the potential for >> bugs here. And key canonicalization is a bad smell. >> >> On 27 September 2016 at 14:51, Jacob Hoffman-Andrews <[email protected]> >> wrote: >> > I understand the concern, but I think that clients already have to store >> > a significant amount of state: the ACME directory URL, the private key, >> > and the domain names, certificates, and private keys of existing >> > certificates. I think that one more item, the account URL, is not a >> > heavy burden, especially when weighed against a real flaw in the >> > protocol. You could consider it akin to storing a username and password >> > for a more traditional login. >> > >> > All that said, for clients that find it to be a big savings, there is >> > always the method of finding the account URL by POSTing again to new-reg >> > with the same key. >> > >> > On 09/24/2016 06:16 PM, Hugo Landau wrote: >> >> I'm somewhat against this on the grounds that it introduces unnecessary >> >> state into clients (the registration URI), increasing their complexity. >> >> >> >> _______________________________________________ >> >> Acme mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/acme >> >> >> > >> > _______________________________________________ >> > Acme mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/acme >> >> _______________________________________________ >> Acme mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
