RFC Errata
RFC 6797, "HTTP Strict Transport Security (HSTS)", November 2012
Source of RFC: websec (app)
Errata ID: 8153
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Matthew Lawrence
Date Reported: 2024-10-18
Rejected by: Francesca Palombini
Date Rejected: 2024-10-29
Section 8.1.1 says:
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.
It should say:
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: <websec@ietf.org>.