Re: [Acme] Mail regarding craft of hash for draft-ietf-acme-dns-account-challenge

Aaron Gable <aaron@letsencrypt.org> Mon, 05 February 2024 17:23 UTC

Return-Path: <aaron@letsencrypt.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 A7B42C14F68A for <acme@ietfa.amsl.com>; Mon, 5 Feb 2024 09:23:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, WEIRD_PORT=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org
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 l9UPcZrkfCYo for <acme@ietfa.amsl.com>; Mon, 5 Feb 2024 09:22:56 -0800 (PST)
Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com [IPv6:2001:4860:4864:20::30]) (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 79CE6C14F6A5 for <acme@ietf.org>; Mon, 5 Feb 2024 09:22:51 -0800 (PST)
Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-2196dd318feso1199077fac.2 for <acme@ietf.org>; Mon, 05 Feb 2024 09:22:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; t=1707153770; x=1707758570; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cHGE9gSB8tuzO/Z+nnf2YKr5o/r6lmpE6v7dfoBRV38=; b=NEnEIgXWoHp55hmH5vgkreg3BlS5qBlJToI9AnxLRgF47IFQcfVka0XuALzmnb7j+Y m/75OvEdy+0dzzRE4q1MNRnC6Xq837uRVmlSVPjle6mP8d1x3hhxldHLNyYv28dPOQyB 81yn4xXPy9NBOt8QJOu7qB0jvIjq7MApO1c9Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707153770; x=1707758570; 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=cHGE9gSB8tuzO/Z+nnf2YKr5o/r6lmpE6v7dfoBRV38=; b=nDbuc7w9hRKN2l16EUPmHcXIH8Mzxy3Hds7ue9Mg+CdUngEGy6Lqpg8gkcL/7auUi1 9Uq7fnQoStZhi3JHixr0sST5wIN0TZCE4qJXv/RrOnx1R/BqTLKiOPZnk0wu9KTbGhjf sTuZXB6xH8KXx/D1wOP5EV8P3TXIne1/hr5AquwrZ6uQXl03lb2AaWh4XObKIhUskZxF 9bS8pF+myjF9tAFS2gsv8AwEJQc62u5Ac21sviAOYWa1QSxZdwX9XHpnwhhdB9gqHMza vOBh3xGAqFntxoVHyT16+2sQlV6N9VD9Q29AwK9XGRqI3/M8ZchYHOx6Qnebl1a9O5Vl C3Rw==
X-Gm-Message-State: AOJu0YymHyXoTgQJWaEymGLoygdYYCJAg50i5feidygzMTvwCk2ALHnS rfV1r9P4oEUKVjIO1uw19CrSqW7xAijGM6/eKPFZVK37YmDocmnlepYg4rtMIbxVARodabDc6dl A6yJhK1k5cA0Cfc0yWK0eZnP07fBA8eNiJfKk6jB7qAvAwg+P
X-Google-Smtp-Source: AGHT+IFVmIJkwAlUq08ZYBuwMLKsEicquOaunjaf0vgBzkWSRDfebquKkcYJzPuLoAfBTi/1A2o70CUqUDYbIOz0rLY=
X-Received: by 2002:a05:6870:f153:b0:210:be09:2920 with SMTP id l19-20020a056870f15300b00210be092920mr384665oac.27.1707153770302; Mon, 05 Feb 2024 09:22:50 -0800 (PST)
MIME-Version: 1.0
References: <31b872f6-2ced-41b3-b22c-58ae89058570@gmail.com> <CAOG=JULrdnk4wYBKB-pfY4kXK=fF=ODi6PZ3wEj=zn7B4=nZXQ@mail.gmail.com> <ab7caac8-52b8-4416-9083-fe8533d51ec4@gmail.com> <CAOG=JUJvhTfN8b_giddEN0wH+3mf2Fh0j6FNij=qg=AXj+zzSA@mail.gmail.com>
In-Reply-To: <CAOG=JUJvhTfN8b_giddEN0wH+3mf2Fh0j6FNij=qg=AXj+zzSA@mail.gmail.com>
From: Aaron Gable <aaron@letsencrypt.org>
Date: Mon, 05 Feb 2024 09:22:39 -0800
Message-ID: <CAEmnErfLN6cN21_-pJPb-d7u+tPCd1Dw97d-GmDzFm9wfT4d=w@mail.gmail.com>
To: Amir Omidi <amir=40aaomidi.com@dmarc.ietf.org>
Cc: Seo Suchan <tjtncks@gmail.com>, acme@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000e62ce0610a5b695"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/JhyNam633cyuHfJgVqskKmkgc9w>
Subject: Re: [Acme] Mail regarding craft of hash for draft-ietf-acme-dns-account-challenge
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: Mon, 05 Feb 2024 17:23:00 -0000

And I think the implication here is that, if an ACME server responds on
multiple URIs and reflects those multiple URIs back to the client in the
Location header, then that server must also support hashes of those
multiple URIs when conducting DNS-ACCOUNT-01. Does that make sense?

Aaron

On Sat, Feb 3, 2024 at 1:18 PM Amir Omidi <amir=40aaomidi.com@dmarc.ietf.org>
wrote:

> No, the accountURL/URI that new-account returns is the only authoritative
> path. I'll make sure that it is spelled out in the RFC. If an acme client
> has an account key, it can use the method described here:
> https://datatracker.ietf.org/doc/html/rfc8555#section-7.3.1 to find the
> accountURL for that account.
>
> Since ACME does not define "what the ID part of an accountURL is", I'm
> much more inclined on just keeping the entire accountURL as the ID to be
> hashed for the challenge label.
>
> On Sat, Feb 3, 2024 at 3:59 AM Seo Suchan <tjtncks@gmail.com> wrote:
>
>> if it's stable but has multiple valid path (ex: acme-v1.ca.com and
>> acme-v2.ca.com) , would server need try for both subdomain and lookup
>> every possible valid path?
>> 2024-02-03 오전 1:35에 Amir Omidi 이(가) 쓴 글:
>>
>> From my understanding, under ACME we treat that entire accountURL as the
>> userID. So I think that URL will need to be stable.
>>
>> On Fri, Feb 2, 2024 at 2:36 AM Seo Suchan <tjtncks@gmail.com> wrote:
>>
>>> for some ACME servers they have multiple allowed acme endpoint domains,
>>> and server doesn't know what domain name client used to access its API
>>> duce don't have full accounturl that used to craft challenge subdomain:
>>>
>>> like boulder (what Let's encrypt uses) allows to accessed from mulitple
>>> path ex:
>>>
>>> "accountURIPrefixes": [
>>> "http://boulder.service.consul:4000/acme/reg/",
>>> "http://boulder.service.consul:4001/acme/acct/"
>>>          ]
>>>
>>>   , and pebble and smallstep do not have host in config but allow any ip
>>> or domain pointed to them and reflect them to create link to
>>> account/order/ect
>>>
>>> would only using userid part of accountURL (ExampleAccount) from
>>> https://example.com/acme/acct/ExampleAccount have problem? while it's
>>> trivial to extract from hash to accounturl as accountID was
>>> autoincrementing counter, but was there are so few large acme provider
>>> it was trivial to make rainbow table anyway.
>>>
>>> _______________________________________________
>>> 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
>