[Acme] Potential issues with dns-persist-01

zandoodle <maxoscarhearnden@gmail.com> Sun, 05 April 2026 01:46 UTC

Return-Path: <maxoscarhearnden@gmail.com>
X-Original-To: acme@mail2.ietf.org
Delivered-To: acme@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 0FB95D68C4CB for <acme@mail2.ietf.org>; Sat, 4 Apr 2026 18:46:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1775353586; bh=tBdlxDJS+Kvb5ybYBfJ8242Q8cGBSacv/8JCiAqWDMo=; h=From:Date:Subject:To; b=eA+GQ5dloOPBlJ2vvFVVMQAUNkumRhn/Be2FSJVloq2lQSqqLehij70/lJldtOsQu BlqsDjlIbNRdjXCq6rLq8MpmTgUTNGO+boKgDJJGEWBRBMrgatjETdnPumHG8Ni98y KCY4jfeTodz0cUKzgjt5bqOwbL43ANP9xw2TDGpA=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmAQaezVsCyZ for <acme@mail2.ietf.org>; Sat, 4 Apr 2026 18:46:25 -0700 (PDT)
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 9F641D68C4C4 for <acme@ietf.org>; Sat, 4 Apr 2026 18:46:25 -0700 (PDT)
Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-358d80f60ccso1813119a91.3 for <acme@ietf.org>; Sat, 04 Apr 2026 18:46:25 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1775353585; cv=none; d=google.com; s=arc-20240605; b=EzqixZx2sJGDNZvtC7Yh3Su044IL9O/CxDTRLthOS097GPrrVoQCPtBv/Axmy+SSg+ 5yuDKzXs129an6qXQ8PKa/4j6+w46fBJAoustbw6GluZVhvyILIZF7XBe9WwAlv7fZVl LIv33cSUgrNTxvrxyAKeSCtNOaQlwhJ8EYHjxn0tGxH94VhiF4uE+tW1kceNeGzmIBk3 YTwW1+iXT7klI8TlsrcuNu1dHjnCjqBZwbJAFPmdwwABhABHiwlO0RkaNE2pucc+3pvB rpVGXhtp3UERxd2LXm5wW5aP+yf9jVEuTenAMHGIJaltCPQp3YSk8INpR2EhCeq0wbZ6 CLMQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=M4PsMtD/FL1f6btfIp8Fsidb4XRzwbw63asRFkJpzzg=; fh=FsstuwMttWLQ3Or/hON/k6d0sP4hWjEB5KnC48Ftt34=; b=PxUmeizLlLgwbZCl0yZNIzPPIDLL5PffD89LQj/XlcKhFYPKH4092MiCmaJ+SCR205 VFB8nY/TSclJ2lVOpt546xdwHKXOXo4N8tTfen5dDOEkN0OGdy3xJuaaeIxk4Ai8gKrb XhnVJWHh/irJruiSliAnfmCcr/5baffUswwvLSCVZS0IuYHzuNmXL+oqSLXWW1lTNQv4 8wVIMpOadgq1R5S4M2f2CRj+v3wX+CoIeEk5mTo/S8pTmRRSvTaB5Wb0t0vpYfiyAFKf tRlgtdaDkVnHpN8YY5zBNR1Uw8v5IjEW82b9sv+SVKJBgREzBSOdD+FZQjdc6zFQYxXH bR6Q==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775353585; x=1775958385; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=M4PsMtD/FL1f6btfIp8Fsidb4XRzwbw63asRFkJpzzg=; b=dIC/KlgavHPojcIW0YqvxTh1nSFcpdkAdIiFkiYaxEC3+N3ZQqAzqp5gJe8IWnq8N3 fNM+d0XTUfhnSuMhqfD7mbqDNrpr/stWORWHAEqlOROWYiDZaoUJjNqh9HGuR8TVqmaj 9srYKrMIzWTKvCkC5V9TKMTNXiwQZe4lcTFyO+X7YQKsBGgnrMe8lQo3Qpix2Jz7BFhz BI97k+sWKsYqJA2qysfxVI73RwH9U5DhMMGI+TwlTWhkvuHhfvTUYSOBgEz/QhydWIj4 ie2HiH1fvGnIezb9F4Q2MFyoScpsShxpfH70MQsK7Xrv5eKelaZ0biJh/OtXCcuuOM4U iZuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775353585; x=1775958385; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=M4PsMtD/FL1f6btfIp8Fsidb4XRzwbw63asRFkJpzzg=; b=C6e5fHa9mK7Y8YvGmH1YlmECzk2q4h4MI45XpFg8KYkGzzQfnSdZH3c6E8RAb0oVOi zGXi77CvStkr2zEbVNmq/5wvA8WlRK3zjj8cLbwKi2ZQa1ErA60XxXj0RKxr1zGy2iiL VIdpJISu+Mc2d8Y9K5O15GwxPcgHd6ca7Txz0d8jb/W650DdVEaMHEIlj+R50TUTXABz BFVqVBM///22WuysmcMVTkOZlUmsYjw5E7F1h4cVls5w2R02B1paf9/PO+HM1S2xe+wR n4djHabmRbgGeSKmViAz/edlXc7PoGJkXbeuGO0FjU8S2mWT3rIA1mtfehPYiTHF6lYB fYuw==
X-Gm-Message-State: AOJu0YyA24mlNExKXeUX2n1QQdqkcy1imizTFAiwx6BV321CdCeYYSnD KSA/cHyfMFEfHRT3dnDpfxvQB/zlzPFl0hXLhCW121P6daZ5iHzUrcMexk9+F/78xYTGC32VYZl parUBDsVzQzXiPzi4jml3yoBglqPXmRte6Dq8
X-Gm-Gg: AeBDievc2CAdRJY49yffz7t/7HNkT+BqpND6IVrFKZtMijg/T9Kr7dRdL92uZeIG9aa iCK29PwYz2m5NI0Oak1v42jTl4VO3sC0WoefAkZLhFaVcHISbxFrusUNg0HMph2eiBWXCAMIu2R qSyGstDtIJpvv7yFe1fGyF9Z0/5EA2VaFxh+wuS/+Y0Aln1m98paj5NZolUfpJ6wJReE1skeOWy bQuDh0nRbDc3bTjqYSUKUWdWC4A4zhaPI2U9awKuQ7xXGyywHGOpbSPqRSth/F4fJy3OWFvKabs R0hqBcQHDEE/BbfKHAvIKUbVLmVYivSZcOq1gK7Y3m4KRY/aapjtGg5oVkjUwuS2KGO2lsDb+g= =
X-Received: by 2002:a17:90b:3c85:b0:35b:e553:9cc2 with SMTP id 98e67ed59e1d1-35de6977d09mr7018829a91.26.1775353584653; Sat, 04 Apr 2026 18:46:24 -0700 (PDT)
MIME-Version: 1.0
From: zandoodle <maxoscarhearnden@gmail.com>
Date: Sun, 05 Apr 2026 02:46:13 +0100
X-Gm-Features: AQROBzAVij5uP_C9H-xUtqIrrOn_MnRiljMmo4bM5UYikPfbysDp5JvqHquXgl0
Message-ID: <CAFg2froJTxp+kT_VdSuNs9LVqFQhO-WJZBt=-qoVQO9c8M+=Xw@mail.gmail.com>
To: acme@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c39741064eacb73e"
Message-ID-Hash: 5FJXQXCWSHLNHMXJEW6Y4P5ZQO2I6YZH
X-Message-ID-Hash: 5FJXQXCWSHLNHMXJEW6Y4P5ZQO2I6YZH
X-MailFrom: maxoscarhearnden@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-acme.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Acme] Potential issues with dns-persist-01
List-Id: Automated Certificate Management Environment <acme.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/5FKQ3eYoilJBJqyoUFc5n9ierzM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Owner: <mailto:acme-owner@ietf.org>
List-Post: <mailto:acme@ietf.org>
List-Subscribe: <mailto:acme-join@ietf.org>
List-Unsubscribe: <mailto:acme-leave@ietf.org>

