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

Phillip Hallam-Baker <hallam@gmail.com> Thu, 17 December 2015 21:05 UTC

Return-Path: <hallam@gmail.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 DFE501B30B3 for <acme@ietfa.amsl.com>; Thu, 17 Dec 2015 13:05:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 BjgmaXyjqE5R for <acme@ietfa.amsl.com>; Thu, 17 Dec 2015 13:05:05 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700121B30B2 for <acme@ietf.org>; Thu, 17 Dec 2015 13:05:05 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id 68so36687237pfc.1 for <acme@ietf.org>; Thu, 17 Dec 2015 13:05:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=LgbwMZQQKIQOy1Fybj7uNTKOQxhbT+6T37L8tGaWQmo=; b=I7P7BA4EDuzagwuwzzI5L4G4ql7ppLNvEthOvrXj7W54sP6WVYwLMQTr6JeF5Yt47T mpl3Gc7lY5YflxMlqb8L2HJsN25VGPhui1OIF3nsjwBSIB6jQPYJLG1p664Vnn8K1ybi y6FY2b4WP0dRpurGVshyNPQSWk9UejpD6Cs3YCT+jushkvlJvYj8q56XjyzVg5gCQUs/ 40AlQ0aUpBmKlYZIi000/6WbTWjTftCLWGXi+iGhiO46Ze0Tn9hXh+fvicHSI21IeLVB nEBtnYMlbekml+TqFinCIPRPlGm4tFZiquDNtAjrNGDokWP6CJ7Qbg5BAulN2Pfue3s5 NEqw==
X-Received: by 10.98.72.199 with SMTP id q68mr17442067pfi.140.1450386305081; Thu, 17 Dec 2015 13:05:05 -0800 (PST)
Received: from mail.outlook.com (ec2-52-24-139-88.us-west-2.compute.amazonaws.com. [52.24.139.88]) by smtp.gmail.com with ESMTPSA id by2sm17677199pab.20.2015.12.17.13.05.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Dec 2015 13:05:02 -0800 (PST)
Date: Thu, 17 Dec 2015 21:05:01 +0000 (UTC)
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>, Andrew Ayer <agwa@andrewayer.name>
Message-ID: <994C5976EA09B556.6A5BB9CE-8E8F-47E8-9439-3B38538FD768@mail.outlook.com>
In-Reply-To: <CA+9kkMArP3f-rAcSBz4+Jxet2PBqUdLQt4z3qrFMhw45+0XGTA@mail.gmail.com>
References: <CANBOYLWRn_k1LoMx3pgQx=0spM8VQMXen8DuOx44ksBtWjdHUA@mail.gmail.com> <20151217081948.153cafa35132a31a44794cb7@andrewayer.name> <CA+9kkMArP3f-rAcSBz4+Jxet2PBqUdLQt4z3qrFMhw45+0XGTA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_5412_1483030097.1450386301841"
X-Mailer: Outlook for iOS and Android
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/Xv5Aw9EQlrZWCPipKZ67Gs_X-kI>
Cc: acme@ietf.org, Eric Mill <eric@konklone.com>
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 21:05:08 -0000

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" <ted.ietf@gmail.com> wrote:










On Thu, Dec 17, 2015 at 8:19 AM, Andrew Ayer <agwa@andrewayer.name> wrote:
On Thu, 17 Dec 2015 02:23:20 -0500

Eric Mill <eric@konklone.com> 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.  
​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

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



_______________________________________________

Acme mailing list

Acme@ietf.org

https://www.ietf.org/mailman/listinfo/acme