Re: [Acme] DNS challenge spec doesn't support CNAME model

[Andrew Ayer <[e-mail]>]

On Thu, 17 Dec 2015 17:40:42 -0500
Eric Mill <[e-mail]> wrote:

> On Thu, Dec 17, 2015 at 11:19 AM, Andrew Ayer <[e-mail]>
> wrote:
> 
> > On Thu, 17 Dec 2015 02:23:20 -0500
> > Eric Mill <[e-mail]> 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