[Acme] dns-01 challenge limitations

Simon Ser <contact@emersion.fr> Fri, 11 September 2020 13:08 UTC

Return-Path: <contact@emersion.fr>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 71C1E3A08BD for <acme@ietfa.amsl.com>; Fri, 11 Sep 2020 06:08:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=emersion.fr
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EXZ4206WNZ9e for <acme@ietfa.amsl.com>; Fri, 11 Sep 2020 06:08:41 -0700 (PDT)
Received: from mail1.protonmail.ch (mail1.protonmail.ch []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DBC23A0816 for <acme@ietf.org>; Fri, 11 Sep 2020 06:08:41 -0700 (PDT)
Date: Fri, 11 Sep 2020 13:08:33 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emersion.fr; s=protonmail2; t=1599829718; bh=22v5QxuNCCfl6ZSjgoWMsL3gqvySirzbK47hu1tJgZg=; h=Date:To:From:Cc:Reply-To:Subject:From; b=SCwC1RIxQMoGBSkyFn6nxebjlbuy5EeKJOfr9XJOh/lbftjepYUTPEcjKRGAs7CZO vNT1oIJ6Nts2L7DM8ccpIVqYPLFVUv9rD6upaNF+aMNbAm88lhpsGtFhj8aviK5AV5 OpBTpY930xh4xNBDZJ4ah/BNYz6vtXTqwcxfkiK0f0ZWY4HbXgsrAgbiqbQlRo25lq YMBtjUxjHr4JLX5EOmQdV+OrresZ95Qlsm0tv2qRt4htPtoCs9stOnrnjEOfxpamsG tJ5rEFo63k8xTUkbU4JFRhUCnNwcxJr6i5eC2WtCKOPaPx5QPi94chVndkoOTpw2Q0 bGQNdcCob3qAw==
To: "acme@ietf.org" <acme@ietf.org>
From: Simon Ser <contact@emersion.fr>
Cc: "Matthew.Holt@gmail.com" <Matthew.Holt@gmail.com>
Reply-To: Simon Ser <contact@emersion.fr>
Message-ID: <uu-OR5wP1b7svN1Rxems1U8_axHG7M8M9_kYqTBVyhQFxqrddppvhasyxKtLQ-4AZkrbBWhJ_9V-Xs8mQBK5E4smP4_1vANgZazIwicsbq0=@emersion.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/w8sqjRuWclcsMsCOQR9PfCGvczY>
Subject: [Acme] dns-01 challenge limitations
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 11 Sep 2020 13:08:44 -0000

Hi all,

I've been working on an ACME client acting as a TLS termination proxy. In order
to retrieve wildcard certificates from the Let's Encrypt ACME servers, support
for the dns-01 challenge is required.

dns-01 requires the ACME client to complete the challenge by updating a DNS
record. This is bothersome because this often requires interacting with the
DNS registry operator. This is typically done via vendor-specific APIs, with
access control handled via vendor-specific means (tokens, public keys, etc).

I understand that it's difficult for ACME clients to prove that they are
authorized to obtain wildcard certificates. However, have other alternatives
been considered?

For instance, it would be possible to require users to add a short public key
in a DNS TXT record, then ask the ACME client to sign challenges with that key.
Something like this would significantly ease the development of ACME clients.

Are there specific reasons why dns-01 requires updating a DNS record?


Simon Ser

(CC mholt, I figured you might be interested in this for Caddy too)