Hi Simon, On Wed, Mar 25, 2015 at 10:26 PM, SJ Kissane <[email protected]> wrote:
> 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. ​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 > (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 > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
