Re: [Acme] A single failed challenge should not invalidate an entire order

Benjamin Kaduk <kaduk@mit.edu> Thu, 20 August 2020 05:57 UTC

Date: Wed, 19 Aug 2020 22:57:42 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Matt Holt <matt@lightcodelabs.com>
Cc: Acme <acme@ietf.org>
Message-ID: <20200820055742.GJ92412@kduck.mit.edu>
References: <17403370784.10c140257139874.6544499691253662216@lightcodelabs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <17403370784.10c140257139874.6544499691253662216@lightcodelabs.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/HjqWncOQVL4XF62DLiW9Lk48-Sk>
Subject: Re: [Acme] A single failed challenge should not invalidate an entire order
Precedence: list

On Tue, Aug 18, 2020 at 02:16:12PM -0600, Matt Holt wrote:
> Hi,
> 
> After working heavily with ACME clients for the past 5 years (including "ACMEv1" before RFC 8555) I've come to realize some unfortunate ambiguities/inefficiencies in RFC 8555 with regards to server behavior after a challenge is attempted and failed by the client.
> 
> I recently implemented an RFC 8555-compliant client library in Go (https://github.com/mholt/acmez), and am convinced that a simple revision to the spec can both reduce costs for CAs *and* greatly simplify client implementations, if only the handling of failed challenges is revised.
> 
> My realizations are spelled out in this commit: https://github.com/mholt/acmez/commit/80adb6d5e64a3d36a56c58c66965b131ea366b8c
> 
> In summary: to get a certificate, a client creates an Order. The client then has to validate all Authorizations ("authzs"). For each Authorization, the client needs to successfully complete one of the offered Challenges. One successful challenge is sufficient to validate the authz. However, one failed challenge is apparently sufficient to invalidate the authz, and thus the entire Order. To try another challenge, the client then has to deactivate the other Authorizations (expensive) and create a new Order (also expensive), repeating the whole process. Instead, the client should be able to simply try the next challenge. In other words, a single failed challenge should not invalidate an authz; an authz should be "pending" until all offered challenges have failed or one has succeeded.

I believe that this part of the spec does not have strong specific
motivation, and in some sense stems from the last paragraph of the
"DISCUSS" section of my ballot position (see thread at
https://mailarchive.ietf.org/arch/msg/acme/YLYlBVdnv2VxllVCS8pF-QueLe8/) --
I just wanted clarity on what the actual behavior *was*, so that client and
server were in agreement.  It seems that we ended up at the "one failed
challenge fails everything" out of expediency w.r.t. minimizing textual
changes at the late stage, though I did not review the entire thread to
confirm that.

Presumably next steps on this front are to confirm that this is indeed the
source of the behavior, and then consider how the reised semantics might
be deployed (bearing in mind the continued need for client and server to
agree on what the semantics are for any given order).  It may be that a new
version would be needed :-/

-Ben

[Acme] A single failed challenge should not inval… Matt Holt
Re: [Acme] A single failed challenge should not i… Kas
Re: [Acme] A single failed challenge should not i… Benjamin Kaduk