One document matched: draft-ietf-websec-strict-transport-sec-14.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC.793 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY RFC.1035 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!--
<!ENTITY RFC.1983 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1983.xml">
-->
<!ENTITY RFC.2119 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC.2396 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2396.xml">
<!ENTITY RFC.2560 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2560.xml">
<!ENTITY RFC.2616 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!--
<!ENTITY RFC.2664 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2664.xml">
-->
<!ENTITY RFC.2818 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY RFC.3454 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3454.xml">
<!ENTITY RFC.3490 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3490.xml">
<!ENTITY RFC.3492 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3492.xml">
<!ENTITY RFC.3864 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3864.xml">
<!ENTITY RFC.3986 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC.4033 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC.4732 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4732.xml">
<!ENTITY RFC.4949 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC.5226 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC.5246 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC.5280 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC.5890 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
<!ENTITY RFC.5891 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5891.xml">
<!ENTITY RFC.5894 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5894.xml">
<!ENTITY RFC.5895 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5895.xml">
<!ENTITY RFC.5905 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5905.xml">
<!ENTITY RFC.6066 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml">
<!ENTITY RFC.6101 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6101.xml">
<!ENTITY RFC.6265 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6265.xml">
<!ENTITY RFC.6454 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6454.xml">
<!ENTITY RFC.6698 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!--
<!ENTITY I-D.draft-ietf-httpbis-p1-messaging-18 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-httpbis-p1-messaging-18.xml">
-->
<!--
<!ENTITY W3C.WD-html5-20100304 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml4/reference.W3C.WD-html5-20100304">
-->
<!ENTITY W3C.REC-html401-19991224 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-html401-19991224">
<!ENTITY W3C.REC-wsc-ui-20100812 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-wsc-ui-20100812.xml">
]>
<!-- PROCESSING INSTRUCTIONS -->
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes" ?>
<?rfc tocdepth="4"?>
<!--
This .xml file intended to be processed by xml2rfc
http://xml.resource.org/
source filename: draft-ietf-websec-strict-transport-sec-14.xml
-->
<rfc category="std" ipr="trust200902"
docName="draft-ietf-websec-strict-transport-sec-14">
<front>
<title>HTTP Strict Transport Security (HSTS)</title>
<author initials="J." surname="Hodges" fullname="Jeff Hodges">
<organization>PayPal</organization>
<address>
<postal>
<street>2211 North First Street</street>
<city>San Jose</city>
<region>California</region>
<code>95131</code>
<country>US</country>
</postal>
<email>Jeff.Hodges@PayPal.com</email>
</address>
</author>
<author initials="C." surname="Jackson" fullname="Collin Jackson" >
<organization>Carnegie Mellon University</organization>
<address>
<email>collin.jackson@sv.cmu.edu</email>
</address>
</author>
<author initials="A." surname="Barth" fullname="Adam Barth">
<organization>
Google, Inc.
</organization>
<address>
<email>ietf@adambarth.com</email>
<uri>http://www.adambarth.com/</uri>
</address>
</author>
<date day="29" month="Sep" year="2012"/>
<area>Applications</area>
<workgroup>WEBSEC Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
This specification defines a mechanism enabling web sites to
declare themselves accessible only via secure connections,
and/or for users to be able to direct their user agent(s) to
interact with given sites only over secure connections. This
overall policy is referred to as HTTP Strict Transport
Security (HSTS). The policy is declared by web sites via the
Strict-Transport-Security HTTP response header field, and/or by
other means, such as user agent configuration, for example.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="sec-intro">
<!--
<t>
[ Please discuss this draft on the WebSec@ietf.org
mailing list <xref target="WEBSEC"/>. ]
</t>
-->
<t>
The HTTP protocol <xref target="RFC2616" /> may be used over
various transports, typically the Transmission Control
Protocol (TCP). However, TCP does
not provide channel integrity protection, confidentiality, nor
secure host identification. Thus, the Secure Sockets Layer
(SSL) protocol <xref target="RFC6101"/>, and
its successor Transport Layer Security (TLS) <xref
target="RFC5246" />, were developed in order to provide
channel-oriented security, and are typically layered between
application protocols and TCP. <xref target="RFC2818" />
specifies how HTTP is layered onto TLS, and defines the
Uniform Resource Identifier (URI) scheme of
"https" (in practice however, HTTP user agents (UAs)
typically use either TLS or SSL3 depending upon a combination of
negotiation with the server and user preferences).
</t>
<t>
UAs employ various local security policies with respect to the
characteristics of their interactions with web resources
depending on (in part) whether they are communicating with a
given web resource's host using HTTP or
HTTP-over-a-Secure-Transport. For example, cookies (<xref
target="RFC6265" />) may be
flagged as Secure. UAs are to send such Secure cookies to
their addressed host only over a secure transport. This is
in contrast to non-Secure cookies, which are returned to the
host regardless of transport (although subject to other rules).
</t>
<t>
UAs typically announce to their users any issues with secure
connection establishment, such as being unable to validate a TLS
server certificate trust chain, or if a TLS server certificate is
expired, or if a TLS host's domain name appears incorrectly in
the TLS server certificate (see Section 3.1 of <xref
target="RFC2818" />).
Often, UAs enable users to elect to continue to interact with
a web resource's host in the face of such issues. This behavior is
sometimes referred to as "click(ing) through"
security <xref target="GoodDhamijaEtAl05" /> <xref
target="SunshineEgelmanEtAl09" />, and thus can be described
as "click-through insecurity".
</t>
<t>
A key vulnerability enabled by click-through insecurity is
the leaking of any cookies the web resource may be using
to manage a user's session. The threat here is that an attacker
could obtain the cookies and then interact with the legitimate
web resource while impersonating the user.
</t>
<t>
Jackson and Barth proposed an approach, in <xref
target="ForceHTTPS" />, to enable web resources
to declare that any interactions by UAs
with the web resource must
be conducted securely, and that any issues with establishing
a secure transport session are to be treated as fatal
and without direct user recourse. The aim is to prevent
click-through insecurity, and address other potential
threats.
</t>
<t>
This specification embodies and refines the approach proposed
in <xref target="ForceHTTPS" />.
For example, rather than using a cookie to convey policy
from a web resource's host to a UA,
it defines an HTTP response header field for this purpose.
Additionally, a web resource's host may declare its policy to apply
to the entire domain name
subtree rooted at its host name.
This enables HSTS to protect so-called "domain cookies", which
are applied to all subdomains of a given web resource's host name.
</t>
<t>
This specification also incorporates notions from <xref
target="JacksonBarth2008" /> in that policy is applied on an
"entire-host" basis: it applies to HTTP (only) over any TCP
port of the issuing host.
</t>
<t>
Note that the policy defined by this specification
is distinctly different than the "same-origin policy"
defined in "The Web Origin Concept" <xref target="RFC6454"/>.
These differences are summarized below in <xref
target="apdx-diff-same-origin-policy"/>.
</t>
<section anchor="intro-organization"
title="Organization of this specification">
<t>
This specification begins with an overview of the use cases, policy effects,
threat models, and requirements for HSTS (in <xref target="sctn-overview"/>).
Then, <xref target="sctn-conformance"/> defines conformance requirements.
The HSTS mechanism itself is formally specified
in <xref target="sctn-terminology"/> through <xref target="sec-iana-consid"/>.
</t>
</section>
<section title="Document Conventions">
<t>
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
This is a note to the reader. These are points that should be
expressly kept in mind and/or considered.
</t>
</list>
<!--
<list style="hanging" hangIndent="10">
<t hangText="Warning:">
This is how a warning is shown.
These are things that can have negative
downside risks if not heeded.
</t>
</list>
-->
<!--
<cref anchor="XXXn" source="JeffH">
Some of the
more major known issues are marked like this
(where "n" in "XXXn" is a number).
</cref>
-->
</t>
<!--
<t>
<cref anchor="TODOn" source="JeffH">
Things to fix
(where "n" in "TODOn" is a number).
</cref>
</t>
-->
</section> <!-- Document Conventions -->
</section> <!-- Introduction -->
<section anchor="sctn-overview" title="Overview">
<t>
This section discusses the use cases, summarizes the HTTP Strict
Transport Security (HSTS) policy, and continues with a
discussion of the threat model, non-addressed threats, and
derived requirements.
</t>
<section anchor="sctn-use-cases" title="Use Cases">
<t>
The high-level use case is a combination of:
</t>
<t>
<list style="symbols">
<t>
Web browser user wishes to interact with various web sites (some
arbitrary, some known) in a secure fashion.
</t>
<t>
Web site deployer wishes to offer their site in an
explicitly secure fashion for both their own, as well as
their users', benefit.
</t>
</list>
</t>
</section> <!-- sctn-use-cases -->
<section anchor="sctn-sts-policy-summary"
title="HTTP Strict Transport Security Policy Effects">
<t>
The effects of the HTTP Strict Transport Security
(HSTS) Policy,
as applied by a conformant UA in interactions with a web resource host
wielding such policy (known as an HSTS Host), are summarized as
follows:
</t>
<t>
<list style="numbers">
<!--
<t>
All insecure ("http") references to any TCP ports on a
HSTS Host are interpreted by the UA as secure connections
("https") at connection establishment time.
</t>
-->
<t>
UAs transform insecure URI references to an HSTS Host
into secure URI references before dereferencing them.
</t>
<t>
The UA terminates any secure
transport connection attempts upon any and all secure
transport errors or warnings.
<!-- This includes warnings or errors caused by a
HSTS Host presenting --> <!-- self-signed certificates. -->
<!-- fix for bug# 39 -->
<!-- a certificate matching a trusted certificate association
as denoted via the DANE protocol
<xref target="I-D.ietf-dane-protocol" />, or any other
form of self-signed certificate that does not chain to a
trust anchor in the UA or operating system CA root certificate
store. -->
</t>
</list>
</t>
</section> <!-- sctn-sts-policy-summary -->
<section anchor="sctn-threat-model" title="Threat Model">
<t>
HSTS is concerned with three threat classes: passive network
attackers, active network attackers, and imperfect web
developers. However, it is explicitly not a remedy for two
other classes of threats: phishing and malware. Addressed
and not addressed threats are briefly discussed below.
Readers may wish to refer to Section 2 of
<xref target="ForceHTTPS"/> for
details as well as relevant citations.
</t>
<section anchor="sctn-threats-addr" title="Threats Addressed">
<section anchor="sctn-psv-net-atkr" title="Passive Network Attackers">
<t>
When a user browses the web on a local wireless network
(e.g., an 802.11-based wireless local area network)
a nearby attacker can possibly eavesdrop on the user's
unencrypted Internet Protocol-based connections, such as
HTTP, regardless of whether or not the local wireless
network itself is secured <xref target="BeckTews09"/>.
Freely available wireless sniffing toolkits (e.g., <xref
target="Aircrack-ng"/>) enable such passive eavesdropping
attacks, even if the local wireless network is operating in
a secure fashion.
A passive network attacker using such tools can steal session
identifiers/cookies and hijack the user's web session(s), by
obtaining cookies containing authentication credentials
<xref target="ForceHTTPS"/>.
For example, there exist widely-available tools, such as
Firesheep (a web browser extension)
<xref target="Firesheep"/>, which
enable their wielder to obtain other local users' session cookies
for various web applications.
</t>
<t>
To mitigate such threats, some Web sites support, but usually
do not force, access using end-to-end secure transport
-- e.g., signaled through URIs constructed with the
"https" scheme <xref target="RFC2818" />. This
can lead users to believe that accessing such services
using secure transport protects them from passive
network attackers. Unfortunately, this is often not the
case in real-world deployments as session identifiers
are often stored in non-Secure cookies to permit
interoperability with versions of the service offered
over insecure transport ("Secure cookies" are those
cookies containing the "Secure" attribute
<xref target="RFC6265"/>). For example, if the session
identifier for a web site (an email service, say) is
stored in a non-Secure cookie, it permits an attacker to
hijack the user's session if the user's UA makes a single
insecure HTTP request to the site.
</t>
</section> <!-- sctn-psv-net-atkr -->
<section anchor="sctn-actv-net-atkr" title="Active Network Attackers">
<t>
A determined attacker can mount an active attack, either
by impersonating a user's DNS server or, in a wireless
network, by spoofing network frames or offering a
similarly-named evil twin access point. If the user is
behind a wireless home router, an attacker can attempt
to reconfigure the router using default passwords and
other vulnerabilities. Some sites, such as banks, rely
on end-to-end secure transport to protect themselves and their
users from such active attackers. Unfortunately,
browsers allow their users to easily opt-out of these
protections in order to be usable for sites that
incorrectly deploy secure transport, for example by
generating and self-signing their own certificates
(without also distributing their certification authority (CA)
certificate to their
users' browsers).
</t>
</section> <!-- sctn-actv-net-atkr -->
<section anchor="sctn-web-dvlp" title="Web Site Development and Deployment Bugs">
<t>
The security of an otherwise uniformly secure site (i.e.
all of its content is materialized via "https" URIs),
can be compromised completely by an active attacker
exploiting a simple mistake, such as the loading of a
cascading style sheet or a SWF (Shockwave Flash)
movie over an insecure
connection (both cascading style sheets and SWF movies
can script the embedding page, to the surprise of many
web developers, plus some browsers do not issue
so-called "mixed content warnings" when SWF files are
embedded via insecure connections). Even if the site's
developers carefully scrutinize their login page for
"mixed content", a single insecure embedding anywhere on
the overall site compromises the security of their login
page because an attacker can script (i.e., control) the
login page by injecting code (e.g., a script) into another, insecurely
loaded, site page.
</t>
<t>
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
"Mixed content" as used above (see also Section 5.3
in <xref target="W3C.REC-wsc-ui-20100812" />) refers
to the notion termed "mixed security context" in
this specification, and should not be confused with
the same "mixed content" term used in the context of
markup languages such as XML and HTML.
</t>
</list>
</t>
</section> <!-- sctn-web-dvlp -->
</section> <!-- sctn-threats-addr -->
<section anchor="sctn-threats-not-addressed" title="Threats Not Addressed">
<section anchor="sctn-phishing" title="Phishing">
<t>
Phishing attacks occur when an attacker solicits
authentication credentials from the user by hosting a
fake site located on a different domain than the real
site, perhaps driving traffic to the fake site by
sending a link in an email message. Phishing attacks can
be very effective because users find it difficult to
distinguish the real site from a fake site. HSTS is not a
defense against phishing per se; rather, it complements
many existing phishing defenses by instructing the
browser to protect session integrity and long-lived
authentication tokens <xref target="ForceHTTPS" />.
</t>
</section> <!-- sctn-phishing -->
<section anchor="sctn-malware" title="Malware and Browser Vulnerabilities">
<t>
Because HSTS is implemented as a browser security
mechanism, it relies on the trustworthiness of the
user's system to protect the session. Malicious
code executing on
the user's system can compromise a browser session,
regardless of whether HSTS is used.
</t>
</section> <!-- sctn-malware -->
</section> <!-- sctn-threats-not-addressed -->
</section> <!-- sctn-threat-model -->
<section anchor="sctn-reqs" title="Requirements">
<t>
This section identifies and enumerates various
requirements derived from the use cases and the threats
discussed above, and lists the detailed core requirements
HTTP Strict Transport Security addresses, as well as ancillary
requirements that are not directly addressed.
</t>
<section anchor="sctn-reqs-ovrl-req" title="Overall Requirement">
<t>
<list style="symbols">
<t>
Minimize, for web browser users and web site deployers, the risks
that are derived from passive and active network attackers,
web site development and deployment bugs, and insecure user actions.
</t>
</list>
</t>
<section anchor="sctn-reqs-core" title="Detailed Core Requirements">
<t>
These core requirements are derived from the overall
requirement, and are addressed by this specification.
</t>
<t>
<list style="numbers">
<!-- 1 -->
<t>
Web sites need to be able to declare to UAs that
they should be accessed using a strict security
policy.
</t>
<!-- 2 -->
<t>
Web sites need to be able to instruct UAs that
contact them insecurely to do so securely.
</t>
<!-- 3 -->
<t>
UAs need to retain persistent data about
web sites that signal strict
security policy enablement,
for time spans declared by the web sites.
Additionally, UAs need to cache the "freshest"
strict security policy information, in order to allow
web sites to update the information.
</t>
<!-- 4 -->
<t>
UAs need to re-write all insecure UA
"http" URI loads to use the
"https" secure scheme for those web sites
for which secure policy is enabled.
</t>
<!-- 5 -->
<t>
Web site administrators need to be able to signal
strict security policy application to subdomains of
higher-level domains for which strict security policy
is enabled, and UAs need to enforce such policy.
<vspace blankLines="1"/>
For example, both example.com and foo.example.com
could set policy for bar.foo.example.com.
</t>
<!-- 6 -->
<t>
UAs need to disallow security policy application to
peer domains, and/or higher-level domains, by domains
for which strict security policy is enabled.
<vspace blankLines="1"/>
For example, neither bar.foo.example.com nor
foo.example.com can set policy for example.com, nor
can bar.foo.example.com set policy for
foo.example.com. Also, foo.example.com cannot set
policy for sibling.example.com.
</t>
<!-- 7 -->
<t>
UAs need to prevent users from clicking-through
security warnings. Halting connection attempts in the
face of secure transport exceptions is acceptable. See
also <xref
target="sctn-ua-impl-adv-norecourse"/> "<xref
target="sctn-ua-impl-adv-norecourse" format="title"/>".
</t>
</list>
</t>
<t>
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
A means for uniformly securely meeting the first
core requirement above is not specifically addressed
by this specification (see <xref
target="sctn-sec-cons-boot"/> "<xref
target="sctn-sec-cons-boot"
format="title"/>"). It may be addressed by a
future revision of this specification or some other
specification. Note also that there are means by
which UA implementations may more fully meet the
first core requirement; see <xref
target="sctn-ua-impl-advice"/> "<xref
target="sctn-ua-impl-advice" format="title"/>".
</t>
</list>
</t>
</section> <!-- sctn-reqs-core -->
<section anchor="sctn-reqs-ancillary" title="Detailed Ancillary Requirements">
<t>
These ancillary requirements are also derived from the
overall requirement. They are not normatively addressed in
this specification, but could be met by UA implementations
at their implementor's discretion, although meeting these
requirements may be complex.
</t>
<t>
<list style="numbers">
<t>
Disallow "mixed security context" loads
(see <xref target="sctn-web-dvlp"/>).
</t>
<t>
Facilitate user declaration of web sites for which
strict security policy is enabled, regardless of whether
the sites signal HSTS Policy.
</t>
</list>
</t>
</section> <!-- sctn-reqs-ancillary -->
</section> <!-- sctn-reqs-ovrl-req -->
</section> <!-- Requirements -->
</section>
<section anchor="sctn-conformance" title="Conformance Criteria">
<t>
This specification is written for hosts and user agents
(UAs).
</t>
<!--
<t>
As well as sections and appendices marked as non-normative,
all diagrams, examples, and notes in this specification are
non-normative. Everything else in this specification is
normative.
</t>
-->
<t>
[[IESG NOTE: the next two paragraphs are for readers with a background in W3C
specification style, of which we expect many. RFC Editor, please
remove this note before publication.]]
</t>
<t>
A conformant host is one that implements all the
requirements listed in this specification that are
applicable to hosts.
</t>
<t>
A conformant user agent is one that implements all the
requirements listed in this specification that are
applicable to user agents.
</t>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119" />.
</t>
</section> <!-- sctn-conformance -->
<section anchor="sctn-terminology" title="Terminology">
<t>Terminology is defined in this section.</t>
<!--
<t><list style="hanging" hangIndent="18">
<t hangText="ABNF">
<vspace/>
is an acronym standing for "Augmented Backus-Naur Form",
and which is used as a short hand means of referring to
syntax
</t></list>
</t>
-->
<t><list style="hanging" hangIndent="18">
<t hangText="ASCII case-insensitive comparison:">
<vspace/>
means comparing two
strings exactly, codepoint for codepoint, except that the
characters in the range U+0041 .. U+005A (i.e. LATIN CAPITAL
LETTER A to LATIN CAPITAL LETTER Z) and the corresponding
characters in the range U+0061 .. U+007A (i.e. LATIN SMALL
LETTER A to LATIN SMALL LETTER Z) are considered to also
match. See <xref target="Unicode" /> for details.
</t></list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="codepoint:">
is a colloquial
contraction of Code Point, which is any value in the Unicode
codespace; that is, the range of integers from 0 to
10FFFF(hex) <xref target="Unicode" />.
</t></list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="domain name:">
domain names, also
referred to as DNS Names, are defined in <xref
target="RFC1035" /> to be represented outside of the DNS
protocol itself (and implementations thereof) as a series of
labels separated by dots, e.g., "example.com" or
"yet.another.example.org". In the context of this
specification, domain names appear in that portion of a URI
satisfying the reg-name production in "Appendix A.
Collected ABNF for URI" in <xref target="RFC3986" />,
and the host component from the Host HTTP header field
production in Section 14.23 of <xref target="RFC2616"
/>.
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
The domain names appearing in actual URI instances and
matching the aforementioned production components may or
may not be a fully qualified domain name.
</t>
</list>
</t>
</list>
</t>
<t>
<list style="hanging" hangIndent="18">
<t hangText="domain name label:">
is that portion of a domain name appearing
"between the dots", i.e. consider
"foo.example.com": "foo",
"example", and "com" are all domain
name labels.
</t>
</list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="Effective Request URI:">
<vspace/>
is a URI, identifying the target resource, that can be
inferred by an HTTP host for any given HTTP request it
receives. Such inference is necessary
because HTTP requests often do not contain a complete
"absolute" URI
identifying the
target resource. See <xref
target="sctn-svrproc-httpreq-eru"/> "<xref
target="sctn-svrproc-httpreq-eru" format="title"/>".
<!--
That is, they do not carry
for the target
resource.
Rather, different portions of a resource's URI may be
mapped to both the Request-Line header field and the Host
header field in an HTTP request message <xref
target="I-D.ietf-httpbis-p1-messaging" />. The HTTP server
coalesces these URI fragments and constructs an equivalent
of the Request-URI that was used by the UA to generate the
received HTTP request message.
-->
</t></list>
</t>
<!--
<t><list style="hanging" hangIndent="18">
<t hangText="FQDN">
is an acronym for Fully-qualified domain name. A FQDN is a
domain name that includes all higher level domains
relevant to the named entity (typically a HSTS Host in
the context of this specification). If one thinks of the
DNS as a tree-structure with each node having its own
domain name label, a FQDN for a specific node would be its
label followed by the labels of all the other nodes
between it and the root of the tree. For example, for a
host, a FQDN would include the label that identifies the
particular host, plus all domains of which the host is a
part, up to and including the top-level domain (the root
domain is always null) <xref target="RFC2664" />.
</t></list>
</t>
-->
<t><list style="hanging" hangIndent="18">
<t hangText="HTTP Strict Transport Security:">
<vspace/>
is the
overall name for the combined UA- and server-side security
policy defined by this specification.
</t></list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="HTTP Strict Transport Security Host:">
<vspace/>
is a
conformant host implementing the HTTP server aspects of the HSTS
Policy. This means that an HSTS Host returns the
"Strict-Transport-Security" HTTP response header field
in its HTTP response messages sent over secure
transport.
</t></list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="HTTP Strict Transport Security Policy:">
<vspace/>
is the name of the combined overall
UA- and server-side facets of the behavior defined in
this specification.
</t></list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="HSTS:">
See HTTP Strict Transport
Security.
</t></list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="HSTS Host:">
See HTTP Strict
Transport Security Host.
</t></list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="HSTS Policy:">
See HTTP Strict Transport Security Policy.
</t></list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="Known HSTS Host:">
is an HSTS
Host for which the UA has an HSTS Policy in effect. I.e.,
the UA has noted this host as a Known HSTS Host.
See <xref target="sctn-uaproc-stshf-note"/> "<xref
target="sctn-uaproc-stshf-note" format="title"/>
for particulars."
</t></list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="Local policy:">
comprises policy rules deployers specify and which are often
manifested as configuration settings.
</t></list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="MITM:">
is an acronym for
man-in-the-middle. See "man-in-the-middle
attack" in <xref target="RFC4949" />.
</t></list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="Request URI:">
is the URI used to
cause a UA to issue an HTTP request message.
See also "Effective Request URI".
</t></list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="UA:">
is a an acronym for user agent. For
the purposes of this specification, a UA is an HTTP client
application typically actively manipulated by a user <xref
target="RFC2616" /> .
</t></list>
</t>
<t><list style="hanging" hangIndent="18">
<t hangText="unknown HSTS Host:">
is an HSTS
Host that the user agent has not noted.
</t></list>
</t>
</section> <!-- sctn-terminology -->
<section anchor="sctn-hsts-mech-overview" title="HSTS Mechanism Overview">
<t>
This section provides an overview of the mechanism
by which an HSTS Host conveys its HSTS Policy to UAs,
and how User Agents process the HSTS Policies received from HSTS Hosts.
The mechanism details are specified in
<xref target="sctn-syntax"/> through <xref target="sec-iana-consid"/>.
</t>
<section anchor="sctn-hsts-host-declaration" title="HSTS Host Declaration">
<t>
An HTTP host declares itself an HSTS Host by issuing to UAs an
HSTS Policy, which is represented by, and conveyed via, the
Strict-Transport-Security HTTP response header field over
secure transport (e.g., TLS). Upon error-free receipt and
processing of this header by a conformant UA, the UA regards
the host as a Known HSTS Host.
</t>
</section>
<section anchor="sctn-hsts-policy" title="HSTS Policy">
<t>
An HSTS Policy directs UAs to communicate with a Known HSTS
Host only over secure transport, and specifies policy
retention time duration.
</t>
<t>
HSTS Policy explicitly overrides
the UA processing of URI references, user input (e.g., via
the "location bar"), or other information that, in the
absence of HSTS Policy, might otherwise cause UAs to
communicate insecurely with the Known HSTS Host.
</t>
<t>
An HSTS Policy may contain an optional directive --
includeSubDomains -- specifying that this HSTS Policy also
applies to any hosts whose domain names are subdomains of
the Known HSTS Host's domain name.
</t>
</section>
<section anchor="sctn-hsts-policy-strg-maint"
title="HSTS Policy Storage and Maintenance by User Agents">
<t>
UAs store and index HSTS Policies based strictly upon the
domain names of the issuing HSTS Hosts.
</t>
<t>
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 superdomains or
subdomains of the given HSTS Host's domain name. Only the
given HSTS Host can update, or cause deletion of, its issued
HSTS Policy. It accomplishes this by sending
Strict-Transport-Security HTTP response header fields to UAs
with new values for policy time duration and subdomain
applicability. Thus, UAs cache the "freshest" HSTS Policy
information on behalf of an HSTS Host. Specifying a zero
time duration signals to the UA to delete the HSTS Policy
(including any asserted
includeSubDomains directive) for that HSTS Host.
See <xref target="sctn-resp-hdr-proc"/>
"<xref target="sctn-resp-hdr-proc" format="title"/>" for
details. Additionally, <xref target="sctn-syntax-examples"/>
presents examples of Strict-Transport-Security HTTP response
header fields.
</t>
</section>
<section anchor="sctn-hsts-policy-app"
title="User Agent HSTS Policy Enforcement">
<t>
When establishing an HTTP connection to a given host, however
instigated, the UA examines
its cache of Known HSTS Hosts to see if there are any with
domain names that are superdomains of the given host's
domain name. If any are found, and of those if any have the
includeSubDomains directive asserted, then HSTS
Policy applies to the given host. Otherwise, HSTS Policy
applies to the given host only if the given host is itself known to
the UA as an HSTS Host. See <xref
target="sctn-uri-load-port-map"/> "<xref
target="sctn-uri-load-port-map" format="title"/>" for
details.
</t>
</section>
</section> <!-- sctn-overview -->
<section anchor="sctn-syntax" title="Syntax">
<t>
This section defines the syntax of the
Strict-Transport-Security HTTP response header field
and its directives, and presents some examples.
</t>
<t>
<xref target="server-processing-model"/>
"<xref target="server-processing-model" format="title"/>"
then details how hosts
employ this header field to declare their HSTS Policy,
and
<xref target="user-agent-processing-model"/>
"<xref target="user-agent-processing-model" format="title"/>"
details how user agents process the header field and
apply the HSTS Policy.
</t>
<section anchor="sctn-syntax-grammar"
title="Strict-Transport-Security HTTP Response Header Field">
<t>
The Strict-Transport-Security HTTP response header field
(STS header field)
indicates to a UA that it MUST enforce the HSTS Policy in
regards to the host emitting the response message
containing this header field.
</t>
<t>
The ABNF (Augmented Backus-Naur Form) syntax
for the STS header field is given below. It
is based on the Generic Grammar defined in Section 2 of
<xref target="RFC2616"/> (which includes a notion of
"implied linear whitespace", also known as "implied *LWS").
</t>
<figure>
<artwork type="abnf2616">
Strict-Transport-Security = "Strict-Transport-Security" ":"
[ directive ] *( ";" [ directive ] )
directive = directive-name [ "=" directive-value ]
directive-name = token
directive-value = token | quoted-string
</artwork>
</figure>
<t>
where:
</t>
<figure>
<artwork type="abnf2616">
token = <token, defined in [RFC2616], Section 2.2>
quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
</artwork>
</figure>
<t>
The two directives defined in this specification are
described below. The overall requirements for directives are:
<list style="numbers">
<t><!-- 1 -->
The order of appearance of directives is not
significant.
</t>
<t><!-- 2 -->
All directives MUST appear only once in an STS header field.
Directives are either optional or required, as stipulated
in their definitions.
</t>
<t><!-- 3 -->
Directive names are case-insensitive.
</t>
<t><!-- 4 -->
UAs MUST ignore any STS header fields containing
directives, or other header field value data, that does
not conform to the syntax defined in this specification.
</t>
<t><!-- 5 -->
If an STS header field contains
directive(s) not recognized by the UA, the UA
MUST ignore the unrecognized directives
and if the STS header field otherwise
satisfies the above
requirements (1 through 4), the
UA MUST process the recognized directives.
</t>
</list>
</t>
<t>
Additional directives extending the semantic
functionality of the STS header field
can be defined in other specifications, with a registry
(having an IANA policy definition of IETF Review
<xref target="RFC5226"/>)
defined for them at such time.
</t>
<t>
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
Such future directives will be ignored by UAs implementing
only this specification, as well as by generally non-conforming UAs.
See <xref target="sctn-sec-cons-nonconform-uas"/>
"<xref target="sctn-sec-cons-nonconform-uas" format="title"/>"
for further discussion.
</t>
</list>
</t>
<section anchor="sctn-syntax-max-age" title="The max-age Directive">
<t>
The REQUIRED "max-age" directive specifies the number of
seconds, after the reception of the STS header field,
during which the UA regards the host (from whom the
message was received) as a Known HSTS Host. See also <xref
target="sctn-uaproc-stshf-note"/> "<xref
target="sctn-uaproc-stshf-note" format="title"/>".
The delta-seconds production is specified in <xref
target="RFC2616" />.
</t>
<t>
The syntax of the max-age directive's REQUIRED value
(after quoted-string unescaping, if necessary)
is defined as:
<figure>
<artwork type="abnf2616">
max-age-value = delta-seconds
delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>
</artwork>
</figure>
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
A max-age value of zero (i.e., "max-age=0") signals the
UA to cease regarding the host as a Known HSTS Host,
including the includeSubDomains directive (if asserted for that
HSTS Host).
See also
<xref target="sctn-resp-hdr-proc"/>
"<xref target="sctn-resp-hdr-proc" format="title"/>".
</t>
</list>
</t>
</section>
<section anchor="sctn-syntax-includeSubDomains"
title="The includeSubDomains Directive">
<t>
The OPTIONAL
"includeSubDomains" directive is a valueless directive which, if
present (i.e., it is "asserted"),
signals to the UA that the HSTS Policy applies to
this HSTS Host as well as any subdomains of the host's
domain name.
</t>
</section>
</section> <!-- sctn-syntax-grammar -->
<section anchor="sctn-syntax-examples" title="Examples">
<t>
The below HSTS header field stipulates that the HSTS Policy
is to remain in effect for one year (there are approximately
31 536 000 seconds in a year), and the policy applies only
to the domain of the HSTS Host issuing it:
<figure>
<artwork type="example">
Strict-Transport-Security: max-age=31536000
</artwork>
</figure>
</t>
<t>
The below HSTS header field stipulates that the HSTS Policy
is to remain in effect for approximately six months and the
policy applies to the domain of the issuing HSTS Host
and all of its subdomains:
<figure>
<artwork type="example">
Strict-Transport-Security: max-age=15768000 ; includeSubDomains
</artwork>
</figure>
</t>
<t>
The max-age directive value can optionally be quoted:
<figure>
<artwork type="example">
Strict-Transport-Security: max-age="31536000"
</artwork>
</figure>
</t>
<t>
The below HSTS header field indicates that the UA must
delete the entire HSTS Policy associated with the HSTS Host that
sent the header field:
<figure>
<artwork type="example">
Strict-Transport-Security: max-age=0
</artwork>
</figure>
</t>
<t>
The below HSTS header field has exactly the same effect as
the one immediately above because the includeSubDomains directive's
presence
in the HSTS header field is ignored when max-age is zero:
<figure>
<artwork type="example">
Strict-Transport-Security: max-age=0; includeSubDomains
</artwork>
</figure>
</t>
</section> <!-- sctn-syntax-examples -->
</section> <!-- sctn-syntax -->
<section anchor="server-processing-model" title="Server Processing Model">
<t>
This section describes the processing model that HSTS Hosts
implement. The model comprises two facets: the first
being the processing rules for HTTP request messages received
over a secure transport (TLS <xref target="RFC5246" /> or
SSL <xref target="RFC6101" />, see also
<xref target="sctn-sec-cons-secure-transport"/> "<xref
target="sctn-sec-cons-secure-transport" format="title"/>"),
the second being the processing rules for HTTP request
messages received over non-secure transports, such as TCP.
<!-- <xref target="RFC0793" /> -->
</t>
<section title="HTTP-over-Secure-Transport Request Type">
<t>
When replying to an HTTP request that was conveyed over a
secure transport, an HSTS Host SHOULD include
in its response message an STS header field
that MUST satisfy the grammar
specified above in <xref target="sctn-syntax-grammar"/> "<xref
target="sctn-syntax-grammar" format="title"/>".
If an STS header field is
included, the HSTS Host MUST include
only one such header field.
</t>
<t>
Establishing a given host as a Known HSTS Host, in the
context of a given UA, MAY be accomplished over the HTTP
protocol, which is in turn running over secure transport,
by correctly returning (per this specification) at
least one valid STS header field to the UA. Other
mechanisms, such as a client-side pre-loaded Known HSTS Host
list MAY also be used. E.g., see <xref
target="sctn-ua-impl-advice"/> "<xref
target="sctn-ua-impl-advice" format="title"/>".
</t>
<t>
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
Including the STS header field is stipulated as a
"SHOULD" in order to accommodate various server- and
network-side caches and load-balancing configurations
where it may be difficult to uniformly emit STS header
fields on behalf of a given HSTS Host.
</t>
</list>
</t>
</section> <!-- HTTP-over-Secure-Transport Request Type -->
<section title="HTTP Request Type">
<t>
If an HSTS Host receives a HTTP request message over a
non-secure transport,
it SHOULD send a HTTP response message containing
a status code indicating a permanent redirect, such as status code 301
(Section 10.3.2 of <xref target="RFC2616"/>),
and a Location header field
value containing either the HTTP request's original
Effective Request URI
(see <xref
target="sctn-svrproc-httpreq-eru"/> "<xref
target="sctn-svrproc-httpreq-eru" format="title"/>")
altered as necessary to have a URI scheme of
"https", or a URI generated according to local
policy with a URI scheme of
"https").
</t>
<t>
<list style="hanging" hangIndent="0">
<t hangText="NOTE:">
The above behavior is a "SHOULD" rather than a
"MUST" due to:
<list style="symbols">
<t>
Risks in server-side
non-secure-to-secure redirects <xref target="owaspTLSGuide"/>.
</t>
<t>
Site deployment characteristics. For example, a site that incorporates
third-party components may not behave correctly when
doing server-side non-secure-to-secure redirects in the case
of being accessed over non-secure transport, but
does behave correctly when accessed uniformly over
secure transport. The latter is the case given a
HSTS-capable UA that has already noted
the site as a Known HSTS Host (by whatever means, e.g.,
prior interaction or UA configuration).
</t>
</list>
</t>
</list>
</t>
<t>
<!--
<cref anchor="XXX1" source="JeffH">
perhaps the "SHOULD" in the above behavior should be a "MAY" given the
reasons it's presently not a "MUST".
</cref>
-->
</t>
<t>
An HSTS Host MUST NOT include the STS header field in HTTP
responses conveyed over non-secure transport.
</t>
</section> <!-- HTTP Request Type -->
</section> <!-- server-processing-model -->
<section anchor="user-agent-processing-model"
title="User Agent Processing Model">
<t>
This section describes the HTTP Strict Transport
Security processing model for UAs.
There are several facets to the model, enumerated by the
following subsections.
</t>
<t>
This processing model assumes
that the UA implements IDNA2008 <xref target="RFC5890" />,
or possibly IDNA2003 <xref target="RFC3490" />, as noted in
<xref target="sctn-idna-dep"/> "<xref
target="sctn-idna-dep"
format="title"/>".
It also assumes that all domain names
manipulated
in this specification's context
are already IDNA-canonicalized
as outlined in <xref target="sctn-force-tls-dns-name-canon"/>
"<xref target="sctn-force-tls-dns-name-canon" format="title"/>"
prior to the processing specified in this section.
</t>
<t>
The above assumptions mean that this processing model also specifically assumes that
appropriate IDNA and Unicode validations and character list testing have occurred
on the domain names, in conjunction with their IDNA-canonicalization,
prior to the processing specified in this section.
See the IDNA-specific security considerations
in <xref target="sctn-sec-cons-idna"/> "<xref
target="sctn-sec-cons-idna"
format="title"/>"
for rationale and further details.
</t>
<section anchor="sctn-resp-hdr-proc"
title="Strict-Transport-Security Response Header Field Processing">
<t>
If an HTTP response, received over a secure transport,
includes an STS header field,
conforming to the grammar specified in
<xref target="sctn-syntax-grammar"/>
"<xref target="sctn-syntax-grammar" format="title"/>",
and there are no underlying secure transport
errors or warnings
(see <xref target="sctn-err-tls-estab"/>),
the UA MUST either:
</t>
<t>
<list style="symbols">
<t>
Note the host as a Known HSTS Host if it is not already
so noted (see <xref target="sctn-uaproc-stshf-note"/>
"<xref target="sctn-uaproc-stshf-note" format="title"/>"),
</t>
</list>
</t>
<t>
or,
</t>
<t>
<list style="symbols">
<t>
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.
<vspace blankLines="1"/>
The max-age value is essentially a "time to live" value
relative to the reception time of the
STS header field.
<vspace blankLines="1"/>
If the max-age header field value token has a value of
zero, the UA MUST remove its cached HSTS Policy
information (including the includeSubDomains directive if asserted)
if the HSTS Host is known, or, MUST NOT note
this HSTS Host if it is not yet known.
<vspace blankLines="1"/>
If a UA receives more than one STS header field in a
HTTP response message over secure transport, then the UA
MUST process only the first such header field.
</t>
</list>
</t>
<t>
Otherwise:
</t>
<t>
<list style="symbols">
<t>
If an HTTP response is received over insecure
transport, the UA MUST ignore
any present STS header field(s).
</t>
<t>
The UA MUST ignore any
STS header fields not
conforming to the grammar specified in
<xref target="sctn-syntax-grammar"/>
"<xref target="sctn-syntax-grammar" format="title"/>".
</t>
</list>
</t>
<section anchor="sctn-uaproc-stshf-note"
title="Noting an HSTS Host - Storage Model">
<t>
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 <xref target="RFC3986"
/>, then the UA MUST NOT note this host as a Known HSTS
Host.
</t>
<t>
Otherwise, if the substring does not congruently match a
Known HSTS Host's domain name, per the matching procedure
specified in <xref target="sctn-ksts-dn-match"/> "<xref
target="sctn-ksts-dn-match" format="title"/>", 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 <xref target="sctn-advice-policy-expir"/>
"<xref target="sctn-advice-policy-expir" format="title"/>".
</t>
<t>
The UA MUST NOT modify the expiry time nor the
includeSubDomains directive of any superdomain matched
Known HSTS Host.
</t>
<t>
A Known HSTS Hosts 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.
</t>
</section> <!-- sctn-uaproc-stshf-note -->
</section> <!-- sctn-resp-hdr-proc -->
<section anchor="sctn-ksts-dn-match"
title="Known HSTS Host Domain Name Matching">
<t>
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.
Or, there may be no match.
</t>
<t>
The below steps determine whether
there are any matches, and if so, of which fashion:
</t>
<!--
<t>
<list style="hanging" hangIndent="7">
<t hangText="Note:">
A given domain name may be found to have either
or both fashions of match, or no match.
</t>
</list>
</t>
-->
<t>
<list style="empty">
<t>
Compare the given domain name with the
domain name of each of the UA's unexpired
Known HSTS Hosts.
<!--
Compare the query domain name with the Domain
Names within the UA's set of Known HSTS Hosts.
-->
For each Known HSTS Host's domain name, the
comparison is done with the given domain name
label-by-label (comparing only labels)
using an ASCII case-insensitive
comparison beginning with the rightmost label, and
continuing right-to-left.
<!--
, and ignoring separator
characters.
-->
<!--
The comparison is done by converting the domain names
to sequences of individual label strings, and then
comparing the labels
label-by-label using an ASCII case-insensitive
comparison beginning with the rightmost label, and
-->
See also Section 2.3.2.4. of <xref
target="RFC5890" />.
<list style="symbols">
<t>
Superdomain Match
<vspace blankLines="1"/>
If a label-for-label match between an entire
Known HSTS Host's domain name and a right-hand
portion of the given domain name is found, then this
Known HSTS Host's domain name is a superdomain
match for the given domain name. There could be
multiple superdomain matches for a given domain name.
<vspace blankLines="1"/>
For example:
<figure>
<artwork type="example">
Given Domain Name: qaz.bar.foo.example.com
Superdomain matched
Known HSTS Host DN: bar.foo.example.com
Superdomain matched
Known HSTS Host DN: foo.example.com
</artwork>
</figure>
<vspace blankLines="1"/>
<!--
At this point, the given domain name is
ascertained to effectively represent a Known HSTS
Host (there may also be additional matches
further down the domain name label tree, up to and
including a congruent match).
-->
</t>
<t>
Congruent Match
<vspace blankLines="1"/>
If a label-for-label match between a Known HSTS
Host's domain name and the given domain name is found --
i.e., there are no further labels to compare -- then the
given domain name congruently matches this Known HSTS
Host.
<vspace blankLines="1"/>
For example:
<figure>
<artwork type="example">
Given Domain Name: foo.example.com
Congruently matched
Known HSTS Host DN: foo.example.com
</artwork>
</figure>
<vspace blankLines="1"/>
<!--
The given domain name is ascertained to represent
a Known HSTS Host.
-->
<!--
However, if there are also
superdomain matches, the one highest in the tree
asserts the HSTS Policy for this Known HSTS Host.
-->
</t>
<t>
Otherwise, if no matches are found, the given
domain name does not represent a Known HSTS Host.
</t>
</list>
</t>
</list>
</t>
</section> <!-- sctn-ksts-dn-match -->
<section anchor="sctn-uri-load-port-map" title="URI Loading and Port Mapping">
<t>
Whenever the UA prepares to "load", also known as
"dereference", any "http"
URI <xref target="RFC3986"/>
(including when following HTTP redirects <xref target="RFC2616"/>),
the UA MUST first determine whether
a domain name is given in the URI and whether it
matches a Known HSTS Host, using these steps:
<list style="numbers">
<t>
Extract from the URI any substring
described by
the host component of
the authority component of the URI.
</t>
<t>
If the substring is null, then there is no
match with any Known HSTS Host.
</t>
<t>
Else, if the substring is non-null
and syntactically matches the IP-literal or IPv4address
productions from Section 3.2.2 of <xref target="RFC3986"/>,
then there is no match with any Known HSTS Host.
</t>
<t>
Otherwise, the substring is a given domain name,
which MUST be matched against the UA's Known HSTS Hosts
using the procedure in <xref target="sctn-ksts-dn-match"/> "<xref
target="sctn-ksts-dn-match" format="title"/>".
</t>
<t>
If when performing domain name matching, any superdomain
match with an asserted includeSubDomains directive is found,
or, if no superdomain matches with asserted
includeSubDomains directives are found and a congruent match
is found (with or without an asserted includeSubDomains
directive), then before proceeding with the load:
<list style="empty">
<t>
The UA MUST replace the URI scheme with "https"
<xref target="RFC2818"/>, and,
</t>
<t>
if the URI contains an explicit port component of
"80", then the UA MUST convert the port component to
be "443", or,
</t>
<t>
if the URI contains an explicit port component that
is not equal to "80", the port component value MUST
be preserved, otherwise,
</t>
<t>
if the URI does not contain an explicit port
component, the UA MUST NOT add one.
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
These steps ensure that the HSTS Policy
applies to HTTP over any TCP port of an HSTS Host.
</t>
</list>
</t>
</list>
</t>
</list>
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
In the case where an explicit port is provided (and to a
lesser extent with subdomains), it is reasonably likely that
there is actually an HTTP (i.e., non-secure) server running at
the specified port and thus that an HTTPS request will fail
(see item (6) in <xref target="design-decision-faq"/>
"<xref target="design-decision-faq" format="title"/>").
</t>
</list>
</t>
</section><!-- URI Loading and port mapping -->
<section anchor="sctn-err-tls-estab"
title="Errors in Secure Transport Establishment">
<t>
When connecting to a Known HSTS Host, the UA MUST terminate
the connection (see also
<xref target="sctn-ua-impl-advice"/>
"<xref target="sctn-ua-impl-advice" format="title"/>")
if there are any errors, whether "warning" or
"fatal" or any other error level, with the
underlying secure transport.
For example, this includes any errors found
in certificate validity checking UAs employ
such as
via
Certificate Revocation Lists (CRL)
<xref target="RFC5280"/>,
or via the Online Certificate Status Protocol (OCSP)
<xref target="RFC2560"/>.
</t>
</section> <!-- Errors in Secure Transport Establishment -->
<section title="HTTP-Equiv <Meta> Element Attribute">
<t>
UAs MUST NOT heed
http-equiv="Strict-Transport-Security" attribute
settings on <meta> elements
<xref target="W3C.REC-html401-19991224"/>
in received content.
</t>
</section> <!-- HTTP-Equiv <Meta> Element Attribute -->
<section anchor="sctn-missing-hsts-header"
title="Missing Strict-Transport-Security Response Header Field">
<t>
If a UA receives HTTP responses from a Known HSTS Host over
a secure channel, but they are missing the STS header field,
the UA MUST continue to treat the host as a Known HSTS Host
until the max-age value for the knowledge of that Known HSTS
Host is reached.
Note that the max-age value could be effectively infinite for
a given Known HSTS Host.
For example, this would be the case if the Known HSTS Host
is part of a pre-configured list that is implemented such
that the list entries never "age out".
</t>
</section> <!-- HTTP-Equiv <Meta> Element Attribute -->
</section> <!-- user-agent-processing-model -->
<section anchor="sctn-svrproc-httpreq-eru"
title="Constructing an Effective Request URI">
<t>
This section specifies how an HSTS Host must construct the
Effective Request URI for a received HTTP request.
</t>
<t>
HTTP requests often do not carry an absoluteURI for the target
resource; instead, the URI needs to be inferred from the
Request-URI, Host header field, and connection context (<xref
target="RFC2616"/>, Sections 3.2.1, 5.1.2, and 5.2). The result
of this process is called the "effective request URI (ERU)".
The "target resource" is the resource identified by the
effective request URI.
</t>
<section anchor="sctn-svrproc-httpreq-eru-prelim"
title="ERU Fundamental Definitions">
<t>
The first line of an HTTP request message,
Request-Line, is specified by the
following ABNF from <xref target="RFC2616"/>,
Section 5.1:
<figure>
<artwork type="abnf2616">
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
</artwork>
</figure>
The Request-URI, within the Request-Line, is specified
by the following ABNF from
<xref target="RFC2616"/>, Section 5.1.2:
<figure>
<artwork type="abnf2616">
Request-URI = "*" | absoluteURI | abs_path | authority
</artwork>
</figure>
The Host request header field is specified by the following
ABNF from <xref target="RFC2616"/>, Section 14.23:
<figure>
<artwork type="abnf2616">
Host = "Host" ":" host [ ":" port ]
</artwork>
</figure>
</t>
</section> <!-- sctn-svrproc-httpreq-eru-prelim -->
<section anchor="sctn-svrproc-httpreq-eru-determine"
title="Determining the Effective Request URI">
<t>
If the Request-URI is an absoluteURI, then the effective request URI is
the Request-URI.
</t>
<t>
If the Request-URI uses the abs_path form or the asterisk form,
and the Host header field is present, then the effective request URI is
constructed by concatenating:
</t>
<t>
<list style="symbols">
<t>
the scheme name: "http" if the request was received over an insecure
TCP connection, or "https" when received over a TLS/SSL-secured TCP
connection, and,
</t>
<t>
the octet sequence "://", and,
</t>
<t>
the host, and the port (if present), from the Host header field, and
</t>
<t>
the Request-URI obtained from the Request-Line, unless the
Request-URI is just the asterisk "*".
</t>
</list>
</t>
<t>
If the Request-URI uses the abs_path form or the asterisk form,
and the Host header field is not present, then the effective request URI is
undefined.
</t>
<t>
Otherwise, when Request-URI uses the authority form, the effective
request URI is undefined.
</t>
<t>
Effective request URIs are compared using the rules
described in <xref target="RFC2616"/> Section 3.2.3, except
that empty path components MUST NOT be treated as equivalent
to an absolute path of "/".
</t>
<section anchor="sctn-svrproc-httpreq-eru-examples"
title="Effective Request URI Examples">
<figure>
<preamble>
Example 1: the effective request URI for the message
</preamble>
<artwork type="message/http; msgtype="request"">
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080
</artwork>
<postamble>
(received over an insecure TCP connection) is "http", plus
"://", plus the authority component
"www.example.org:8080", plus the request-target
"/pub/WWW/TheProject.html". Thus it is:
"http://www.example.org:8080/pub/WWW/TheProject.html".
</postamble>
</figure>
<figure>
<preamble>
Example 2: the effective request URI for the message
</preamble>
<artwork type="message/http; msgtype="request"">
OPTIONS * HTTP/1.1
Host: www.example.org
</artwork>
<postamble>
(received over an SSL/TLS secured TCP connection) is
"https", plus "://", plus the authority component
"www.example.org". Thus it is: "https://www.example.org".
</postamble>
</figure>
</section> <!-- -->
<!--
<t>
<cref anchor="TODO3" source="JeffH">
This is a first SWAG at this section. Fix/add prose as appropriate, fix ABNF as needed per review.
</cref>
</t>
-->
</section> <!-- sctn-svrproc-httpreq-eru-determine -->
</section> <!-- sctn-svrproc-httpreq-eru -->
<section anchor="sctn-force-tls-dns-name-canon"
title="Domain Name IDNA-Canonicalization">
<t>
An IDNA-canonicalized domain name is the output
string generated by
the following steps.
The input
is a putative domain name string ostensibly
composed of any combination of
"A-labels", "U-labels", and "NR-LDH labels"
(see Section 2 of <xref target="RFC5890"/>) concatenated
using some separator character (typically ".").
<!--
must be a valid
Unicode-encoded (in NFC form <xref target="Unicode"/>)
string-serialized domain name:
-->
<!--
as defined in
<xref target="sctn-terminology"/> "<xref
target="sctn-terminology"
format="title"/>" (above):
-->
</t>
<t>
<list style="numbers">
<t>
Convert the input putative domain name string
to a order-preserving sequence of individual
label strings.
</t>
<t>
When implementing IDNA2008,
convert, validate, and test each A-label and U-label
found among the sequence of individual label strings,
using the procedures
defined in Sections 5.3 through 5.5 of
<xref target="RFC5891"/>.
<vspace blankLines="1"/>
Otherwise, when implementing IDNA2003, convert each
label using the
"ToASCII" conversion in Section 4 of <xref target="RFC3490"/>
(see also the definition of "equivalence of labels"
in Section 2 of the latter specification).
</t>
<t>
If no errors occurred during the foregoing step,
concatenate all the labels in the sequence, in order,
into a string,
separating each label from the next with
a %x2E (".") character. The resulting string, known as a
IDNA-canonicalized domain name, is appropriate for use
in the context of <xref target="user-agent-processing-model"/>
"<xref target="user-agent-processing-model" format="title"/>".
<vspace blankLines="1"/>
Otherwise, errors occurred. The input putative domain name string
was not successfully IDNA-canonicalized. Invokers of this
procedure should attempt appropriate error recovery.
</t>
</list>
See also <xref target="sctn-idna-dep"/>
"<xref target="sctn-idna-dep" format="title"/>"
and
<xref target="sctn-sec-cons-idna"/> "<xref
target="sctn-sec-cons-idna"
format="title"/>"
of this specification for further details and considerations.
</t>
</section> <!-- sctn-force-tls-dns-name-conan -->
<section anchor="sctn-hosting-spec-advice"
title="Server Implementation and Deployment Advice">
<t>This section is non-normative.</t>
<section anchor="sctn-non-cnfmt-ua" title="Non-Conformant User Agent Considerations">
<t>
Non-conformant UAs ignore the Strict-Transport-Security
header field, thus non-conformant user agents do not address the
threats described in <xref target="sctn-threats-addr"/>
"<xref target="sctn-threats-addr" format="title"/>".
Please refer to <xref target="sctn-sec-cons-nonconform-uas"/>
"<xref target="sctn-sec-cons-nonconform-uas" format="title"/>"
for further discussion.
<!--
Therefore web application providers
HSTS Policy is enforced in UAs,
-->
</t>
</section>
<section anchor="sctn-advice-policy-expir"
title="HSTS Policy expiration time considerations">
<t>
Server implementations and deploying web sites need to
consider whether they are setting an expiry time that is a
constant value into the future, or whether they are
setting an expiry time that is a fixed point in time.
</t>
<t>
The constant value into the future
approach can be accomplished by constantly sending
the same max-age value to UAs.
</t>
<t>
For example, a max-age value of 7776000 seconds is 90 days:
<figure>
<artwork type="example">
Strict-Transport-Security: max-age=7776000
</artwork>
</figure>
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.
<!-- The specifics of how this is
accomplished are out of the scope of this specification.
-->
</t>
<t>
The fixed point in time approach can be accomplished
by sending max-age values that represent the
remaining time until the desired expiry time. This would
require the HSTS Host to send a newly-calculated max-age value on
each HTTP response.
<vspace blankLines="1"/>
A consideration here is whether a deployer wishes to have
the signaled HSTS Policy expiry time match that
for the web site's domain certificate.
</t>
<t>
Additionally, server implementers should consider employing
a default max-age value of zero in their deployment configuration
systems. This will require deployers to wilfully set max-age
in order to have UAs enforce the HSTS Policy for their host,
and protects them from inadvertently enabling HSTS with some
arbitrary non-zero duration.
</t>
</section> <!-- sctn-advice-policy-expir -->
<section anchor="sctn-advice-self-signed"
title="Using HSTS in conjunction with self-signed public-key certificates">
<t>
If all four of the following conditions are true...
<list style="symbols">
<t>
a web site/organization/enterprise is generating its
own secure transport public-key certificates for web sites,
and
</t>
<t>
that organization's root certification authority (CA)
certificate is not typically embedded by default in browser
and/or operating system
CA certificate stores, and
</t>
<t>
HSTS Policy is enabled on a
host identifying itself using a certificate signed by the
organization's CA (i.e., a "self-signed certificate"), and
</t>
<t>
<!-- fix for bug# 39 -->
and this certificate does not match a usable TLS certificate
association (as defined by Section 4 of the TLSA protocol
specification <xref target="RFC6698"/>),
</t>
</list>
...then secure connections to that site will fail, per the HSTS
design. This is to protect against various active attacks,
as discussed above.
</t>
<t>
However, if said organization wishes to employ its own CA,
and self-signed certificates, in concert with HSTS, it can
do so by deploying its root CA certificate to its users'
browsers or operating system CA root certificate
stores. It can also, in addition or instead, distribute to
its users' browsers the end-entity certificate(s) for
specific hosts. There are various ways in which this can be
accomplished (details are out of scope for this
specification). Once its root CA certificate is installed
in the browsers, it may employ HSTS Policy on its
site(s).
</t>
<t>
Alternatively, that organization can deploy the TLSA protocol;
all browsers that also use TLSA will then be able to trust
the certificates identified by usable TLS certificate associations
as denoted via TLSA.
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
Interactively distributing root CA certificates to
users, e.g., via email, and having the users install
them, is arguably training the users to be susceptible
to a possible form of phishing attack. See <xref
target="sctn-sec-cons-bogus-ca"/> "<xref
target="sctn-sec-cons-bogus-ca" format="title"/>".
Thus care should be taken in the manner in which
such certificates are distributed and installed on
users' systems and browsers.
</t>
</list>
</t>
</section> <!-- sctn-advice-self-signed -->
<section anchor="sctn-incudesubdomains-cons"
title="Implications of includeSubDomains">
<t>
The includeSubDomains directive has some practical
implications. For example, consider these two scenarios
where use of the includeSubDomains directive needs to be
carefully considered:
<list style="symbols">
<t>
An HSTS Host offers unsecured
HTTP-based services on alternate ports or at
various subdomains of its HSTS Host domain name.
</t>
<t>
Distinct web applications are offered at distinct
subdomains of an HSTS Host, such that UAs often
interact directly with these
subdomain web applications without having necessarily
interacted with a web application offered at
the HSTS Host's domain name (if any).
</t>
</list>
The sections below discuss each of these scenarios in turn.
</t>
<section anchor="sctn-incudesubdomains-cons-unsecured-svcs"
title="Considerations for Offering
Unsecured HTTP Services at Alternate Ports or Subdomains
of an HSTS Host">
<t>
For example, certification authorities often offer their
CRL distribution and OCSP services <xref
target="RFC2560"/> over plain HTTP, and sometimes at a
subdomain of a publicly-available web application which
may be secured by TLS/SSL. For example,
<https://ca.example.com/> is a publicly-available
web application for "Example CA", a certification
authority. Customers use this web application to register
their public keys and obtain certificates. Example CA
generates certificates for customers containing
<http://crl-and-ocsp.ca.example.com/> as the value
for the "CRL Distribution Points" and "Authority
Information Access:OCSP" certificate fields.
</t>
<t>
If ca.example.com were to issue an HSTS Policy with the
includeSubDomains directive, then HTTP-based user agents
implementing HSTS that have interacted with the
ca.example.com web application would fail to retrieve
CRLs, and fail to check OCSP for certificates, because
these services are offered over plain HTTP.
</t>
<t>
In this case, Example CA can either:
<list style="symbols">
<t>
not use the includeSubDomains directive, or,
</t>
<t>
ensure HTTP-based services offered at subdomains of
ca.example.com are also uniformly offered over
TLS/SSL, or,
</t>
<t>
offer plain HTTP-based services at a different domain
name, e.g., crl-and-ocsp.ca.example.NET, or,
</t>
<t>
utilize an alternative approach to distributing
certificate status information, obviating the need to
offer CRL distribution and OCSP services over plain
HTTP (e.g., the "Certificate Status Request" TLS
extension <xref target="RFC6066"/>, often colloquially
referred to as "OCSP Stapling").
</t>
</list>
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
The above points are expressly only an example and do
not purport to address all the involved complexities.
For instance, there are many considerations -- on the
part of CAs, certificate deployers, and applications
(e.g., browsers) -- involved in deploying an approach
such as "OCSP Stapling". Such issues are out of scope
for this specification.
</t>
</list>
</t>
</section> <!-- sctn-incudesubdomains-cons-unsecured-svcs -->
<section anchor="sctn-incudesubdomains-cons-subdmn-apps"
title="Considerations for Offering Web Applications at
Subdomains of an HSTS Host">
<t>
In this scenario, an HSTS Host declares an HSTS Policy
with an includeSubDomains directive, and there also exist
distinct web applications offered at distinct subdomains
of the HSTS Host, such that UAs often interact directly
with these subdomain web applications without having
necessarily interacted with the HSTS Host, then the UAs
will not receive or enforce the HSTS Policy.
</t>
<t>
For example, the HSTS host is "example.com", and it is
configured to emit the STS header field with the
includeSubDomains directive. However, example.com's actual
web application is addressed at "www.example.com", and
example.com simply redirects user agents
to "https://www.example.com/".
</t>
<t>
If the STS header field is only emitted by "example.com",
but UAs typically bookmark, and links (from anywhere on the web)
are typically established
to, "www.example.com", and "example.com" is not contacted
directly by all user agents in some non-zero
percentage of interactions, then some number of UAs
will not note "example.com" as an HSTS Host and some number of
users of "www.example.com"
will be unprotected by HSTS Policy.
</t>
<t>
To address this, HSTS Hosts should be configured such that
the STS header field is emitted directly at each HSTS Host
domain or subdomain name that constitutes a well-known "entry point"
to one's web application(s), whether or not
the includeSubDomains directive is employed.
</t>
<t>
Thus in our example, if the STS header field is emitted
from both "example.com" and "www.example.com", this issue
will be addressed. Also, if there are any other well-known
entry points to web applications offered by "example.com", such
as "foo.example.com", they should also be configured to
emit the STS header field.
</t>
</section> <!-- sctn-incudesubdomains-cons-subdmn-apps -->
</section> <!-- sctn-incudesubdomains-cons -->
</section> <!-- sctn-hosting-spec-advice -->
<section anchor="sctn-ua-impl-advice"
title="User Agent Implementation Advice">
<t>This section is non-normative.</t>
<t>
In order to provide users and web sites more effective
protection, as well as controls for managing their UA's
caching of HSTS Policy, UA implementers should consider
including features such as:
</t>
<section anchor="sctn-ua-impl-adv-norecourse"
title="No User Recourse">
<t>
Failing secure connection establishment on any warnings or
errors (per <xref target="sctn-err-tls-estab"/> "<xref
target="sctn-err-tls-estab" format="title"/>") should be
done with "no user recourse". This means that the user
should not be presented with a dialog giving
her the option to proceed. Rather, it should be treated
similarly to a server error where there is nothing further
the user can do with respect to interacting with the target
web application, other than wait and re-try.
<vspace blankLines="1"/>
Essentially, "any warnings or
errors" means anything that would cause the UA
implementation to announce to the user that something is
not entirely correct with the connection establishment.
<vspace blankLines="1"/>
Not doing this, i.e., allowing
user recourse such as "clicking-through warning/error
dialogs", is a recipe for a Man-in-the-Middle attack. If a
web application issues an HSTS Policy, then it is opting into this
scheme, whereby all certificate errors or warnings cause a
connection termination, with no chance to "fool" the user
into making the wrong decision and compromising themselves.
</t>
</section>
<section anchor="sctn-ua-impl-adv-usermods"
title="User-declared HSTS Policy">
<t>
A User-declared HSTS Policy is the
ability for users to explicitly declare a given Domain
Name as representing an HSTS Host, thus seeding it as a Known
HSTS Host before any actual interaction with it. This would
help protect against the <xref target="sctn-sec-cons-boot"/>
"<xref target="sctn-sec-cons-boot" format="title"/>".
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
Such a feature is difficult to get right on a per-site
basis. See the discussion of "rewrite rules" in
Section 5.5 of <xref target="ForceHTTPS" />. For
example, arbitrary web sites may not materialize all
their URIs using the "https" scheme, and thus could
"break" if a UA were to attempt to access the site
exclusively using such URIs.
Also note that this feature
would complement, but is independent of,
an "HSTS Pre-Loaded List" feature
(see <xref target="sctn-ua-impl-adv-preloaded"/>).
</t>
</list>
</t>
</section>
<section anchor="sctn-ua-impl-adv-preloaded"
title="HSTS Pre-Loaded List">
<t>
An HSTS Pre-Loaded List
is a facility whereby web site administrators can have UAs
pre-configured with HSTS Policy for their site(s) by the UA
vendor(s) -- a so-called "pre-loaded list" -- in a manner
similar to how root CA certificates are embedded in browsers
"at the factory". This would help protect against the <xref
target="sctn-sec-cons-boot"/> "<xref
target="sctn-sec-cons-boot" format="title"/>".
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
Such a facility would complement a
"<xref target="sctn-ua-impl-adv-usermods" format="title"/>"
feature.
</t>
</list>
</t>
</section>
<section anchor="sctn-ua-impl-adv-mixed"
title="Disallow Mixed Security Context Loads">
<t>
"Mixed security context" loads happen when
an web application resource, fetched
by the UA over a secure transport,
subsequently causes the fetching of one or more
other resources without using secure
transport. This is also generally
referred to as "mixed content" loads
(see Section 5.3 "Mixed Content" in <xref
target="W3C.REC-wsc-ui-20100812" />),
but should not be confused with
the same "mixed content" term that is
also used in the context of
markup languages such as XML and HTML.
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
In order to provide behavioral uniformity across UA
implementations, the notion of mixed security context
will require further standardization work,
e.g., to define the term(s) more clearly and to define
specific behaviors with respect to it.
</t>
</list>
</t>
</section>
<section anchor="sctn-ua-impl-adv-deletion"
title="HSTS Policy Deletion">
<t>
HSTS Policy Deletion is the
ability to delete a UA's cached HSTS Policy
on a per HSTS Host basis.
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
Adding such a feature should be done very carefully in both
the user interface and security senses.
Deleting a cache entry for a Known HSTS Host
should be a very deliberate and well-considered act -- it shouldn't be something
users get used to just "clicking through" in order to get work done.
Also, implementations need to guard against
allowing an attacker to inject code, e.g. ECMAscript,
into the UA that silently and programmatically removes
entries from the UA's cache of Known HSTS Hosts.
</t>
</list>
</t>
</section>
<!--
<t>
<cref anchor="XXX2" source="JeffH">
These latter items beg the question of having some means of secure web site metadata and policy discovery
and acquisition. There is extant work that may be of interest, e.g. the W3C POWDER work, OASIS XRI/XRD work
(as well as XRDS-Simple), and "Link-based Resource Descriptor Discovery" (draft-hammer-discovery).
</cref>
</t>
-->
</section> <!-- ua-impl-advice -->
<section anchor="sctn-idna-dep"
title="Internationalized Domain Names for Applications (IDNA): Dependency and Migration">
<t>
Textual domain names on the modern Internet may contain
one or more "internationalized" domain name labels.
Such domain names are referred to as
"internationalized domain names" (IDNs). The specification suites
defining IDNs and the protocols for their use are named
"Internationalized Domain Names for Applications (IDNA)".
At this time, there are two such specification suites:
IDNA2008 <xref target="RFC5890" /> and its predecessor
IDNA2003 <xref target="RFC3490" />.
</t>
<t>
IDNA2008 obsoletes IDNA2003, but there are differences between
the two specifications, and thus there can be differences in
processing (e.g., converting) domain name labels that have
been registered under one from those registered under the
other. There will be a transition period of some time during
which IDNA2003-based domain name labels will exist in the
wild.
In order to facilitate their
IDNA transition, user agents SHOULD implement IDNA2008 <xref
target="RFC5890" /> and MAY implement <xref target="RFC5895"
/> (see also Section 7 of <xref target="RFC5894"/>)
or <xref target="UTS46" />.
If a user agent does not implement IDNA2008,
the user agent MUST implement IDNA2003.
</t>
</section> <!-- sctn-idna-dep -->
<section anchor="sctn-sec-cons" title="Security Considerations">
<!-- <t>This section is non-normative.</t> -->
<t>
This specification concerns the expression, conveyance, and enforcement
of the HSTS Policy.
The overall HSTS Policy threat model, including addressed and unaddressed
threats, is given in <xref target="sctn-threat-model"/>
"<xref target="sctn-threat-model" format="title"/>".
</t>
<t>
Additionally, the below sections discuss operational ramifications of the HSTS Policy,
provide feature rationale, discuss potential HSTS Policy misuse, and
highlight some known vulnerabilities in the HSTS Policy regime.
</t>
<section anchor="sctn-sec-cons-secure-transport"
title="Underlying Secure Transport Considerations">
<t>
This specification is fashioned to be independent of the
secure transport underlying HTTP. However, the threat analysis and
requirements in <xref target="sctn-overview"/>
"<xref target="sctn-overview" format="title"/>"
in fact presume TLS or SSL as
the underlying secure transport. Thus employment of HSTS
in the context of HTTP running over some other secure transport
protocol would require assessment of that secure transport
protocol's security model in conjunction with the specifics of how
HTTP is layered over it in order to assess HSTS's subsequent
security properties in that context.
</t>
</section>
<section anchor="sctn-sec-cons-nonconform-uas"
title="Non-Conformant User Agent Implications">
<t>
Non-conformant user agents ignore the Strict-Transport-Security
header field, thus non-conformant user agents do not address the
threats described in <xref target="sctn-threats-addr"/>
"<xref target="sctn-threats-addr" format="title"/>".
</t>
<t>
This means that the web application and its users wielding non-conformant UAs
will be vulnerable to both:
<list style="symbols">
<t>
Passive network attacks due to web site development and
deployment bugs:
<list style="empty">
<t>
For example, if the web application contains any
insecure, non-"https", references to the web
application server, and if not all of its cookies
are flagged as "Secure", then its cookies will be
vulnerable to passive network sniffing, and
potentially subsequent misuse of user credentials.
</t>
</list>
</t>
<t>
Active network attacks:
<list style="empty">
<t>
For example, if an attacker is able to place a
man-in-the-middle, secure transport connection
attempts will likely yield warnings to the user, but
without HSTS Policy being enforced, the present
common practice is to allow the user to
"click-through" and proceed. This renders the user
and possibly the web application open to abuse by
such an attacker.
</t>
</list>
</t>
</list>
This is essentially the status-quo for all web applications and their users
in the absence of HSTS Policy.
Since web application providers typically do not control the
type or version of UAs their web applications interact with,
the implication is that HSTS Host deployers must generally
exercise the same level of care to avoid web site
development and deployment bugs
(see <xref target="sctn-web-dvlp"/>)
as they would if they
were not asserting HSTS Policy.
</t>
</section>
<section anchor="sctn-sec-cons-proxies"
title="Ramifications of HSTS Policy Establishment only over Error-free Secure Transport">
<t>
The <xref target="user-agent-processing-model"
format="title"/> defined in <xref
target="user-agent-processing-model"/>, stipulates that a
host is initially noted as a Known HSTS Host, or that
updates are made to a Known HSTS Host's cached information,
only if the UA receives the STS header field over a secure
transport connection having no underlying secure transport
errors or warnings.
</t>
<t>
The rationale behind this is that if there is a
man-in-the-middle (MITM) -- whether a legitimately deployed
proxy
or an illegitimate entity -- it could cause various
mischief (see also <xref target="design-decision-faq"/>
"<xref target="design-decision-faq" format="title"/>", item
<xref target="design-hsts-policy-no-sec-trans-errors"
format="counter"/>, as well as
<xref target="sctn-sec-cons-boot"/>
"<xref target="sctn-sec-cons-boot" format="title"/>"),
for example:
<list style="symbols">
<t>
Unauthorized notation of the host as a Known HSTS Host,
potentially leading to a denial of service situation if
the host does not uniformly offer its services over
secure transport (see also <xref target="sctn-dos"/>
"<xref target="sctn-dos" format="title"/>").
</t>
<t>
Resetting the time-to-live for the host's designation as
a Known HSTS Host by manipulating the max-age header
field parameter value that is returned to the UA. If
max-age is returned as zero, this will cause the host to
cease being regarded as an Known HSTS Host by the UA,
leading to either insecure connections to the host or
possibly denial-of-service if the host delivers its
services only over secure transport.
</t>
</list>
</t>
<t>
However, this means that if a UA is "behind" a MITM
non-transparent TLS proxy --
within a corporate intranet, for example -- and interacts
with an unknown HSTS Host beyond the proxy, the user could
possibly be presented with the legacy secure connection
error dialogs. Even if the risk is accepted and the user
clicks-through, the host will not be noted as an HSTS Host.
Thus, as long as the UA is behind such a proxy the user will
be vulnerable, and possibly be presented with the legacy
secure connection error dialogs for as yet unknown HSTS
Hosts.
</t>
<t>
Once the UA successfully connects to an unknown HSTS
Host over error-free secure transport, the host will be
noted as a Known HSTS Host. This will result in the failure
of subsequent connection attempts from behind interfering
proxies.
</t>
<t>
The above discussion relates to the recommendation in <xref
target="sctn-ua-impl-advice"/> "<xref
target="sctn-ua-impl-advice" format="title"/>" that the
secure connection be terminated with "no user recourse"
whenever there are warnings and errors and the host is a
Known HSTS Host. Such a posture protects users from "clicking
through" security warnings and putting themselves at risk.
</t>
</section> <!-- sctn-sec-cons-proxies -->
<section anchor="sctn-sec-cons-includeSD"
title="The Need for includeSubDomains">
<t>
Without the includeSubDomains directive, a web application
would not be able to adequately protect so-called "domain
cookies" (even if these cookies have their "Secure" flag set
and thus are conveyed only on secure channels). These are
cookies the web application expects UAs to return to any and
all subdomains of the web application.
</t>
<t>
For example, suppose example.com represents the top-level
DNS name for a web application. Further suppose that this
cookie is set for the entire example.com domain, i.e. it is
a "domain cookie", and it has its Secure flag set. Suppose
example.com is a Known HSTS Host for this UA, but the
includeSubDomains directive is not set.
</t>
<t>
Now, if an attacker causes the UA to request a subdomain
name that is unlikely to already exist in the web
application, such as "https://uxdhbpahpdsf.example.com/",
but that the attacker has managed to register in
the DNS and point at an HTTP server under the attacker's control, then:
<list style="numbers">
<t>
The UA is unlikely to already have an HSTS Policy
established for "uxdhbpahpdsf.example.com", and,
</t>
<t>
The HTTP request sent to uxdhbpahpdsf.example.com will
include the Secure-flagged domain cookie.
</t>
<t>
If "uxdhbpahpdsf.example.com" returns a certificate
during TLS establishment, and the user clicks through
any warning that might be presented (it is possible,
but not certain, that one may obtain a requisite
certificate for such a domain name such that a warning
may or may not appear), then the attacker can obtain the
Secure-flagged domain cookie that's ostensibly being
protected.
</t>
</list> Without the "includeSubDomains" directive, HSTS is
unable to protect such Secure-flagged domain cookies.
</t>
</section> <!-- The Need for includeSubDomains -->
<section anchor="sctn-dos" title="Denial of Service">
<t>
HSTS could be used to mount certain forms of Denial-of-
Service (DoS) attacks against web sites. A DoS attack is an
attack in which one or more network entities target a victim
entity and attempt to prevent the victim from doing useful
work. This section discusses such scenarios in terms of
HSTS, though this list is not exhaustive. See also <xref
target="RFC4732"/> for a discussion of overall Internet
DoS considerations.
<list style="symbols">
<t>
Web applications available over HTTP
<vspace blankLines="1"/>
There is an opportunity for
perpetrating DoS attacks with web applications that are
-- or critical portions of them are -- available only
over HTTP without secure transport, if attackers can
cause UAs to set HSTS Policy for such web applications'
host(s).
<vspace blankLines="1"/>
This is because once the HSTS
Policy is set for a web application's host in a UA, the
UA will only use secure transport to communicate with
the host. If the host is not using secure transport, or
is not for critical portions of its web application,
then the web application will be rendered unusable for
the UA's user.
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
This is a use case for UAs to offer
a "HSTS Policy Deletion" feature as noted
in <xref target="sctn-ua-impl-adv-deletion"/>
"<xref target="sctn-ua-impl-adv-deletion" format="title"/>".
</t>
</list>
<vspace blankLines="1"/>
An HSTS Policy can be set for a
victim host in various ways:
<list style="symbols">
<t>
If the web application has a HTTP response splitting
vulnerability <xref target="CWE-113"/> (which can be
abused in order to facilitate "HTTP Header
Injection").
</t>
<t>
If an attacker can spoof a redirect from an insecure
victim site, e.g., <http://example.com/> to
<httpS://example.com/>, where the latter is
attacker-controlled and has an apparently valid
certificate, then the attacker can set an HSTS
Policy for example.com, and also for all subdomains
of example.com.
</t>
<t>
If an attacker can convince users to manually
configure HSTS Policy for a victim host. This assumes
their UAs offer such a capability (see <xref
target="sctn-ua-impl-advice"/> "<xref
target="sctn-ua-impl-advice"
format="title"/>"). Or, if such UA
configuration is scriptable, then an attacker can
cause UAs to execute his script and set HSTS Policies
for whichever desired domains.
</t>
</list>
</t>
<t>
Inadvertent use of includeSubDomains
<vspace blankLines="1"/>
The includeSubDomains directive
instructs UAs to automatically regard all subdomains of
the given HSTS Host as Known HSTS Hosts. If any such
subdomains do not support properly configured secure
transport, then they will be rendered unreachable from
such UAs.
</t>
</list>
</t>
</section> <!-- sctn-dos -->
<section anchor="sctn-sec-cons-boot" title="Bootstrap MITM Vulnerability">
<t>
The bootstrap MITM (Man-In-The-Middle) vulnerability is a
vulnerability users and HSTS Hosts encounter in the
situation where the user manually enters, or follows a link,
to an unknown HSTS Host using a "http" URI rather than a
"https" URI. Because the UA uses an insecure
channel in the initial attempt to interact with the
specified server, such an initial interaction is vulnerable
to various attacks (see Section 5.3 of <xref target="ForceHTTPS"/>).
</t>
<t>
<list style="hanging" hangIndent="7">
<t hangText="NOTE:">
There are various features/facilities that UA
implementations may employ in order to mitigate this
vulnerability. Please see <xref
target="sctn-ua-impl-advice"/> "<xref
target="sctn-ua-impl-advice" format="title"/>".
</t>
</list>
</t>
</section> <!-- sctn-sec-cons-boot -->
<section title="Network Time Attacks">
<t>
Active network attacks can subvert network time protocols
(such as Network Time Protocol (NTP) <xref target="RFC5905"/>)
- making HSTS less effective against clients
that trust NTP or lack a real time clock. Network time
attacks are beyond the scope of this specification. Note
that modern operating systems use NTP by default. See also
Section 2.10 of <xref target="RFC4732"/>.
</t>
</section> <!-- Network Time Attacks -->
<section anchor="sctn-sec-cons-bogus-ca"
title="Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack">
<t>
An attacker could conceivably obtain a victim HSTS-protected
web application's users'
login credentials via a bogus root CA certificate phish plus
DNS cache poisoning attack.
</t>
<t>
For example, the attacker could first convince users
of a victim web application
(which is protected by HSTS
Policy) to install the attacker's version of a root CA
certificate purporting (falsely) to represent the CA of the
victim web application.
This might be accomplished by
sending the users
a phishing email message with a link to such a certificate, which their
browsers may offer to install if clicked on.
</t>
<t>
Then, if the attacker can perform an attack on the users' DNS servers,
(e.g., via cache poisoning) and turn on HSTS Policy for their
fake web application, the affected users' browsers would access the
attackers' web application rather than the legitimate web application.
</t>
<t>
This type of attack leverages vectors
that are outside of the scope of HSTS.
However, the feasibility such threats can be mitigated by
including in a web application's overall deployment approach
appropriate employment, in addition to HSTS,
of security facilities such as DNS Security Extensions
<xref target="RFC4033"/>, plus techniques to
block email phishing and
fake certificate injection.
</t>
</section> <!-- sctn-sec-cons-bogus-ca -->
<section anchor="sctn-sec-cons-storage"
title="Creative Manipulation of HSTS Policy Store">
<t>
Since an HSTS Host may select its own host name and
subdomains thereof, and this information is cached in the
HSTS Policy store of conforming UAs, it is possible for
those who control an HSTS Host(s) to encode information into
domain names they control and cause such UAs to cache this
information as a matter of course in the process of noting
the HSTS Host. This information can be retrieved by
other hosts through clever loaded page construction causing the
UA to send queries to (variations of) the encoded domain names.
Such queries can reveal whether the UA had prior visited the
original HSTS Host (and subdomains).
</t>
<t>
Such a technique could potentially be abused as yet another
form of "web tracking" <xref target="WebTracking"/>.
</t>
</section>
<section anchor="sctn-sec-cons-idna"
title="Internationalized Domain Names">
<t>
Internet security relies in part on the DNS and the domain
names it hosts. Domain names are used by users to identify
and connect to Internet hosts and other network resources.
For example, Internet security is compromised if a user
entering an internationalized domain name (IDN) is connected
to different hosts based on different interpretations of the
IDN.
</t>
<t>
The processing models specified in this specification assume
that the domain names they manipulate are
IDNA-canonicalized, and that the canonicalization process
correctly performed all appropriate IDNA and Unicode
validations and character list testing per the requisite
specifications (e.g., as noted in <xref
target="sctn-force-tls-dns-name-canon"/> "<xref
target="sctn-force-tls-dns-name-canon"
format="title"/>"). These steps are necessary in
order to avoid various potentially compromising situations.
</t>
<t>
In brief, some examples of issues that could stem from lack
of careful and consistent Unicode and IDNA validations are
things such as unexpected processing exceptions, truncation
errors, and buffer overflows, as well as false-positive
and/or false-negative domain name matching results. Any of
the foregoing issues could possibly be leveraged by
attackers in various ways.
</t>
<t>
Additionally, IDNA2008 <xref target="RFC5890" /> differs
from IDNA2003 <xref target="RFC3490" /> in terms of
disallowed characters and character mapping conventions.
This situation can also lead to false-positive and/or
false-negative domain name matching results, resulting in,
for example, users possibly communicating with unintended
hosts, or not being able to reach intended hosts.
</t>
<t>
For details, refer to the Security Considerations sections
of <xref target="RFC5890" />, <xref target="RFC5891"/>, and
<xref target="RFC3490" />, as well as the specifications
they normatively reference. Additionally, <xref
target="RFC5894"/> provides detailed background and
rationale for IDNA2008 in particular, as well as IDNA and
its issues in general, and should be consulted in
conjunction with the former specifications.
</t>
</section> <!-- sctn-sec-cons-idna -->
</section> <!-- sctn-sec-cons -->
<section anchor="sec-iana-consid" title="IANA Considerations">
<t>
Below is the Internet Assigned Numbers Authority (IANA)
Permanent Message Header Field registration
information per <xref target="RFC3864" />.
</t>
<figure>
<artwork>
Header field name: Strict-Transport-Security
Applicable protocol: HTTP
Status: standard
Author/Change controller: IETF
Specification document(s): this one
</artwork>
</figure>
</section> <!-- sec-iana-consid -->
</middle>
<back>
<references title="Normative References">
<!-- <xref target="I-D.draft-ietf-httpbis-p1-messaging" /> -->
<!-- &I-D.draft-ietf-httpbis-p1-messaging-15; -->
<!-- <xref target="W3C.WD-html5-20100304" /> -->
<!-- &W3C.WD-html5-20100304; -->
<!-- <xref target="I-D.ietf-dane-protocol" /> -->
<!-- &I-D.ietf-dane-protocol; -->
&RFC.2119; <!-- <xref target="RFC2119"/> -->
<!-- &RFC.2396; --> <!-- <xref target="RFC2396"/> -->
&RFC.2616; <!-- <xref target="RFC2616"/> -->
&RFC.2818; <!-- <xref target="RFC2818"/> -->
<!-- &RFC.3490; --> <!-- <xref target="RFC3490"/> -->
<!-- &RFC.3492; --> <!-- <xref target="RFC3492"/> -->
<reference anchor='RFC3490'>
<front>
<title>Internationalizing Domain Names in Applications (IDNA)</title>
<author initials='P.' surname='Faltstrom' fullname='P. Faltstrom'>
<organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='A.' surname='Costello' fullname='A. Costello'>
<organization /></author>
<date year='2003' month='March' />
</front>
<seriesInfo name='RFC' value='3490' />
<format type='TXT' octets='51943' target='ftp://ftp.isi.edu/in-notes/rfc3490.txt' />
<annotation>
This specification is referenced due to its ongoing relevance to
actual deployments for the foreseeable future.
</annotation>
</reference>
<reference anchor='RFC3492'>
<front>
<title>Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)</title>
<author initials='A.' surname='Costello' fullname='A. Costello'>
<organization /></author>
<date year='2003' month='March' />
</front>
<seriesInfo name='RFC' value='3492' />
<format type='TXT' octets='67439' target='ftp://ftp.isi.edu/in-notes/rfc3492.txt' />
<annotation>
This specification is referenced due to its
ongoing relevance to actual deployments for the
foreseeable future.
</annotation>
</reference>
&RFC.3864; <!-- <xref target="RFC3864"/> -->
&RFC.3986; <!-- <xref target="RFC3986"/> -->
&RFC.5246; <!-- <xref target="RFC5246"/> -->
&RFC.5890; <!-- <xref target="RFC5890"/> -->
&RFC.5891; <!-- <xref target="RFC5891"/> -->
&RFC.5895; <!-- <xref target="RFC5895"/> -->
&RFC.6698; <!-- <xref target="RFC6698"/> -->
<!-- <xref target="W3C.REC-html401-19991224"/> -->
&W3C.REC-html401-19991224;
<!-- <xref target="Unicode" /> -->
<reference anchor="Unicode"
target="http://www.unicode.org/versions/latest/">
<front>
<title>The Unicode Standard</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date year="" />
</front>
<!--
<seriesInfo
name="Unicode 6.0.0, Mountain View, CA, The Unicode Consortium"
value="ISBN 978-1-936213-01-6" />
-->
</reference>
<reference anchor="UTS46" target="http://unicode.org/reports/tr46/">
<front>
<title>Unicode IDNA Compatibility Processing</title>
<author initials="M." surname="Davis" fullname="Mark Davis">
<organization />
</author>
<author initials="M." surname="Suignard" fullname="Michel Suignard">
<organization />
</author>
<!-- <date year="2010" /> -->
</front>
<seriesInfo name="Unicode Technical Standards" value="# 46" />
</reference>
<!--
<reference anchor='RFC2396'>
<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifiers (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='MIT/LCS'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email></address></author>
<author initials='R.T.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='U.C. Irvine'>Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Xerox Corporation'>Xerox PARC</organization>
<address>
<postal>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<facsimile>+1(415)812-4333</facsimile>
<email>masinter@parc.xerox.com</email></address></author>
<date year='1998' month='August' />
<area>Applications</area>
<keyword>uniform resource</keyword>
<keyword>URI</keyword>
</front>
<seriesInfo name='RFC' value='2396' />
<format type='TXT' octets='83639' target='ftp://ftp.isi.edu/in-notes/rfc2396.txt' />
<format type='HTML' octets='130223' target='http://xml.resource.org/public/rfc/html/rfc2396.html' />
<format type='XML' octets='104983' target='http://xml.resource.org/public/rfc/xml/rfc2396.xml' />
<annotation>
Normatively referenced due to dependence on
<xref target="RFC2616"/>.
</annotation>
</reference>
-->
</references>
<!-- ================== Informative References ===================== -->
<references title="Informative References">
<!-- &RFC.793; --> <!-- <xref target="RFC0793" /> -->
&RFC.1035; <!-- <xref target="RFC1035"/> -->
<!-- &RFC.3454;--> <!-- <xref target="RFC3454"/> -->
&RFC.2560; <!-- <xref target="RFC2560"/> -->
&RFC.4033; <!-- <xref target="RFC4033"/> -->
&RFC.4732; <!-- <xref target="RFC4732"/> -->
&RFC.4949; <!-- <xref target="RFC4949"/> -->
&RFC.5226; <!-- <xref target="RFC5226"/> -->
&RFC.5280; <!-- <xref target="RFC5280"/> -->
&RFC.5894; <!-- <xref target="RFC5894"/> -->
&RFC.5905; <!-- <xref target="RFC5905"/> -->
&RFC.6066; <!-- <xref target="RFC6066"/> -->
&RFC.6101; <!-- <xref target="RFC6101"/> -->
&RFC.6265; <!-- <xref target="RFC6265"/> -->
&RFC.6454; <!-- <xref target="RFC6454"/> -->
<!-- <xref target="Aircrack-ng"/> -->
<reference anchor="Aircrack-ng"
target="http://www.aircrack-ng.org/">
<front>
<title>
Aircrack-ng
</title>
<author initials="T" surname="d'Otreppe" fullname="">
<organization />
</author>
<date year=""/>
</front>
<seriesInfo name="Accessed:" value="11-Jul-2010" />
</reference>
<!-- <xref target="BeckTews09"/> -->
<reference anchor="BeckTews09"
target="http://wirelesscenter.dk/Crypt/wifi-security-attacks/Practical%20Attacks%20Against%20WEP%20and%20WPA.pdf">
<front>
<title>
Practical Attacks Against WEP and WPA
</title>
<author initials="M" surname="Beck" fullname="">
<organization />
</author>
<author initials="E" surname="Tews" fullname="">
<organization />
</author>
<date year="2009" />
</front>
<seriesInfo name="Second ACM Conference on Wireless Network Security" value="Zurich, Switzerland" />
</reference>
<!-- <xref target="CWE-113"/> -->
<reference anchor="CWE-113" target="http://cwe.mitre.org/data/definitions/113.html">
<front>
<title>CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')</title>
<author/>
<date year=""/>
</front>
<seriesInfo name="Common Weakness Enumeration" value="<http://cwe.mitre.org/>" />
<seriesInfo name="The Mitre Corporation" value="<http://www.mitre.org/>" />
<format target="http://cwe.mitre.org/data/definitions/113.html" type="HTML" />
</reference>
<!-- <xref target="Firesheep"/> -->
<reference anchor="Firesheep"
target="https://secure.wikimedia.org/wikipedia/en/wiki/Firesheep">
<front>
<title>
Firesheep
</title>
<author surname="Various" fullname="Various">
<organization />
</author>
<date year="on-going" />
</front>
<seriesInfo name="Wikipedia" value="Online" />
</reference>
<!-- <xref target="ForceHTTPS"/> -->
<reference anchor="ForceHTTPS" target="https://crypto.stanford.edu/forcehttps/">
<front>
<title>
ForceHTTPS:
Protecting High-Security Web Sites from Network
Attacks
</title>
<author initials="C" surname="Jackson" fullname="Collin Jackson">
<organization />
</author>
<author initials="A" surname="Barth" fullname="Adam Barth">
<organization />
</author>
<date month="" year="2008" />
</front>
<seriesInfo name="In Proceedings of
the 17th International World Wide Web Conference (WWW2008)" value="" />
</reference>
<!-- <xref target="GoodDhamijaEtAl05" /> -->
<reference anchor="GoodDhamijaEtAl05" target="http://people.ischool.berkeley.edu/~rachna/papers/spyware_study.pdf">
<front>
<title>
Stopping
Spyware at the Gate: A User Study of Privacy, Notice and
Spyware
</title>
<author initials="N" surname="Good" fullname="">
<organization />
</author>
<author initials="R" surname="Dhamija" fullname="">
<organization />
</author>
<author initials="J" surname="Grossklags" fullname="">
<organization />
</author>
<author initials="D" surname="Thaw" fullname="">
<organization />
</author>
<author initials="S" surname="Aronowitz" fullname="">
<organization />
</author>
<author initials="D" surname="Mulligan" fullname="">
<organization />
</author>
<author initials="J" surname="Konstan" fullname="">
<organization />
</author>
<date month="July" year="2005" />
</front>
<seriesInfo name="In Proceedings of
Symposium On Usable Privacy and Security (SOUPS)" value="Pittsburgh, PA, USA" />
</reference>
<!-- <xref target="JacksonBarth2008" /> -->
<reference anchor="JacksonBarth2008" target="http://www.adambarth.com/papers/2008/jackson-barth-b.pdf">
<front>
<title>
Beware of Finer-Grained Origins
</title>
<author initials="C" surname="Jackson" fullname="Collin Jackson">
<organization />
</author>
<author initials="A" surname="Barth" fullname="Adam Barth">
<organization />
</author>
<date year="2008" />
</front>
<seriesInfo name="Web 2.0 Security and Privacy" value="Oakland, CA, USA" />
</reference>
<!-- <xref target="I-D.ietf-tls-ssl-version3" /> -->
<!--
<reference anchor="I-D.ietf-tls-ssl-version3" target="http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00">
<front>
<title>
The SSL Protocol Version 3.0
</title>
<author initials="A" surname="Freier" fullname="">
<organization />
</author>
<author initials="P" surname="Karlton" fullname="">
<organization />
</author>
<author initials="P" surname="Kocher" fullname="">
<organization />
</author>
<date month="November" year="1996" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-ssl-version3-00" />
<annotation>This is the canonical reference for SSLv3.0.</annotation>
</reference>
-->
<!-- <xref target="MathewsHunt08" /> --> <!-- commented out
<reference anchor="MathewsHunt08"
target="http://www.cosc.canterbury.ac.nz/moffat.mathews/papers/moffatmathews-evolution-of-wireless-security.pdf">
<front>
<title>
EVOLUTION OF WIRELESS LAN SECURITY ARCHITECTURE TO IEEE
802.11i (WPA2)
</title>
<author initials="M" surname="Mathews" fullname="">
<organization />
</author>
<author initials="R" surname="Hunt" fullname="">
<organization />
</author>
</author>
<date year="2007" />
</front>
<seriesInfo name="IASTED Communication Systems and Networks" value="Phuket, Thailand" />
</reference>
-->
<!-- <xref target="SunshineEgelmanEtAl09" /> -->
<reference anchor="SunshineEgelmanEtAl09" target="http://www.usenix.org/events/sec09/tech/full_papers/sunshine.pdf">
<front>
<title>
Crying Wolf: An Empirical Study of SSL Warning Effectiveness
</title>
<author initials="J" surname="Sunshine" fullname="">
<organization />
</author>
<author initials="S" surname="Egelman" fullname="">
<organization />
</author>
<author initials="H" surname="Almuhimedi" fullname="">
<organization />
</author>
<author initials="N" surname="Atri" fullname="">
<organization />
</author>
<author initials="L" surname="Cranor" fullname="">
<organization />
</author>
<date month="Augus" year="2009" />
</front>
<seriesInfo name="In Proceedings of
18th USENIX Security Symposium" value="Montreal, Canada" />
</reference>
<!-- <xref target="owaspTLSGuide"/> -->
<reference anchor="owaspTLSGuide"
target="http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet">
<front>
<title>
Transport Layer Protection Cheat Sheet
</title>
<author initials="M" surname="Coates" fullname="">
<organization />
</author>
<author initials="d" surname="Wichers" fullname="">
<organization />
</author>
<author initials="M" surname="Boberski" fullname="">
<organization />
</author>
<author initials="T" surname="Reguly" fullname="">
<organization />
</author>
<date year=""/>
</front>
<seriesInfo name="Accessed:" value="11-Jul-2010" />
</reference>
<!-- <xref target="WebTracking"/> -->
<reference anchor="WebTracking"
target="http://www.snet.tu-berlin.de/fileadmin/fg220/courses/SS11/snet-project/web-tracking_schmuecker.pdf">
<front>
<title>Web Tracking</title>
<author initials="N." surname="Schmucker" fullname="Niklas Schmucker">
<organization>
Berlin University of Technology
</organization>
</author>
<date year="2011" />
</front>
<seriesInfo name="SNET2 Seminar Paper" value="Summer Term" />
</reference>
<!-- <xref target="W3C.REC-wsc-ui-20100812"/> -->
&W3C.REC-wsc-ui-20100812;
<!-- <xref target="WEBSEC"/> -->
<!--
<reference anchor="WEBSEC" target="https://www.ietf.org/mailman/listinfo/websec">
<front>
<title>WebSec -- HTTP Application Security Minus Authentication and Transport</title>
<author/>
<date year=""/>
</front>
<annotation>
Mailing list for IETF WebSec Working Group. [RFCEditor:
please remove this reference upon publication as an RFC.]
</annotation>
</reference>
-->
</references> <!-- informative -->
<section anchor="design-decision-faq" title="Design Decision Notes">
<!-- <t>This appendix is non-normative.</t> -->
<t>This appendix documents various design decisions.</t>
<t>
<list style="numbers">
<!-- 1 -->
<t>
Cookies aren't appropriate for HSTS Policy expression as
they are potentially mutable (while stored in the UA),
therefore an HTTP header field is employed.
</t>
<!-- 2 -->
<t>
We chose to not attempt to specify how "mixed
security context loads" (also known as "mixed content
loads") are handled due to UA implementation
considerations as well as classification difficulties.
</t>
<!-- 3 -->
<t anchor="design-hsts-policy-no-sec-trans-errors">
An HSTS Host may update UA notions of HSTS Policy via new
HSTS header field parameter values. We chose to have UAs
honor the "freshest" information received from a
server because there is the chance of a web site sending
out an erroneous HSTS Policy, such as a multi-year max-age
value, and/or an incorrect includeSubDomains directive. If the
HSTS Host couldn't correct such errors over protocol, it
would require some form of annunciation to users and
manual intervention on the users' part, which could be a
non-trivial problem for both web application providers and
their users.
</t>
<!-- 4 -->
<t>
HSTS Hosts are identified only via domain names --
explicit IP address identification of all forms is
excluded. This is for simplification and also is in
recognition of various issues with using direct IP address
identification in concert with PKI-based security.
</t>
<!-- 5 -->
<t>
The max-age approach of having the HSTS Host provide a simple
integer number of seconds for a cached HSTS Policy time-to-live value,
as opposed to an approach of stating an expiration time in the
future was chosen for various reasons. Amongst the reasons are
no need for clock synchronization, no need to define date and time
value syntaxes (specification simplicity), and implementation simplicity.
</t>
<!-- 6 -->
<t>
In determining whether port mapping was to be employed,
the option of merely refusing to dereference any URL with
an explicit port was considered. It was felt, though, that
the possibility that the URI to be dereferenced is
incorrect (and there is indeed a valid HTTPS server at
that port) is worth the small cost of possibly wasted
HTTPS fetches to HTTP servers.
</t>
</list>
</t>
</section> <!-- design-decision-faq -->
<section anchor="apdx-diff-same-origin-policy"
title="Differences between HSTS Policy and Same-Origin Policy">
<t>
HSTS Policy has the following primary characteristics:
<list>
<t>
HSTS Policy stipulates requirements for the security
characteristics of UA-to-host connection establishment, on
a per-host basis.
</t>
<t>
Hosts explicitly declare HSTS Policy to UAs.
Conformant UAs are obliged to implement hosts'
declared HSTS Policies.
</t>
<t>
HSTS Policy is conveyed over
protocol from the host to the UA.
</t>
<t>
The UA maintains a cache of Known HSTS Hosts.
</t>
<t>
UAs apply HSTS Policy whenever making a HTTP connection to
a Known HSTS Host, regardless of host port number. I.e.,
it applies to all ports on a Known HSTS Host. Hosts are
unable to affect this aspect of HSTS Policy.
</t>
<t>
Hosts may optionally declare that their HSTS Policy
applies to all subdomains of their host domain name.
</t>
</list>
</t>
<t>
In contrast, the Same-Origin Policy (SOP) <xref target="RFC6454"/>
has the following primary characteristics:
<list>
<t>
An origin is the scheme, host, and port of a URI identifying
a resource.
</t>
<t>
A UA may dereference a URI, thus loading a representation of
the resource the URI identifies.
UAs label resource representations with their origins, which
are derived from their URIs.
</t>
<t>
The SOP refers to a collection of
principles, implemented within UAs, governing the isolation of
and communication between resource representations
within the UA, as well as
resource representations' access to network resources.
</t>
</list>
In summary, although both HSTS Policy and SOP are enforced
by UAs, HSTS Policy is optionally declared by hosts and is
not origin-based, while the SOP applies to all
resource representations loaded from all hosts by conformant
UAs.
</t>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<!-- <t>This appendix is non-normative.</t> -->
<t>
The authors thank
Devdatta Akhawe,
Michael Barrett,
Ben Campbell,
Tobias Gondrom,
Paul Hoffman,
Murray Kucherawy,
Barry Leiba,
James Manger,
Alexey Melnikov,
Håvard Molland,
Yoav Nir,
Yngve N. Pettersen,
Laksh Raghavan,
Marsh Ray,
Julian Reschke,
Eric Rescorla,
Tom Ritter,
Peter Saint-Andre,
Brian Smith,
Robert Sparks,
Maciej Stachowiak,
Sid Stamm,
Andy Steingrubl,
Brandon Sterne,
Martin Thomson,
Daniel Veditz,
Jan Wrobel,
as well as all the websec working group participants and others
for
their various reviews and helpful contributions.
</t>
<t>
Thanks to Julian Reschke for his elegant re-writing of the
effective request URI text, which he did when incorporating
the ERU notion into the HTTPbis work. Subsequently, the ERU
text in this spec was lifted from Julian's work in the
updated HTTP/1.1 (part 1) specification
and adapted to the
<xref target="RFC2616"/> ABNF.
</t>
<!--
<t>Special thanks to ...</t>
-->
</section> <!-- acknowledgments -->
<section anchor="sctn-chg-log" title="Change Log">
<t>
[RFCEditor: please remove this section upon publication as an RFC.]
</t>
<t>
Changes are grouped by spec revision listed in reverse issuance order.
</t>
<section title="For draft-ietf-websec-strict-transport-sec">
<t>
<list>
<t>
Changes from -13 to -14:
<list style="numbers">
<t>
Added a new subsection entitled "Considerations for
Offering Unsecured HTTP Services at Alternate Ports
or Subdomains of an HSTS Host" to section 11.4
"Implications of includeSubDomains". This is
addresses Robert Sparks' Discuss point
(1): <eref
target="https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport-sec/ballot/#robert-sparks"/>
<vspace blankLines="1"/>
Also s/flag/directive/ for all uses of e.g.
"includeSubDomains flag", and noted that the presence
of an includeSubDomains directive in an STS header field
means it is "asserted".
</t>
<t>
Added a definition of an expired known HSTS Host, as well as a
stipulation that the UA must evict expired known
HSTS hosts from the cache (to section 8.1.1 "Noting an HSTS
Host - Storage Model"). Added an "unexpired" adjective appropriately
to section 8.2 "Known HSTS Host Domain Name Matching".
This is addresses Robert Sparks' Discuss point (2):
<eref
target="https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport-sec/ballot/#robert-sparks"/>
</t>
<t>
Added a note 14.4 reason for clients to consider
providing a way for users to remove entries from the
cache. This is addresses Robert Sparks'
first Comment: <eref
target="https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport-sec/ballot/#robert-sparks"/>
</t>
<t>
Noted in 2nd para of section 7.1 that HTTP is running over
secure transport.
This is addresses Robert Sparks' second comment ("nit"):
<eref
target="https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport-sec/ballot/#robert-sparks"/>
</t>
<t>
Struck the "or perhaps others" phrase from Section 7. Added
Section 14 "Underlying Secure Transport Considerations" to Sec Cons.
This is addresses a portion of Eric Rescorla's feedback.
</t>
<t>
Added a NOTE to Section 8.3 URI Loading and Port Mapping regarding
non-HTTPS servers running at non-standard ports identified in URIs.
Added item (6) to Appendix A explaining the port mapping design decision.
This addresses the other portion of EKR's feedback.
</t>
<!--
<t>
.
This addresses issue ticket #.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/"/>
</t>
<t>
.
This addresses issue ticket #.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/"/>
</t>
<t>
.
This addresses issue ticket #.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/"/>
</t>
-->
</list>
</t>
<t>
Changes from -12 to -13:
<list style="numbers">
<t>
Addressed the IANA registry and IANA registry policy
questions raised in Ben Campbel's Gen-ART LC review. Selected
"IETF Review" for IANA policy.
See the portion of this thread from this message onwards for details:
<eref
target="https://www.ietf.org/mail-archive/web/websec/current/msg01355.html"/>
</t>
<t>
Clarified the questions regarding max-age=0
interacting with includeSubdomains. Expanded section
5. HSTS Mechanism Overview, Added clarification text
and forward ref to S 8.1 from S 6.1.1. Added two
additional examples to S 6.2 which contain
max-age=0. See the thread rooted here for questions
that informed this: <eref
target="https://www.ietf.org/mail-archive/web/websec/current/msg01347.html"/>
</t>
<t>
upgraded ref to draft-ietf-dane-protocol to be to RFC6698.
</t>
</list>
</t>
<t>
Changes from -11 to -12:
<list style="numbers">
<t>
Addressed various issues in Ben Campbel's Gen-ART LC review.
See this message for details:
<eref
target="https://www.ietf.org/mail-archive/web/websec/current/msg01324.html"/>
</t>
</list>
</t>
<t>
Changes from -10 to -11:
<list style="numbers">
<t>
Various minor editorial fixes based on Barry Leiba's AD review, as
well as ID-Nits warnings.
</t>
<t>
Clarification addition of directive-name and directive-value
to Strict-Transport-Security ABNF in Section
6.1, from Barry's AD review.
<eref
target="https://www.ietf.org/mail-archive/web/websec/current/msg01265.html"/>
</t>
<t>
Moved ref to RFC5894 to Informational since it is a
truly informational reference.
</t>
</list>
</t>
<t>
Changes from -09 to -10:
<list style="numbers">
<t>
Added "(including when following HTTP redirects [RFC2616])"
to section 8.3.
This addresses issue ticket #47.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/47"/>
</t>
<t>
Fixed max-age value in section 10.1. Substituted 7776000 (actually
90 days) for 778000 (only 9 days).
This addresses issue ticket #48.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/48"/>
</t>
<t>
Added mention of "Certificate Status Request" TLS extension [RFC6066]
aka "OCSP stapling"
to example in section 10.3.
This addresses issue ticket #49.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/49"/>
</t>
<!--
<t>
.
This addresses issue ticket #.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/"/>
</t>
<t>
.
This addresses issue ticket #.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/"/>
</t>
<t>
.
This addresses issue ticket #.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/"/>
</t>
<t>
.
This addresses issue ticket #.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/"/>
</t>
-->
</list>
</t>
<t>
Changes from -08 to -09:
<list style="numbers">
<t>
Added IESG Note to Section 3 "Conformance Criteria"
per Barry Leiba's suggestion on the mailing list.
<eref
target="https://www.ietf.org/mail-archive/web/websec/current/msg01200.html"/>
</t>
<t>
Added additional requirement #5 to
requirements for STS header field directives in Section 6.1
per Alexey's review.
This completes the addressing of issue ticket #45.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/45"/>
</t>
<t>
Addressed editorial feedback in Murray's AppsDir review of
-06.
<vspace blankLines="1"/>
Most all of these changes were addressing detailed/small editorial items,
however note the addition of a couple of introductory paragraphs
in the Security Considerations section, as well as a re-written
and expanded Section 14.6 "Bogus Root CA Certificate Phish
plus DNS Cache Poisoning Attack", as well the new item #5 to
Appendix A "Design Decision Notes".
<vspace blankLines="1"/>
This addresses issue ticket #46.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/46"/>
</t>
</list>
</t>
<t>
Changes from -07 to -08:
<list style="numbers">
<t>
Clarified requirement #4 for STS header field directives in Section 6.1,
and removed "(which "update" this specification)".
Also added explicit "max-age=0" to Section 6.1.1.
Reworked final sentence in 2nd para of Section 13.
This addresses issue ticket #45.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/45"/>
</t>
</list>
</t>
<t>
Changes from -06 to -07:
<list style="numbers">
<t>
Various minor/modest editorial tweaks throughout as
I went through it pursuing the below issue
tickets. Viewing a visual diff against -06 revision
recommended.
</t>
<t>
fixed some minor editorial issues noted in review
by Alexey, fixes noted in here:
<eref
target="https://www.ietf.org/mail-archive/web/websec/current/msg01163.html"/>
</t>
<t>
Addressed ABNF exposition issues, specifically inclusion of
quoted-string syntax for directive values. Fix STS header
ABNF such that a leading ";" isn't required. Add example of
quoted-string-encoded max-age-value.
This addresses (re-opened) issue ticket #33.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/33"/>
</t>
<t>
Reworked sections 8.1 through 8.3 to ensure matching algorithm
and resultant HSTS Policy application is more clear, and that
it is explicitly stipulated to not muck with attributes of
superdomain matching
Known HSTS Hosts.
This addresses issue ticket #37.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/37"/>
</t>
<t>
Added reference to draft-ietf-dane-protocol,
pared back extraneous discussion in section 2.2,
and updated discussion in 10.2 to accomodate
TLSA (nee DANE).
This addresses issue ticket #39.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/39"/>
</t>
<t>
Addressed various editorial items from issue ticket #40.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/40"/>
</t>
<t>
Loosened up the language regarding redirecting "http" requests
to "https" in section 7.2 such that future flavors of
permanent redirects are accommodated.
This addresses issue ticket #43.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/43"/>
</t>
<t>
Reworked the terminology and language in Section 9, in particular
defining the term "putative domain name string" to replace
"valid Unicode-encoded string-serialized domain name".
This addresses issue ticket #44.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/44"/>
</t>
</list>
</t>
<t>
Changes from -05 to -06:
<list style="numbers">
<t>
Addressed various editorial comments provided by Tobias G.
This addresses issue ticket #38.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/38"/>
</t>
</list>
</t>
<t>
Changes from -04 to -05:
<list style="numbers">
<t>
Fixed up references to move certain ones back to the
normative section -- as requested by Alexey M. Added
explanation for referencing obsoleted <xref
target="RFC3490"/> and <xref
target="RFC3492"/>. This addresses issue ticket #36.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/36"/>
</t>
<t>
Made minor change to Strict-Transport-Security header field
ABNF in order to address further feedback as appended
to ticket #33. This addresses issue ticket #33.
<eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/33"/>
</t>
</list>
</t>
<t>
Changes from -03 to -04:
<list style="numbers">
<t>
Clarified that max-age=0 will cause UA to forget a known HSTS Host, and
more generally clarified that the "freshest" info from the HSTS Host
is cached, and thus HSTS Hosts are able to alter the cached max-age in UAs.
This addresses issue ticket #13.
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/13"/>
</t>
<t>
Updated section on "Constructing an Effective
Request URI" to remove remaining reference to RFC3986
and reference RFC2616 instead.
Further addresses issue ticket #14. <eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/14"/>
</t>
<t>
Addresses further ABNF issues noted in comment:1 of issue ticket #27.
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/27#comment:1"/>
</t>
<t>
Reworked the introduction to clarify the denotation of "HSTS Policy"
and added the new Appendix B summarizing the primary characteristics
of HSTS Policy and Same-Origin Policy, and identifying their
differences. Added ref to <xref
target="RFC4732"/>.
This addresses issue ticket #28.
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/28"/>
</t>
<t>
Reworked language in <xref
target="sctn-web-dvlp"/>. wrt "mixed content", more
clearly explain such vulnerability, disambiguate
"mixed content" in web security context from its
usage in markup language context. This addresses
issue ticket #29. <eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/29"/>
</t>
<t>
Expanded Denial of Service discussion in Security
Considerations. Added refs to <xref
target="RFC4732"/> and <xref target="CWE-113"/>.
This addresses
issue ticket #30. <eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/30"/>
</t>
<t>
Mentioned in prose the case-insensitivity of directive names.
This addresses
issue ticket #31. <eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/31"/>
</t>
<t>
Added <xref target="sctn-incudesubdomains-cons"/> "<xref
target="sctn-incudesubdomains-cons" format="title"/>".
This addresses issue ticket #32. <eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/32"/>
</t>
<t>
Further refines text and ABNF definitions of
STS header field directives.
Retains use of quoted-string in directive grammar.
This addresses issue ticket #33. <eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/33"/>
</t>
<t>
Added <xref target="sctn-sec-cons-storage"/> "<xref
target="sctn-sec-cons-storage" format="title"/>",
including reference to <xref target="WebTracking"/>.
This addresses issue ticket #34. <eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/34"/>
</t>
<t>
Added <xref target="sctn-sec-cons-proxies"/> "<xref
target="sctn-sec-cons-proxies" format="title"/>" and
made some accompanying editorial fixes in some other
sections. This addresses issue ticket #35. <eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/35"/>
</t>
<t>
Refined references. Cleaned out un-used ones, updated to
latest RFCs for others, consigned many to Informational.
This addresses issue ticket #36. <eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/36"/>
</t>
<!--
<t>
</t>
<t>
</t>
-->
<t>
Fixed-up some inaccuracies in the "Changes from -02 to -03" section.
</t>
</list>
</t>
<t>
Changes from -02 to -03:
<list style="numbers">
<t>
Updated section on "Constructing an Effective Request URI" to remove
references to RFC3986. Addresses issue ticket #14.
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/14"/>
</t>
<t>
Reference RFC5890 for IDNA, retaining subordinate refs to RFC3490.
Updated IDNA-specific language, e.g. domain name
canonicalization and IDNA dependencies.
Addresses
issue ticket #26
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/26"/>.
</t>
<t>
Completely re-wrote the STS header ABNF to be fully
based on RFC2616, rather than a hybrid of RFC2616
and httpbis.
Addresses
issue ticket #27
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/27"/>.
</t>
</list>
</t>
<t>
Changes from -01 to -02:
<list style="numbers">
<t>
Updated <xref target="sctn-uri-load-port-map"/>
"<xref target="sctn-uri-load-port-map" format="title"/>"
fairly thoroughly in terms of refining the presentation of the steps,
and to ensure the various aspects of port mapping are clear.
Nominally fixes issue ticket #1
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/1"/>
</t>
<t>
Removed dependencies on
[I-D.draft-ietf-httpbis-p1-messaging-15]. Thus
updated STS ABNF in <xref
target="sctn-syntax-grammar"/> "<xref
target="sctn-syntax-grammar" format="title"/>"
by lifting some productions entirely from
[I-D.draft-ietf-httpbis-p1-messaging-15] and
leveraging <xref target="RFC2616"/>. Addresses
issue ticket #2
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/2"/>.
</t>
<t>
Updated Effective Request URI section and definition
to use language from
[I-D.draft-ietf-httpbis-p1-messaging-15] and ABNF
from <xref target="RFC2616"/>. Fixes issue ticket
#3
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/3"/>.
</t>
<t>
Added explicit mention that the HSTS Policy applies to all TCP
ports of a host advertising the HSTS Policy.
Nominally fixes issue ticket #4
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/4"/>
</t>
<t>
Clarified the need for the "includeSubDomains"
directive, e.g. to protect Secure-flagged domain
cookies. In <xref
target="sctn-sec-cons-includeSD"/> "<xref
target="sctn-sec-cons-includeSD" format="title"/>".
Nominally fixes issue ticket #5 <eref
target="http://trac.tools.ietf.org/wg/websec/trac/ticket/5"/>
</t>
<t>
Cited Firesheep as real-live threat
in <xref target="sctn-psv-net-atkr"/>
"<xref target="sctn-psv-net-atkr" format="title"/>".
Nominally fixes issue ticket #6
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/6"/>.
</t>
<t>
Added text to
<xref
target="sctn-ua-impl-advice"/> "<xref
target="sctn-ua-impl-advice" format="title"/>"
justifying connection termination due to tls warnings/errors.
Nominally fixes issue ticket #7
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/7"/>.
</t>
<t>
Added new subsection
<xref target="sctn-missing-hsts-header"/>
"<xref target="sctn-missing-hsts-header" format="title"/>".
Nominally fixes issue ticket #8
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/8"/>.
</t>
<t>
Added text to
<xref target="sctn-err-tls-estab"/>
"<xref target="sctn-err-tls-estab" format="title"/>"
explicitly note revocation check failures as errors causing connection termination.
Added references to <xref target="RFC5280"/> and <xref target="RFC2560"/>.
Nominally fixes issue ticket #9
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/9"/>.
</t>
<t>
Added a sentence, noting that distributing specific
end-entity certificates to browsers will also work for self-signed/private-CA
cases, to
<xref target="sctn-hosting-spec-advice"/>
"<xref target="sctn-hosting-spec-advice" format="title"/>"
Nominally fixes issue ticket #10
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/10"/>.
</t>
<t>
Moved "with no user recourse" language from
<xref target="sctn-err-tls-estab"/>
"<xref target="sctn-err-tls-estab" format="title"/>" to
<xref target="sctn-ua-impl-advice"/>
"<xref target="sctn-ua-impl-advice" format="title"/>".
This nominally fixes issue ticket #11
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/11"/>.
</t>
<t>
Removed any and all dependencies on [I-D.draft-ietf-httpbis-p1-messaging-15], instead
depending on <xref target="RFC2616"/> only.
Fixes issue ticket #12
<eref target="http://trac.tools.ietf.org/wg/websec/trac/ticket/12"/>.
</t>
<t>
Removed the inline "XXX1" issue because no one had commented on it and it seems reasonable
to suggest as a SHOULD that web apps should redirect incoming insecure connections to
secure connections.
</t>
<t>
Removed the inline "XXX2" issue because it was simply for raising consciousness about
having some means for distributing secure web application metadata.
</t>
<t>
Removed "TODO1" because description prose for "max-age" in the
Note following the ABNF in <xref target="sctn-syntax"/>
seems to be fine.
</t>
<t>
Decided for "TODO2" that "the first STS header field wins". TODO2 had read:
"Decide UA behavior in face of encountering multiple HSTS headers in a message.
Use first header? Last?". Removed TODO2.
</t>
<t>
Added
<xref target="intro-organization"/>
"<xref target="intro-organization" format="title"/>"
for readers' convenience.
</t>
<t>
Moved design decision notes to be a proper appendix <xref target="design-decision-faq"/>.
</t>
</list>
</t>
<t>
Changes from -00 to -01:
<list style="numbers">
<t>
Changed the "URI Loading" section to be "URI Loading and Port Mapping".
</t>
<t>
(HASMAT) reference changed to (WEBSEC).
</t>
<t>
Changed "server" -> "host" where applicable, notably when
discussing "HSTS Hosts". Left as "server" when discussing
e.g. "http server"s.
</t>
<t>
Fixed minor editorial nits.
</t>
</list>
</t>
<t>
Changes from draft-hodges-strict-transport-sec-02 to draft-ietf-websec-strict-transport-sec-00:
<list style="numbers">
<t>
Altered spec metadata (e.g. filename, date)
in order to submit as a WebSec working group Internet-Draft.
</t>
</list>
</t>
</list>
</t>
</section>
<section title="For draft-hodges-strict-transport-sec">
<t>
<list>
<t>
Changes from -01 to -02:
<list style="numbers">
<t>
updated abstract such that means for expressing HSTS
Policy other than via HSTS header field is noted.
</t>
<t>
Changed spec title to "HTTP Strict Transport
Security (HSTS)" from "Strict Transport Security".
Updated use of "STS" acronym throughout spec to HSTS
(except for when specifically discussing syntax of
Strict-Transport-Security HTTP Response Header
field), updated "Terminology"
appropriately.
</t>
<t>
Updated the discussion of "Passive Network
Attackers" to be more precise and offered
references.
</t>
<t>
Removed para on nomative/non-normative from
"Conformance Criteria" pending polishing
said section to IETF RFC norms.
</t>
<t>
Added examples subsection to "Syntax"
section.
</t>
<t>
Added OWS to maxAge production in
Strict-Transport-Security ABNF.
</t>
<t>
Cleaned up explanation in the "Note:" in
the "HTTP-over-Secure-Transport Request
Type" section, folded 3d para into
"Note:", added conformance clauses to the
latter.
</t>
<t>
Added exaplanatory "Note:" and reference
to "HTTP Request Type" section. Added
"XXX1" issue.
</t>
<t>
Added conformance clause to "URI Loading".
</t>
<t>
Moved "Notes for STS Server implementers:"
from "UA Implementation dvice " to
"HSTS Policy expiration time
considerations:" in "Server Implementation
Advice", and also noted another option.
</t>
<t>
Added cautionary "Note:" to "Ability
to delete UA's cached HSTS Policy on a per HSTS
Server basis".
</t>
<t>
Added some informative references.
</t>
<t>
Various minor editorial fixes.
</t>
</list>
</t>
<t>
Changes from -00 to -01:
<list style="numbers">
<t>
Added reference to HASMAT mailing list and request
that this spec be discussed there.
</t>
</list>
</t>
</list>
</t>
</section>
</section> <!-- Change Log -->
</back>
</rfc>
<!-- PLEASE DO NOT DELETE!!! The below is used by XEmacs XML major-mode -->
<!--
Local Variables:
mode: xml
indent-tabs-mode:nil
sgml-omittag:t
sgml-shorttag:t
sgml-namecase-general:t
sgml-general-insert-case:lower
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:2
sgml-indent-data:t
sgml-parent-document:nil
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
-->
<!-- PLEASE DO NOT DELETE!!! The above is used by XEmacs XML major-mode -->
| PAFTECH AB 2003-2026 | 2026-04-22 22:09:21 |