I agree with James' reading. The intent was to allow HTTP->HTTPS redirects during validation, and that is common practice today. The errata makes the language a little clearer around that, so I vote "hold for document update." ________________________________ From: James Kasten <jdkas...@umich.edu> Sent: Wednesday, February 9, 2022 7:25 AM To: Benjamin Kaduk <ka...@mit.edu> Cc: Richard Barnes <r...@ipv.sx>; Jacob Hoffman-Andrews <j...@eff.org>; Daniel McCarney <c...@letsencrypt.org>; Roman Danyliw <r...@cert.org>; deco...@nsa.gov <deco...@nsa.gov>; debcool...@gmail.com <debcool...@gmail.com>; Yoav Nir <ynir.i...@gmail.com>; IETF ACME <acme@ietf.org>; RFC Errata System <rfc-edi...@rfc-editor.org> Subject: Re: [Technical Errata Reported] RFC8555 (6843)
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 <ka...@mit.edu<mailto:ka...@mit.edu>> 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 <jdkas...@umich.edu<mailto:jdkas...@umich.edu>> > > 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
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
