[websec] [Technical Errata Reported] RFC6797 (8153)

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

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

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