Subject: [Acme] Account Key Loss

From: Russ Housley <[email-masked]>
Date: Thu, 18 Aug 2016 14:14:45 -0400

In Berlin, I agreed to offer a few words about account key loss.  Here
it my initial suggestion.  After the mail list makes improvements, I
leave it to the document authors to find the right location in the
document to place it.  Somewhere in Section 6.2 or somewhere in
Section 9 seems appropriate.

Russ

= = = = = = = =

Account Key Loss

   A client may need to change the public key that is associated with a
   registration if the account private key is lost.  In this situation,
   the rollover procedure in Section 6.2.1 cannot be used because the
   signature with the existing key on the account cannot be produced.
   The CA needs to establish an out-of-band process to change the key
   associated with an account, and the process must be highly resistant
   to social engineering.  If an attacker is able to successfully
   replace an account key, then they will be able to replace all of the
   associated certificates with ones that contain keys of their own
   choosing.

   Social engineering is an attack that relies heavily on human
   interaction, and it often involves tricking people into breaking
   or bypassing security procedures.  Many techniques have been used
   over the years to thwart social engineering; they usually involve
   gathering additional information during the registration process
   that can be used later to increate confidence that one is actually
   communicating with the person that did the initial registration.
   For example, the CA might collect the answers to a set of
   questions that are not likely to be available in online databases,
   and the CA might collect a telephone number that can be used as part
   of challenge-response authentication.

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Thu, 18 Aug 2016 14:45:38 -0700

> Section 9 seems appropriate.

Is there much enthusiasm for including account recovery details in the
specification? The original token based recovery method was initially
removed as there were no planned implementers. On the Let's Encrypt side
our rational for this was that in the account of genuine key loss there
is nothing unique to that account, e.g. they can easily just create a
new account and re-create all of their authorizations. It is true they
loose the ability to revoke their previously issued certificates but in
the case of key loss, and not compromise, this doesn't really seem like
a problem.

If we are to add language to the specification detailing how key loss
should be dealt with I'd rather an actual method be defined rather than
leaving the details up to the implementer since vulnerabilities in this
process would be very dangerous.

As far as I remember there were no real design issues with token based
recovery, if we need recovery at all why not just bring that back?

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 18 Aug 2016 17:52:22 -0400

> the case of key loss, and not compromise, this doesn't really seem like

This is my understanding of the requested action.

The process for recovering from the loss should not revoke the previous certificates until the new account setup proves that it has all of the appropriate accesses.  If an attacker could get the account to be deleted and the current certificates revoked as the first step in a replacement process, then we have created a denial of service opportunity.

Russ