The following errata report has been submitted for RFC6797, "HTTP Strict Transport Security (HSTS)".
-------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5372 -------------------------------------- Type: Technical Reported by: Claudio Saavedra <[email protected]> Section: 8.1 Original Text ------------- 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. Corrected Text -------------- 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. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can 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 Area : Applications Stream : IETF Verifying Party : IESG _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
