On 18/04/16 19:14, Albert ARIBAUD wrote: > In the spec above, apparently nothing prevents the attacker from rolling > over and over again, and the server will only be able to handle a > finite number of keys before it either misfunctions or decides to drop > the newest or oldest keys.
This can be solved with some rate-limiting for key roll-over requests. ACME defines a "rateLimited" error code for this purpose. The "Denial-of-Service Considerations" section mentions rate limits as one possible mitigation for DoS. I'll describe how rate limits would work in the scenarios you mentioned: > I might have missed something, but it seems to me that we thus > might have the following scenarios: > > - server cannot handle more than N rollovers: that is a (D)DoS > opportunity for the attacker, not against the victim user, but > against the server. That's correct. In order to prevent a DoS, key roll-over requests would have to be rate-limited based on keys per registration or keys per IP (similar to the existing registrations per IP rate limit in boulder). > - server handles more than N rollovers by not accepting more than N > (dropping the newest keys): attacker can still lock out the victim by > doing N rollovers before the victim does their first (and we can > safely assume the victim won't realize there is an attack > immediately). The proposal suggests that ACME should accept old (replaced) keys *only* for delete requests. If the attacker has access to the account key, the registration is already compromised and being locked out of it should not be a problem. The proposal would still allow the victim to delete the registration in order to prevent any further damage from being done, which was the whole point of this. > - server handles more than N rollovers by only keeping the last N keys > (dropping the oldest keys): again, the attacker can force N rollovers > so that the victim's key "drops out" as the oldest, and the victim is > then locked out. Yep, that wouldn't be a good solution - the server should rather stop accepting new keys. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