Hello, IETF participants

I'm somewhat concerned about the lack of binding between an account's key,
the challenge and the certificate request. This could lead to two new
similar attacks against a user's domain.

   1. An attacker sets up an ACME server and convinces the client to use
   it, the client is then provided the attacker's ACME account on the CA's
   domain and instructs the client to setup dns-persist-01 under the
   attacker's account.
   2. An attacker sets up an ACME server and convinces the client to use
   it, the client is then provided the attacker's ACME account for the
   attacker's domain and instructs the client to setup dns-persist-01 under
   the attacker's account. This requires that the certificate authority allows
   accounts to be created under the attacker's domain e.g. creating the
   account under the domain in the Host header field as done by Let's Encrypt.

dns-01, http-01 and tls-alpn-01 all have the client's ACME account's public
key as part of the challenge so the client's account and the account the
certificate authority is issuing to must be the same.

The first attack could be prevented by having the client by making a POST
request of some sort to the account URI which allows them to verify that
their key is valid for the account.

The second attack could be prevented by the certificate authority by
verifying the account-uri is both https and on a domain they control when
verifying/offering the dns-persist-01 challenge or by restricting the
domains under which an account can be created.

Both attacks could also be prevented by having the client check that the
directory, account URI and issuer domain name have the same domain name
however this might be overly restrictive.

The issuer domain name might not be sufficient protection as the server
instructs the client as to what it should be. Given the strong security
requirements for the issuer domain names including DNSSEC but with no
requirement to resolve the domain names, maybe the authors intended to put
metadata at the issuer domain names.