Subject: [Acme] How does ACME handle domain reuse?

From: SJ Kissane <[email-masked]>
Date: Thu, 26 Mar 2015 16:26:23 +1100

Hi

Sally registers the domain example.com to host her website. She uses
ACME to SSL protect it. Later, Sally loses interest in her website and
decides not to renew example.com, and it expires. Steve wants to start
a website - he notices that example.com is unregistered, so he
registers it and opens his own website on it. He then tries to use
ACME to SSL protect it. How should the ACME server distinguish this
(entirely legitimate) domain reuse scenario from a domain hijacking
attack? Steve doesn't know Sally, cannot rely on Sally to provide the
recovery token. Steve might be very disappointed to discover he can't
use ACME for SSL, simply because a previous registrant of the same
domain name has already used it. How will ACME protocol handle this?

One option is maybe the ACME server operator can scan WHOIS records to
detect changes in domain ownership. This still might pose a problem
for subdomains, e.g. if I allow other people to register under my
example.com, and then one of the subdomain users sets up ACME, and
then I want to use subdomain for something else, and then suppose I
cannot get the former subdomain assignee to hand over the recovery
token. Maybe we need a way in the protocol for a parent domain
controller to revoke control of the child domain. So if I control
example.com, and authenticate to ACME using example.com, I can then
make ACME revoke foo.example.com, even if I don't know the recovery
token for it.

Or possibly, the right solution is non-technical: ACME server operator
establish an out of band manual process to handle these scenarios.
But, even if you decide that is the answer, the RFC should still
discuss these scenarios, and require the ACME server operator to
establish a policy/business process to handle them.

Regards
Simon

---

From: Ted Hardie <[email-masked]>
Date: Fri, 3 Apr 2015 11:27:31 -0700

Hi Simon,

On Wed, Mar 25, 2015 at 10:26 PM, SJ Kissane <[email-masked]> wrote:

> ACME to SSL protect it.

​There are a couple of timing questions inherent in this.  If the ACME
system enables shorter-lived certificates, then Sally's certificate for
example.com may simply expire between Sally's use and Steve's interest​.
Once it has expired, there is no real issue here, because the standard ACME
methods for proving control of the domain will just work.

If we could count on the interval between Steve's use and Sally's use being
moderately long, this would likely be enough.  Given domain squatting on
expired domains, it seems likely it won't be as the attempts at re-use may
be almost instantaneous.  If the domain validity for ACME certificates
lasts longer than whatever the interval turns out to be, ACME could still
use control-of-domain methods to test Steve's use of the domain, but there
would be a risk to Steve that the valid certificate issued to Sally might
be available to an attacker wishing to MiTM or spoof his site.

The ACME server might take the existence of a different extant certificate
as a block to issuing a new one; it might also have a procedure for
revoking the certificate issued to Sally once Steve has registered interest
and some set of tests for Sally have failed.  In that case, the usual
revocation methods (and their usual limitations) apply.

I agree that the invocation of these methods may well mean Steve does not
get the low friction experience we're trying to enable, but that seems to
me a part of the cost of re-using an existing domain.  More to the point,
since lowering that cost may actually enable attackers, I'm pretty much
loathe to do that.  So I'm not sure that create protocol mechanics around
this make sense, but I do agree that describing this issue in the documents
would be useful.

regards,

Ted

> How should the ACME server distinguish this
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>