On Thu, 17 Dec 2015 17:40:42 -0500 Eric Mill <[email protected]> wrote:
> On Thu, Dec 17, 2015 at 11:19 AM, Andrew Ayer <[email protected]> > wrote: > > > On Thu, 17 Dec 2015 02:23:20 -0500 > > Eric Mill <[email protected]> wrote: > > > > > I think that ACME should revisit the DNS specification and avoid > > > using a prefix for the TXT validation, to enable this use case. > > > > I disagree, because of a major restriction that DNS places on > > CNAMEs: CNAMEs cannot coexist with other record types. If ACME > > didn't use prefixes, and you CNAME'd blog.ericmill.com over to > > Tumblr, you would lose the ability to yourself complete a DNS > > challenge for blog.ericmill.com, since no other record type could > > coexist with that CNAME. This would pose a major problem for users > > of third-party services which do support TLS with user-provided > > certs but don't implement ACME. > > > > Meanwhile, there is a simple solution that does enable your use > > case: Tumblr can ask you to also CNAME > > _acme-challenge.blog.ericmill.com over to them. It's slightly > > inconvenient to have to provision two CNAMEs instead of one, but > > this seems preferable to forcing some users to choose between > > CNAMEing to a third-party service and being able to use ACME > > themselves. Let me expand on this, in case others weren't sure what I was proposing: the _acme-challenge.blog.ericmill.com CNAME would point to a TXT record maintained by the third-party blog service containing the ACME challenge response. The third-party service would be responsible for updating the TXT record as necessary; the user would only need to set up the CNAME in their DNS once. That's pretty easy for new users, who have to add a CNAME to the third-party service anyways, but I acknowledge that it would present a hurdle when deploying HTTPS to existing users. > Yes, but this forces users to do the work of adding a second CNAME > that points to the third party service, and prevents the service from > doing it themselves. > > The user base that would *benefit* from keeping the prefix consists of > users who want to CNAME their domain to a service (instead of full DNS > delegation) but who wish to obtain a cert themselves and then upload > that certificate to the service they've CNAMEd their domain to. That > user base sounds relatively small to me -- certainly smaller than the > number of users who currently use (or would use) custom domain > support on third party services. These third party services do have an option that would avoid the need for their users to add a second CNAME: they could use the HTTP or TLS SNI challenges. This would require extra engineering work, as they would need to coordinate the installation/configuration of ACME challenge responses across a fleet of servers as opposed to changing a DNS record. However, I suspect that the services with large userbases that you're concerned about are likely to have the engineering resources needed to implement HTTP or TLS SNI. In contrast, a small- or medium-scale operator with CNAMEs pointing to cloud load balancers or other infrastructure services might find HTTP or TLS SNI too inconvenient, and these are the operators who would be forced to use HTTP or TLS SNI if the prefix were removed. > To me, it seems like we'll get more widespread use of ACME (and HTTPS > adoption) by allowing large services to just "flip the switch" for > everyone, rather than involving the user in this decision. > > The ideal would be to allow both use cases! So perhaps there's a way > I'm not thinking of, or perhaps we could split this into two separate > DNS-based validation methods, to support both kinds of uses. Indeed, since there are two use cases, perhaps there should be two DNS challenges, or the DNS challenge should simply be defined to check both with and without a prefix. Regards, Andrew _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
