On Sat, Oct 22, 2022 at 05:48:35PM +0200, Sebastian Nielsen wrote:
I don't see any problem with it since:
1: It requires possessing a account key with a valid authorization for the
domain in question.
In my eyes, one that posess such a key IS the valid domain owner.
That is an extremely odd way of looking at the situation. An account key
authorizes operations against an ACME endpoint, it doesn't express (or
imply) ownership or control of anything else.
A more reasonable position might be that someone who has allowed their ACME
account private key to become available to a miscreant has foregone all
expectation of protection from any form of attack. A counterpoint to that
could be that, at present, possession of an ACME account private key, by
itself, allows certain attack vectors (such as denial of service, due to
allowing certificate or account revocation requests). However it does not
allow (as far as I can determine) straightforward issuance of certificates
to an attacker (again, an attacker who *only* has the account private key).
To that extent, standardising and implementing a new feature in ACME that
suddenly *does* allow that attack to be mounted is a change to the risk
profile for the security of the account private key. Someone who setup the
protections for their private key in the expectation that it could "only" be
used for certain attacks may be somewhat dismayed to discover that it can
now be used for a wider range of attacks.
If you can't keep your account key secret, what says you can keep your
certificate keys secret?
This is a false equivalence. An account key is a long-lived credential that
must remain available and unchanged for an extended period, potentially
across multiple devices/services, whereas a certificate key can (and usually
does) rotate every few months (or even more frequently) as certificates are
re-issued.
2: A domain whose account key has leaked out, is already compromised in some
way or another.
For example, you could hack into the ACME client server and steal the key,
and then place a trojan which transmits the order ID to you under the
current regime.
Sure, but compromise of the ACME client endpoint is far from the only way
that an account key could become available to a miscreant. I discover, on
average, about three to four Let's Encrypt account keys per week via the
operation of pwnedkeys.com, and I can assure you that the methodology used
does not include compromising anyone's servers.
Adding a order list still needs you to somehow listen on the
victim to time the attack correctly.
The only victims that this attack will work on, is victims that let an
authorized order stay for days rather than finalizing it immediately.
Days? I think you understate the probabilities rather significantly.
- Matt
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
