Re: [Acme] DNS-ACCOUNT-01 Updates

Q Misell <q@as207960.net> Fri, 12 May 2023 18:43 UTC

Return-Path: <q@as207960.net>
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 8B4E2C15C501 for <acme@ietfa.amsl.com>; Fri, 12 May 2023 11:43:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=as207960.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-z1zOeiaX7o for <acme@ietfa.amsl.com>; Fri, 12 May 2023 11:43:46 -0700 (PDT)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB82DC15152E for <acme@ietf.org>; Fri, 12 May 2023 11:43:46 -0700 (PDT)
Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-50bd2d7ba74so92080113a12.1 for <acme@ietf.org>; Fri, 12 May 2023 11:43:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=as207960.net; s=google; t=1683917023; x=1686509023; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=VOkx0FneK+N4qdvCiTQQwJH9weWIYx8No8cKS7TXDWM=; b=N9AKGX91ZutlYIhY6K/kLyPs/OOEQ+7KQXd5SEbVHwK8NtyK4hcQLhiCbMwS9OQuUF 8r7nH/TTUp3/+mHw40gZ342uBWV6xg+5hJO8WWLqmO81xVSJesmIP0oQgi74thtnMLlq 6sDEA1Jc7WzgnPGOVe8TFvEXmu9CBFVWmKjnIaRyw6JC4gkhK01aKplFqtu6zRRlpBY7 /CaZIE6YjOPEZWd3OLpiaOp/x9zNsJu9d3yJEq6f+ahfrLVqD4U3nEwZnyuAFPW05bd9 B+JZIh43qfLp3mkLyDZCfmVl6UsD8CSBMcY4miq1RoRR4jiWu0+uTuLBwYfbfLo1izM6 DRUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683917023; x=1686509023; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=VOkx0FneK+N4qdvCiTQQwJH9weWIYx8No8cKS7TXDWM=; b=hWNZMJIS5lhcH0I5Rvx2fz8pNGCuidvPuzLY5pMnAKQ0SSocELSHhohPU8PU5+nNhO xz81PevtC6sv3cqim5+lgKXp/9s6Ag+GE37cGAV7H7YzwuDIaeP31lndlBar/eWxfl5e FF+8jnKjwRSJSu1QI7blHRpEh17545s9T2CUoqNaPfqznUBRfpEMMB90YhYCS9LyVLNr cApn1J+Zv0knEckDuz7joOzN/Fq5qdzC7LFfJuqfICynq2eg9/QNJp9QZkl/mESgF2T2 mNs3smQXqs7a9HIVxcVdztuG28+eybmlK/Ci068KFBR9NffrcelGetTD1nKNtvXZmQQH kKAQ==
X-Gm-Message-State: AC+VfDznDexXkNUZw6Db4EotJI/7H77SOgq1k7Wa2kkIbsAJM/CO8MsV rbSxJAORD/41KHqhinam+f//0/2pBhUOfOq680Xpxw==
X-Google-Smtp-Source: ACHHUZ5PveFrOY03BFHf1J1Yjfi7GFJf4Xr+6/vEr+GZYERsCSQmrtTLbVGOaoWlsbwamAjwQuFc7iwme5b0gx4IMKM=
X-Received: by 2002:a17:907:1622:b0:965:aa65:233f with SMTP id hb34-20020a170907162200b00965aa65233fmr24051703ejc.2.1683917023596; Fri, 12 May 2023 11:43:43 -0700 (PDT)
MIME-Version: 1.0
References: <22209596-7C4D-42F4-9415-98F106047C33@gmail.com> <CAEmnErcRPMn9SiBNHtS0-oVEXVJCR+c9eXavGXMU6NLgoakwsA@mail.gmail.com>
In-Reply-To: <CAEmnErcRPMn9SiBNHtS0-oVEXVJCR+c9eXavGXMU6NLgoakwsA@mail.gmail.com>
From: Q Misell <q@as207960.net>
Date: Fri, 12 May 2023 19:43:07 +0100
Message-ID: <CAMEWqGsXZGmP2VXcEemxM9T+2+zAppY2orP6wXyW+1xCeHuviA@mail.gmail.com>
To: Aaron Gable <aaron=40letsencrypt.org@dmarc.ietf.org>
Cc: Antonios Chariton <daknob.mac@gmail.com>, IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000005e6fb05fb837ce9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/pJzt45cN-r-GaLxQERB5LeBZ2u8>
Subject: Re: [Acme] DNS-ACCOUNT-01 Updates
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.39
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, 12 May 2023 18:43:51 -0000

I'm also in favour of calling it DNS-02. I highly doubt there will be many
(if any) versions of challenges beyond version 1. It makes more sense to me
to read DNS-02 and DNS challenge type 2, not a upgraded edition of version
1.
------------------------------

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>.
ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>.
UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524.
South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are
registered trademarks in the UK, under № UK00003718474 and № UK00003718468,
respectively.


