Is this still accurate? I'll mark it as 'Verified' and hold it for update.
Note: I'm stripping the addresses on these a little - [email protected] is bouncing, and Ben isn't Sec AD currently. Oh and the chairs have to approve posts with more than a few addresses listed.... Deb On Thu, Feb 24, 2022 at 1:30 PM Jacob Hoffman-Andrews <[email protected]> wrote: > 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 <[email protected]> > *Sent:* Wednesday, February 9, 2022 7:25 AM > *To:* Benjamin Kaduk <[email protected]> > *Cc:* Richard Barnes <[email protected]>; Jacob Hoffman-Andrews <[email protected]>; > Daniel McCarney <[email protected]>; Roman Danyliw <[email protected]>; > [email protected] <[email protected]>; [email protected] < > [email protected]>; Yoav Nir <[email protected]>; IETF ACME < > [email protected]>; RFC Errata System <[email protected]> > *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 <[email protected]> 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 <[email protected]> > > > > 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 [email protected] https://www.ietf.org/mailman/listinfo/acme
