The following errata report has been rejected for RFC6797, "HTTP Strict Transport Security (HSTS)".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid8153 -------------------------------------- Status: Rejected Type: Technical Reported by: Eric Matthew Lawrence <[email protected]> Date Reported: 2024-10-18 Rejected by: Francesca Palombini (IESG) Section: 8.1.1 Original Text ------------- 8.1.1. Noting an HSTS Host - Storage Model If the substring matching the host production from the Request-URI (of the message to which the host responded) syntactically matches the IP-literal or IPv4address productions from Section 3.2.2 of [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host. Otherwise, if the substring does not congruently match a Known HSTS Host's domain name, per the matching procedure specified in Section 8.2 ("Known HSTS Host Domain Name Matching"), then the UA MUST note this host as a Known HSTS Host, caching the HSTS Host's domain name and noting along with it the expiry time of this information, as effectively stipulated per the given max-age value, as well as whether the includeSubDomains directive is asserted or not. See also Section 11.2 ("HSTS Policy Expiration Time Considerations"). The UA MUST NOT modify the expiry time or the includeSubDomains directive of any superdomain matched Known HSTS Host. A Known HSTS Host is "expired" if its cache entry has an expiry date in the past. The UA MUST evict all expired Known HSTS Hosts from its cache if, at any time, an expired Known HSTS Host exists in the cache. Corrected Text -------------- 8.1.1. Noting an HSTS Host - Storage Model If the substring matching the host production from the Request-URI (of the message to which the host responded) syntactically matches the IP-literal or IPv4address productions from Section 3.2.2 of [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host. If the substring matching the host production from the Request-URI (of the message to which the host responded) syntactically matches the string "localhost" or ends with ".localhost", then the UA MAY choose not to note this host as a Known HSTS host. Otherwise, if the substring does not congruently match a Known HSTS Host's domain name, per the matching procedure specified in Section 8.2 ("Known HSTS Host Domain Name Matching"), then the UA MUST note this host as a Known HSTS Host, caching the HSTS Host's domain name and noting along with it the expiry time of this information, as effectively stipulated per the given max-age value, as well as whether the includeSubDomains directive is asserted or not. See also Section 11.2 ("HSTS Policy Expiration Time Considerations"). The UA MUST NOT modify the expiry time or the includeSubDomains directive of any superdomain matched Known HSTS Host. A Known HSTS Host is "expired" if its cache entry has an expiry date in the past. The UA MUST evict all expired Known HSTS Hosts from its cache if, at any time, an expired Known HSTS Host exists in the cache. Notes ----- Localhost is already a secure context and unambiguously refers to the local machine, for which transport-level security is not required. Because multiple software packages from independent vendors commonly run on localhost (and web developers commonly use localhost for testing), but HSTS is applied to ALL ports on a given host, the setting of HSTS rules for localhost can cause unexpected and difficult to avoid functional errors. Firefox does not apply HSTS to Localhost requests and a corresponding change is pending for Chromium (see https://crbug.com/41251622) --VERIFIER NOTES-- Your proposed change is not in scope for errata reports, which are meant to collect errors in the documents, things that were actual errors at publication and that would have been fixed at that time had the working group or document authors noticed them -- they were just missed. What you've reported changes the intended behaviour (adding normative text), and is not an erratum. This sort of change needs to be achieved through a consensus document, possibly an update to this document. I would suggest that you re-formulate this suggestion and post it to the websec mailing list, which is still open: <[email protected]>. -------------------------------------- RFC6797 (draft-ietf-websec-strict-transport-sec-14) -------------------------------------- Title : HTTP Strict Transport Security (HSTS) Publication Date : November 2012 Author(s) : J. Hodges, C. Jackson, A. Barth Category : PROPOSED STANDARD Source : Web Security Stream : IETF Verifying Party : IESG _______________________________________________ websec mailing list -- [email protected] To unsubscribe send an email to [email protected]
