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