The following errata report has been submitted for RFC6797, "HTTP Strict Transport Security (HSTS)".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid8153 -------------------------------------- Type: Technical Reported by: Eric Matthew Lawrence <[email protected]> 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) Instructions: ------------- This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -------------------------------------- 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]
