Subject: [Acme] [acme] Account deletion for security currently useless if rolled over

From: "sheel.at" <[email-masked]>
Date: Sat, 16 Apr 2016 11:30:39 +0200

Suppose an account key gets compromised. To prevent abuse, the owner can
delete the account:
https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#deleting-an-account
However, people having the key can simply change it without any effort:
https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#account-key-roll-over

What happens if the attacker does so before the owner can react, or even
before the owner notices anything of the breach?

I suggest changing tha specs (and implementation) to keep old keys after
changes for while. More specifically:
* When an account key is rolled over, the old key is kept for eg. 30 days.
* Multiple changes within this 30 days mean that there are multiple old
keys.
* Account deletion is possible with any of the saved keys, be it old or new.
* Everything else (other than account deletion) only accepts the new
(newest) key.

Related:
The owner has no possibiliy to revoke certificates issued by the
attacker. For proper uses, nuking all certs when deleting the account
might be not what the users like, but for the attack scenarion...

Related 2 (yeah, it's getting bothersome)
If there is an "optional" certificate nuking when deleting accounts, the
attacker could issue certificates and then delete the accountwithout
destroying the certificates(the attacker!), to prevent the real owner
from destroying the certificates. Meaning, a "partially" deleted account
has to stay around for ... as long as there are non-expired
certificates?, just for the possibility that someone wants to delete the
rest too. (But without being useful for anything else other than deleting)

...
I'm rather new to the Let'sEncrypt internals, so if I missed the fact
that there is a solution already, please forgive me.

Otherwise, sorry, I know spec'ing and implementing this would be
annoying. But without this, the possibility for deleting an account key
is not particularly useful.

---

From: Philipp Junghannß <[email-masked]>
Date: Mon, 18 Apr 2016 18:30:35 +0200

In my opinion it would be also nice if you could revoke with the cert key
making it possible to remove the cert even if the acc is down.
Am 18.04.2016 18:15 schrieb "sheel.at" <[email-masked]>:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 18 Apr 2016 12:32:53 -0400

You can already revoke with the cert key.

---

From: Philipp Junghannß <[email-masked]>
Date: Mon, 18 Apr 2016 18:34:39 +0200

Okay didnt know that one yet.

---

From: Richard Barnes <[email-masked]>
Date: Mon, 18 Apr 2016 12:51:54 -0400

This is a very good point.

> * Everything else (other than account deletion) only accepts the new

These sound like good recommendations to go in the account deletion
section.  Would you like to draft a PR?

> might be not what the users like, but for the attack scenarion...

Something like this?

```
POST /acme/reg/asdf HTTP/1.1

{ "delete": { "revokeCerts": true } }
```

> rest too. (But without being useful for anything else other than deleting)

Oof, that is bothersome :)

I think there are a couple of mitigations here, though:

1. The CA can allow revocation by a new account that's authorized for the
names in the cert
3. The Baseline Requirements require CAs to revoke mis-issued certs, so
even if ACME doesn't provide a mechanism, you should be able to use
email/phone/fax/etc.

On the other side, I can imagine scenarios where the flexibility about
nuking would be valuable.  Maybe I'm handing over a domain, and I don't
want to make my servers stop working right away.

One alternative you could consider would be to recommend allowing old
account keys to do certificate revocation, just like for account deletion
above.  That has the disadvantage that you can't truly delete the
registration resource, so I think I come away preferring to have a switch
in the delete request.

--Richard

---

From: Albert ARIBAUD <[email-masked]>
Date: Mon, 18 Apr 2016 19:14:27 +0200

Hello,

Le Sat, 16 Apr 2016 11:30:39 +0200
"sheel.at" <[email-masked]> a écrit:

> Suppose an account key gets compromised. To prevent abuse, the owner
> can delete the account:
> What happens if the attacker does so before the owner can react, or
> even before the owner notices anything of the breach?
> 
> I suggest changing tha specs (and implementation) to keep old keys
> after changes for while. More specifically:
> * Multiple changes within this 30 days mean that there are multiple
> old keys.

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.

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.

- 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).

- 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.

Again, maybe these scenarios cannot really happen due to some part of
the specification which I missed. And if they can, then no, I don't see
any simple solution, at least not off the top of my head.

Amicalement,
-- 
Albert.

---

From: Patrick Figel <[email-masked]>
Date: Mon, 18 Apr 2016 20:29:39 +0200

> 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

>   opportunity for the attacker, not against the victim user, but

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).

>   safely assume the victim won't realize there is an attack

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.

>   so that the victim's key "drops out" as the oldest, and the victim is

Yep, that wouldn't be a good solution - the server should rather stop
accepting new keys.

---

From: "sheel.at" <[email-masked]>
Date: Wed, 20 Apr 2016 22:48:08 +0200

What is a PR? :)

> section.  Would you like to draft a PR?

Anyways, it's good to see that I wasn't stupid somehow,
and the added ideas are fine too...

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 21 Apr 2016 18:37:26 +0000

> What is a PR? :)

Assuming the question is serious, take a look at this tutorial: https://yangsu.github.io/pull-request-tutorial/

Alternatively, post a diff to the list with the changes you'd like to see.

---

From: "sheel.at" <[email-masked]>
Date: Thu, 21 Apr 2016 22:26:00 +0200

Thank you, T. Hardie.

R. Salz: Well, sorry for asking something stupid :rolleyes:

I know git, and it's clear what's requested.
I just didn't made the connection from PR to git,
being somewhere where this abbreviation isn't used for
"pull request", and having lots of things other in mind.

Will make a draft...

...
I'll get to

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 21 Apr 2016 21:03:25 +0000

It’s not stupid ?  Understand the terms used (such as PR in this WG:) can be among the hardest parts.

> Will make a draft...

Great, looking forward to it!

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz