[Acme] Assisted-DNS challenge type
Jacob Hoffman-Andrews <jsha@eff.org> Tue, 23 January 2018 01:09 UTC
Return-Path: <jsha@eff.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4D5124235 for <acme@ietfa.amsl.com>; Mon, 22 Jan 2018 17:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level:
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org
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 CrfBCYO6Enhx for <acme@ietfa.amsl.com>; Mon, 22 Jan 2018 17:09:54 -0800 (PST)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1DE1201F2 for <acme@ietf.org>; Mon, 22 Jan 2018 17:09:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:To:Subject:From; bh=xosJgmIsVaWgBLljsVVcFLqHT71WOtBb4Gfeen3XRqo=; b=QKDvkK5HTfFYTVvWBk/n3PnQL5sv34a2vhJ6mzOxltH/qXKQHUdt9ExnGdswtMR/duWIMGl4hTcGTFe3XdxIgRRn3FL7NDFYF0hOT/e0SAPT71CIRa9anQmNpQhUQZlqN1G3LbEUcJNvVPH0SkjMtVDmtZsvZNuKBdZlZPoCP4c=;
Received: ; Mon, 22 Jan 2018 17:09:49 -0800
From: Jacob Hoffman-Andrews <jsha@eff.org>
To: "acme@ietf.org" <acme@ietf.org>
Message-ID: <bbaea6b0-65dc-9dff-0a23-e55e6eebb580@eff.org>
Date: Mon, 22 Jan 2018 17:09:53 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/6_j3fecaxIgwNTpJ3693U_n0Kec>
Subject: [Acme] Assisted-DNS challenge type
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 23 Jan 2018 01:09:57 -0000
Inspired by a thread on Let's Encrypt's community forum (https://community.letsencrypt.org/t/suggestion-lets-encrypt-operated-txt-only-dns-hosting-for-dns-challenges/50399/1), I'd like to propose a new challenge type, "assisted-dns-01". The existing DNS challenge is good for a number of reasons, but it has a couple of key problems: - It's hard to automate, and many DNS providers may offer no automation at all. - Automating it may mean putting DNS credentials on a web frontend, which may increase risk. To fix that, the CA could assist the user by providing narrowly-scoped DNS hosting: It would serve only TXT records used in validating DNS challenges. The CA instruct subscribers to delegate the _acme-challenge subdomain to a subdomain of the CA's hosted DNS domain. For instance, if a subscriber has account number 1234, the CA would say: Please deploy a CNAME record like so: _acme-challenge.example.com. CNAME 1234.challenges.ca.example.net. The assisted-dns-01 challenge would then be validated like dns-01, except: As the first step in validation, the CA would deploy the expected TXT value at 1234.challenges.ca.example.net. Then the CA would continue to look up "TXT _acme-challenge.example.com." In a way, fetching final TXT record would be a formality: the CA could in theory stop once it saw the CNAME pointed at the right location, though most likely abiding by the terms of the BRs would require following the formal lookup steps. This challenge has the big advantage that subscribers only need to do a one-time CNAME setup, and renewals can be reliably automated without requiring that renewing systems have permission to update DNS. In effect, the CNAME record would act like a long-term delegation permitting the CA to issue continuously for the base domain. The challenge object would contain a field telling the client what the CNAME target should be. Based on this, clients can check the existing DNS and prompt a user to add the CNAME if needed, or continue automatically if it's already present. Example assisted-dns-01 challenge: { "type": "assisted-dns-01", "token": "abc123", "cnameTarget": "1234.challenges.ca.example.net.", } If people think this challenge type has merit, my proposal is that it be part of an extension document, not part of the core ACME doc. Credit to Joona Hoikkala, Matt Nordhoff, and forum user @_az for helping to develop this concept.
- [Acme] Assisted-DNS challenge type Jacob Hoffman-Andrews
- Re: [Acme] Assisted-DNS challenge type Alex Zorin
- Re: [Acme] Assisted-DNS challenge type Zach Shepherd
- Re: [Acme] Assisted-DNS challenge type Ilari Liusvaara
- Re: [Acme] Assisted-DNS challenge type Niklas Keller
- Re: [Acme] Assisted-DNS challenge type Thomas Lußnig
- Re: [Acme] Assisted-DNS challenge type Jörn Heissler
- Re: [Acme] Assisted-DNS challenge type Tim Hollebeek
- Re: [Acme] Assisted-DNS challenge type Thomas Lußnig
- Re: [Acme] Assisted-DNS challenge type Matthew D. Hardeman
- Re: [Acme] Assisted-DNS challenge type Alan Doherty