idnits 2.17.1 draft-ietf-websec-strict-transport-sec-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Sep 29, 2012) is 4221 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.draft-ietf-httpbis-p1-messaging-15' is mentioned on line 2389, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 5895 -- Possible downref: Non-RFC (?) normative reference: ref. 'UTS46' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBSEC Working Group J. Hodges 3 Internet-Draft PayPal 4 Intended status: Standards Track C. Jackson 5 Expires: April 2, 2013 Carnegie Mellon University 6 A. Barth 7 Google, Inc. 8 Sep 29, 2012 10 HTTP Strict Transport Security (HSTS) 11 draft-ietf-websec-strict-transport-sec-14 13 Abstract 15 This specification defines a mechanism enabling web sites to declare 16 themselves accessible only via secure connections, and/or for users 17 to be able to direct their user agent(s) to interact with given sites 18 only over secure connections. This overall policy is referred to as 19 HTTP Strict Transport Security (HSTS). The policy is declared by web 20 sites via the Strict-Transport-Security HTTP response header field, 21 and/or by other means, such as user agent configuration, for example. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 2, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.1. Organization of this specification . . . . . . . . . . . 6 59 1.2. Document Conventions . . . . . . . . . . . . . . . . . . 6 60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.2. HTTP Strict Transport Security Policy Effects . . . . . . 7 63 2.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . 7 64 2.3.1. Threats Addressed . . . . . . . . . . . . . . . . . . 7 65 2.3.1.1. Passive Network Attackers . . . . . . . . . . . . 7 66 2.3.1.2. Active Network Attackers . . . . . . . . . . . . . 8 67 2.3.1.3. Web Site Development and Deployment Bugs . . . . . 8 68 2.3.2. Threats Not Addressed . . . . . . . . . . . . . . . . 9 69 2.3.2.1. Phishing . . . . . . . . . . . . . . . . . . . . . 9 70 2.3.2.2. Malware and Browser Vulnerabilities . . . . . . . 9 71 2.4. Requirements . . . . . . . . . . . . . . . . . . . . . . 9 72 2.4.1. Overall Requirement . . . . . . . . . . . . . . . . . 9 73 2.4.1.1. Detailed Core Requirements . . . . . . . . . . . . 9 74 2.4.1.2. Detailed Ancillary Requirements . . . . . . . . . 10 75 3. Conformance Criteria . . . . . . . . . . . . . . . . . . . . . 11 76 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 5. HSTS Mechanism Overview . . . . . . . . . . . . . . . . . . . 13 78 5.1. HSTS Host Declaration . . . . . . . . . . . . . . . . . . 13 79 5.2. HSTS Policy . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.3. HSTS Policy Storage and Maintenance by User Agents . . . 14 81 5.4. User Agent HSTS Policy Enforcement . . . . . . . . . . . 14 82 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 6.1. Strict-Transport-Security HTTP Response Header Field . . 15 84 6.1.1. The max-age Directive . . . . . . . . . . . . . . . . 16 85 6.1.2. The includeSubDomains Directive . . . . . . . . . . . 16 86 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 16 87 7. Server Processing Model . . . . . . . . . . . . . . . . . . . 17 88 7.1. HTTP-over-Secure-Transport Request Type . . . . . . . . . 17 89 7.2. HTTP Request Type . . . . . . . . . . . . . . . . . . . . 18 90 8. User Agent Processing Model . . . . . . . . . . . . . . . . . 18 91 8.1. Strict-Transport-Security Response Header Field 92 Processing . . . . . . . . . . . . . . . . . . . . . . . 19 93 8.1.1. Noting an HSTS Host - Storage Model . . . . . . . . . 20 94 8.2. Known HSTS Host Domain Name Matching . . . . . . . . . . 20 95 8.3. URI Loading and Port Mapping . . . . . . . . . . . . . . 21 96 8.4. Errors in Secure Transport Establishment . . . . . . . . 22 97 8.5. HTTP-Equiv Element Attribute . . . . . . . . . . . 22 98 8.6. Missing Strict-Transport-Security Response Header 99 Field . . . . . . . . . . . . . . . . . . . . . . . . . . 23 100 9. Constructing an Effective Request URI . . . . . . . . . . . . 23 101 9.1. ERU Fundamental Definitions . . . . . . . . . . . . . . . 23 102 9.2. Determining the Effective Request URI . . . . . . . . . . 23 103 9.2.1. Effective Request URI Examples . . . . . . . . . . . . 24 104 10. Domain Name IDNA-Canonicalization . . . . . . . . . . . . . . 25 105 11. Server Implementation and Deployment Advice . . . . . . . . . 25 106 11.1. Non-Conformant User Agent Considerations . . . . . . . . 25 107 11.2. HSTS Policy expiration time considerations . . . . . . . 26 108 11.3. Using HSTS in conjunction with self-signed public-key 109 certificates . . . . . . . . . . . . . . . . . . . . . . 26 110 11.4. Implications of includeSubDomains . . . . . . . . . . . . 27 111 11.4.1. Considerations for Offering Unsecured HTTP 112 Services at Alternate Ports or Subdomains of an 113 HSTS Host . . . . . . . . . . . . . . . . . . . . . . 28 114 11.4.2. Considerations for Offering Web Applications at 115 Subdomains of an HSTS Host . . . . . . . . . . . . . . 29 116 12. User Agent Implementation Advice . . . . . . . . . . . . . . . 29 117 12.1. No User Recourse . . . . . . . . . . . . . . . . . . . . 30 118 12.2. User-declared HSTS Policy . . . . . . . . . . . . . . . . 30 119 12.3. HSTS Pre-Loaded List . . . . . . . . . . . . . . . . . . 30 120 12.4. Disallow Mixed Security Context Loads . . . . . . . . . . 31 121 12.5. HSTS Policy Deletion . . . . . . . . . . . . . . . . . . 31 122 13. Internationalized Domain Names for Applications (IDNA): 123 Dependency and Migration . . . . . . . . . . . . . . . . . . . 31 124 14. Security Considerations . . . . . . . . . . . . . . . . . . . 32 125 14.1. Underlying Secure Transport Considerations . . . . . . . 32 126 14.2. Non-Conformant User Agent Implications . . . . . . . . . 32 127 14.3. Ramifications of HSTS Policy Establishment only over 128 Error-free Secure Transport . . . . . . . . . . . . . . . 33 129 14.4. The Need for includeSubDomains . . . . . . . . . . . . . 34 130 14.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 35 131 14.6. Bootstrap MITM Vulnerability . . . . . . . . . . . . . . 36 132 14.7. Network Time Attacks . . . . . . . . . . . . . . . . . . 36 133 14.8. Bogus Root CA Certificate Phish plus DNS Cache 134 Poisoning Attack . . . . . . . . . . . . . . . . . . . . 36 135 14.9. Creative Manipulation of HSTS Policy Store . . . . . . . 37 136 14.10. Internationalized Domain Names . . . . . . . . . . . . . 37 137 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 138 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 139 16.1. Normative References . . . . . . . . . . . . . . . . . . 38 140 16.2. Informative References . . . . . . . . . . . . . . . . . 40 141 Appendix A. Design Decision Notes . . . . . . . . . . . . . . . . 42 142 Appendix B. Differences between HSTS Policy and Same-Origin 143 Policy . . . . . . . . . . . . . . . . . . . . . . . 43 145 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . . 44 146 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 45 147 D.1. For draft-ietf-websec-strict-transport-sec . . . . . . . 45 148 D.2. For draft-hodges-strict-transport-sec . . . . . . . . . . 53 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 151 1. Introduction 153 The HTTP protocol [RFC2616] may be used over various transports, 154 typically the Transmission Control Protocol (TCP). However, TCP does 155 not provide channel integrity protection, confidentiality, nor secure 156 host identification. Thus, the Secure Sockets Layer (SSL) protocol 157 [RFC6101], and its successor Transport Layer Security (TLS) 158 [RFC5246], were developed in order to provide channel-oriented 159 security, and are typically layered between application protocols and 160 TCP. [RFC2818] specifies how HTTP is layered onto TLS, and defines 161 the Uniform Resource Identifier (URI) scheme of "https" (in practice 162 however, HTTP user agents (UAs) typically use either TLS or SSL3 163 depending upon a combination of negotiation with the server and user 164 preferences). 166 UAs employ various local security policies with respect to the 167 characteristics of their interactions with web resources depending on 168 (in part) whether they are communicating with a given web resource's 169 host using HTTP or HTTP-over-a-Secure-Transport. For example, 170 cookies ([RFC6265]) may be flagged as Secure. UAs are to send such 171 Secure cookies to their addressed host only over a secure transport. 172 This is in contrast to non-Secure cookies, which are returned to the 173 host regardless of transport (although subject to other rules). 175 UAs typically announce to their users any issues with secure 176 connection establishment, such as being unable to validate a TLS 177 server certificate trust chain, or if a TLS server certificate is 178 expired, or if a TLS host's domain name appears incorrectly in the 179 TLS server certificate (see Section 3.1 of [RFC2818]). Often, UAs 180 enable users to elect to continue to interact with a web resource's 181 host in the face of such issues. This behavior is sometimes referred 182 to as "click(ing) through" security [GoodDhamijaEtAl05] 183 [SunshineEgelmanEtAl09], and thus can be described as "click-through 184 insecurity". 186 A key vulnerability enabled by click-through insecurity is the 187 leaking of any cookies the web resource may be using to manage a 188 user's session. The threat here is that an attacker could obtain the 189 cookies and then interact with the legitimate web resource while 190 impersonating the user. 192 Jackson and Barth proposed an approach, in [ForceHTTPS], to enable 193 web resources to declare that any interactions by UAs with the web 194 resource must be conducted securely, and that any issues with 195 establishing a secure transport session are to be treated as fatal 196 and without direct user recourse. The aim is to prevent click- 197 through insecurity, and address other potential threats. 199 This specification embodies and refines the approach proposed in 200 [ForceHTTPS]. For example, rather than using a cookie to convey 201 policy from a web resource's host to a UA, it defines an HTTP 202 response header field for this purpose. Additionally, a web 203 resource's host may declare its policy to apply to the entire domain 204 name subtree rooted at its host name. This enables HSTS to protect 205 so-called "domain cookies", which are applied to all subdomains of a 206 given web resource's host name. 208 This specification also incorporates notions from [JacksonBarth2008] 209 in that policy is applied on an "entire-host" basis: it applies to 210 HTTP (only) over any TCP port of the issuing host. 212 Note that the policy defined by this specification is distinctly 213 different than the "same-origin policy" defined in "The Web Origin 214 Concept" [RFC6454]. These differences are summarized below in 215 Appendix B. 217 1.1. Organization of this specification 219 This specification begins with an overview of the use cases, policy 220 effects, threat models, and requirements for HSTS (in Section 2). 221 Then, Section 3 defines conformance requirements. The HSTS mechanism 222 itself is formally specified in Section 4 through Section 15. 224 1.2. Document Conventions 226 NOTE: This is a note to the reader. These are points that should be 227 expressly kept in mind and/or considered. 229 2. Overview 231 This section discusses the use cases, summarizes the HTTP Strict 232 Transport Security (HSTS) policy, and continues with a discussion of 233 the threat model, non-addressed threats, and derived requirements. 235 2.1. Use Cases 237 The high-level use case is a combination of: 239 o Web browser user wishes to interact with various web sites (some 240 arbitrary, some known) in a secure fashion. 242 o Web site deployer wishes to offer their site in an explicitly 243 secure fashion for both their own, as well as their users', 244 benefit. 246 2.2. HTTP Strict Transport Security Policy Effects 248 The effects of the HTTP Strict Transport Security (HSTS) Policy, as 249 applied by a conformant UA in interactions with a web resource host 250 wielding such policy (known as an HSTS Host), are summarized as 251 follows: 253 1. UAs transform insecure URI references to an HSTS Host into secure 254 URI references before dereferencing them. 256 2. The UA terminates any secure transport connection attempts upon 257 any and all secure transport errors or warnings. 259 2.3. Threat Model 261 HSTS is concerned with three threat classes: passive network 262 attackers, active network attackers, and imperfect web developers. 263 However, it is explicitly not a remedy for two other classes of 264 threats: phishing and malware. Addressed and not addressed threats 265 are briefly discussed below. Readers may wish to refer to Section 2 266 of [ForceHTTPS] for details as well as relevant citations. 268 2.3.1. Threats Addressed 270 2.3.1.1. Passive Network Attackers 272 When a user browses the web on a local wireless network (e.g., an 273 802.11-based wireless local area network) a nearby attacker can 274 possibly eavesdrop on the user's unencrypted Internet Protocol-based 275 connections, such as HTTP, regardless of whether or not the local 276 wireless network itself is secured [BeckTews09]. Freely available 277 wireless sniffing toolkits (e.g., [Aircrack-ng]) enable such passive 278 eavesdropping attacks, even if the local wireless network is 279 operating in a secure fashion. A passive network attacker using such 280 tools can steal session identifiers/cookies and hijack the user's web 281 session(s), by obtaining cookies containing authentication 282 credentials [ForceHTTPS]. For example, there exist widely-available 283 tools, such as Firesheep (a web browser extension) [Firesheep], which 284 enable their wielder to obtain other local users' session cookies for 285 various web applications. 287 To mitigate such threats, some Web sites support, but usually do not 288 force, access using end-to-end secure transport -- e.g., signaled 289 through URIs constructed with the "https" scheme [RFC2818]. This can 290 lead users to believe that accessing such services using secure 291 transport protects them from passive network attackers. 292 Unfortunately, this is often not the case in real-world deployments 293 as session identifiers are often stored in non-Secure cookies to 294 permit interoperability with versions of the service offered over 295 insecure transport ("Secure cookies" are those cookies containing the 296 "Secure" attribute [RFC6265]). For example, if the session 297 identifier for a web site (an email service, say) is stored in a non- 298 Secure cookie, it permits an attacker to hijack the user's session if 299 the user's UA makes a single insecure HTTP request to the site. 301 2.3.1.2. Active Network Attackers 303 A determined attacker can mount an active attack, either by 304 impersonating a user's DNS server or, in a wireless network, by 305 spoofing network frames or offering a similarly-named evil twin 306 access point. If the user is behind a wireless home router, an 307 attacker can attempt to reconfigure the router using default 308 passwords and other vulnerabilities. Some sites, such as banks, rely 309 on end-to-end secure transport to protect themselves and their users 310 from such active attackers. Unfortunately, browsers allow their 311 users to easily opt-out of these protections in order to be usable 312 for sites that incorrectly deploy secure transport, for example by 313 generating and self-signing their own certificates (without also 314 distributing their certification authority (CA) certificate to their 315 users' browsers). 317 2.3.1.3. Web Site Development and Deployment Bugs 319 The security of an otherwise uniformly secure site (i.e. all of its 320 content is materialized via "https" URIs), can be compromised 321 completely by an active attacker exploiting a simple mistake, such as 322 the loading of a cascading style sheet or a SWF (Shockwave Flash) 323 movie over an insecure connection (both cascading style sheets and 324 SWF movies can script the embedding page, to the surprise of many web 325 developers, plus some browsers do not issue so-called "mixed content 326 warnings" when SWF files are embedded via insecure connections). 327 Even if the site's developers carefully scrutinize their login page 328 for "mixed content", a single insecure embedding anywhere on the 329 overall site compromises the security of their login page because an 330 attacker can script (i.e., control) the login page by injecting code 331 (e.g., a script) into another, insecurely loaded, site page. 333 NOTE: "Mixed content" as used above (see also Section 5.3 in 334 [W3C.REC-wsc-ui-20100812]) refers to the notion termed "mixed 335 security context" in this specification, and should not be 336 confused with the same "mixed content" term used in the 337 context of markup languages such as XML and HTML. 339 2.3.2. Threats Not Addressed 341 2.3.2.1. Phishing 343 Phishing attacks occur when an attacker solicits authentication 344 credentials from the user by hosting a fake site located on a 345 different domain than the real site, perhaps driving traffic to the 346 fake site by sending a link in an email message. Phishing attacks 347 can be very effective because users find it difficult to distinguish 348 the real site from a fake site. HSTS is not a defense against 349 phishing per se; rather, it complements many existing phishing 350 defenses by instructing the browser to protect session integrity and 351 long-lived authentication tokens [ForceHTTPS]. 353 2.3.2.2. Malware and Browser Vulnerabilities 355 Because HSTS is implemented as a browser security mechanism, it 356 relies on the trustworthiness of the user's system to protect the 357 session. Malicious code executing on the user's system can 358 compromise a browser session, regardless of whether HSTS is used. 360 2.4. Requirements 362 This section identifies and enumerates various requirements derived 363 from the use cases and the threats discussed above, and lists the 364 detailed core requirements HTTP Strict Transport Security addresses, 365 as well as ancillary requirements that are not directly addressed. 367 2.4.1. Overall Requirement 369 o Minimize, for web browser users and web site deployers, the risks 370 that are derived from passive and active network attackers, web 371 site development and deployment bugs, and insecure user actions. 373 2.4.1.1. Detailed Core Requirements 375 These core requirements are derived from the overall requirement, and 376 are addressed by this specification. 378 1. Web sites need to be able to declare to UAs that they should be 379 accessed using a strict security policy. 381 2. Web sites need to be able to instruct UAs that contact them 382 insecurely to do so securely. 384 3. UAs need to retain persistent data about web sites that signal 385 strict security policy enablement, for time spans declared by the 386 web sites. Additionally, UAs need to cache the "freshest" strict 387 security policy information, in order to allow web sites to 388 update the information. 390 4. UAs need to re-write all insecure UA "http" URI loads to use the 391 "https" secure scheme for those web sites for which secure policy 392 is enabled. 394 5. Web site administrators need to be able to signal strict security 395 policy application to subdomains of higher-level domains for 396 which strict security policy is enabled, and UAs need to enforce 397 such policy. 399 For example, both example.com and foo.example.com could set 400 policy for bar.foo.example.com. 402 6. UAs need to disallow security policy application to peer domains, 403 and/or higher-level domains, by domains for which strict security 404 policy is enabled. 406 For example, neither bar.foo.example.com nor foo.example.com can 407 set policy for example.com, nor can bar.foo.example.com set 408 policy for foo.example.com. Also, foo.example.com cannot set 409 policy for sibling.example.com. 411 7. UAs need to prevent users from clicking-through security 412 warnings. Halting connection attempts in the face of secure 413 transport exceptions is acceptable. See also Section 12.1 "No 414 User Recourse". 416 NOTE: A means for uniformly securely meeting the first core 417 requirement above is not specifically addressed by this 418 specification (see Section 14.6 "Bootstrap MITM 419 Vulnerability"). It may be addressed by a future revision of 420 this specification or some other specification. Note also 421 that there are means by which UA implementations may more 422 fully meet the first core requirement; see Section 12 "User 423 Agent Implementation Advice". 425 2.4.1.2. Detailed Ancillary Requirements 427 These ancillary requirements are also derived from the overall 428 requirement. They are not normatively addressed in this 429 specification, but could be met by UA implementations at their 430 implementor's discretion, although meeting these requirements may be 431 complex. 433 1. Disallow "mixed security context" loads (see Section 2.3.1.3). 435 2. Facilitate user declaration of web sites for which strict 436 security policy is enabled, regardless of whether the sites 437 signal HSTS Policy. 439 3. Conformance Criteria 441 This specification is written for hosts and user agents (UAs). 443 [[IESG NOTE: the next two paragraphs are for readers with a 444 background in W3C specification style, of which we expect many. RFC 445 Editor, please remove this note before publication.]] 447 A conformant host is one that implements all the requirements listed 448 in this specification that are applicable to hosts. 450 A conformant user agent is one that implements all the requirements 451 listed in this specification that are applicable to user agents. 453 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 454 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 455 document are to be interpreted as described in [RFC2119]. 457 4. Terminology 459 Terminology is defined in this section. 461 ASCII case-insensitive comparison: 462 means comparing two strings exactly, codepoint for 463 codepoint, except that the characters in the range 464 U+0041 .. U+005A (i.e. LATIN CAPITAL LETTER A to 465 LATIN CAPITAL LETTER Z) and the corresponding 466 characters in the range U+0061 .. U+007A (i.e. 467 LATIN SMALL LETTER A to LATIN SMALL LETTER Z) are 468 considered to also match. See [Unicode] for 469 details. 471 codepoint: is a colloquial contraction of Code Point, which is 472 any value in the Unicode codespace; that is, the 473 range of integers from 0 to 10FFFF(hex) [Unicode]. 475 domain name: domain names, also referred to as DNS Names, are 476 defined in [RFC1035] to be represented outside of 477 the DNS protocol itself (and implementations 478 thereof) as a series of labels separated by dots, 479 e.g., "example.com" or "yet.another.example.org". 480 In the context of this specification, domain names 481 appear in that portion of a URI satisfying the reg- 482 name production in "Appendix A. Collected ABNF for 483 URI" in [RFC3986], and the host component from the 484 Host HTTP header field production in Section 14.23 485 of [RFC2616]. 487 NOTE: The domain names appearing in actual URI 488 instances and matching the aforementioned 489 production components may or may not be a 490 fully qualified domain name. 492 domain name label: is that portion of a domain name appearing 493 "between the dots", i.e. consider 494 "foo.example.com": "foo", "example", and "com" are 495 all domain name labels. 497 Effective Request URI: 498 is a URI, identifying the target resource, that can 499 be inferred by an HTTP host for any given HTTP 500 request it receives. Such inference is necessary 501 because HTTP requests often do not contain a 502 complete "absolute" URI identifying the target 503 resource. See Section 9 "Constructing an Effective 504 Request URI". 506 HTTP Strict Transport Security: 507 is the overall name for the combined UA- and 508 server-side security policy defined by this 509 specification. 511 HTTP Strict Transport Security Host: 512 is a conformant host implementing the HTTP server 513 aspects of the HSTS Policy. This means that an 514 HSTS Host returns the "Strict-Transport-Security" 515 HTTP response header field in its HTTP response 516 messages sent over secure transport. 518 HTTP Strict Transport Security Policy: 519 is the name of the combined overall UA- and server- 520 side facets of the behavior defined in this 521 specification. 523 HSTS: See HTTP Strict Transport Security. 525 HSTS Host: See HTTP Strict Transport Security Host. 527 HSTS Policy: See HTTP Strict Transport Security Policy. 529 Known HSTS Host: is an HSTS Host for which the UA has an HSTS Policy 530 in effect. I.e., the UA has noted this host as a 531 Known HSTS Host. See Section 8.1.1 "Noting an HSTS 532 Host - Storage Model for particulars." 534 Local policy: comprises policy rules deployers specify and which 535 are often manifested as configuration settings. 537 MITM: is an acronym for man-in-the-middle. See "man-in- 538 the-middle attack" in [RFC4949]. 540 Request URI: is the URI used to cause a UA to issue an HTTP 541 request message. See also "Effective Request URI". 543 UA: is a an acronym for user agent. For the purposes 544 of this specification, a UA is an HTTP client 545 application typically actively manipulated by a 546 user [RFC2616] . 548 unknown HSTS Host: is an HSTS Host that the user agent has not 549 noted. 551 5. HSTS Mechanism Overview 553 This section provides an overview of the mechanism by which an HSTS 554 Host conveys its HSTS Policy to UAs, and how User Agents process the 555 HSTS Policies received from HSTS Hosts. The mechanism details are 556 specified in Section 6 through Section 15. 558 5.1. HSTS Host Declaration 560 An HTTP host declares itself an HSTS Host by issuing to UAs an HSTS 561 Policy, which is represented by, and conveyed via, the Strict- 562 Transport-Security HTTP response header field over secure transport 563 (e.g., TLS). Upon error-free receipt and processing of this header 564 by a conformant UA, the UA regards the host as a Known HSTS Host. 566 5.2. HSTS Policy 568 An HSTS Policy directs UAs to communicate with a Known HSTS Host only 569 over secure transport, and specifies policy retention time duration. 571 HSTS Policy explicitly overrides the UA processing of URI references, 572 user input (e.g., via the "location bar"), or other information that, 573 in the absence of HSTS Policy, might otherwise cause UAs to 574 communicate insecurely with the Known HSTS Host. 576 An HSTS Policy may contain an optional directive -- includeSubDomains 577 -- specifying that this HSTS Policy also applies to any hosts whose 578 domain names are subdomains of the Known HSTS Host's domain name. 580 5.3. HSTS Policy Storage and Maintenance by User Agents 582 UAs store and index HSTS Policies based strictly upon the domain 583 names of the issuing HSTS Hosts. 585 This means that UAs will maintain the HSTS Policy of any given HSTS 586 Host separately from any HSTS Policies issued by any other HSTS Hosts 587 whose domain names are superdomains or subdomains of the given HSTS 588 Host's domain name. Only the given HSTS Host can update, or cause 589 deletion of, its issued HSTS Policy. It accomplishes this by sending 590 Strict-Transport-Security HTTP response header fields to UAs with new 591 values for policy time duration and subdomain applicability. Thus, 592 UAs cache the "freshest" HSTS Policy information on behalf of an HSTS 593 Host. Specifying a zero time duration signals to the UA to delete 594 the HSTS Policy (including any asserted includeSubDomains directive) 595 for that HSTS Host. See Section 8.1 "Strict-Transport-Security 596 Response Header Field Processing" for details. Additionally, 597 Section 6.2 presents examples of Strict-Transport-Security HTTP 598 response header fields. 600 5.4. User Agent HSTS Policy Enforcement 602 When establishing an HTTP connection to a given host, however 603 instigated, the UA examines its cache of Known HSTS Hosts to see if 604 there are any with domain names that are superdomains of the given 605 host's domain name. If any are found, and of those if any have the 606 includeSubDomains directive asserted, then HSTS Policy applies to the 607 given host. Otherwise, HSTS Policy applies to the given host only if 608 the given host is itself known to the UA as an HSTS Host. See 609 Section 8.3 "URI Loading and Port Mapping" for details. 611 6. Syntax 613 This section defines the syntax of the Strict-Transport-Security HTTP 614 response header field and its directives, and presents some examples. 616 Section 7 "Server Processing Model" then details how hosts employ 617 this header field to declare their HSTS Policy, and Section 8 "User 618 Agent Processing Model" details how user agents process the header 619 field and apply the HSTS Policy. 621 6.1. Strict-Transport-Security HTTP Response Header Field 623 The Strict-Transport-Security HTTP response header field (STS header 624 field) indicates to a UA that it MUST enforce the HSTS Policy in 625 regards to the host emitting the response message containing this 626 header field. 628 The ABNF (Augmented Backus-Naur Form) syntax for the STS header field 629 is given below. It is based on the Generic Grammar defined in 630 Section 2 of [RFC2616] (which includes a notion of "implied linear 631 whitespace", also known as "implied *LWS"). 633 Strict-Transport-Security = "Strict-Transport-Security" ":" 634 [ directive ] *( ";" [ directive ] ) 636 directive = directive-name [ "=" directive-value ] 637 directive-name = token 638 directive-value = token | quoted-string 640 where: 642 token = 643 quoted-string = 645 The two directives defined in this specification are described below. 646 The overall requirements for directives are: 648 1. The order of appearance of directives is not significant. 650 2. All directives MUST appear only once in an STS header field. 651 Directives are either optional or required, as stipulated in 652 their definitions. 654 3. Directive names are case-insensitive. 656 4. UAs MUST ignore any STS header fields containing directives, or 657 other header field value data, that does not conform to the 658 syntax defined in this specification. 660 5. If an STS header field contains directive(s) not recognized by 661 the UA, the UA MUST ignore the unrecognized directives and if the 662 STS header field otherwise satisfies the above requirements (1 663 through 4), the UA MUST process the recognized directives. 665 Additional directives extending the semantic functionality of the STS 666 header field can be defined in other specifications, with a registry 667 (having an IANA policy definition of IETF Review [RFC5226]) defined 668 for them at such time. 670 NOTE: Such future directives will be ignored by UAs implementing 671 only this specification, as well as by generally non- 672 conforming UAs. See Section 14.2 "Non-Conformant User Agent 673 Implications" for further discussion. 675 6.1.1. The max-age Directive 677 The REQUIRED "max-age" directive specifies the number of seconds, 678 after the reception of the STS header field, during which the UA 679 regards the host (from whom the message was received) as a Known HSTS 680 Host. See also Section 8.1.1 "Noting an HSTS Host - Storage Model". 681 The delta-seconds production is specified in [RFC2616]. 683 The syntax of the max-age directive's REQUIRED value (after quoted- 684 string unescaping, if necessary) is defined as: 686 max-age-value = delta-seconds 688 delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2> 690 NOTE: A max-age value of zero (i.e., "max-age=0") signals the UA to 691 cease regarding the host as a Known HSTS Host, including the 692 includeSubDomains directive (if asserted for that HSTS Host). 693 See also Section 8.1 "Strict-Transport-Security Response 694 Header Field Processing". 696 6.1.2. The includeSubDomains Directive 698 The OPTIONAL "includeSubDomains" directive is a valueless directive 699 which, if present (i.e., it is "asserted"), signals to the UA that 700 the HSTS Policy applies to this HSTS Host as well as any subdomains 701 of the host's domain name. 703 6.2. Examples 705 The below HSTS header field stipulates that the HSTS Policy is to 706 remain in effect for one year (there are approximately 31 536 000 707 seconds in a year), and the policy applies only to the domain of the 708 HSTS Host issuing it: 710 Strict-Transport-Security: max-age=31536000 712 The below HSTS header field stipulates that the HSTS Policy is to 713 remain in effect for approximately six months and the policy applies 714 to the domain of the issuing HSTS Host and all of its subdomains: 716 Strict-Transport-Security: max-age=15768000 ; includeSubDomains 718 The max-age directive value can optionally be quoted: 720 Strict-Transport-Security: max-age="31536000" 722 The below HSTS header field indicates that the UA must delete the 723 entire HSTS Policy associated with the HSTS Host that sent the header 724 field: 726 Strict-Transport-Security: max-age=0 728 The below HSTS header field has exactly the same effect as the one 729 immediately above because the includeSubDomains directive's presence 730 in the HSTS header field is ignored when max-age is zero: 732 Strict-Transport-Security: max-age=0; includeSubDomains 734 7. Server Processing Model 736 This section describes the processing model that HSTS Hosts 737 implement. The model comprises two facets: the first being the 738 processing rules for HTTP request messages received over a secure 739 transport (TLS [RFC5246] or SSL [RFC6101], see also Section 14.1 740 "Underlying Secure Transport Considerations"), the second being the 741 processing rules for HTTP request messages received over non-secure 742 transports, such as TCP. 744 7.1. HTTP-over-Secure-Transport Request Type 746 When replying to an HTTP request that was conveyed over a secure 747 transport, an HSTS Host SHOULD include in its response message an STS 748 header field that MUST satisfy the grammar specified above in 749 Section 6.1 "Strict-Transport-Security HTTP Response Header Field". 750 If an STS header field is included, the HSTS Host MUST include only 751 one such header field. 753 Establishing a given host as a Known HSTS Host, in the context of a 754 given UA, MAY be accomplished over the HTTP protocol, which is in 755 turn running over secure transport, by correctly returning (per this 756 specification) at least one valid STS header field to the UA. Other 757 mechanisms, such as a client-side pre-loaded Known HSTS Host list MAY 758 also be used. E.g., see Section 12 "User Agent Implementation 759 Advice". 761 NOTE: Including the STS header field is stipulated as a "SHOULD" in 762 order to accommodate various server- and network-side caches 763 and load-balancing configurations where it may be difficult to 764 uniformly emit STS header fields on behalf of a given HSTS 765 Host. 767 7.2. HTTP Request Type 769 If an HSTS Host receives a HTTP request message over a non-secure 770 transport, it SHOULD send a HTTP response message containing a status 771 code indicating a permanent redirect, such as status code 301 772 (Section 10.3.2 of [RFC2616]), and a Location header field value 773 containing either the HTTP request's original Effective Request URI 774 (see Section 9 "Constructing an Effective Request URI") altered as 775 necessary to have a URI scheme of "https", or a URI generated 776 according to local policy with a URI scheme of "https"). 778 NOTE: The above behavior is a "SHOULD" rather than a "MUST" due to: 780 * Risks in server-side non-secure-to-secure redirects 781 [owaspTLSGuide]. 783 * Site deployment characteristics. For example, a site that 784 incorporates third-party components may not behave correctly 785 when doing server-side non-secure-to-secure redirects in the 786 case of being accessed over non-secure transport, but does 787 behave correctly when accessed uniformly over secure transport. 788 The latter is the case given a HSTS-capable UA that has already 789 noted the site as a Known HSTS Host (by whatever means, e.g., 790 prior interaction or UA configuration). 792 An HSTS Host MUST NOT include the STS header field in HTTP responses 793 conveyed over non-secure transport. 795 8. User Agent Processing Model 797 This section describes the HTTP Strict Transport Security processing 798 model for UAs. There are several facets to the model, enumerated by 799 the following subsections. 801 This processing model assumes that the UA implements IDNA2008 802 [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 13 803 "Internationalized Domain Names for Applications (IDNA): Dependency 804 and Migration". It also assumes that all domain names manipulated in 805 this specification's context are already IDNA-canonicalized as 806 outlined in Section 10 "Domain Name IDNA-Canonicalization" prior to 807 the processing specified in this section. 809 The above assumptions mean that this processing model also 810 specifically assumes that appropriate IDNA and Unicode validations 811 and character list testing have occurred on the domain names, in 812 conjunction with their IDNA-canonicalization, prior to the processing 813 specified in this section. See the IDNA-specific security 814 considerations in Section 14.10 "Internationalized Domain Names" for 815 rationale and further details. 817 8.1. Strict-Transport-Security Response Header Field Processing 819 If an HTTP response, received over a secure transport, includes an 820 STS header field, conforming to the grammar specified in Section 6.1 821 "Strict-Transport-Security HTTP Response Header Field", and there are 822 no underlying secure transport errors or warnings (see Section 8.4), 823 the UA MUST either: 825 o Note the host as a Known HSTS Host if it is not already so noted 826 (see Section 8.1.1 "Noting an HSTS Host - Storage Model"), 828 or, 830 o Update the UA's cached information for the Known HSTS Host if 831 either or both of the max-age and includeSubDomains header field 832 value tokens are conveying information different than that already 833 maintained by the UA. 835 The max-age value is essentially a "time to live" value relative 836 to the reception time of the STS header field. 838 If the max-age header field value token has a value of zero, the 839 UA MUST remove its cached HSTS Policy information (including the 840 includeSubDomains directive if asserted) if the HSTS Host is 841 known, or, MUST NOT note this HSTS Host if it is not yet known. 843 If a UA receives more than one STS header field in a HTTP response 844 message over secure transport, then the UA MUST process only the 845 first such header field. 847 Otherwise: 849 o If an HTTP response is received over insecure transport, the UA 850 MUST ignore any present STS header field(s). 852 o The UA MUST ignore any STS header fields not conforming to the 853 grammar specified in Section 6.1 "Strict-Transport-Security HTTP 854 Response Header Field". 856 8.1.1. Noting an HSTS Host - Storage Model 858 If the substring matching the host production from the Request-URI 859 (of the message to which the host responded) syntactically matches 860 the IP-literal or IPv4address productions from Section 3.2.2 of 861 [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host. 863 Otherwise, if the substring does not congruently match a Known HSTS 864 Host's domain name, per the matching procedure specified in 865 Section 8.2 "Known HSTS Host Domain Name Matching", then the UA MUST 866 note this host as a Known HSTS Host, caching the HSTS Host's domain 867 name and noting along with it the expiry time of this information, as 868 effectively stipulated per the given max-age value, as well as 869 whether the includeSubDomains directive is asserted or not. See also 870 Section 11.2 "HSTS Policy expiration time considerations". 872 The UA MUST NOT modify the expiry time nor the includeSubDomains 873 directive of any superdomain matched Known HSTS Host. 875 A Known HSTS Hosts is "expired" if its cache entry has an expiry date 876 in the past. The UA MUST evict all expired Known HSTS Hosts from its 877 cache, if at any time, an expired Known HSTS Host exists in the 878 cache. 880 8.2. Known HSTS Host Domain Name Matching 882 A given domain name may match a Known HSTS Host's domain name in one 883 or both of two fashions: a congruent match, or a superdomain match. 884 Or, there may be no match. 886 The below steps determine whether there are any matches, and if so, 887 of which fashion: 889 Compare the given domain name with the domain name of each of the 890 UA's unexpired Known HSTS Hosts. For each Known HSTS Host's 891 domain name, the comparison is done with the given domain name 892 label-by-label (comparing only labels) using an ASCII case- 893 insensitive comparison beginning with the rightmost label, and 894 continuing right-to-left. See also Section 2.3.2.4. of [RFC5890]. 896 * Superdomain Match 898 If a label-for-label match between an entire Known HSTS Host's 899 domain name and a right-hand portion of the given domain name 900 is found, then this Known HSTS Host's domain name is a 901 superdomain match for the given domain name. There could be 902 multiple superdomain matches for a given domain name. 904 For example: 906 Given Domain Name: qaz.bar.foo.example.com 908 Superdomain matched 909 Known HSTS Host DN: bar.foo.example.com 911 Superdomain matched 912 Known HSTS Host DN: foo.example.com 914 * Congruent Match 916 If a label-for-label match between a Known HSTS Host's domain 917 name and the given domain name is found -- i.e., there are no 918 further labels to compare -- then the given domain name 919 congruently matches this Known HSTS Host. 921 For example: 923 Given Domain Name: foo.example.com 925 Congruently matched 926 Known HSTS Host DN: foo.example.com 928 * Otherwise, if no matches are found, the given domain name does 929 not represent a Known HSTS Host. 931 8.3. URI Loading and Port Mapping 933 Whenever the UA prepares to "load", also known as "dereference", any 934 "http" URI [RFC3986] (including when following HTTP redirects 935 [RFC2616]), the UA MUST first determine whether a domain name is 936 given in the URI and whether it matches a Known HSTS Host, using 937 these steps: 939 1. Extract from the URI any substring described by the host 940 component of the authority component of the URI. 942 2. If the substring is null, then there is no match with any Known 943 HSTS Host. 945 3. Else, if the substring is non-null and syntactically matches the 946 IP-literal or IPv4address productions from Section 3.2.2 of 947 [RFC3986], then there is no match with any Known HSTS Host. 949 4. Otherwise, the substring is a given domain name, which MUST be 950 matched against the UA's Known HSTS Hosts using the procedure in 951 Section 8.2 "Known HSTS Host Domain Name Matching". 953 5. If when performing domain name matching, any superdomain match 954 with an asserted includeSubDomains directive is found, or, if no 955 superdomain matches with asserted includeSubDomains directives 956 are found and a congruent match is found (with or without an 957 asserted includeSubDomains directive), then before proceeding 958 with the load: 960 The UA MUST replace the URI scheme with "https" [RFC2818], 961 and, 963 if the URI contains an explicit port component of "80", then 964 the UA MUST convert the port component to be "443", or, 966 if the URI contains an explicit port component that is not 967 equal to "80", the port component value MUST be preserved, 968 otherwise, 970 if the URI does not contain an explicit port component, the UA 971 MUST NOT add one. 973 NOTE: These steps ensure that the HSTS Policy applies to HTTP 974 over any TCP port of an HSTS Host. 976 NOTE: In the case where an explicit port is provided (and to a 977 lesser extent with subdomains), it is reasonably likely that 978 there is actually an HTTP (i.e., non-secure) server running at 979 the specified port and thus that an HTTPS request will fail 980 (see item (6) in Appendix A "Design Decision Notes"). 982 8.4. Errors in Secure Transport Establishment 984 When connecting to a Known HSTS Host, the UA MUST terminate the 985 connection (see also Section 12 "User Agent Implementation Advice") 986 if there are any errors, whether "warning" or "fatal" or any other 987 error level, with the underlying secure transport. For example, this 988 includes any errors found in certificate validity checking UAs employ 989 such as via Certificate Revocation Lists (CRL) [RFC5280], or via the 990 Online Certificate Status Protocol (OCSP) [RFC2560]. 992 8.5. HTTP-Equiv Element Attribute 994 UAs MUST NOT heed http-equiv="Strict-Transport-Security" attribute 995 settings on elements [W3C.REC-html401-19991224] in received 996 content. 998 8.6. Missing Strict-Transport-Security Response Header Field 1000 If a UA receives HTTP responses from a Known HSTS Host over a secure 1001 channel, but they are missing the STS header field, the UA MUST 1002 continue to treat the host as a Known HSTS Host until the max-age 1003 value for the knowledge of that Known HSTS Host is reached. Note 1004 that the max-age value could be effectively infinite for a given 1005 Known HSTS Host. For example, this would be the case if the Known 1006 HSTS Host is part of a pre-configured list that is implemented such 1007 that the list entries never "age out". 1009 9. Constructing an Effective Request URI 1011 This section specifies how an HSTS Host must construct the Effective 1012 Request URI for a received HTTP request. 1014 HTTP requests often do not carry an absoluteURI for the target 1015 resource; instead, the URI needs to be inferred from the Request-URI, 1016 Host header field, and connection context ([RFC2616], Sections 3.2.1, 1017 5.1.2, and 5.2). The result of this process is called the "effective 1018 request URI (ERU)". The "target resource" is the resource identified 1019 by the effective request URI. 1021 9.1. ERU Fundamental Definitions 1023 The first line of an HTTP request message, Request-Line, is specified 1024 by the following ABNF from [RFC2616], Section 5.1: 1026 Request-Line = Method SP Request-URI SP HTTP-Version CRLF 1028 The Request-URI, within the Request-Line, is specified by the 1029 following ABNF from [RFC2616], Section 5.1.2: 1031 Request-URI = "*" | absoluteURI | abs_path | authority 1033 The Host request header field is specified by the following ABNF from 1034 [RFC2616], Section 14.23: 1036 Host = "Host" ":" host [ ":" port ] 1038 9.2. Determining the Effective Request URI 1040 If the Request-URI is an absoluteURI, then the effective request URI 1041 is the Request-URI. 1043 If the Request-URI uses the abs_path form or the asterisk form, and 1044 the Host header field is present, then the effective request URI is 1045 constructed by concatenating: 1047 o the scheme name: "http" if the request was received over an 1048 insecure TCP connection, or "https" when received over a TLS/ 1049 SSL-secured TCP connection, and, 1051 o the octet sequence "://", and, 1053 o the host, and the port (if present), from the Host header field, 1054 and 1056 o the Request-URI obtained from the Request-Line, unless the 1057 Request-URI is just the asterisk "*". 1059 If the Request-URI uses the abs_path form or the asterisk form, and 1060 the Host header field is not present, then the effective request URI 1061 is undefined. 1063 Otherwise, when Request-URI uses the authority form, the effective 1064 request URI is undefined. 1066 Effective request URIs are compared using the rules described in 1067 [RFC2616] Section 3.2.3, except that empty path components MUST NOT 1068 be treated as equivalent to an absolute path of "/". 1070 9.2.1. Effective Request URI Examples 1072 Example 1: the effective request URI for the message 1074 GET /pub/WWW/TheProject.html HTTP/1.1 1075 Host: www.example.org:8080 1077 (received over an insecure TCP connection) is "http", plus "://", 1078 plus the authority component "www.example.org:8080", plus the 1079 request-target "/pub/WWW/TheProject.html". Thus it is: 1080 "http://www.example.org:8080/pub/WWW/TheProject.html". 1082 Example 2: the effective request URI for the message 1084 OPTIONS * HTTP/1.1 1085 Host: www.example.org 1087 (received over an SSL/TLS secured TCP connection) is "https", plus 1088 "://", plus the authority component "www.example.org". Thus it is: 1089 "https://www.example.org". 1091 10. Domain Name IDNA-Canonicalization 1093 An IDNA-canonicalized domain name is the output string generated by 1094 the following steps. The input is a putative domain name string 1095 ostensibly composed of any combination of "A-labels", "U-labels", and 1096 "NR-LDH labels" (see Section 2 of [RFC5890]) concatenated using some 1097 separator character (typically "."). 1099 1. Convert the input putative domain name string to a order- 1100 preserving sequence of individual label strings. 1102 2. When implementing IDNA2008, convert, validate, and test each 1103 A-label and U-label found among the sequence of individual label 1104 strings, using the procedures defined in Sections 5.3 through 5.5 1105 of [RFC5891]. 1107 Otherwise, when implementing IDNA2003, convert each label using 1108 the "ToASCII" conversion in Section 4 of [RFC3490] (see also the 1109 definition of "equivalence of labels" in Section 2 of the latter 1110 specification). 1112 3. If no errors occurred during the foregoing step, concatenate all 1113 the labels in the sequence, in order, into a string, separating 1114 each label from the next with a %x2E (".") character. The 1115 resulting string, known as a IDNA-canonicalized domain name, is 1116 appropriate for use in the context of Section 8 "User Agent 1117 Processing Model". 1119 Otherwise, errors occurred. The input putative domain name 1120 string was not successfully IDNA-canonicalized. Invokers of this 1121 procedure should attempt appropriate error recovery. 1123 See also Section 13 "Internationalized Domain Names for Applications 1124 (IDNA): Dependency and Migration" and Section 14.10 1125 "Internationalized Domain Names" of this specification for further 1126 details and considerations. 1128 11. Server Implementation and Deployment Advice 1130 This section is non-normative. 1132 11.1. Non-Conformant User Agent Considerations 1134 Non-conformant UAs ignore the Strict-Transport-Security header field, 1135 thus non-conformant user agents do not address the threats described 1136 in Section 2.3.1 "Threats Addressed". Please refer to Section 14.2 1137 "Non-Conformant User Agent Implications" for further discussion. 1139 11.2. HSTS Policy expiration time considerations 1141 Server implementations and deploying web sites need to consider 1142 whether they are setting an expiry time that is a constant value into 1143 the future, or whether they are setting an expiry time that is a 1144 fixed point in time. 1146 The constant value into the future approach can be accomplished by 1147 constantly sending the same max-age value to UAs. 1149 For example, a max-age value of 7776000 seconds is 90 days: 1151 Strict-Transport-Security: max-age=7776000 1153 Note that each receipt of this header by a UA will require the UA to 1154 update its notion of when it must delete its knowledge of this Known 1155 HSTS Host. 1157 The fixed point in time approach can be accomplished by sending max- 1158 age values that represent the remaining time until the desired expiry 1159 time. This would require the HSTS Host to send a newly-calculated 1160 max-age value on each HTTP response. 1162 A consideration here is whether a deployer wishes to have the 1163 signaled HSTS Policy expiry time match that for the web site's domain 1164 certificate. 1166 Additionally, server implementers should consider employing a default 1167 max-age value of zero in their deployment configuration systems. 1168 This will require deployers to wilfully set max-age in order to have 1169 UAs enforce the HSTS Policy for their host, and protects them from 1170 inadvertently enabling HSTS with some arbitrary non-zero duration. 1172 11.3. Using HSTS in conjunction with self-signed public-key 1173 certificates 1175 If all four of the following conditions are true... 1177 o a web site/organization/enterprise is generating its own secure 1178 transport public-key certificates for web sites, and 1180 o that organization's root certification authority (CA) certificate 1181 is not typically embedded by default in browser and/or operating 1182 system CA certificate stores, and 1184 o HSTS Policy is enabled on a host identifying itself using a 1185 certificate signed by the organization's CA (i.e., a "self-signed 1186 certificate"), and 1188 o and this certificate does not match a usable TLS certificate 1189 association (as defined by Section 4 of the TLSA protocol 1190 specification [RFC6698]), 1192 ...then secure connections to that site will fail, per the HSTS 1193 design. This is to protect against various active attacks, as 1194 discussed above. 1196 However, if said organization wishes to employ its own CA, and self- 1197 signed certificates, in concert with HSTS, it can do so by deploying 1198 its root CA certificate to its users' browsers or operating system CA 1199 root certificate stores. It can also, in addition or instead, 1200 distribute to its users' browsers the end-entity certificate(s) for 1201 specific hosts. There are various ways in which this can be 1202 accomplished (details are out of scope for this specification). Once 1203 its root CA certificate is installed in the browsers, it may employ 1204 HSTS Policy on its site(s). 1206 Alternatively, that organization can deploy the TLSA protocol; all 1207 browsers that also use TLSA will then be able to trust the 1208 certificates identified by usable TLS certificate associations as 1209 denoted via TLSA. 1211 NOTE: Interactively distributing root CA certificates to users, 1212 e.g., via email, and having the users install them, is 1213 arguably training the users to be susceptible to a possible 1214 form of phishing attack. See Section 14.8 "Bogus Root CA 1215 Certificate Phish plus DNS Cache Poisoning Attack". Thus care 1216 should be taken in the manner in which such certificates are 1217 distributed and installed on users' systems and browsers. 1219 11.4. Implications of includeSubDomains 1221 The includeSubDomains directive has some practical implications. For 1222 example, consider these two scenarios where use of the 1223 includeSubDomains directive needs to be carefully considered: 1225 o An HSTS Host offers unsecured HTTP-based services on alternate 1226 ports or at various subdomains of its HSTS Host domain name. 1228 o Distinct web applications are offered at distinct subdomains of an 1229 HSTS Host, such that UAs often interact directly with these 1230 subdomain web applications without having necessarily interacted 1231 with a web application offered at the HSTS Host's domain name (if 1232 any). 1234 The sections below discuss each of these scenarios in turn. 1236 11.4.1. Considerations for Offering Unsecured HTTP Services at 1237 Alternate Ports or Subdomains of an HSTS Host 1239 For example, certification authorities often offer their CRL 1240 distribution and OCSP services [RFC2560] over plain HTTP, and 1241 sometimes at a subdomain of a publicly-available web application 1242 which may be secured by TLS/SSL. For example, 1243 is a publicly-available web application for 1244 "Example CA", a certification authority. Customers use this web 1245 application to register their public keys and obtain certificates. 1246 Example CA generates certificates for customers containing 1247 as the value for the "CRL 1248 Distribution Points" and "Authority Information Access:OCSP" 1249 certificate fields. 1251 If ca.example.com were to issue an HSTS Policy with the 1252 includeSubDomains directive, then HTTP-based user agents implementing 1253 HSTS that have interacted with the ca.example.com web application 1254 would fail to retrieve CRLs, and fail to check OCSP for certificates, 1255 because these services are offered over plain HTTP. 1257 In this case, Example CA can either: 1259 o not use the includeSubDomains directive, or, 1261 o ensure HTTP-based services offered at subdomains of ca.example.com 1262 are also uniformly offered over TLS/SSL, or, 1264 o offer plain HTTP-based services at a different domain name, e.g., 1265 crl-and-ocsp.ca.example.NET, or, 1267 o utilize an alternative approach to distributing certificate status 1268 information, obviating the need to offer CRL distribution and OCSP 1269 services over plain HTTP (e.g., the "Certificate Status Request" 1270 TLS extension [RFC6066], often colloquially referred to as "OCSP 1271 Stapling"). 1273 NOTE: The above points are expressly only an example and do not 1274 purport to address all the involved complexities. For 1275 instance, there are many considerations -- on the part of CAs, 1276 certificate deployers, and applications (e.g., browsers) -- 1277 involved in deploying an approach such as "OCSP Stapling". 1278 Such issues are out of scope for this specification. 1280 11.4.2. Considerations for Offering Web Applications at Subdomains of 1281 an HSTS Host 1283 In this scenario, an HSTS Host declares an HSTS Policy with an 1284 includeSubDomains directive, and there also exist distinct web 1285 applications offered at distinct subdomains of the HSTS Host, such 1286 that UAs often interact directly with these subdomain web 1287 applications without having necessarily interacted with the HSTS 1288 Host, then the UAs will not receive or enforce the HSTS Policy. 1290 For example, the HSTS host is "example.com", and it is configured to 1291 emit the STS header field with the includeSubDomains directive. 1292 However, example.com's actual web application is addressed at 1293 "www.example.com", and example.com simply redirects user agents to 1294 "https://www.example.com/". 1296 If the STS header field is only emitted by "example.com", but UAs 1297 typically bookmark, and links (from anywhere on the web) are 1298 typically established to, "www.example.com", and "example.com" is not 1299 contacted directly by all user agents in some non-zero percentage of 1300 interactions, then some number of UAs will not note "example.com" as 1301 an HSTS Host and some number of users of "www.example.com" will be 1302 unprotected by HSTS Policy. 1304 To address this, HSTS Hosts should be configured such that the STS 1305 header field is emitted directly at each HSTS Host domain or 1306 subdomain name that constitutes a well-known "entry point" to one's 1307 web application(s), whether or not the includeSubDomains directive is 1308 employed. 1310 Thus in our example, if the STS header field is emitted from both 1311 "example.com" and "www.example.com", this issue will be addressed. 1312 Also, if there are any other well-known entry points to web 1313 applications offered by "example.com", such as "foo.example.com", 1314 they should also be configured to emit the STS header field. 1316 12. User Agent Implementation Advice 1318 This section is non-normative. 1320 In order to provide users and web sites more effective protection, as 1321 well as controls for managing their UA's caching of HSTS Policy, UA 1322 implementers should consider including features such as: 1324 12.1. No User Recourse 1326 Failing secure connection establishment on any warnings or errors 1327 (per Section 8.4 "Errors in Secure Transport Establishment") should 1328 be done with "no user recourse". This means that the user should not 1329 be presented with a dialog giving her the option to proceed. Rather, 1330 it should be treated similarly to a server error where there is 1331 nothing further the user can do with respect to interacting with the 1332 target web application, other than wait and re-try. 1334 Essentially, "any warnings or errors" means anything that would cause 1335 the UA implementation to announce to the user that something is not 1336 entirely correct with the connection establishment. 1338 Not doing this, i.e., allowing user recourse such as "clicking- 1339 through warning/error dialogs", is a recipe for a Man-in-the-Middle 1340 attack. If a web application issues an HSTS Policy, then it is 1341 opting into this scheme, whereby all certificate errors or warnings 1342 cause a connection termination, with no chance to "fool" the user 1343 into making the wrong decision and compromising themselves. 1345 12.2. User-declared HSTS Policy 1347 A User-declared HSTS Policy is the ability for users to explicitly 1348 declare a given Domain Name as representing an HSTS Host, thus 1349 seeding it as a Known HSTS Host before any actual interaction with 1350 it. This would help protect against the Section 14.6 "Bootstrap MITM 1351 Vulnerability". 1353 NOTE: Such a feature is difficult to get right on a per-site basis. 1354 See the discussion of "rewrite rules" in Section 5.5 of 1355 [ForceHTTPS]. For example, arbitrary web sites may not 1356 materialize all their URIs using the "https" scheme, and thus 1357 could "break" if a UA were to attempt to access the site 1358 exclusively using such URIs. Also note that this feature 1359 would complement, but is independent of, an "HSTS Pre-Loaded 1360 List" feature (see Section 12.3). 1362 12.3. HSTS Pre-Loaded List 1364 An HSTS Pre-Loaded List is a facility whereby web site administrators 1365 can have UAs pre-configured with HSTS Policy for their site(s) by the 1366 UA vendor(s) -- a so-called "pre-loaded list" -- in a manner similar 1367 to how root CA certificates are embedded in browsers "at the 1368 factory". This would help protect against the Section 14.6 1369 "Bootstrap MITM Vulnerability". 1371 NOTE: Such a facility would complement a "User-declared HSTS Policy" 1372 feature. 1374 12.4. Disallow Mixed Security Context Loads 1376 "Mixed security context" loads happen when an web application 1377 resource, fetched by the UA over a secure transport, subsequently 1378 causes the fetching of one or more other resources without using 1379 secure transport. This is also generally referred to as "mixed 1380 content" loads (see Section 5.3 "Mixed Content" in 1381 [W3C.REC-wsc-ui-20100812]), but should not be confused with the same 1382 "mixed content" term that is also used in the context of markup 1383 languages such as XML and HTML. 1385 NOTE: In order to provide behavioral uniformity across UA 1386 implementations, the notion of mixed security context will 1387 require further standardization work, e.g., to define the 1388 term(s) more clearly and to define specific behaviors with 1389 respect to it. 1391 12.5. HSTS Policy Deletion 1393 HSTS Policy Deletion is the ability to delete a UA's cached HSTS 1394 Policy on a per HSTS Host basis. 1396 NOTE: Adding such a feature should be done very carefully in both 1397 the user interface and security senses. Deleting a cache 1398 entry for a Known HSTS Host should be a very deliberate and 1399 well-considered act -- it shouldn't be something users get 1400 used to just "clicking through" in order to get work done. 1401 Also, implementations need to guard against allowing an 1402 attacker to inject code, e.g. ECMAscript, into the UA that 1403 silently and programmatically removes entries from the UA's 1404 cache of Known HSTS Hosts. 1406 13. Internationalized Domain Names for Applications (IDNA): Dependency 1407 and Migration 1409 Textual domain names on the modern Internet may contain one or more 1410 "internationalized" domain name labels. Such domain names are 1411 referred to as "internationalized domain names" (IDNs). The 1412 specification suites defining IDNs and the protocols for their use 1413 are named "Internationalized Domain Names for Applications (IDNA)". 1414 At this time, there are two such specification suites: IDNA2008 1415 [RFC5890] and its predecessor IDNA2003 [RFC3490]. 1417 IDNA2008 obsoletes IDNA2003, but there are differences between the 1418 two specifications, and thus there can be differences in processing 1419 (e.g., converting) domain name labels that have been registered under 1420 one from those registered under the other. There will be a 1421 transition period of some time during which IDNA2003-based domain 1422 name labels will exist in the wild. In order to facilitate their 1423 IDNA transition, user agents SHOULD implement IDNA2008 [RFC5890] and 1424 MAY implement [RFC5895] (see also Section 7 of [RFC5894]) or [UTS46]. 1425 If a user agent does not implement IDNA2008, the user agent MUST 1426 implement IDNA2003. 1428 14. Security Considerations 1430 This specification concerns the expression, conveyance, and 1431 enforcement of the HSTS Policy. The overall HSTS Policy threat 1432 model, including addressed and unaddressed threats, is given in 1433 Section 2.3 "Threat Model". 1435 Additionally, the below sections discuss operational ramifications of 1436 the HSTS Policy, provide feature rationale, discuss potential HSTS 1437 Policy misuse, and highlight some known vulnerabilities in the HSTS 1438 Policy regime. 1440 14.1. Underlying Secure Transport Considerations 1442 This specification is fashioned to be independent of the secure 1443 transport underlying HTTP. However, the threat analysis and 1444 requirements in Section 2 "Overview" in fact presume TLS or SSL as 1445 the underlying secure transport. Thus employment of HSTS in the 1446 context of HTTP running over some other secure transport protocol 1447 would require assessment of that secure transport protocol's security 1448 model in conjunction with the specifics of how HTTP is layered over 1449 it in order to assess HSTS's subsequent security properties in that 1450 context. 1452 14.2. Non-Conformant User Agent Implications 1454 Non-conformant user agents ignore the Strict-Transport-Security 1455 header field, thus non-conformant user agents do not address the 1456 threats described in Section 2.3.1 "Threats Addressed". 1458 This means that the web application and its users wielding non- 1459 conformant UAs will be vulnerable to both: 1461 o Passive network attacks due to web site development and deployment 1462 bugs: 1464 For example, if the web application contains any insecure, 1465 non-"https", references to the web application server, and if 1466 not all of its cookies are flagged as "Secure", then its 1467 cookies will be vulnerable to passive network sniffing, and 1468 potentially subsequent misuse of user credentials. 1470 o Active network attacks: 1472 For example, if an attacker is able to place a man-in-the- 1473 middle, secure transport connection attempts will likely yield 1474 warnings to the user, but without HSTS Policy being enforced, 1475 the present common practice is to allow the user to "click- 1476 through" and proceed. This renders the user and possibly the 1477 web application open to abuse by such an attacker. 1479 This is essentially the status-quo for all web applications and their 1480 users in the absence of HSTS Policy. Since web application providers 1481 typically do not control the type or version of UAs their web 1482 applications interact with, the implication is that HSTS Host 1483 deployers must generally exercise the same level of care to avoid web 1484 site development and deployment bugs (see Section 2.3.1.3) as they 1485 would if they were not asserting HSTS Policy. 1487 14.3. Ramifications of HSTS Policy Establishment only over Error-free 1488 Secure Transport 1490 The User Agent Processing Model defined in Section 8, stipulates that 1491 a host is initially noted as a Known HSTS Host, or that updates are 1492 made to a Known HSTS Host's cached information, only if the UA 1493 receives the STS header field over a secure transport connection 1494 having no underlying secure transport errors or warnings. 1496 The rationale behind this is that if there is a man-in-the-middle 1497 (MITM) -- whether a legitimately deployed proxy or an illegitimate 1498 entity -- it could cause various mischief (see also Appendix A 1499 "Design Decision Notes", item 3, as well as Section 14.6 "Bootstrap 1500 MITM Vulnerability"), for example: 1502 o Unauthorized notation of the host as a Known HSTS Host, 1503 potentially leading to a denial of service situation if the host 1504 does not uniformly offer its services over secure transport (see 1505 also Section 14.5 "Denial of Service"). 1507 o Resetting the time-to-live for the host's designation as a Known 1508 HSTS Host by manipulating the max-age header field parameter value 1509 that is returned to the UA. If max-age is returned as zero, this 1510 will cause the host to cease being regarded as an Known HSTS Host 1511 by the UA, leading to either insecure connections to the host or 1512 possibly denial-of-service if the host delivers its services only 1513 over secure transport. 1515 However, this means that if a UA is "behind" a MITM non-transparent 1516 TLS proxy -- within a corporate intranet, for example -- and 1517 interacts with an unknown HSTS Host beyond the proxy, the user could 1518 possibly be presented with the legacy secure connection error 1519 dialogs. Even if the risk is accepted and the user clicks-through, 1520 the host will not be noted as an HSTS Host. Thus, as long as the UA 1521 is behind such a proxy the user will be vulnerable, and possibly be 1522 presented with the legacy secure connection error dialogs for as yet 1523 unknown HSTS Hosts. 1525 Once the UA successfully connects to an unknown HSTS Host over error- 1526 free secure transport, the host will be noted as a Known HSTS Host. 1527 This will result in the failure of subsequent connection attempts 1528 from behind interfering proxies. 1530 The above discussion relates to the recommendation in Section 12 1531 "User Agent Implementation Advice" that the secure connection be 1532 terminated with "no user recourse" whenever there are warnings and 1533 errors and the host is a Known HSTS Host. Such a posture protects 1534 users from "clicking through" security warnings and putting 1535 themselves at risk. 1537 14.4. The Need for includeSubDomains 1539 Without the includeSubDomains directive, a web application would not 1540 be able to adequately protect so-called "domain cookies" (even if 1541 these cookies have their "Secure" flag set and thus are conveyed only 1542 on secure channels). These are cookies the web application expects 1543 UAs to return to any and all subdomains of the web application. 1545 For example, suppose example.com represents the top-level DNS name 1546 for a web application. Further suppose that this cookie is set for 1547 the entire example.com domain, i.e. it is a "domain cookie", and it 1548 has its Secure flag set. Suppose example.com is a Known HSTS Host 1549 for this UA, but the includeSubDomains directive is not set. 1551 Now, if an attacker causes the UA to request a subdomain name that is 1552 unlikely to already exist in the web application, such as 1553 "https://uxdhbpahpdsf.example.com/", but that the attacker has 1554 managed to register in the DNS and point at an HTTP server under the 1555 attacker's control, then: 1557 1. The UA is unlikely to already have an HSTS Policy established for 1558 "uxdhbpahpdsf.example.com", and, 1560 2. The HTTP request sent to uxdhbpahpdsf.example.com will include 1561 the Secure-flagged domain cookie. 1563 3. If "uxdhbpahpdsf.example.com" returns a certificate during TLS 1564 establishment, and the user clicks through any warning that might 1565 be presented (it is possible, but not certain, that one may 1566 obtain a requisite certificate for such a domain name such that a 1567 warning may or may not appear), then the attacker can obtain the 1568 Secure-flagged domain cookie that's ostensibly being protected. 1570 Without the "includeSubDomains" directive, HSTS is unable to protect 1571 such Secure-flagged domain cookies. 1573 14.5. Denial of Service 1575 HSTS could be used to mount certain forms of Denial-of- Service (DoS) 1576 attacks against web sites. A DoS attack is an attack in which one or 1577 more network entities target a victim entity and attempt to prevent 1578 the victim from doing useful work. This section discusses such 1579 scenarios in terms of HSTS, though this list is not exhaustive. See 1580 also [RFC4732] for a discussion of overall Internet DoS 1581 considerations. 1583 o Web applications available over HTTP 1585 There is an opportunity for perpetrating DoS attacks with web 1586 applications that are -- or critical portions of them are -- 1587 available only over HTTP without secure transport, if attackers 1588 can cause UAs to set HSTS Policy for such web applications' 1589 host(s). 1591 This is because once the HSTS Policy is set for a web 1592 application's host in a UA, the UA will only use secure transport 1593 to communicate with the host. If the host is not using secure 1594 transport, or is not for critical portions of its web application, 1595 then the web application will be rendered unusable for the UA's 1596 user. 1598 NOTE: This is a use case for UAs to offer a "HSTS Policy 1599 Deletion" feature as noted in Section 12.5 "HSTS Policy 1600 Deletion". 1602 An HSTS Policy can be set for a victim host in various ways: 1604 * If the web application has a HTTP response splitting 1605 vulnerability [CWE-113] (which can be abused in order to 1606 facilitate "HTTP Header Injection"). 1608 * If an attacker can spoof a redirect from an insecure victim 1609 site, e.g., to , 1610 where the latter is attacker-controlled and has an apparently 1611 valid certificate, then the attacker can set an HSTS Policy for 1612 example.com, and also for all subdomains of example.com. 1614 * If an attacker can convince users to manually configure HSTS 1615 Policy for a victim host. This assumes their UAs offer such a 1616 capability (see Section 12 "User Agent Implementation Advice"). 1617 Or, if such UA configuration is scriptable, then an attacker 1618 can cause UAs to execute his script and set HSTS Policies for 1619 whichever desired domains. 1621 o Inadvertent use of includeSubDomains 1623 The includeSubDomains directive instructs UAs to automatically 1624 regard all subdomains of the given HSTS Host as Known HSTS Hosts. 1625 If any such subdomains do not support properly configured secure 1626 transport, then they will be rendered unreachable from such UAs. 1628 14.6. Bootstrap MITM Vulnerability 1630 The bootstrap MITM (Man-In-The-Middle) vulnerability is a 1631 vulnerability users and HSTS Hosts encounter in the situation where 1632 the user manually enters, or follows a link, to an unknown HSTS Host 1633 using a "http" URI rather than a "https" URI. Because the UA uses an 1634 insecure channel in the initial attempt to interact with the 1635 specified server, such an initial interaction is vulnerable to 1636 various attacks (see Section 5.3 of [ForceHTTPS]). 1638 NOTE: There are various features/facilities that UA implementations 1639 may employ in order to mitigate this vulnerability. Please 1640 see Section 12 "User Agent Implementation Advice". 1642 14.7. Network Time Attacks 1644 Active network attacks can subvert network time protocols (such as 1645 Network Time Protocol (NTP) [RFC5905]) - making HSTS less effective 1646 against clients that trust NTP or lack a real time clock. Network 1647 time attacks are beyond the scope of this specification. Note that 1648 modern operating systems use NTP by default. See also Section 2.10 1649 of [RFC4732]. 1651 14.8. Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack 1653 An attacker could conceivably obtain a victim HSTS-protected web 1654 application's users' login credentials via a bogus root CA 1655 certificate phish plus DNS cache poisoning attack. 1657 For example, the attacker could first convince users of a victim web 1658 application (which is protected by HSTS Policy) to install the 1659 attacker's version of a root CA certificate purporting (falsely) to 1660 represent the CA of the victim web application. This might be 1661 accomplished by sending the users a phishing email message with a 1662 link to such a certificate, which their browsers may offer to install 1663 if clicked on. 1665 Then, if the attacker can perform an attack on the users' DNS 1666 servers, (e.g., via cache poisoning) and turn on HSTS Policy for 1667 their fake web application, the affected users' browsers would access 1668 the attackers' web application rather than the legitimate web 1669 application. 1671 This type of attack leverages vectors that are outside of the scope 1672 of HSTS. However, the feasibility such threats can be mitigated by 1673 including in a web application's overall deployment approach 1674 appropriate employment, in addition to HSTS, of security facilities 1675 such as DNS Security Extensions [RFC4033], plus techniques to block 1676 email phishing and fake certificate injection. 1678 14.9. Creative Manipulation of HSTS Policy Store 1680 Since an HSTS Host may select its own host name and subdomains 1681 thereof, and this information is cached in the HSTS Policy store of 1682 conforming UAs, it is possible for those who control an HSTS Host(s) 1683 to encode information into domain names they control and cause such 1684 UAs to cache this information as a matter of course in the process of 1685 noting the HSTS Host. This information can be retrieved by other 1686 hosts through clever loaded page construction causing the UA to send 1687 queries to (variations of) the encoded domain names. Such queries 1688 can reveal whether the UA had prior visited the original HSTS Host 1689 (and subdomains). 1691 Such a technique could potentially be abused as yet another form of 1692 "web tracking" [WebTracking]. 1694 14.10. Internationalized Domain Names 1696 Internet security relies in part on the DNS and the domain names it 1697 hosts. Domain names are used by users to identify and connect to 1698 Internet hosts and other network resources. For example, Internet 1699 security is compromised if a user entering an internationalized 1700 domain name (IDN) is connected to different hosts based on different 1701 interpretations of the IDN. 1703 The processing models specified in this specification assume that the 1704 domain names they manipulate are IDNA-canonicalized, and that the 1705 canonicalization process correctly performed all appropriate IDNA and 1706 Unicode validations and character list testing per the requisite 1707 specifications (e.g., as noted in Section 10 "Domain Name IDNA- 1708 Canonicalization"). These steps are necessary in order to avoid 1709 various potentially compromising situations. 1711 In brief, some examples of issues that could stem from lack of 1712 careful and consistent Unicode and IDNA validations are things such 1713 as unexpected processing exceptions, truncation errors, and buffer 1714 overflows, as well as false-positive and/or false-negative domain 1715 name matching results. Any of the foregoing issues could possibly be 1716 leveraged by attackers in various ways. 1718 Additionally, IDNA2008 [RFC5890] differs from IDNA2003 [RFC3490] in 1719 terms of disallowed characters and character mapping conventions. 1720 This situation can also lead to false-positive and/or false-negative 1721 domain name matching results, resulting in, for example, users 1722 possibly communicating with unintended hosts, or not being able to 1723 reach intended hosts. 1725 For details, refer to the Security Considerations sections of 1726 [RFC5890], [RFC5891], and [RFC3490], as well as the specifications 1727 they normatively reference. Additionally, [RFC5894] provides 1728 detailed background and rationale for IDNA2008 in particular, as well 1729 as IDNA and its issues in general, and should be consulted in 1730 conjunction with the former specifications. 1732 15. IANA Considerations 1734 Below is the Internet Assigned Numbers Authority (IANA) Permanent 1735 Message Header Field registration information per [RFC3864]. 1737 Header field name: Strict-Transport-Security 1738 Applicable protocol: HTTP 1739 Status: standard 1740 Author/Change controller: IETF 1741 Specification document(s): this one 1743 16. References 1745 16.1. Normative References 1747 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1748 Requirement Levels", BCP 14, RFC 2119, March 1997. 1750 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1751 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1752 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1754 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1756 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1757 "Internationalizing Domain Names in Applications (IDNA)", 1758 RFC 3490, March 2003. 1760 This specification is referenced due to its ongoing 1761 relevance to actual deployments for the foreseeable 1762 future. 1764 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1765 for Internationalized Domain Names in Applications 1766 (IDNA)", RFC 3492, March 2003. 1768 This specification is referenced due to its ongoing 1769 relevance to actual deployments for the foreseeable 1770 future. 1772 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1773 Procedures for Message Header Fields", BCP 90, RFC 3864, 1774 September 2004. 1776 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1777 Resource Identifier (URI): Generic Syntax", STD 66, 1778 RFC 3986, January 2005. 1780 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1781 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1783 [RFC5890] Klensin, J., "Internationalized Domain Names for 1784 Applications (IDNA): Definitions and Document Framework", 1785 RFC 5890, August 2010. 1787 [RFC5891] Klensin, J., "Internationalized Domain Names in 1788 Applications (IDNA): Protocol", RFC 5891, August 2010. 1790 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 1791 Internationalized Domain Names in Applications (IDNA) 1792 2008", RFC 5895, September 2010. 1794 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1795 of Named Entities (DANE) Transport Layer Security (TLS) 1796 Protocol: TLSA", RFC 6698, August 2012. 1798 [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility 1799 Processing", Unicode Technical Standards # 46, 1800 . 1802 [Unicode] The Unicode Consortium, "The Unicode Standard", 1803 . 1805 [W3C.REC-html401-19991224] 1806 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 1807 Specification", World Wide Web Consortium 1808 Recommendation REC-html401-19991224, December 1999, 1809 . 1811 16.2. Informative References 1813 [Aircrack-ng] 1814 d'Otreppe, T., "Aircrack-ng", Accessed: 11-Jul-2010, 1815 . 1817 [BeckTews09] 1818 Beck, M. and E. Tews, "Practical Attacks Against WEP and 1819 WPA", Second ACM Conference on Wireless Network 1820 Security Zurich, Switzerland, 2009, . 1824 [CWE-113] "CWE-113: Improper Neutralization of CRLF Sequences in 1825 HTTP Headers ('HTTP Response Splitting')", Common Weakness 1826 Enumeration , The Mitre 1827 Corporation , 1828 . 1830 [Firesheep] 1831 Various, "Firesheep", Wikipedia Online, on-going, 1832 . 1835 [ForceHTTPS] 1836 Jackson, C. and A. Barth, "ForceHTTPS: Protecting High- 1837 Security Web Sites from Network Attacks", In Proceedings 1838 of the 17th International World Wide Web Conference 1839 (WWW2008) , 2008, 1840 . 1842 [GoodDhamijaEtAl05] 1843 Good, N., Dhamija, R., Grossklags, J., Thaw, D., 1844 Aronowitz, S., Mulligan, D., and J. Konstan, "Stopping 1845 Spyware at the Gate: A User Study of Privacy, Notice and 1846 Spyware", In Proceedings of Symposium On Usable Privacy 1847 and Security (SOUPS) Pittsburgh, PA, USA, July 2005, . 1851 [JacksonBarth2008] 1852 Jackson, C. and A. Barth, "Beware of Finer-Grained 1853 Origins", Web 2.0 Security and Privacy Oakland, CA, USA, 1854 2008, 1855 . 1858 [RFC1035] Mockapetris, P., "Domain names - implementation and 1859 specification", STD 13, RFC 1035, November 1987. 1861 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1862 Adams, "X.509 Internet Public Key Infrastructure Online 1863 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1865 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1866 Rose, "DNS Security Introduction and Requirements", 1867 RFC 4033, March 2005. 1869 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 1870 Service Considerations", RFC 4732, December 2006. 1872 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1873 RFC 4949, August 2007. 1875 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1876 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1877 May 2008. 1879 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1880 Housley, R., and W. Polk, "Internet X.509 Public Key 1881 Infrastructure Certificate and Certificate Revocation List 1882 (CRL) Profile", RFC 5280, May 2008. 1884 [RFC5894] Klensin, J., "Internationalized Domain Names for 1885 Applications (IDNA): Background, Explanation, and 1886 Rationale", RFC 5894, August 2010. 1888 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1889 Time Protocol Version 4: Protocol and Algorithms 1890 Specification", RFC 5905, June 2010. 1892 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1893 Extension Definitions", RFC 6066, January 2011. 1895 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 1896 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 1897 August 2011. 1899 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1900 April 2011. 1902 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1903 December 2011. 1905 [SunshineEgelmanEtAl09] 1906 Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and 1907 L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning 1908 Effectiveness", In Proceedings of 18th USENIX Security 1909 Symposium Montreal, Canada, Augus 2009, . 1913 [W3C.REC-wsc-ui-20100812] 1914 Saldhana, A. and T. Roessler, "Web Security Context: User 1915 Interface Guidelines", World Wide Web Consortium 1916 Recommendation REC-wsc-ui-20100812, August 2010, 1917 . 1919 [WebTracking] 1920 Schmucker, N., "Web Tracking", SNET2 Seminar Paper Summer 1921 Term, 2011, . 1924 [owaspTLSGuide] 1925 Coates, M., Wichers, d., Boberski, M., and T. Reguly, 1926 "Transport Layer Protection Cheat Sheet", Accessed: 11- 1927 Jul-2010, . 1930 Appendix A. Design Decision Notes 1932 This appendix documents various design decisions. 1934 1. Cookies aren't appropriate for HSTS Policy expression as they are 1935 potentially mutable (while stored in the UA), therefore an HTTP 1936 header field is employed. 1938 2. We chose to not attempt to specify how "mixed security context 1939 loads" (also known as "mixed content loads") are handled due to 1940 UA implementation considerations as well as classification 1941 difficulties. 1943 3. An HSTS Host may update UA notions of HSTS Policy via new HSTS 1944 header field parameter values. We chose to have UAs honor the 1945 "freshest" information received from a server because there is 1946 the chance of a web site sending out an erroneous HSTS Policy, 1947 such as a multi-year max-age value, and/or an incorrect 1948 includeSubDomains directive. If the HSTS Host couldn't correct 1949 such errors over protocol, it would require some form of 1950 annunciation to users and manual intervention on the users' part, 1951 which could be a non-trivial problem for both web application 1952 providers and their users. 1954 4. HSTS Hosts are identified only via domain names -- explicit IP 1955 address identification of all forms is excluded. This is for 1956 simplification and also is in recognition of various issues with 1957 using direct IP address identification in concert with PKI-based 1958 security. 1960 5. The max-age approach of having the HSTS Host provide a simple 1961 integer number of seconds for a cached HSTS Policy time-to-live 1962 value, as opposed to an approach of stating an expiration time in 1963 the future was chosen for various reasons. Amongst the reasons 1964 are no need for clock synchronization, no need to define date and 1965 time value syntaxes (specification simplicity), and 1966 implementation simplicity. 1968 6. In determining whether port mapping was to be employed, the 1969 option of merely refusing to dereference any URL with an explicit 1970 port was considered. It was felt, though, that the possibility 1971 that the URI to be dereferenced is incorrect (and there is indeed 1972 a valid HTTPS server at that port) is worth the small cost of 1973 possibly wasted HTTPS fetches to HTTP servers. 1975 Appendix B. Differences between HSTS Policy and Same-Origin Policy 1977 HSTS Policy has the following primary characteristics: 1979 HSTS Policy stipulates requirements for the security 1980 characteristics of UA-to-host connection establishment, on a per- 1981 host basis. 1983 Hosts explicitly declare HSTS Policy to UAs. Conformant UAs are 1984 obliged to implement hosts' declared HSTS Policies. 1986 HSTS Policy is conveyed over protocol from the host to the UA. 1988 The UA maintains a cache of Known HSTS Hosts. 1990 UAs apply HSTS Policy whenever making a HTTP connection to a Known 1991 HSTS Host, regardless of host port number. I.e., it applies to 1992 all ports on a Known HSTS Host. Hosts are unable to affect this 1993 aspect of HSTS Policy. 1995 Hosts may optionally declare that their HSTS Policy applies to all 1996 subdomains of their host domain name. 1998 In contrast, the Same-Origin Policy (SOP) [RFC6454] has the following 1999 primary characteristics: 2001 An origin is the scheme, host, and port of a URI identifying a 2002 resource. 2004 A UA may dereference a URI, thus loading a representation of the 2005 resource the URI identifies. UAs label resource representations 2006 with their origins, which are derived from their URIs. 2008 The SOP refers to a collection of principles, implemented within 2009 UAs, governing the isolation of and communication between resource 2010 representations within the UA, as well as resource 2011 representations' access to network resources. 2013 In summary, although both HSTS Policy and SOP are enforced by UAs, 2014 HSTS Policy is optionally declared by hosts and is not origin-based, 2015 while the SOP applies to all resource representations loaded from all 2016 hosts by conformant UAs. 2018 Appendix C. Acknowledgments 2020 The authors thank Devdatta Akhawe, Michael Barrett, Ben Campbell, 2021 Tobias Gondrom, Paul Hoffman, Murray Kucherawy, Barry Leiba, James 2022 Manger, Alexey Melnikov, Haevard Molland, Yoav Nir, Yngve N. 2023 Pettersen, Laksh Raghavan, Marsh Ray, Julian Reschke, Eric Rescorla, 2024 Tom Ritter, Peter Saint-Andre, Brian Smith, Robert Sparks, Maciej 2025 Stachowiak, Sid Stamm, Andy Steingrubl, Brandon Sterne, Martin 2026 Thomson, Daniel Veditz, Jan Wrobel, as well as all the websec working 2027 group participants and others for their various reviews and helpful 2028 contributions. 2030 Thanks to Julian Reschke for his elegant re-writing of the effective 2031 request URI text, which he did when incorporating the ERU notion into 2032 the HTTPbis work. Subsequently, the ERU text in this spec was lifted 2033 from Julian's work in the updated HTTP/1.1 (part 1) specification and 2034 adapted to the [RFC2616] ABNF. 2036 Appendix D. Change Log 2038 [RFCEditor: please remove this section upon publication as an RFC.] 2040 Changes are grouped by spec revision listed in reverse issuance 2041 order. 2043 D.1. For draft-ietf-websec-strict-transport-sec 2045 Changes from -13 to -14: 2047 1. Added a new subsection entitled "Considerations for Offering 2048 Unsecured HTTP Services at Alternate Ports or Subdomains of an 2049 HSTS Host" to section 11.4 "Implications of 2050 includeSubDomains". This is addresses Robert Sparks' Discuss 2051 point (1): 2054 Also s/flag/directive/ for all uses of e.g. "includeSubDomains 2055 flag", and noted that the presence of an includeSubDomains 2056 directive in an STS header field means it is "asserted". 2058 2. Added a definition of an expired known HSTS Host, as well as a 2059 stipulation that the UA must evict expired known HSTS hosts 2060 from the cache (to section 8.1.1 "Noting an HSTS Host - 2061 Storage Model"). Added an "unexpired" adjective appropriately 2062 to section 8.2 "Known HSTS Host Domain Name Matching". This 2063 is addresses Robert Sparks' Discuss point (2): 2067 3. Added a note 14.4 reason for clients to consider providing a 2068 way for users to remove entries from the cache. This is 2069 addresses Robert Sparks' first Comment: 2073 4. Noted in 2nd para of section 7.1 that HTTP is running over 2074 secure transport. This is addresses Robert Sparks' second 2075 comment ("nit"): 2078 5. Struck the "or perhaps others" phrase from Section 7. Added 2079 Section 14 "Underlying Secure Transport Considerations" to Sec 2080 Cons. This is addresses a portion of Eric Rescorla's 2081 feedback. 2083 6. Added a NOTE to Section 8.3 URI Loading and Port Mapping 2084 regarding non-HTTPS servers running at non-standard ports 2085 identified in URIs. Added item (6) to Appendix A explaining 2086 the port mapping design decision. This addresses the other 2087 portion of EKR's feedback. 2089 Changes from -12 to -13: 2091 1. Addressed the IANA registry and IANA registry policy questions 2092 raised in Ben Campbel's Gen-ART LC review. Selected "IETF 2093 Review" for IANA policy. See the portion of this thread from 2094 this message onwards for details: 2097 2. Clarified the questions regarding max-age=0 interacting with 2098 includeSubdomains. Expanded section 5. HSTS Mechanism 2099 Overview, Added clarification text and forward ref to S 8.1 2100 from S 6.1.1. Added two additional examples to S 6.2 which 2101 contain max-age=0. See the thread rooted here for questions 2102 that informed this: 2105 3. upgraded ref to draft-ietf-dane-protocol to be to RFC6698. 2107 Changes from -11 to -12: 2109 1. Addressed various issues in Ben Campbel's Gen-ART LC review. 2110 See this message for details: 2113 Changes from -10 to -11: 2115 1. Various minor editorial fixes based on Barry Leiba's AD 2116 review, as well as ID-Nits warnings. 2118 2. Clarification addition of directive-name and directive-value 2119 to Strict-Transport-Security ABNF in Section 6.1, from Barry's 2120 AD review. 2123 3. Moved ref to RFC5894 to Informational since it is a truly 2124 informational reference. 2126 Changes from -09 to -10: 2128 1. Added "(including when following HTTP redirects [RFC2616])" to 2129 section 8.3. This addresses issue ticket #47. 2130 2132 2. Fixed max-age value in section 10.1. Substituted 7776000 2133 (actually 90 days) for 778000 (only 9 days). This addresses 2134 issue ticket #48. 2135 2137 3. Added mention of "Certificate Status Request" TLS extension 2138 [RFC6066] aka "OCSP stapling" to example in section 10.3. 2139 This addresses issue ticket #49. 2140 2142 Changes from -08 to -09: 2144 1. Added IESG Note to Section 3 "Conformance Criteria" per Barry 2145 Leiba's suggestion on the mailing list. 2148 2. Added additional requirement #5 to requirements for STS header 2149 field directives in Section 6.1 per Alexey's review. This 2150 completes the addressing of issue ticket #45. 2151 2153 3. Addressed editorial feedback in Murray's AppsDir review of 2154 -06. 2156 Most all of these changes were addressing detailed/small 2157 editorial items, however note the addition of a couple of 2158 introductory paragraphs in the Security Considerations 2159 section, as well as a re-written and expanded Section 14.6 2160 "Bogus Root CA Certificate Phish plus DNS Cache Poisoning 2161 Attack", as well the new item #5 to Appendix A "Design 2162 Decision Notes". 2164 This addresses issue ticket #46. 2165 2167 Changes from -07 to -08: 2169 1. Clarified requirement #4 for STS header field directives in 2170 Section 6.1, and removed "(which "update" this 2171 specification)". Also added explicit "max-age=0" to Section 2172 6.1.1. Reworked final sentence in 2nd para of Section 13. 2173 This addresses issue ticket #45. 2174 2176 Changes from -06 to -07: 2178 1. Various minor/modest editorial tweaks throughout as I went 2179 through it pursuing the below issue tickets. Viewing a visual 2180 diff against -06 revision recommended. 2182 2. fixed some minor editorial issues noted in review by Alexey, 2183 fixes noted in here: 2186 3. Addressed ABNF exposition issues, specifically inclusion of 2187 quoted-string syntax for directive values. Fix STS header 2188 ABNF such that a leading ";" isn't required. Add example of 2189 quoted-string-encoded max-age-value. This addresses (re- 2190 opened) issue ticket #33. 2191 2193 4. Reworked sections 8.1 through 8.3 to ensure matching algorithm 2194 and resultant HSTS Policy application is more clear, and that 2195 it is explicitly stipulated to not muck with attributes of 2196 superdomain matching Known HSTS Hosts. This addresses issue 2197 ticket #37. 2198 2200 5. Added reference to draft-ietf-dane-protocol, pared back 2201 extraneous discussion in section 2.2, and updated discussion 2202 in 10.2 to accomodate TLSA (nee DANE). This addresses issue 2203 ticket #39. 2204 2206 6. Addressed various editorial items from issue ticket #40. 2207 2209 7. Loosened up the language regarding redirecting "http" requests 2210 to "https" in section 7.2 such that future flavors of 2211 permanent redirects are accommodated. This addresses issue 2212 ticket #43. 2213 2215 8. Reworked the terminology and language in Section 9, in 2216 particular defining the term "putative domain name string" to 2217 replace "valid Unicode-encoded string-serialized domain name". 2218 This addresses issue ticket #44. 2219 2221 Changes from -05 to -06: 2223 1. Addressed various editorial comments provided by Tobias G. 2224 This addresses issue ticket #38. 2225 2227 Changes from -04 to -05: 2229 1. Fixed up references to move certain ones back to the normative 2230 section -- as requested by Alexey M. Added explanation for 2231 referencing obsoleted [RFC3490] and [RFC3492]. This addresses 2232 issue ticket #36. 2233 2235 2. Made minor change to Strict-Transport-Security header field 2236 ABNF in order to address further feedback as appended to 2237 ticket #33. This addresses issue ticket #33. 2238 2240 Changes from -03 to -04: 2242 1. Clarified that max-age=0 will cause UA to forget a known HSTS 2243 Host, and more generally clarified that the "freshest" info 2244 from the HSTS Host is cached, and thus HSTS Hosts are able to 2245 alter the cached max-age in UAs. This addresses issue ticket 2246 #13. 2248 2. Updated section on "Constructing an Effective Request URI" to 2249 remove remaining reference to RFC3986 and reference RFC2616 2250 instead. Further addresses issue ticket #14. 2251 2253 3. Addresses further ABNF issues noted in comment:1 of issue 2254 ticket #27. 2257 4. Reworked the introduction to clarify the denotation of "HSTS 2258 Policy" and added the new Appendix B summarizing the primary 2259 characteristics of HSTS Policy and Same-Origin Policy, and 2260 identifying their differences. Added ref to [RFC4732]. This 2261 addresses issue ticket #28. 2262 2264 5. Reworked language in Section 2.3.1.3. wrt "mixed content", 2265 more clearly explain such vulnerability, disambiguate "mixed 2266 content" in web security context from its usage in markup 2267 language context. This addresses issue ticket #29. 2268 2270 6. Expanded Denial of Service discussion in Security 2271 Considerations. Added refs to [RFC4732] and [CWE-113]. This 2272 addresses issue ticket #30. 2273 2275 7. Mentioned in prose the case-insensitivity of directive names. 2276 This addresses issue ticket #31. 2277 2279 8. Added Section 11.4 "Implications of includeSubDomains". This 2280 addresses issue ticket #32. 2281 2283 9. Further refines text and ABNF definitions of STS header field 2284 directives. Retains use of quoted-string in directive 2285 grammar. This addresses issue ticket #33. 2286 2288 10. Added Section 14.9 "Creative Manipulation of HSTS Policy 2289 Store", including reference to [WebTracking]. This addresses 2290 issue ticket #34. 2291 2293 11. Added Section 14.3 "Ramifications of HSTS Policy 2294 Establishment only over Error-free Secure Transport" and made 2295 some accompanying editorial fixes in some other sections. 2296 This addresses issue ticket #35. 2297 2299 12. Refined references. Cleaned out un-used ones, updated to 2300 latest RFCs for others, consigned many to Informational. 2301 This addresses issue ticket #36. 2302 2304 13. Fixed-up some inaccuracies in the "Changes from -02 to -03" 2305 section. 2307 Changes from -02 to -03: 2309 1. Updated section on "Constructing an Effective Request URI" to 2310 remove references to RFC3986. Addresses issue ticket #14. 2311 2313 2. Reference RFC5890 for IDNA, retaining subordinate refs to 2314 RFC3490. Updated IDNA-specific language, e.g. domain name 2315 canonicalization and IDNA dependencies. Addresses issue 2316 ticket #26 2317 . 2319 3. Completely re-wrote the STS header ABNF to be fully based on 2320 RFC2616, rather than a hybrid of RFC2616 and httpbis. 2321 Addresses issue ticket #27 2322 . 2324 Changes from -01 to -02: 2326 1. Updated Section 8.3 "URI Loading and Port Mapping" fairly 2327 thoroughly in terms of refining the presentation of the 2328 steps, and to ensure the various aspects of port mapping are 2329 clear. Nominally fixes issue ticket #1 2330 2332 2. Removed dependencies on 2333 [I-D.draft-ietf-httpbis-p1-messaging-15]. Thus updated STS 2334 ABNF in Section 6.1 "Strict-Transport-Security HTTP Response 2335 Header Field" by lifting some productions entirely from 2336 [I-D.draft-ietf-httpbis-p1-messaging-15] and leveraging 2337 [RFC2616]. Addresses issue ticket #2 2338 . 2340 3. Updated Effective Request URI section and definition to use 2341 language from [I-D.draft-ietf-httpbis-p1-messaging-15] and 2342 ABNF from [RFC2616]. Fixes issue ticket #3 2343 . 2345 4. Added explicit mention that the HSTS Policy applies to all 2346 TCP ports of a host advertising the HSTS Policy. Nominally 2347 fixes issue ticket #4 2348 2350 5. Clarified the need for the "includeSubDomains" directive, 2351 e.g. to protect Secure-flagged domain cookies. In 2352 Section 14.4 "The Need for includeSubDomains". Nominally 2353 fixes issue ticket #5 2354 2356 6. Cited Firesheep as real-live threat in Section 2.3.1.1 2357 "Passive Network Attackers". Nominally fixes issue ticket #6 2358 . 2360 7. Added text to Section 12 "User Agent Implementation Advice" 2361 justifying connection termination due to tls warnings/errors. 2362 Nominally fixes issue ticket #7 2363 . 2365 8. Added new subsection Section 8.6 "Missing Strict-Transport- 2366 Security Response Header Field". Nominally fixes issue 2367 ticket #8 2368 . 2370 9. Added text to Section 8.4 "Errors in Secure Transport 2371 Establishment" explicitly note revocation check failures as 2372 errors causing connection termination. Added references to 2373 [RFC5280] and [RFC2560]. Nominally fixes issue ticket #9 2374 . 2376 10. Added a sentence, noting that distributing specific end- 2377 entity certificates to browsers will also work for self- 2378 signed/private-CA cases, to Section 11 "Server Implementation 2379 and Deployment Advice" Nominally fixes issue ticket #10 2380 . 2382 11. Moved "with no user recourse" language from Section 8.4 2383 "Errors in Secure Transport Establishment" to Section 12 2384 "User Agent Implementation Advice". This nominally fixes 2385 issue ticket #11 2386 . 2388 12. Removed any and all dependencies on 2389 [I-D.draft-ietf-httpbis-p1-messaging-15], instead depending 2390 on [RFC2616] only. Fixes issue ticket #12 2391 . 2393 13. Removed the inline "XXX1" issue because no one had commented 2394 on it and it seems reasonable to suggest as a SHOULD that web 2395 apps should redirect incoming insecure connections to secure 2396 connections. 2398 14. Removed the inline "XXX2" issue because it was simply for 2399 raising consciousness about having some means for 2400 distributing secure web application metadata. 2402 15. Removed "TODO1" because description prose for "max-age" in 2403 the Note following the ABNF in Section 6 seems to be fine. 2405 16. Decided for "TODO2" that "the first STS header field wins". 2406 TODO2 had read: "Decide UA behavior in face of encountering 2407 multiple HSTS headers in a message. Use first header? 2408 Last?". Removed TODO2. 2410 17. Added Section 1.1 "Organization of this specification" for 2411 readers' convenience. 2413 18. Moved design decision notes to be a proper appendix 2414 Appendix A. 2416 Changes from -00 to -01: 2418 1. Changed the "URI Loading" section to be "URI Loading and Port 2419 Mapping". 2421 2. (HASMAT) reference changed to (WEBSEC). 2423 3. Changed "server" -> "host" where applicable, notably when 2424 discussing "HSTS Hosts". Left as "server" when discussing 2425 e.g. "http server"s. 2427 4. Fixed minor editorial nits. 2429 Changes from draft-hodges-strict-transport-sec-02 to 2430 draft-ietf-websec-strict-transport-sec-00: 2432 1. Altered spec metadata (e.g. filename, date) in order to submit 2433 as a WebSec working group Internet-Draft. 2435 D.2. For draft-hodges-strict-transport-sec 2437 Changes from -01 to -02: 2439 1. updated abstract such that means for expressing HSTS Policy 2440 other than via HSTS header field is noted. 2442 2. Changed spec title to "HTTP Strict Transport Security (HSTS)" 2443 from "Strict Transport Security". Updated use of "STS" 2444 acronym throughout spec to HSTS (except for when specifically 2445 discussing syntax of Strict-Transport-Security HTTP Response 2446 Header field), updated "Terminology" appropriately. 2448 3. Updated the discussion of "Passive Network Attackers" to be 2449 more precise and offered references. 2451 4. Removed para on nomative/non-normative from "Conformance 2452 Criteria" pending polishing said section to IETF RFC norms. 2454 5. Added examples subsection to "Syntax" section. 2456 6. Added OWS to maxAge production in Strict-Transport-Security 2457 ABNF. 2459 7. Cleaned up explanation in the "Note:" in the "HTTP-over- 2460 Secure-Transport Request Type" section, folded 3d para into 2461 "Note:", added conformance clauses to the latter. 2463 8. Added exaplanatory "Note:" and reference to "HTTP Request 2464 Type" section. Added "XXX1" issue. 2466 9. Added conformance clause to "URI Loading". 2468 10. Moved "Notes for STS Server implementers:" from "UA 2469 Implementation dvice " to "HSTS Policy expiration time 2470 considerations:" in "Server Implementation Advice", and also 2471 noted another option. 2473 11. Added cautionary "Note:" to "Ability to delete UA's cached 2474 HSTS Policy on a per HSTS Server basis". 2476 12. Added some informative references. 2478 13. Various minor editorial fixes. 2480 Changes from -00 to -01: 2482 1. Added reference to HASMAT mailing list and request that this 2483 spec be discussed there. 2485 Authors' Addresses 2487 Jeff Hodges 2488 PayPal 2489 2211 North First Street 2490 San Jose, California 95131 2491 US 2493 Email: Jeff.Hodges@PayPal.com 2495 Collin Jackson 2496 Carnegie Mellon University 2498 Email: collin.jackson@sv.cmu.edu 2500 Adam Barth 2501 Google, Inc. 2503 Email: ietf@adambarth.com 2504 URI: http://www.adambarth.com/