| Internet-Draft | HSTS Tracking Prevention | May 2025 |
| Bingler | Expires 30 November 2025 | [Page] |
As mentioned in Section 14.9 of [RFC6797], it's possible for entities in control of multiple hosts to encode arbitrary data within a user agent's HSTS policy store. This data can later be retrieved and could be used to identify users.¶
This document proposes a change to the user agent processing model of [RFC6797] to enable user agents to employ tracking mitigation methods.¶
This note is to be removed before publishing as an RFC.¶
Source for this draft and an issue tracker can be found at https://github.com/sbingler/hsts-tracking-prevention-spec.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 30 November 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
HTTP Strict Transport Security (HSTS), [RFC6797], improves security for users by allowing a host to tell the user agent that it should only ever be accessed over a secure connection.¶
However, the design of HSTS allows for servers to abuse its state caching in order to set and retrieve arbitrary data, potentially for the purposes of tracking a user around the web. Section 14.9 of [RFC6797] warns of this possibility but does not discuss prevention.¶
This document offers some minor modifications to Section 8 of [RFC6797] that allows for user agents to implement a way to prevent tracking of the user.¶
It also touches on potential implementations.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Tracking prevention could take one of a few forms:¶
Prevent servers from setting tracking data.¶
Prevent servers from retrieving tracking data.¶
Make correlating data between sites infeasible.¶
The first could be implemented by ignoring Strict-Transport-Security response headers from tracking hosts. This requires user agents to ignore otherwise valid Strict-Transport-Security response headers if the user agent has reason to believe that header would be used for tracking purposes.¶
The second could be implemented by not upgrading URI for tracking hosts. This requires user agents to not upgrade otherwise eligible URIs to "https" if the user agent has reason to believe the upgraded URI would be used for tracking purposes.¶
The third could be implemented by partitioning the HSTS policy store by the current site the user is on. This would force any server interested in tracking a user to set new data on every site, making it infeasible to correlate the user’s visits between sites via HSTS upgrades.¶
To allow user agents the option of preventing hosts they believe are tracking the user from setting HSTS data Section 8.1.1 of [RFC6797] should be changed as follows:¶
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...¶
should be modified to include¶
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 UA has reason to believe this host intends to set tracking data then the UA MAY not note this host as a Known HSTS Host. Otherwise, if the substring...¶
To allow user agents the option of preventing hosts they believe are tracking the user from retrieving HSTS data Section 8.3 of [RFC6797] should be changed as follows:¶
1. Extract from the URI any substring described by the host component of the authority component of the URI. 2. If the substring is null, then there is no match with any Known HSTS Host.¶
should be modified to include¶
1. Extract from the URI any substring described by the host component of the authority component of the URI. 2. If the UA has reason to believe this host intends to retrieve tracking data then the UA MAY abort this algorithm. 3. If the substring is null, then there is no match with any Known HSTS Host.¶
Making data correlation infeasible for tracking servers could be implemented a number of ways, but a straightforward design would be to keep the HSTS policies of different sites separated, so that even if tracker.example is embedded into both site.example and othersite.example it cannot easily track users between those sites. Doing this is frequently referred to as partitioning.¶
This can be allowed by modifying the storage and indexing requirement of Section 5.3 of [RFC6797] to allow for partitioning of the HSTS policy Store.¶
UAs store and index HSTS Policies based strictly upon the domain names of the issuing HSTS Hosts. This means that UAs will maintain the HSTS Policy of any given HSTS Host separately from any HSTS Policies issued by any other HSTS Hosts whose domain names are...¶
Should be modified to include¶
UAs store and index HSTS Policies based strictly upon the domain names of the issuing HSTS Hosts. Note: UAs MAY decide to partition their HSTS policies by other inputs such as the top-level site the agent has been navigated to. In this case the UA should store and index HSTS Policies within that partition based strictly upon the domain names of the issuing HSTS Hosts. This means that UAs will maintain the HSTS Policy of any given HSTS Host separately from any HSTS Policies issued by any other HSTS Hosts whose domain names are...¶
Section 8.2 of [RFC6797] should receive a similar change¶
A given domain name may match a Known HSTS Host's domain name in one or both of two fashions: a congruent match, or a superdomain match. Alternatively, there may be no match. The steps below determine whether there are any matches, and if so, of which fashion:¶
Should be modified to include¶
A given domain name may match a Known HSTS Host's domain name in one or both of two fashions: a congruent match, or a superdomain match. Alternatively, there may be no match. Note: If the UA has decided to partition its HSTS Policies then the following algorithm MUST be performed only on HSTS Policies within the applicable partition. The steps below determine whether there are any matches, and if so, of which fashion:¶
Depending on the tracking prevention technique employed the UA may risk reducing the security of HTTP requests. Many UAs however implement some form of mixed content blocking and upgrading along with automatic upgrades of navigations to https top-level sites. These behaviors help limit any potential security decreases.¶
This document has no IANA actions.¶