On Fri, 12 May 2023 at 17:58, Aaron Gable <aaron=
40letsencrypt.org@dmarc.ietf.org> wrote:

> For what it's worth, I'm in favor of calling it DNS-02. Despite your
> totally correct descriptions of the disadvantages of this new method, I
> *do* still view it as a generally-improved version of DNS-01. It's
> obviously backwards-incompatible, hence the new major version number, but
> it is generally an improvement that creates more flexibility for clients at
> little cost. I also find the name "DNS-ACCOUNT-01" to be slightly
> unfortunate, as no "dns accounts" are involved -- it makes sense once you
> understand the method, but the name gives little to no hint to how the
> method works on its own.
>
> Aaron
>
> On Thu, May 11, 2023 at 4:52 PM Antonios Chariton <daknob.mac@gmail.com>
> wrote:
>
>> Hello everyone,
>>
>> I’m sending this e-mail to the list to update you all on DNS-ACCOUNT-01
>> and the news we have since the presentation in IETF 116.
>>
>> You can all help by reviewing the text[0], these updates, and sharing
>> your opinion in this thread here!
>>
>> The CA/B Forum 2023-05-04 meeting discussed DNS-ACCOUNT-01 and three
>> things came out of it, as it is evident in the minutes[1]:
>>
>> 1) This method is compatible with the CA/B Forum Baseline Requirements
>> that are binding for all WebPKI CAs, specifically section 3.2.2.4.7 for
>> agreed-upon change to a DNS record. This means that CAs can start using
>> this standard immediately, and there are no other dependencies. The design
>> seemed to be good in its current version. Obviously, quick changes to their
>> CP/CPS may be required, but this is not blocking and unilateral.
>>
>> 2) There is a documented need for various usecases where this challenge
>> would help, from several stakeholders, and evidence that it could be
>> beneficial to the ecosystem and its development. It allows ACME to be used
>> in even more situations where more traditional and non-automatable methods
>> had to be relied upon.
>>
>> 3) There was a suggestion to rename this challenge to DNS-02. This is
>> something that we had rejected back when we created this challenge, however
>> it has been suggested several times, so we are happy to reconsider this. It
>> may be the right choice.
>>
>> There’s no published precedence of what -02 means right now, so it’s
>> unclear whether it is a second option, or a next generation / improved
>> challenge. We never planned to replace DNS-01 with our challenge, we always
>> intended to add more options, and cover more use cases. Here are some
>> technical “disadvantages” of this work vs DNS-01:
>>
>> 1) ACME Clients need to calculate the correct label. Although we provide
>> the algorithm, a bash script, and test vectors, anecdotal data from ISRG
>> suggest that some clients still mess things up (implementing RFC 8555), so
>> this is another value where this may happen. An easy solution here would be
>> to share the expected label with the client, but we decided against this to
>> protect against cross-protocol attacks, and also to protect the client
>> against an ACME server giving it arbitrary DNS records to change. If
>> clients calculate this independently, they don’t need to trust the server.
>>
>> 2) The label is longer, so some very very long domain names may no longer
>> work. Since this is 17 characters longer than DNS-01’s label, anything
>> approaching the various limits (of DNS, etc.) may break. For example, if in
>> DNS-01 you end up with a 236-253 character domain name to check for the TXT
>> record, then DNS-ACCOUNT-01 will go over the limit and won’t work. We don’t
>> consider this to be a major problem. We’re also not aware of many domain
>> names in the 236-253 character range.
>>
>> 3) If an ACME client for whatever reason loses access to the ACME
>> account, this “set and forget” DNS label now has to change. Things would
>> break here with other standards too (if you need an EAB token, you can’t
>> create a new account anyways, if you limit the ACME account via CAA
>> records, you can’t issue, etc.) but DNS-ACCOUNT-01 would just add to the
>> things that would have to be taken into account. We don’t currently
>> consider this a huge issue, but if you think it could be, let us know.
>>
>> As you can see, these 3 tradeoffs above had to be made, to ensure we can
>> cover more use cases. We think these are good tradeoffs for an additional
>> ACME challenge, but perhaps they are not for an “upgraded” one.
>>
>> What do you think about the naming? Do you perceive “DNS-02” as an
>> improved version, or as a second option? We are happy to rename this to
>> DNS-02 and we have no plans of breaking any ACME server or client already
>> using DNS-01 :)
>>
>> Thanks for reading through this, and I am happy to hear your thoughts and
>> get reviews on the draft, so we can move further with this work.
>>
>> Antonios Chariton
>> Independent Contributor ;)
>>
>> - - -
>> Links:
>>
>> [0] :
>> https://archive.cabforum.org/pipermail/validation/2023-May/001892.html
>> [1] : https://daknob.github.io/draft-todo-chariton-dns-account-01/
>> _______________________________________________
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>