To me, the idea of shared secret at the time of order creation, is a good protocol improvement.
From: Acme [mailto:[email protected]] On Behalf Of Aaron Gable Sent: Monday, October 24, 2022 3:24 PM To: Ilari Liusvaara <[email protected]> Cc: [email protected] Subject: Re: [Acme] Potential race condition attack via account pending order lists The ACME domain validation protocol is only capable of asserting a single statement: "the entity which controls this account private key also controls this domain name". If someone other than the original applicant also controls the same account private key, the ACME protocol has no way to determine that fact. All entities which hold the account private key are, from the ACME server perspective, the same Subscriber. So in fact holding an account key does imply control over all names for which that account has demonstrated control. That's not to say that the situation described in the first message of this thread isn't a problem, however. It's valuable to distinguish between attacks which require persistent presence versus those which can be conducted from a different time and location than the initial compromise. The attack as described is of the latter category, where an initial exfiltration of a key opens the door to asynchronous attack later. That's something to be concerned about. But it's not clear to me that it's worth being more concerned about than any of the other attacks that are possible with a compromised account key, such as: - changing the account contact information so the original subscriber cannot be contacted by the CA; - revoking every cert held by that account, effectively a denial-of-service against all sites operated by the Subscriber; - requesting new orders for any names which still have valid authorizations (remember that the Baseline Requirements allow validation document reuse for up to 398 days!); and - conducting an account key rollover so the original subscriber can't undo any of the actions you've taken. Aaron On Mon, Oct 24, 2022 at 7:12 AM Ilari Liusvaara <[email protected] <mailto:[email protected]> > wrote: On Fri, Oct 21, 2022 at 02:33:15PM -0700, David Weitzman wrote: > The attack described below wouldn't work on Let's Encrypt because it > hasn't implemented the order list feature yet, so this is more of a > hypothetical attack for anyone who finishes implementing the standard. Well, Let's Encrypt implements authorization caching, which causes much more serious issues if someone manages to compromise the account key. And then one needs either order list or order reuse in order to recover from no-reply order creation (however, I do not think any current ACME client supports recovery using order list, so in practice CA needs order reuse). -Ilari _______________________________________________ Acme mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
