RFC Errata
Found 5 records.
Status: Rejected (5)
RFC 6797, "HTTP Strict Transport Security (HSTS)", November 2012
Source of RFC: websec (app)
Errata ID: 4075
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Lawrence
Date Reported: 2014-08-08
Rejected by: Barry Leiba
Date Rejected: 2014-08-11
Section 14 says:
Without the "includeSubDomains" directive, HSTS is unable to protect such Secure-flagged domain cookies.
It should say:
Without the "includeSubDomains" directive, HSTS is unable to protect
such Secure-flagged domain cookies.
Even with the "includeSubDomains" directive, the unavailability of
an "includeParent" directive means that an Active MITM attacker can
perform a cookie-injection attack against an otherwise
HSTS-protected victim domain.
Consider the following scenario:
The user visits https://sub.example.com and gets a HSTS policy with
includeSubdomains set. All subsequent navigations to
sub.example.com and its subdomains will be secure.
An attacker causes the victim's browser to navigate to
http://example.com. Because the HSTS policy applies only to
sub.example.com and its superdomain matches, this insecure
navigation is not blocked by the user agent.
The attacker intercepts this insecure request and returns a
response that sets a cookie on the entire domain tree using a
Set-Cookie header.
All subsequent requests to sub.example.com carry the injected
cookie, despite the use of HSTS.
Notes:
To mitigate this attack, HSTS-protected websites should perform a background fetch of a resource at the first-level domain. This resource should carry a HSTS header that will apply to the entire domain and all subdomains.
--VERIFIER NOTES--
This is a valid issue, but not suitable for the errata system. The websec working group is discussing handling this with a short document to update RFC 6797.
Errata ID: 5204
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Dilßner
Date Reported: 2017-12-13
Rejected by: Francesca Palombini
Date Rejected: 2024-10-29
Section 6.1.2 says:
includeSubDomains
It should say:
include-sub-domains or includesubdomains
Notes:
- In Section 6.1 the Strict-Transport-Security is defined as follows:
Strict-Transport-Security = "Strict-Transport-Security" ":" [ directive ] *( ";" [ directive ] )
- valueless Directive "includeSubDomains" is defined as a optional directive
- a directive is definied as followed:
directive = directive-name [ "=" directive-value ]
- so "includeSubDomains" is only a directive-name which is defined as "token"
- according to "[RFC2616], Section 2.2" a token is any octet from 0 - 127 except CTL's (octets 0 - 31 + 127) and separators which NOT exclude '-' (octet 45)
So all Fine? Yes, BUT at [RFC6797], Section 6.1 the "overall reuqirements for directives", Rule 3 defines:
3. Directive names are case-insensitive.
And there is no other specification in Section 6.1.2 or has a IANA policy definition [RFC5226] like it is defined for additionals.
- That means the "directive-name" includeSubDomains is "case-insensitive"!
The "case-sensitive" camelized directive-name is misleading, because of many other definitions with "-", like seen in all examples or in Header Field itself.
- to aware the clear understanding the "directive definition" in section 6.1.2 and ALL occurences needs to be renamend.
the minimum of renaming is "includesubdomains" OR "INCLUDESUBDOMAINS", but this is not readable anymore.
- So it should be renamed like other valuless directives for Example the "schemes-source's" directives at "Content-Security-Policy", which means:
"include-sub-domains"
Best Regards
Nick
--VERIFIER NOTES--
That is true, directive names are case insensitive, which means that, except for possibly misleading the reader, includeSubDomains and includesubdomains are equivalent. Making this change might be considered an editorial fix, however I do not believe this is necessary. Changing the name to "include-sub-domains" can't be done via an erratum, and would need a publishing a consensus document and an update to this rfc.
Errata ID: 5372
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Claudio Saavedra
Date Reported: 2018-05-29
Rejected by: Francesca Palombini
Date Rejected: 2024-10-29
Section 8.1 says:
o Update the UA's cached information for the Known HSTS Host if
either or both of the max-age and includeSubDomains header field
value tokens are conveying information different than that already
maintained by the UA.
It should say:
o Update the UA's cached information for the Known HSTS Host.
Notes:
Section 8.1 states:
Update the UA's cached information for the Known HSTS Host if either
or both of the max-age and includeSubDomains header field value
tokens are conveying information different than that already
maintained by the UA.
The way I understand this is that if a HSTS host keeps sending the same values to a conforming client, this should not update the information cached and hence the cached information will expire after max-age seconds have passed since the _first_reception_ of this header.
However, section 11.2 states:
The "constant value into the future" approach can be accomplished by
constantly sending the same max-age value to UAs.
For example, a max-age value of 7776000 seconds is 90 days:
Strict-Transport-Security: max-age=7776000
Note that each receipt of this header by a UA will require the UA to
update its notion of when it must delete its knowledge of this Known
HSTS Host.
This seems to contradict what I quoted from section 8.1. If the server constantly sends a max-age of 7776000 and includeSubDomains is not changed (which is implicit in the example), then by 8.1 the cache
information won't be updated.
I believe that the desired implementation behavior is as described in 11.2, that is, UA must update the cached information, regardless of whether either of the max-age or includeSubDomains header field values are different from what is already maintained by the UA.
--VERIFIER NOTES--
I believe this comes from a misinterpretation of the following text:
"conveying information different than that already maintained"
The text covers the case this report describes, and is consistent with what described in 11.2 and how the reporter reads it, i.e. even if the "max-age" value is the same, as the age is evolving, the _information_ on its expiracy is in fact different. As such, this report is rejected.
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>.
Errata ID: 8186
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joe Hildebrand
Date Reported: 2024-11-22
Rejected by: Orie Steele
Date Rejected: 2024-12-02
Section 6.1 says:
directive-value = token | quoted-string
It should say:
directive-value = token / quoted-string
Notes:
The "directive-value" production should use a "/" for alternatives, not a "|". See RFC 5234, which should be referenced by this spec but isn't. This is an editorial nitpick.
--VERIFIER NOTES--
RFC6797 relies on the BNF from RFC2616 which uses the "|" for alternatives,
see https://datatracker.ietf.org/doc/html/rfc2616#section-2.1