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

From: Eric Mill <[email-masked]>
Date: Thu, 17 Dec 2015 02:23:20 -0500

Hi,

Both the IETF and LE versions of the ACME spec define a DNS validation
method[1] which requires the validating party to set a TXT record for a
prefixed version of the hostname the cert is being requested for.

The client constructs the validation domain name by prepending the label
"_acme-challenge" to the domain name being validated, then provisions a TXT
record with the digest value under that name. For example, if the domain
name being validated is "example.com", then the client would provision [_
acme-challenge.example.com.]

I can see some discussion last December about the rationale for this
approach[2], but this doesn't apply to at least one large class of users,
which are services which ask their users to CNAME their custom domain over
to their service.

For example, a CNAME is how WordPress[3], Tumblr[4], and GitHub Pages[5]
allow customers to point non-apex domains at their services. If I want
blog.ericmill.com to be hosted by Tumblr, I set a CNAME record for "
blog.ericmill.com" with the value "domains.tumblr.com". Many other CDNs and
web services operate the same way.

Since DNS specifies that a CNAME can be thought of as an alias[6], this
means that a service like Tumblr is capable of setting a TXT record for
domains.tumblr.com with the validation token for blog.ericmill.com. A
spec-compliant DNS resolver looking for a TXT record for blog.ericmill.com
should follow the CNAME alias first, and then correctly identify the TXT
record for domains.tumblr.com as applying to blog.ericmill.com.

However, the current ACME spec asks for the record to be set for a prefix,
not for the requested FQDN. And if I CNAME blog.ericmill.com over to
Tumblr, Tumblr does not have the ability to set any records for a prefix,
such as _acme-challenge.blog.ericmill.com. This means that services which
have users CNAME domains are not able to use DNS validation to obtain
certificates.

I think that ACME should revisit the DNS specification and avoid using a
prefix for the TXT validation, to enable this use case.

Also: I can't think of any changes offhand that would enable Let's Encrypt
to support a use case where users set an A record to point to a third party
service, such as for apex domains in the services mentioned above. But this
is another important use case, especially for service providers which don't
distinguish between apex and non-apex domains in their business
offerings.[7] It'd be great to hear ideas for how that might be achieved.

-- Eric

[1]
https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#dns
[2] https://mailarchive.ietf.org/arch/msg/acme/gN1NxR4kmB3c9RT4ZIvZo1SBHKo
[3] https://en.support.wordpress.com/map-subdomain/
[4] https://www.tumblr.com/docs/en/custom_domains
[5]
https://help.github.com/articles/setting-up-a-custom-domain-with-github-pages/
[6] https://tools.ietf.org/html/rfc1034#section-3.6.2
[7] Few services distinguish these. But Bitly is an interesting case where
its very nature (short links) mean that their custom domains are almost
exclusively SLDs that require an A record.
http://support.bitly.com/knowledgebase/articles/76741-how-do-i-set-up-a-custom-short-domain-

-- 
konklone.com | @konklone <https://twitter.com/konklone>

---

From: Thomas Lußnig <[email-masked]>
Date: Thu, 17 Dec 2015 16:56:40 +0100

Hi,

even better it would be if it does not introduce an new record.
The challenge could be that the user sign an random token + random value 
from him with an private key.
So CA send (token, challenges[...])
User reply (userToken, SIGNED(token,userToken),publicKey,"tlsa-311")

This has two advantages over the current model:
1) There is no dynamic update required
2) The CA can direct verify the challenge since the user can pre publish 
the tlsa record.
3) It is not more insecure than any other dns-01, tls-sni-01 or http-01 
since if he have controll
over the DNS he can select the ip.
4) It should be compatible with cname.

Gruß Thomas

---

From: Andrew Ayer <[email-masked]>
Date: Thu, 17 Dec 2015 08:19:48 -0800

On Thu, 17 Dec 2015 02:23:20 -0500
Eric Mill <[email-masked]> wrote:

> Since DNS specifies that a CNAME can be thought of as an alias[6],
> this means that a service like Tumblr is capable of setting a TXT
> record for domains.tumblr.com with the validation token for
> blog.ericmill.com. A spec-compliant DNS resolver looking for a TXT
> record for blog.ericmill.com should follow the CNAME alias first, and
> then correctly identify the TXT record for domains.tumblr.com as
> applying to blog.ericmill.com.
> 
> However, the current ACME spec asks for the record to be set for a
> prefix, not for the requested FQDN. And if I CNAME blog.ericmill.com
> over to Tumblr, Tumblr does not have the ability to set any records
> for a prefix, such as _acme-challenge.blog.ericmill.com. This means
> that services which have users CNAME domains are not able to use DNS
> validation to obtain certificates.
> 
> 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.

