Re: [Acme] [Technical Errata Reported] RFC8555 (6317)

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 03 January 2024 16:02 UTC

Return-Path: <ilariliusvaara@welho.com>
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 49223C14F6BB for <acme@ietfa.amsl.com>; Wed, 3 Jan 2024 08:02:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=ham autolearn_force=no
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 DkV3dnDXCycP for <acme@ietfa.amsl.com>; Wed, 3 Jan 2024 08:02:01 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2b.welho.com [83.102.41.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E55C14F6BA for <acme@ietf.org>; Wed, 3 Jan 2024 08:02:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id B774446D2A for <acme@ietf.org>; Wed, 3 Jan 2024 18:01:57 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id eayUNuB4qPg5 for <acme@ietf.org>; Wed, 3 Jan 2024 18:01:57 +0200 (EET)
Received: from LK-Perkele-VII2 (78-27-96-203.bb.dnainternet.fi [78.27.96.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 8993D287 for <acme@ietf.org>; Wed, 3 Jan 2024 18:01:56 +0200 (EET)
Date: Wed, 03 Jan 2024 18:01:56 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: acme@ietf.org
Message-ID: <ZZWE9Ni3hx0Cot1J@LK-Perkele-VII2.locald>
References: <20201023221949.B6009F4072C@rfc-editor.org> <CAGgd1OcBrF-W_rktuTyCNnC_8-tU2i5VQSLAUoc_mw-aZTSANQ@mail.gmail.com> <50047612-01A3-436F-A940-6CAE115F2AD9@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <50047612-01A3-436F-A940-6CAE115F2AD9@gmail.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/xSvyg6_WRDi6hyjqNeSb5qG5CUc>
Subject: Re: [Acme] [Technical Errata Reported] RFC8555 (6317)
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: Wed, 03 Jan 2024 16:02:03 -0000

On Wed, Jan 03, 2024 at 11:13:01PM +0900, Seo Suchan wrote:
> While looks sensible I wonder if how many clients pulling on auth
> instead of challanges: Those client will pull without limit if this
> behavior applied to CA
>
> For example this client do watch auths status instead of challenge
> itself.
> https://github.com/diafygi/acme-tiny/blob/c29c0f36cedbca2a7117169c6a9e1f166c501899/acme_tiny.py#L151 

I would imagine most clients do that. The one that I have written
certainly does (I think it would timeout with "authorization status
stuck" error after 10min).

AFAIK, ACME does not even guarantee that challenges are fetchable.


And one does not have to deactivate authorizations in order to retry.
Just creating new order will either restart from scratch or resume
where one left off, depending on the CA.

Yes, one would need autotimeouting blacklist for clients that can
try multiple methods, but I do not think that is hard (at least
compared to stuff like handling the three different concurrent
order race conditions).


The only reasons I know to deactivate authorizations:
- Getting rid of zombie auths that fail CAA validationmethods.
- Dropping authority to reduce damage on key compromise (explicit
  clear-all would be better for this purpose).




-Ilari