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

Ted Hardie <> Fri, 03 April 2015 18:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7D13B1ACED3 for <>; Fri, 3 Apr 2015 11:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tQrWUwgHplZh for <>; Fri, 3 Apr 2015 11:27:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0216A1ACE3B for <>; Fri, 3 Apr 2015 11:27:32 -0700 (PDT)
Received: by iedfl3 with SMTP id fl3so108219552ied.1 for <>; Fri, 03 Apr 2015 11:27:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wXqcRwRK0eXXGz5yZ63O6kGHqnCL1a4Lk9ktnxuZG4A=; b=a+w9noj3rp0YN+Ms4Y4zpje/nYqR6asDtGI2h4VP5VjwaMex/yVI5zvGn1y498V+q9 sufbHvyxu1Z6O4vRPFcJmvSLD5bpBFpJgGmPEHLaU8+doZVjRptnYwJe1gBmNNEk29SO iCB5tCD8Ta+AsuKfpMepthDQzATBdN27EbaTxfeOFbHeIIUmlA64p66zcSKZBNnos2sW qxlc50ujygVZNZ9YmMLPTM9W0z3pnv1n1eUnrtZ4MlBllqpvTaATqAy7jHQhZtgGUh0z eZQICJJWQBqcV7/8/QTA6CjmBa5T5SLPo5WUs8+AhmlQrZ+cM2JoNI8u7mVyski9g9g2 6EAA==
MIME-Version: 1.0
X-Received: by with SMTP id p20mr5374626ice.62.1428085651473; Fri, 03 Apr 2015 11:27:31 -0700 (PDT)
Received: by with HTTP; Fri, 3 Apr 2015 11:27:31 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Fri, 3 Apr 2015 11:27:31 -0700
Message-ID: <>
From: Ted Hardie <>
To: SJ Kissane <>
Content-Type: multipart/alternative; boundary=20cf301d3a28f708650512d6191c
Archived-At: <>
Cc: "" <>
Subject: Re: [Acme] How does ACME handle domain reuse?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Apr 2015 18:27:34 -0000

Hi Simon,

On Wed, Mar 25, 2015 at 10:26 PM, SJ Kissane <> wrote:

> Hi
> Sally registers the domain to host her website. She uses
> ACME to SSL protect it. Later, Sally loses interest in her website and
> decides not to renew, and it expires. Steve wants to start
> a website - he notices that is unregistered, so he
> registers it and opens his own website on it. He then tries to use
> 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 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.



> 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
>, 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
>, and authenticate to ACME using, I can then
> make ACME revoke, 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
> _______________________________________________
> Acme mailing list