[websec] [Errata Rejected] RFC6797 (8153)

[RFC Errata System <[e-mail]>]

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 <[e-mail]>
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: <[e-mail]>.

--------------------------------------
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