[websec] [Errata Rejected] RFC6797 (5372)

RFC Errata System <rfc-editor@rfc-editor.org> Tue, 29 October 2024 14:20 UTC

To: csaavedra@igalia.com, Jeff.Hodges@PayPal.com, collin.jackson@sv.cmu.edu, ietf@adambarth.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20241029142035.9AEDD7F9E1@rfcpa.rfc-editor.org>
Date: Tue, 29 Oct 2024 07:20:35 -0700
Message-ID-Hash: SS247NAHMXETBMFX4QNPCHXWSQRYADWJ
CC: francesca.palombini@ericsson.com, iesg@ietf.org, websec@ietf.org, rfc-editor@rfc-editor.org
Precedence: list
Subject: [websec] [Errata Rejected] RFC6797 (5372)
Archived-At: <https://mailarchive.ietf.org/arch/msg/websec/b_Zw8rb3sPy9bXa-7lc3GzOQDAk>

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

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Claudio Saavedra <csaavedra@igalia.com>
Date Reported: 2018-05-29
Rejected by: Francesca Palombini (IESG)

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.

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

--------------------------------------
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] [Errata Rejected] RFC6797 (5372) RFC Errata System