Re: [Acme] dns-01 challenge limitations

Simon Ser <> Sun, 13 September 2020 09:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A01F83A0B76 for <>; Sun, 13 Sep 2020 02:13:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FS_A5yP_hXto for <>; Sun, 13 Sep 2020 02:13:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 844203A0B75 for <>; Sun, 13 Sep 2020 02:13:22 -0700 (PDT)
Date: Sun, 13 Sep 2020 09:13:14 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=protonmail2; t=1599988400; bh=bmhPYNXvZN5JxeAAJUYz3LCZjx80Y3QWmPMzfTXLImY=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=U2uOQMksaUiBSf43xMvNgSqRXipVHYFN9b4r5SBlt2NpcY4BBdGNgKmoUqQBL0UVJ gDckc5Jb5tIUprl+ApiNmLakoKM/o1lt4eb33iVU8PMi4PIX7LrCgZcxDC5YluTF2g nd1rXrdgtQy3x2Ljg3fxd+qZnpJUstrsdbv6V3EaeKGp6Q5r0v6OOXrUtf11xyuheu p526bBitda/bAnt41I7wWI2NKZWBAV6avlO3oLMQOBm0Z1vB4kaORv/3q7iW4WmL+J ren/vnY/KbjChDPm3Z1btjdOYZ9yMZdZ9G8HaDvE/MYYOcyQ+nTJaPWFffXZfg79jN /IuP73OQPHCBw==
To: Ryan Sleevi <>
From: Simon Ser <>
Cc: Philipp Junghannß <>, "" <>, "" <>
Reply-To: Simon Ser <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Acme] dns-01 challenge limitations
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 13 Sep 2020 09:13:25 -0000

> On Friday, September 11, 2020 4:26 PM, Ryan Sleevi <> wrote:
> > On Fri, Sep 11, 2020 at 9:28 AM Philipp Junghannß <> wrote:
> >
> > > problem is obviously also the CA/Browser Forum has certain requirements,
> > > and I guess having access to some kind of direct verification at the time
> > > of issue might be probably one of these.
> >
> > This is the correct answer.
> >
> > While the IETF can certainly explore developing voluntary standards for
> > other methods, the ability for CAs to adopt these methods is limited by CAs
> > customers: the browsers and operating systems that include and use CAs to
> > validate domain names on their behalf.
> >
> > The explicit goal by several browser/OS vendors is to obtain a fresh proof
> > of control over a domain, and reduce/eliminate any caching or reuse.
> > Delegation (by keys or persistent records) is definitely an area of
> > expressed concern.

My take is that in theory it's an understandable goal, but that in practice,
this detoriorates security.

In practice, ACME clients:

1. Have a static, long-term token stored in their configuration file
2. The token is powerful and can update any DNS record in the zone

How come browser/OS vendors are fine with this, but not with a different
approach involving an ACME-specific key?

Sure, since this happens behind the ACME/DNS protocols and is an implementation
detail, this isn't ACME's responsibility anymore. However, because browsers/OS
vendors have this requirement of not allowing delegated proofs, we end up with
a worse situation than necessary.

Ultimately, ACME clients need a way to update DNS records to solve the dns-01
challenge. Ignoring and pushing the problem down to the DNS operators does not
fix the root cause.

If an ACME client needs to prove that they have authority over a DNS zone, they
will need some kind of authorization/key/token or similar, be it
vendor-specific or not. Why not acknowlege this fact and come up with a
reasonable standard?

> > I think the suggest of more uniform APIs for managing DNS is very much in
> > line with those goals, and would help far more than ACME.

Yes, no matter what ACME requires, a standardized API to update DNS records
would be nice. Michael Richardson suggested that such an API (or a subset of)
already exists (via secure DDNS), but isn't supported by most DNS operators
(even if supported by some DNS daemons).

Establishing a new standard involves talking to existing DNS operators, and ask
them to implement the new standard. For them, the new standard wouldn't have a
high enough return on investment: ACME clients already volunteer to implement
each and every proprietary API. Even if a good standard ticking the checkboxes
of RFC 5218 existed, I don't think it would be successful (no "Positive Net
Value" for DNS operators).