I'm probably not understanding a key piece of technical info about the protocol, but when I see this statement it makes me think it has similar issues to tls-sni-01. If we're relying on the hosting provider enforcing certain constraints like this, then we're delegating a critical piece of domain control back to the hosting provider which would be a no-go.
4. Security Considerations The design of this challenges relies on some assumptions centered around how a server behaves during validation. The first assumption is that when a server is being used to serve content for multiple DNS names from a single IP address that it properly segregates control of those names to the users on the server that own them. This means that if User A registers Host A and User B registers Host B the server should not allow a TLS request using a SNI value for Host A that only User A should be able to serve that request. If the server allows User B to serve this request it allows them to illegitimately validate control of Host A to the ACME server. Please let me know what I'm missing. Doug > -----Original Message----- > From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Roland Bracewell > Shoemaker > Sent: Friday, February 23, 2018 3:00 AM > To: Rich Salz <rs...@akamai.com> > Cc: IETF ACME <acme@ietf.org>; Martin Thomson > <martin.thom...@gmail.com> > Subject: Re: [Acme] ALPN based TLS challenge > > Here is the ID: https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls- > alpn/ > > > On Feb 22, 2018, at 8:38 PM, Salz, Rich <rs...@akamai.com> wrote: > > > > Yes, like Martin said, submit the individual draft and we can call for > > adoption. > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
