> 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. I've already come out against this, but I'd like to echo Barnes's point about URL comparison being a bit messy. There are multiple possible URLs which represent a resource - "https://example.com/acme/reg/123";, "https://example.com/acme/reg/123?";, "https://example.com/acme/reg/123#";, "https://example.COM./acme/reg/123";, maybe even "http://example.com/acme/reg/123";. Specifying the "right" URL isn't as simple as it seems. What if an implementation considers only the path and ignores the hostname, etc. Clarifying this would probably be a decent-sized paragraph to add to the spec.
Avoiding key comparison also seems like crypto-superstition more than a problem demonstrated in practice. Can we point to any historical vulnerabilities caused by an implementation error of this kind? _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
