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

Eric Mill <eric@konklone.com> Thu, 17 December 2015 22:41 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1121B2FE6 for <acme@ietfa.amsl.com>; Thu, 17 Dec 2015 14:41:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JKf2735-sBo for <acme@ietfa.amsl.com>; Thu, 17 Dec 2015 14:41:25 -0800 (PST)
Received: from sasl.smtp.pobox.com (pb-smtp0.int.icgroup.com [208.72.237.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15FCC1B2C8D for <acme@ietf.org>; Thu, 17 Dec 2015 14:41:25 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 74B75357D3 for <acme@ietf.org>; Thu, 17 Dec 2015 17:41:23 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=MYNllRpMu5pcRKq5LW4Ug4GRV2Q=; b=hIfEnn 4bzTcqdvgBCbcQcjMVGnZgYUSHeur6+ywePnpjcnEybLpky9D8PofdBSy0AMVBF/ fY9idIAp13MlaJbArVRFQwU1XlUC30//oB2Ilau1LSsSSdNTDdxUiaG9ae2SsGbg aWvLVkCbpapfl1Zd1LPVorBgGuZn5XtuC4J+w=
Received: from pb-smtp0.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp0.pobox.com (Postfix) with ESMTP id 6AFA6357D2 for <acme@ietf.org>; Thu, 17 Dec 2015 17:41:23 -0500 (EST)
Received: from mail-ig0-f175.google.com (unknown [209.85.213.175]) (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 0C7EE357D0 for <acme@ietf.org>; Thu, 17 Dec 2015 17:41:23 -0500 (EST)
Received: by mail-ig0-f175.google.com with SMTP id m11so22513667igk.1 for <acme@ietf.org>; Thu, 17 Dec 2015 14:41:22 -0800 (PST)
X-Received: by 10.50.49.109 with SMTP id t13mr6451703ign.89.1450392082297; Thu, 17 Dec 2015 14:41:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.2.6 with HTTP; Thu, 17 Dec 2015 14:40:42 -0800 (PST)
In-Reply-To: <20151217081948.153cafa35132a31a44794cb7@andrewayer.name>
References: <CANBOYLWRn_k1LoMx3pgQx=0spM8VQMXen8DuOx44ksBtWjdHUA@mail.gmail.com> <20151217081948.153cafa35132a31a44794cb7@andrewayer.name>
From: Eric Mill <eric@konklone.com>
Date: Thu, 17 Dec 2015 17:40:42 -0500
X-Gmail-Original-Message-ID: <CANBOYLU9HgD+-Dz=LbKaEBNfnPJAF+e=SsLS8vDwOPf3jup8+Q@mail.gmail.com>
Message-ID: <CANBOYLU9HgD+-Dz=LbKaEBNfnPJAF+e=SsLS8vDwOPf3jup8+Q@mail.gmail.com>
To: Andrew Ayer <agwa@andrewayer.name>
Content-Type: multipart/alternative; boundary=047d7bdc1234d9bcc205271fb8ff
X-Pobox-Relay-ID: 4C77703A-A50F-11E5-A2AF-6BD26AB36C07-82875391!pb-smtp0.pobox.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/OmE9yG-yOHUekSOYTRVSgfwe6N8>
Cc: acme@ietf.org
Subject: Re: [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 22:41:27 -0000

On Thu, Dec 17, 2015 at 11:19 AM, Andrew Ayer <agwa@andrewayer.name> wrote:

> On Thu, 17 Dec 2015 02:23:20 -0500
> Eric Mill <eric@konklone.com> 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.
>

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.


>
> > 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 :-)
>

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

-- Eric


>
> Regards,
> Andrew
>



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