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

[James Kasten <[e-mail]>]

Hi Ben,

Thanks for the response.

Following redirects for the http-01 challenge is already recommended by the
RFC's Section 8.3
<https://datatracker.ietf.org/doc/html/rfc8555#section-8.3>.
```
The server SHOULD follow redirects when dereferencing the URL.
Clients might use redirects, for example, so that the response can be
provided by a centralized certificate management server.  See
Section 10.2 <https://datatracker.ietf.org/doc/html/rfc8555#section-10.2>
for security considerations related to redirects.
```

Section 10.4 <https://datatracker.ietf.org/doc/html/rfc8555#section-10.4>
also contains an additional warning or emphasis regarding redirects with
SSRF, so I included a generic reference to both for completeness.
```
However, if the attacker first sets the domain to one
they control, then they can send the server an HTTP redirect (e.g., a
302 response) which will cause the server to query an arbitrary URL.
...
```

I believe this errata resolves ambiguity in the current text. Popular ACME
CAs and clients are relying upon "http-01" challenge redirects from HTTP to
HTTPS today. As an author who is familiar with the origin of this text, my
intent was for it to read as "must be initiated" rather than "must be
completed" over HTTP. I am happy to hear others' thoughts. I do believe
deviating from this interpretation is extremely harmful for the HTTPS
ecosystem which I can elaborate on if desired.

Best,
James

On Tue, Feb 8, 2022 at 10:54 PM Benjamin Kaduk <[e-mail]> wrote:

> Is there particular guidance from Section 10 that you had in mind to
> justify the following of the redirect?
>
> In light of the role of errata reports as indicating errors in the
> specification at the time it was published, I think the processing options
> here are either "hold for document update" or "rejected".
>
> -Ben
>
> On Tue, Feb 08, 2022 at 12:23:23PM -0800, RFC Errata System wrote:
> > 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/eid6843
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: James Kasten <[e-mail]>
> >
> > Section: 8.3
> >
> > Original Text
> > -------------
> > Because many web servers
> > allocate a default HTTPS virtual host to a particular low-privilege
> > tenant user in a subtle and non-intuitive manner, the challenge must
> > be completed over HTTP, not HTTPS.
> >
> >
> > Corrected Text
> > --------------
> > Because many web servers
> > allocate a default HTTPS virtual host to a particular low-privilege
> > tenant user in a subtle and non-intuitive manner, the challenge must
> > be initiated over HTTP, not HTTPS.
> >
> > Notes
> > -----
> > Completing the entire http-01 challenge over HTTP is unnecessary. The
> threat of default HTTPS virtual hosts is remediated by "initiating" the
> http-01 challenge over HTTP. Validation servers which redirect from HTTP to
> HTTPS should be permitted following the rest of the guidance within Section
> 10, Security Considerations.
> >
> > 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
>