> Also: I can't think of any changes offhand that would enable Let's
> Encrypt to support a use case where users set an A record to point to
> a third party service, such as for apex domains in the services
> mentioned above. But this is another important use case, especially
> for service providers which don't distinguish between apex and
> non-apex domains in their business offerings.[7] It'd be great to
> hear ideas for how that might be achieved.

Again, just CNAME _acme-challenge over to the third-party service :-)

Regards,
Andrew

---

From: Ted Hardie <[email-masked]>
Date: Thu, 17 Dec 2015 12:58:41 -0800

On Thu, Dec 17, 2015 at 8:19 AM, Andrew Ayer <[email-masked]> wrote:

> CNAMEs cannot coexist with other record types.

​Do any of the relevant services support ALIAS or DNAME?

I'm also kind of wondering how many TXT records would build up at
something like domains.tumblr.com if it was the target for many different
blogs.

regards,

Ted

> If ACME didn't use
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 17 Dec 2015 21:05:01 +0000 (UTC)

The point of adding more validation mechanisms should be to cover more use cases.
So examples that http challenge response covers are not too helpful.
I do not see the value of a second type of c/r scheme. Dns is a lousy match for c/r. Why are people so set on this?
If you want to use dns, use a signing key to authorize the request. Put the fingerprint of the key in the dns 

Sent from Outlook Mobile

On Thu, Dec 17, 2015 at 12:58 PM -0800, "Ted Hardie" <[email-masked]> wrote:

regards,

Ted

 If ACME didn't use

implement ACME.

use ACME themselves.

Regards,

Andrew

Acme mailing list

[email-masked]

---

From: Eric Mill <[email-masked]>
Date: Thu, 17 Dec 2015 17:40:42 -0500

> to choose between CNAMEing to a third-party service and being able to

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.

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.

> Again, just CNAME _acme-challenge over to the third-party service :-)

The prefix does neatly solve the issue of delegating via A records - that's
a good point.

-- Eric

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Dec 2015 10:54:14 +1100

On 18 December 2015 at 07:58, Ted Hardie <[email-masked]> wrote:
> Do any of the relevant services support ALIAS or DNAME?

I've tried using DNAME in the past and was unsuccessful.  I wont name
the provider, but they do run a lot of names.  They did fix the
problem in response to my queries though.

---

From: Andrew Ayer <[email-masked]>
Date: Thu, 17 Dec 2015 17:11:14 -0800

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

> > 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.
> 
> 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.

> 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

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 17 Dec 2015 17:17:22 -0800

> 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.

Also, Let's Encrypt currently supports HTTP redirects. So a service
provider could set up a static redirect on all their frontends from
/.well-known/validation/<foo> -> acme-validator.serviceprovider.net/foo.
If acme-validator is assumed to be less widely distributed than the
general-purpose frontends, it would be easier to update quickly.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 18 Dec 2015 08:49:49 -0800

On Thu, Dec 17, 2015 at 2:40 PM, Eric Mill <[email-masked]> wrote:

> So, I'm a wee bit concerned that taking the user out of the decision
entirely will leave us in a place where the user doesn't have an easy way
to withdraw approval for this.   If a user transitions from the user base
you are focused on to the one where they obtain the cert themselves, I'm
not sure how that works.

Put another way, I think we're tryin to make it easy for the user to get
what they want; we're not trying to set it up so that they're not involved
in deciding what they want.

Just my personal opinion,

Ted

---

From: Eric Mill <[email-masked]>
Date: Fri, 18 Dec 2015 13:04:51 -0500

> in deciding what they want.

I meant this in a user-empowering way -- that users are able to get HTTPS
established for them without them having to do any work, and services are
able to roll out HTTPS support from a central vantage point without
reaching out to existing user bases.

If a user wants to withdraw approval, the CNAME is always theirs to revoke.
The case of a user really liking a third party service, but for some reason
really disliking that service's choice of an ACME-based CA, seems unusual
to me and also something best left to market competition among services.
Users don't generally care or review a third party service's choice of e.g.
web server proxy, and the choice of CA is likely to belong in a similar
bucket.

-- Eric