Subject: [Acme] [Technical Errata Reported] RFC8555 (5771)

From: RFC Errata System <[email-masked]>
Date: Tue, 2 Jul 2019 07:04:00 -0700 (PDT)

The following errata report has been submitted for RFC8555,
"Automatic Certificate Management Environment (ACME)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5771

--------------------------------------
Type: Technical
Reported by: Rob Stradling <[email-masked]>

Section: 7.1.1

Original Text
-------------
Clients access the directory by sending a GET request to the
directory URL.

Corrected Text
--------------
Clients access the directory by sending a GET request to the directory
URL.  Before making a request to any URL from the directory, the client
MUST evaluate whether the directory object is still fresh according to
the Cache-Control header(s) received when that directory object was
accessed.  If no Cache-Control header(s) were received, the client MUST
act as if "Cache-Control: no-cache" was received.  If the directory
object is no longer fresh, the client MUST access the directory again
(by sending another GET request to the directory URL) and then use the
updated directory object.

Notes
-----
The original text is underspecified, because it doesn't say how long a directory remains valid.  A server should be able to update its directory (e.g., to add support for newAuthz, to update the termsOfService URL, etc) without having to worry about clients holding on to stale directory objects.
Whilst in practice many clients tend to re-fetch the server's directory object frequently, I think that it's unwise to leave this to chance.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8555 (draft-ietf-acme-acme-18)
--------------------------------------
Title               : Automatic Certificate Management Environment (ACME)
Publication Date    : March 2019
Author(s)           : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
Category            : PROPOSED STANDARD
Source              : Automated Certificate Management Environment
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 2 Jul 2019 14:37:48 +0000

Isn't that corrected text part of the standard specified behavior for HTTP?  Clients could also use If-Modified-Since, right?

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 2 Jul 2019 10:45:11 -0700

I'm in favor of this change in spirit, but it's pretty substantive and 
will actually do the wrong thing with some existing deployments. For 
instance, https://acme-v02.api.letsencrypt.org/directory currently has:

Cache-Control: max-age=0, no-cache, no-store

Which under this language would require clients to refetch the directory 
before every request. Definitely Let's Encrypt should fix that, but 
given that RFCs are meant to reflect "rough consensus and running code," 
I'm reluctant to make such a potentially breaking change to running code 
in an errata. I also feel a little uneasy at adding a MUST that is 
currently violated by every implementation that exists.

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 3 Jul 2019 08:45:40 +0200

+1

> Am 02.07.2019 um 19:45 schrieb Jacob Hoffman-Andrews <[email-masked]>:
> 
> I'm in favor of this change in spirit, but it's pretty substantive and will actually do the wrong thing with some existing deployments. For instance, https://acme-v02.api.letsencrypt.org/directory currently has:
> 
> Which under this language would require clients to refetch the directory before every request. Definitely Let's Encrypt should fix that, but given that RFCs are meant to reflect "rough consensus and running code," I'm reluctant to make such a potentially breaking change to running code in an errata. I also feel a little uneasy at adding a MUST that is currently violated by every implementation that exists.
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Rob Stradling <[email-masked]>
Date: Wed, 3 Jul 2019 09:20:48 +0000

On 02/07/2019 15:37, Salz, Rich wrote:
> Isn't that corrected text part of the standard specified behavior for HTTP?

I don't think so.  IINM, HTTP caching only comes into play when a client 
sends a subsequent HTTP request message that may (or may not) be 
satisfied by a cached HTTP response message.

"Clients access the directory by sending a GET request to the directory 
URL" does not require the client to ever send a subsequent HTTP request 
message to the directory URL.

> Clients could also use If-Modified-Since, right?

Good point.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 3 Jul 2019 12:14:26 +0000

A client that follows caching shouldn't send a new request if the cache-control headers on the first response direct it not to, right?

    Good point.

Then maybe the errata could just be
	Clients SHOULD use an If-Modified-Since header to get more effective caching.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 3 Jul 2019 13:43:21 +0000

> A client that follows caching shouldn't send a new request if the cache-control headers on the first response direct it not to, right?

Right, but the prerequisite is that the client explicitly wants to 
obtain a fresh (or at least unexpired) HTTP response message.  If that's 
not the case, then HTTP caching doesn't come into play, because HTTP 
itself doesn't come into play.

ISTM that once an ACME client has extracted a directory object from an 
HTTP response message, then both HTTP and HTTP caching are no longer in 
play.  The client is now only dealing with a directory object, not an 
HTTP response message.  (From Jacob's message, I get the impression that 
this is the prevailing understanding).

> 	Clients SHOULD use an If-Modified-Since header to get more effective caching.

I think that's a useful optimization suggestion, but I don't think it 
addresses the issue.

The idea behind the erratum is to force HTTP caching rules to apply to 
directory objects, so that servers can update their directory objects 
and expect clients to take note.

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 4 Jul 2019 10:09:43 +0200

> Am 03.07.2019 um 15:43 schrieb Rob Stradling <[email-masked]>:
> 

Is this a theoretical concern or do you have examples where current clients cache directory information that would harm a server update?

Cheers, Stefan

---

From: Rob Stradling <[email-masked]>
Date: Thu, 4 Jul 2019 16:08:43 +0000

I believe it's a theoretical concern at this point.

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Thu, 4 Jul 2019 09:24:40 -0700

> On Jul 2, 2019, at 07:04, RFC Errata System <[email-masked]> wrote:
> 
> If no Cache-Control header(s) were received, the client MUST
> act as if "Cache-Control: no-cache" was received.

If this is a MUST, the server should be sending it, perhaps.

> If the directory object is no longer fresh, the client MUST access the directory again

Unless the server sent a 304 response, wouldn’t the client just have gotten the object contents in the first request?

Ask

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 4 Jul 2019 16:26:13 +0000

>    I believe it's a theoretical concern at this point.
  
I believe the combination of this, the possibility of If-Modified-Since, and the view of some in the HTTP community believe it should be handled there, see https://github.com/httpwg/http-extensions/issues/840, means that we should reject this.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 11 Jul 2019 09:48:07 +0000

> I believe the combination of this, the possibility of If-Modified-Since, and the view of some in the HTTP community believe it should be handled there, see https://github.com/httpwg/http-extensions…

Hi Rich.  Whilst I still worry that it's not sufficiently obvious that 
directory objects are mutable, I accept that the consensus is to reject 
this proposed erratum.