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

Eric Mill <eric@konklone.com> Thu, 17 December 2015 07:24 UTC

Return-Path: <eric@konklone.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7F4D11B2A6B for <acme@ietfa.amsl.com>; Wed, 16 Dec 2015 23:24:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id c7B2kgHUrT03 for <acme@ietfa.amsl.com>; Wed, 16 Dec 2015 23:24:03 -0800 (PST)
Received: from sasl.smtp.pobox.com (pb-smtp0.int.icgroup.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40B51B2A6F for <acme@ietf.org>; Wed, 16 Dec 2015 23:24:03 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown []) by pb-smtp0.pobox.com (Postfix) with ESMTP id 178B8303AA for <acme@ietf.org>; Thu, 17 Dec 2015 02:24:02 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; s=sasl; bh=g+BS+n V9RXOKejFxupCzhcDCE8s=; b=jZhDeoQsMwhamIrExOctayvR0IxNRUmnYCdtgC mMBdK5xcSq1LupApeSxwzXYqqYO+e8e3XC0AeDdR8RBqEXX4aWUjO3SWP1zqsgAx M7Z5gl44n6z5Rx5wWfkD3s8KSU9AQHxiluKSQDmGYLQvzeCVOonHjBsX8Xj3f02g hnVj4=
Received: from pb-smtp0.int.icgroup.com (unknown []) by pb-smtp0.pobox.com (Postfix) with ESMTP id 0FF87303A9 for <acme@ietf.org>; Thu, 17 Dec 2015 02:24:02 -0500 (EST)
Received: from mail-ig0-f181.google.com (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp0.pobox.com (Postfix) with ESMTPSA id 9BE08303A2 for <acme@ietf.org>; Thu, 17 Dec 2015 02:24:00 -0500 (EST)
Received: by mail-ig0-f181.google.com with SMTP id to4so5687461igc.0 for <acme@ietf.org>; Wed, 16 Dec 2015 23:24:00 -0800 (PST)
X-Received: by with SMTP id kb1mr2161443igb.89.1450337039974; Wed, 16 Dec 2015 23:23:59 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 16 Dec 2015 23:23:20 -0800 (PST)
From: Eric Mill <eric@konklone.com>
Date: Thu, 17 Dec 2015 02:23:20 -0500
X-Gmail-Original-Message-ID: <CANBOYLWRn_k1LoMx3pgQx=0spM8VQMXen8DuOx44ksBtWjdHUA@mail.gmail.com>
Message-ID: <CANBOYLWRn_k1LoMx3pgQx=0spM8VQMXen8DuOx44ksBtWjdHUA@mail.gmail.com>
To: acme@ietf.org
Content-Type: multipart/alternative; boundary=089e01183f801289c5052712e8d0
X-Pobox-Relay-ID: 24A1CFD6-A48F-11E5-ACDC-6BD26AB36C07-82875391!pb-smtp0.pobox.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/QlY1VfWjwIGy-tpz5xjxPEYiBBo>
Subject: [Acme] DNS challenge spec doesn't support CNAME model
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 07:24:06 -0000


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 [_

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

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

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

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