idnits 2.17.1 draft-ietf-websec-strict-transport-sec-13.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 14, 2012) is 4242 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 2248, 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: March 18, 2013 Carnegie Mellon University 6 A. Barth 7 Google, Inc. 8 Sep 14, 2012 10 HTTP Strict Transport Security (HSTS) 11 draft-ietf-websec-strict-transport-sec-13 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 March 18, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Organization of this specification . . . . . . . . . . . . 5 59 1.2. Document Conventions . . . . . . . . . . . . . . . . . . . 5 60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.2. HTTP Strict Transport Security Policy Effects . . . . . . 6 63 2.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3.1. Threats Addressed . . . . . . . . . . . . . . . . . . 6 65 2.3.1.1. Passive Network Attackers . . . . . . . . . . . . 6 66 2.3.1.2. Active Network Attackers . . . . . . . . . . . . . 7 67 2.3.1.3. Web Site Development and Deployment Bugs . . . . . 7 68 2.3.2. Threats Not Addressed . . . . . . . . . . . . . . . . 8 69 2.3.2.1. Phishing . . . . . . . . . . . . . . . . . . . . . 8 70 2.3.2.2. Malware and Browser Vulnerabilities . . . . . . . 8 71 2.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 72 2.4.1. Overall Requirement . . . . . . . . . . . . . . . . . 8 73 2.4.1.1. Detailed Core Requirements . . . . . . . . . . . . 8 74 2.4.1.2. Detailed Ancillary Requirements . . . . . . . . . 9 75 3. Conformance Criteria . . . . . . . . . . . . . . . . . . . . . 10 76 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5. HSTS Mechanism Overview . . . . . . . . . . . . . . . . . . . 12 78 5.1. HSTS Host Declaration . . . . . . . . . . . . . . . . . . 12 79 5.2. HSTS Policy . . . . . . . . . . . . . . . . . . . . . . . 12 80 5.3. HSTS Policy Storage and Maintenance by User Agents . . . . 13 81 5.4. User Agent HSTS Policy Enforcement . . . . . . . . . . . . 13 82 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 6.1. Strict-Transport-Security HTTP Response Header Field . . . 14 84 6.1.1. The max-age Directive . . . . . . . . . . . . . . . . 15 85 6.1.2. The includeSubDomains Directive . . . . . . . . . . . 15 86 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 7. Server Processing Model . . . . . . . . . . . . . . . . . . . 16 88 7.1. HTTP-over-Secure-Transport Request Type . . . . . . . . . 16 89 7.2. HTTP Request Type . . . . . . . . . . . . . . . . . . . . 17 90 8. User Agent Processing Model . . . . . . . . . . . . . . . . . 17 91 8.1. Strict-Transport-Security Response Header Field 92 Processing . . . . . . . . . . . . . . . . . . . . . . . . 18 93 8.1.1. Noting an HSTS Host . . . . . . . . . . . . . . . . . 19 94 8.2. Known HSTS Host Domain Name Matching . . . . . . . . . . . 19 95 8.3. URI Loading and Port Mapping . . . . . . . . . . . . . . . 20 96 8.4. Errors in Secure Transport Establishment . . . . . . . . . 21 97 8.5. HTTP-Equiv Element Attribute . . . . . . . . . . . 21 98 8.6. Missing Strict-Transport-Security Response Header Field . 21 99 9. Constructing an Effective Request URI . . . . . . . . . . . . 22 100 9.1. ERU Fundamental Definitions . . . . . . . . . . . . . . . 22 101 9.2. Determining the Effective Request URI . . . . . . . . . . 22 102 9.2.1. Effective Request URI Examples . . . . . . . . . . . . 23 103 10. Domain Name IDNA-Canonicalization . . . . . . . . . . . . . . 23 104 11. Server Implementation and Deployment Advice . . . . . . . . . 24 105 11.1. Non-Conformant User Agent Considerations . . . . . . . . . 24 106 11.2. HSTS Policy expiration time considerations . . . . . . . . 24 107 11.3. Using HSTS in conjunction with self-signed public-key 108 certificates . . . . . . . . . . . . . . . . . . . . . . . 25 109 11.4. Implications of includeSubDomains . . . . . . . . . . . . 26 110 12. User Agent Implementation Advice . . . . . . . . . . . . . . . 27 111 12.1. No User Recourse . . . . . . . . . . . . . . . . . . . . . 27 112 12.2. User-declared HSTS Policy . . . . . . . . . . . . . . . . 28 113 12.3. HSTS Pre-Loaded List . . . . . . . . . . . . . . . . . . . 28 114 12.4. Disallow Mixed Security Context Loads . . . . . . . . . . 28 115 12.5. HSTS Policy Deletion . . . . . . . . . . . . . . . . . . . 29 116 13. Internationalized Domain Names for Applications (IDNA): 117 Dependency and Migration . . . . . . . . . . . . . . . . . . . 29 118 14. Security Considerations . . . . . . . . . . . . . . . . . . . 29 119 14.1. Non-Conformant User Agent Implications . . . . . . . . . . 30 120 14.2. Ramifications of HSTS Policy Establishment only over 121 Error-free Secure Transport . . . . . . . . . . . . . . . 30 122 14.3. The Need for includeSubDomains . . . . . . . . . . . . . . 31 123 14.4. Denial of Service . . . . . . . . . . . . . . . . . . . . 32 124 14.5. Bootstrap MITM Vulnerability . . . . . . . . . . . . . . . 33 125 14.6. Network Time Attacks . . . . . . . . . . . . . . . . . . . 34 126 14.7. Bogus Root CA Certificate Phish plus DNS Cache 127 Poisoning Attack . . . . . . . . . . . . . . . . . . . . . 34 128 14.8. Creative Manipulation of HSTS Policy Store . . . . . . . . 34 129 14.9. Internationalized Domain Names . . . . . . . . . . . . . . 35 130 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 131 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 132 16.1. Normative References . . . . . . . . . . . . . . . . . . . 36 133 16.2. Informative References . . . . . . . . . . . . . . . . . . 37 134 Appendix A. Design Decision Notes . . . . . . . . . . . . . . . . 40 135 Appendix B. Differences between HSTS Policy and Same-Origin 136 Policy . . . . . . . . . . . . . . . . . . . . . . . 40 137 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . . 41 138 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 42 139 D.1. For draft-ietf-websec-strict-transport-sec . . . . . . . . 42 140 D.2. For draft-hodges-strict-transport-sec . . . . . . . . . . 49 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 143 1. Introduction 145 The HTTP protocol [RFC2616] may be used over various transports, 146 typically the Transmission Control Protocol (TCP). However, TCP does 147 not provide channel integrity protection, confidentiality, nor secure 148 host identification. Thus, the Secure Sockets Layer (SSL) protocol 149 [RFC6101], and its successor Transport Layer Security (TLS) 150 [RFC5246], were developed in order to provide channel-oriented 151 security, and are typically layered between application protocols and 152 TCP. [RFC2818] specifies how HTTP is layered onto TLS, and defines 153 the Uniform Resource Identifier (URI) scheme of "https" (in practice 154 however, HTTP user agents (UAs) typically use either TLS or SSL3 155 depending upon a combination of negotiation with the server and user 156 preferences). 158 UAs employ various local security policies with respect to the 159 characteristics of their interactions with web resources depending on 160 (in part) whether they are communicating with a given web resource's 161 host using HTTP or HTTP-over-a-Secure-Transport. For example, 162 cookies ([RFC6265]) may be flagged as Secure. UAs are to send such 163 Secure cookies to their addressed host only over a secure transport. 164 This is in contrast to non-Secure cookies, which are returned to the 165 host regardless of transport (although subject to other rules). 167 UAs typically announce to their users any issues with secure 168 connection establishment, such as being unable to validate a TLS 169 server certificate trust chain, or if a TLS server certificate is 170 expired, or if a TLS host's domain name appears incorrectly in the 171 TLS server certificate (see Section 3.1 of [RFC2818]). Often, UAs 172 enable users to elect to continue to interact with a web resource's 173 host in the face of such issues. This behavior is sometimes referred 174 to as "click(ing) through" security [GoodDhamijaEtAl05] 175 [SunshineEgelmanEtAl09], and thus can be described as "click-through 176 insecurity". 178 A key vulnerability enabled by click-through insecurity is the 179 leaking of any cookies the web resource may be using to manage a 180 user's session. The threat here is that an attacker could obtain the 181 cookies and then interact with the legitimate web resource while 182 impersonating the user. 184 Jackson and Barth proposed an approach, in [ForceHTTPS], to enable 185 web resources to declare that any interactions by UAs with the web 186 resource must be conducted securely, and that any issues with 187 establishing a secure transport session are to be treated as fatal 188 and without direct user recourse. The aim is to prevent click- 189 through insecurity, and address other potential threats. 191 This specification embodies and refines the approach proposed in 192 [ForceHTTPS]. For example, rather than using a cookie to convey 193 policy from a web resource's host to a UA, it defines an HTTP 194 response header field for this purpose. Additionally, a web 195 resource's host may declare its policy to apply to the entire domain 196 name subtree rooted at its host name. This enables HSTS to protect 197 so-called "domain cookies", which are applied to all subdomains of a 198 given web resource's host name. 200 This specification also incorporates notions from [JacksonBarth2008] 201 in that policy is applied on an "entire-host" basis: it applies to 202 HTTP (only) over any TCP port of the issuing host. 204 Note that the policy defined by this specification is distinctly 205 different than the "same-origin policy" defined in "The Web Origin 206 Concept" [RFC6454]. These differences are summarized below in 207 Appendix B. 209 1.1. Organization of this specification 211 This specification begins with an overview of the use cases, policy 212 effects, threat models, and requirements for HSTS (in Section 2). 213 Then, Section 3 defines conformance requirements. The HSTS mechanism 214 itself is formally specified in Section 4 through Section 15. 216 1.2. Document Conventions 218 NOTE: This is a note to the reader. These are points that should be 219 expressly kept in mind and/or considered. 221 2. Overview 223 This section discusses the use cases, summarizes the HTTP Strict 224 Transport Security (HSTS) policy, and continues with a discussion of 225 the threat model, non-addressed threats, and derived requirements. 227 2.1. Use Cases 229 The high-level use case is a combination of: 231 o Web browser user wishes to interact with various web sites (some 232 arbitrary, some known) in a secure fashion. 234 o Web site deployer wishes to offer their site in an explicitly 235 secure fashion for both their own, as well as their users', 236 benefit. 238 2.2. HTTP Strict Transport Security Policy Effects 240 The effects of the HTTP Strict Transport Security (HSTS) Policy, as 241 applied by a conformant UA in interactions with a web resource host 242 wielding such policy (known as an HSTS Host), are summarized as 243 follows: 245 1. UAs transform insecure URI references to an HSTS Host into secure 246 URI references before dereferencing them. 248 2. The UA terminates any secure transport connection attempts upon 249 any and all secure transport errors or warnings. 251 2.3. Threat Model 253 HSTS is concerned with three threat classes: passive network 254 attackers, active network attackers, and imperfect web developers. 255 However, it is explicitly not a remedy for two other classes of 256 threats: phishing and malware. Addressed and not addressed threats 257 are briefly discussed below. Readers may wish refer to Section 2 of 258 [ForceHTTPS] for details as well as relevant citations. 260 2.3.1. Threats Addressed 262 2.3.1.1. Passive Network Attackers 264 When a user browses the web on a local wireless network (e.g., an 265 802.11-based wireless local area network) a nearby attacker can 266 possibly eavesdrop on the user's unencrypted Internet Protocol-based 267 connections, such as HTTP, regardless of whether or not the local 268 wireless network itself is secured [BeckTews09]. Freely available 269 wireless sniffing toolkits (e.g., [Aircrack-ng]) enable such passive 270 eavesdropping attacks, even if the local wireless network is 271 operating in a secure fashion. A passive network attacker using such 272 tools can steal session identifiers/cookies and hijack the user's web 273 session(s), by obtaining cookies containing authentication 274 credentials [ForceHTTPS]. For example, there exist widely-available 275 tools, such as Firesheep (a web browser extension) [Firesheep], which 276 enable their wielder to obtain other local users' session cookies for 277 various web applications. 279 To mitigate such threats, some Web sites support, but usually do not 280 force, access using end-to-end secure transport -- e.g., signaled 281 through URIs constructed with the "https" scheme [RFC2818]. This can 282 lead users to believe that accessing such services using secure 283 transport protects them from passive network attackers. 284 Unfortunately, this is often not the case in real-world deployments 285 as session identifiers are often stored in non-Secure cookies to 286 permit interoperability with versions of the service offered over 287 insecure transport ("Secure cookies" are those cookies containing the 288 "Secure" attribute [RFC6265]). For example, if the session 289 identifier for a web site (an email service, say) is stored in a non- 290 Secure cookie, it permits an attacker to hijack the user's session if 291 the user's UA makes a single insecure HTTP request to the site. 293 2.3.1.2. Active Network Attackers 295 A determined attacker can mount an active attack, either by 296 impersonating a user's DNS server or, in a wireless network, by 297 spoofing network frames or offering a similarly-named evil twin 298 access point. If the user is behind a wireless home router, an 299 attacker can attempt to reconfigure the router using default 300 passwords and other vulnerabilities. Some sites, such as banks, rely 301 on end-to-end secure transport to protect themselves and their users 302 from such active attackers. Unfortunately, browsers allow their 303 users to easily opt-out of these protections in order to be usable 304 for sites that incorrectly deploy secure transport, for example by 305 generating and self-signing their own certificates (without also 306 distributing their certification authority (CA) certificate to their 307 users' browsers). 309 2.3.1.3. Web Site Development and Deployment Bugs 311 The security of an otherwise uniformly secure site (i.e. all of its 312 content is materialized via "https" URIs), can be compromised 313 completely by an active attacker exploiting a simple mistake, such as 314 the loading of a cascading style sheet or a SWF (Shockwave Flash) 315 movie over an insecure connection (both cascading style sheets and 316 SWF movies can script the embedding page, to the surprise of many web 317 developers, plus some browsers do not issue so-called "mixed content 318 warnings" when SWF files are embedded via insecure connections). 319 Even if the site's developers carefully scrutinize their login page 320 for "mixed content", a single insecure embedding anywhere on the 321 overall site compromises the security of their login page because an 322 attacker can script (i.e., control) the login page by injecting code 323 (e.g., a script) into another, insecurely loaded, site page. 325 NOTE: "Mixed content" as used above (see also Section 5.3 in 326 [W3C.REC-wsc-ui-20100812]) refers to the notion termed "mixed 327 security context" in this specification, and should not be 328 confused with the same "mixed content" term used in the 329 context of markup languages such as XML and HTML. 331 2.3.2. Threats Not Addressed 333 2.3.2.1. Phishing 335 Phishing attacks occur when an attacker solicits authentication 336 credentials from the user by hosting a fake site located on a 337 different domain than the real site, perhaps driving traffic to the 338 fake site by sending a link in an email message. Phishing attacks 339 can be very effective because users find it difficult to distinguish 340 the real site from a fake site. HSTS is not a defense against 341 phishing per se; rather, it complements many existing phishing 342 defenses by instructing the browser to protect session integrity and 343 long-lived authentication tokens [ForceHTTPS]. 345 2.3.2.2. Malware and Browser Vulnerabilities 347 Because HSTS is implemented as a browser security mechanism, it 348 relies on the trustworthiness of the user's system to protect the 349 session. Malicious code executing on the user's system can 350 compromise a browser session, regardless of whether HSTS is used. 352 2.4. Requirements 354 This section identifies and enumerates various requirements derived 355 from the use cases and the threats discussed above, and lists the 356 detailed core requirements HTTP Strict Transport Security addresses, 357 as well as ancillary requirements that are not directly addressed. 359 2.4.1. Overall Requirement 361 o Minimize, for web browser users and web site deployers, the risks 362 that are derived from passive and active network attackers, web 363 site development and deployment bugs, and insecure user actions. 365 2.4.1.1. Detailed Core Requirements 367 These core requirements are derived from the overall requirement, and 368 are addressed by this specification. 370 1. Web sites need to be able to declare to UAs that they should be 371 accessed using a strict security policy. 373 2. Web sites need to be able to instruct UAs that contact them 374 insecurely to do so securely. 376 3. UAs need to retain persistent data about web sites that signal 377 strict security policy enablement, for time spans declared by the 378 web sites. Additionally, UAs need to cache the "freshest" strict 379 security policy information, in order to allow web sites to 380 update the information. 382 4. UAs need to re-write all insecure UA "http" URI loads to use the 383 "https" secure scheme for those web sites for which secure policy 384 is enabled. 386 5. Web site administrators need to be able to signal strict security 387 policy application to subdomains of higher-level domains for 388 which strict security policy is enabled, and UAs need to enforce 389 such policy. 391 For example, both example.com and foo.example.com could set 392 policy for bar.foo.example.com. 394 6. UAs need to disallow security policy application to peer domains, 395 and/or higher-level domains, by domains for which strict security 396 policy is enabled. 398 For example, neither bar.foo.example.com nor foo.example.com can 399 set policy for example.com, nor can bar.foo.example.com set 400 policy for foo.example.com. Also, foo.example.com cannot set 401 policy for sibling.example.com. 403 7. UAs need to prevent users from clicking-through security 404 warnings. Halting connection attempts in the face of secure 405 transport exceptions is acceptable. See also Section 12.1 "No 406 User Recourse". 408 NOTE: A means for uniformly securely meeting the first core 409 requirement above is not specifically addressed by this 410 specification (see Section 14.5 "Bootstrap MITM 411 Vulnerability"). It may be addressed by a future revision of 412 this specification or some other specification. Note also 413 that there are means by which UA implementations may more 414 fully meet the first core requirement; see Section 12 "User 415 Agent Implementation Advice". 417 2.4.1.2. Detailed Ancillary Requirements 419 These ancillary requirements are also derived from the overall 420 requirement. They are not normatively addressed in this 421 specification, but could be met by UA implementations at their 422 implementor's discretion, although meeting these requirements may be 423 complex. 425 1. Disallow "mixed security context" loads (see Section 2.3.1.3). 427 2. Facilitate user declaration of web sites for which strict 428 security policy is enabled, regardless of whether the sites 429 signal HSTS Policy. 431 3. Conformance Criteria 433 This specification is written for hosts and user agents (UAs). 435 [[IESG NOTE: the next two paragraphs are for readers with a 436 background in W3C specification style, of which we expect many. RFC 437 Editor, please remove this note before publication.]] 439 A conformant host is one that implements all the requirements listed 440 in this specification that are applicable to hosts. 442 A conformant user agent is one that implements all the requirements 443 listed in this specification that are applicable to user agents. 445 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 446 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 447 document are to be interpreted as described in [RFC2119]. 449 4. Terminology 451 Terminology is defined in this section. 453 ASCII case-insensitive comparison: 454 means comparing two strings exactly, codepoint for 455 codepoint, except that the characters in the range 456 U+0041 .. U+005A (i.e. LATIN CAPITAL LETTER A to 457 LATIN CAPITAL LETTER Z) and the corresponding 458 characters in the range U+0061 .. U+007A (i.e. 459 LATIN SMALL LETTER A to LATIN SMALL LETTER Z) are 460 considered to also match. See [Unicode] for 461 details. 463 codepoint: is a colloquial contraction of Code Point, which is 464 any value in the Unicode codespace; that is, the 465 range of integers from 0 to 10FFFF(hex) [Unicode]. 467 domain name: domain names, also referred to as DNS Names, are 468 defined in [RFC1035] to be represented outside of 469 the DNS protocol itself (and implementations 470 thereof) as a series of labels separated by dots, 471 e.g., "example.com" or "yet.another.example.org". 472 In the context of this specification, domain names 473 appear in that portion of a URI satisfying the reg- 474 name production in "Appendix A. Collected ABNF for 475 URI" in [RFC3986], and the host component from the 476 Host HTTP header field production in Section 14.23 477 of [RFC2616]. 479 NOTE: The domain names appearing in actual URI 480 instances and matching the aforementioned 481 production components may or may not be a 482 fully qualified domain name. 484 domain name label: is that portion of a domain name appearing 485 "between the dots", i.e. consider 486 "foo.example.com": "foo", "example", and "com" are 487 all domain name labels. 489 Effective Request URI: 490 is a URI, identifying the target resource, that can 491 be inferred by an HTTP host for any given HTTP 492 request it receives. Such inference is necessary 493 because HTTP requests often do not contain a 494 complete "absolute" URI identifying the target 495 resource. See Section 9 "Constructing an Effective 496 Request URI". 498 HTTP Strict Transport Security: 499 is the overall name for the combined UA- and 500 server-side security policy defined by this 501 specification. 503 HTTP Strict Transport Security Host: 504 is a conformant host implementing the HTTP server 505 aspects of the HSTS Policy. This means that an 506 HSTS Host returns the "Strict-Transport-Security" 507 HTTP response header field in its HTTP response 508 messages sent over secure transport. 510 HTTP Strict Transport Security Policy: 511 is the name of the combined overall UA- and server- 512 side facets of the behavior defined in this 513 specification. 515 HSTS: See HTTP Strict Transport Security. 517 HSTS Host: See HTTP Strict Transport Security Host. 519 HSTS Policy: See HTTP Strict Transport Security Policy. 521 Known HSTS Host: is an HSTS Host for which the UA has an HSTS Policy 522 in effect. I.e., the UA has noted this host as a 523 Known HSTS Host. 525 Local policy: comprises policy rules deployers specify and which 526 are often manifested as configuration settings. 528 MITM: is an acronym for man-in-the-middle. See "man-in- 529 the-middle attack" in [RFC4949]. 531 Request URI: is the URI used to cause a UA to issue an HTTP 532 request message. See also "Effective Request URI". 534 UA: is a an acronym for user agent. For the purposes 535 of this specification, a UA is an HTTP client 536 application typically actively manipulated by a 537 user [RFC2616] . 539 unknown HSTS Host: is an HSTS Host that the user agent in question 540 has not yet noted. 542 5. HSTS Mechanism Overview 544 This section provides an overview of the mechanism by which an HSTS 545 Host conveys its HSTS Policy to UAs, and how User Agents process the 546 HSTS Policies received from HSTS Hosts. The mechanism details are 547 specified in Section 6 through Section 15. 549 5.1. HSTS Host Declaration 551 An HTTP host declares itself an HSTS Host by issuing to UAs an HSTS 552 Policy, which is represented by, and conveyed via, the Strict- 553 Transport-Security HTTP response header field over secure transport 554 (e.g., TLS). Upon error-free receipt and processing of this header 555 by a conformant UA, the UA regards the host as a Known HSTS Host. 557 5.2. HSTS Policy 559 An HSTS Policy directs UAs to communicate with a Known HSTS Host only 560 over secure transport, and specifies policy retention time duration. 562 HSTS Policy explicitly overrides the UA processing of URI references, 563 user input (e.g., via the "location bar"), or other information that, 564 in the absence of HSTS Policy, might otherwise cause UAs to 565 communicate insecurely with the Known HSTS Host. 567 An HSTS Policy may contain an optional flag -- includeSubDomains -- 568 specifying that this HSTS Policy also applies to any hosts whose 569 domain names are subdomains of the Known HSTS Host's domain name. 571 5.3. HSTS Policy Storage and Maintenance by User Agents 573 UAs store and index HSTS Policies based strictly upon the domain 574 names of the issuing HSTS Hosts. 576 This means that UAs will maintain the HSTS Policy of any given HSTS 577 Host separately from any HSTS Policies issued by any other HSTS Hosts 578 whose domain names are superdomains or subdomains of the given HSTS 579 Host's domain name. Only the given HSTS Host can update, or cause 580 deletion of, its issued HSTS Policy. It accomplishes this by sending 581 Strict-Transport-Security HTTP response header fields to UAs with new 582 values for policy time duration and subdomain applicability. Thus, 583 UAs cache the "freshest" HSTS Policy information on behalf of an HSTS 584 Host. Specifying a zero time duration signals to the UA to delete 585 the HSTS Policy (including any asserted includeSubDomains flag) for 586 that HSTS Host. See Section 8.1 "Strict-Transport-Security Response 587 Header Field Processing" for details. Additionally, Section 6.2 588 presents examples of Strict-Transport-Security HTTP response header 589 fields. 591 5.4. User Agent HSTS Policy Enforcement 593 When establishing an HTTP connection to a given host, however 594 instigated, the UA examines its cache of Known HSTS Hosts to see if 595 there are any with domain names that are superdomains of the given 596 host's domain name. If any are found, and of those if any have the 597 includeSubDomains flag asserted, then HSTS Policy applies to the 598 given host. Otherwise, HSTS Policy applies to the given host only if 599 the given host is itself known to the UA as an HSTS Host. See 600 Section 8.3 "URI Loading and Port Mapping" for details. 602 6. Syntax 604 This section defines the syntax of the Strict-Transport-Security HTTP 605 response header field and its directives, and presents some examples. 607 Section 7 "Server Processing Model" then details how hosts employ 608 this header field to declare their HSTS Policy, and Section 8 "User 609 Agent Processing Model" details how user agents process the header 610 field and apply the HSTS Policy. 612 6.1. Strict-Transport-Security HTTP Response Header Field 614 The Strict-Transport-Security HTTP response header field (STS header 615 field) indicates to a UA that it MUST enforce the HSTS Policy in 616 regards to the host emitting the response message containing this 617 header field. 619 The ABNF (Augmented Backus-Naur Form) syntax for the STS header field 620 is given below. It is based on the Generic Grammar defined in 621 Section 2 of [RFC2616] (which includes a notion of "implied linear 622 whitespace", also known as "implied *LWS"). 624 Strict-Transport-Security = "Strict-Transport-Security" ":" 625 [ directive ] *( ";" [ directive ] ) 627 directive = directive-name [ "=" directive-value ] 628 directive-name = token 629 directive-value = token | quoted-string 631 where: 633 token = 634 quoted-string = 636 The two directives defined in this specification are described below. 637 The overall requirements for directives are: 639 1. The order of appearance of directives is not significant. 641 2. All directives MUST appear only once in an STS header field. 642 Directives are either optional or required, as stipulated in 643 their definitions. 645 3. Directive names are case-insensitive. 647 4. UAs MUST ignore any STS header fields containing directives, or 648 other header field value data, that does not conform to the 649 syntax defined in this specification. 651 5. If an STS header field contains directive(s) not recognized by 652 the UA, the UA MUST ignore the unrecognized directives and if the 653 STS header field otherwise satisfies the above requirements (1 654 through 4), the UA MUST process the recognized directives. 656 Additional directives extending the semantic functionality of the STS 657 header field can be defined in other specifications, with a registry 658 (having an IANA policy definition of IETF Review [RFC5226]) defined 659 for them at such time. 661 NOTE: Such future directives will be ignored by UAs implementing 662 only this specification, as well as by generally non- 663 conforming UAs. See Section 14.1 "Non-Conformant User Agent 664 Implications" for further discussion. 666 6.1.1. The max-age Directive 668 The REQUIRED "max-age" directive specifies the number of seconds, 669 after the reception of the STS header field, during which the UA 670 regards the host (from whom the message was received) as a Known HSTS 671 Host. See also Section 8.1.1 "Noting an HSTS Host". The delta- 672 seconds production is specified in [RFC2616]. 674 The syntax of the max-age directive's REQUIRED value (after quoted- 675 string unescaping, if necessary) is defined as: 677 max-age-value = delta-seconds 679 delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2> 681 NOTE: A max-age value of zero (i.e., "max-age=0") signals the UA to 682 cease regarding the host as a Known HSTS Host, including the 683 includeSubDomains flag (if asserted for that HSTS Host). See 684 also Section 8.1 "Strict-Transport-Security Response Header 685 Field Processing". 687 6.1.2. The includeSubDomains Directive 689 The OPTIONAL "includeSubDomains" directive is a valueless flag which, 690 if present, signals to the UA that the HSTS Policy applies to this 691 HSTS Host as well as any subdomains of the host's domain name. 693 6.2. Examples 695 The below HSTS header field stipulates that the HSTS Policy is to 696 remain in effect for one year (there are approximately 31 536 000 697 seconds in a year), and the policy applies only to the domain of the 698 HSTS Host issuing it: 700 Strict-Transport-Security: max-age=31536000 702 The below HSTS header field stipulates that the HSTS Policy is to 703 remain in effect for approximately six months and the policy applies 704 to the domain of the issuing HSTS Host and all of its subdomains: 706 Strict-Transport-Security: max-age=15768000 ; includeSubDomains 708 The max-age directive value can optionally be quoted: 710 Strict-Transport-Security: max-age="31536000" 712 The below HSTS header field indicates that the UA must delete the 713 entire HSTS Policy associated with the HSTS Host that sent the header 714 field: 716 Strict-Transport-Security: max-age=0 718 The below HSTS header field has exactly the same effect as the one 719 immediately above because the includeSubDomains flag's presence in 720 the HSTS header field is ignored when max-age is zero: 722 Strict-Transport-Security: max-age=0; includeSubDomains 724 7. Server Processing Model 726 This section describes the processing model that HSTS Hosts 727 implement. The model comprises two facets: the first being the 728 processing rules for HTTP request messages received over a secure 729 transport (TLS [RFC5246], SSL [RFC6101], or perhaps others), the 730 second being the processing rules for HTTP request messages received 731 over non-secure transports, such as TCP. 733 7.1. HTTP-over-Secure-Transport Request Type 735 When replying to an HTTP request that was conveyed over a secure 736 transport, an HSTS Host SHOULD include in its response message an STS 737 header field that MUST satisfy the grammar specified above in 738 Section 6.1 "Strict-Transport-Security HTTP Response Header Field". 739 If an STS header field is included, the HSTS Host MUST include only 740 one such header field. 742 Establishing a given host as a Known HSTS Host, in the context of a 743 given UA, MAY be accomplished over the HTTP protocol by correctly 744 returning, per this specification, at least one valid STS header 745 field to the UA. Other mechanisms, such as a client-side pre-loaded 746 Known HSTS Host list MAY also be used. E.g., see Section 12 "User 747 Agent Implementation Advice". 749 NOTE: Including the STS header field is stipulated as a "SHOULD" in 750 order to accommodate various server- and network-side caches 751 and load-balancing configurations where it may be difficult to 752 uniformly emit STS header fields on behalf of a given HSTS 753 Host. 755 7.2. HTTP Request Type 757 If an HSTS Host receives a HTTP request message over a non-secure 758 transport, it SHOULD send a HTTP response message containing a status 759 code indicating a permanent redirect, such as status code 301 760 (Section 10.3.2 of [RFC2616]), and a Location header field value 761 containing either the HTTP request's original Effective Request URI 762 (see Section 9 "Constructing an Effective Request URI") altered as 763 necessary to have a URI scheme of "https", or a URI generated 764 according to local policy with a URI scheme of "https"). 766 NOTE: The above behavior is a "SHOULD" rather than a "MUST" due to: 768 * Risks in server-side non-secure-to-secure redirects 769 [owaspTLSGuide]. 771 * Site deployment characteristics. For example, a site that 772 incorporates third-party components may not behave correctly 773 when doing server-side non-secure-to-secure redirects in the 774 case of being accessed over non-secure transport, but does 775 behave correctly when accessed uniformly over secure transport. 776 The latter is the case given a HSTS-capable UA that has already 777 noted the site as a Known HSTS Host (by whatever means, e.g., 778 prior interaction or UA configuration). 780 An HSTS Host MUST NOT include the STS header field in HTTP responses 781 conveyed over non-secure transport. 783 8. User Agent Processing Model 785 This section describes the HTTP Strict Transport Security processing 786 model for UAs. There are several facets to the model, enumerated by 787 the following subsections. 789 This processing model assumes that the UA implements IDNA2008 790 [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 13 791 "Internationalized Domain Names for Applications (IDNA): Dependency 792 and Migration". It also assumes that all domain names manipulated in 793 this specification's context are already IDNA-canonicalized as 794 outlined in Section 10 "Domain Name IDNA-Canonicalization" prior to 795 the processing specified in this section. 797 The above assumptions mean that this processing model also 798 specifically assumes that appropriate IDNA and Unicode validations 799 and character list testing have occurred on the domain names, in 800 conjunction with their IDNA-canonicalization, prior to the processing 801 specified in this section. See the IDNA-specific security 802 considerations in Section 14.9 "Internationalized Domain Names" for 803 rationale and further details. 805 8.1. Strict-Transport-Security Response Header Field Processing 807 If an HTTP response, received over a secure transport, includes an 808 STS header field, conforming to the grammar specified in Section 6.1 809 "Strict-Transport-Security HTTP Response Header Field", and there are 810 no underlying secure transport errors or warnings (see Section 8.4), 811 the UA MUST either: 813 o Note the host as a Known HSTS Host if it is not already so noted 814 (see Section 8.1.1 "Noting an HSTS Host"), 816 or, 818 o Update the UA's cached information for the Known HSTS Host if 819 either or both of the max-age and includeSubDomains header field 820 value tokens are conveying information different than that already 821 maintained by the UA. 823 The max-age value is essentially a "time to live" value relative 824 to the reception time of the STS header field. 826 If the max-age header field value token has a value of zero, the 827 UA MUST remove its cached HSTS Policy information (including the 828 includeSubDomains flag if asserted) if the HSTS Host is known, or, 829 MUST NOT note this HSTS Host if it is not yet known. 831 If a UA receives more than one STS header field in a HTTP response 832 message over secure transport, then the UA MUST process only the 833 first such header field. 835 Otherwise: 837 o If an HTTP response is received over insecure transport, the UA 838 MUST ignore any present STS header field(s). 840 o The UA MUST ignore any STS header fields not conforming to the 841 grammar specified in Section 6.1 "Strict-Transport-Security HTTP 842 Response Header Field". 844 8.1.1. Noting an HSTS Host 846 If the substring matching the host production from the Request-URI 847 (of the message to which the host responded) syntactically matches 848 the IP-literal or IPv4address productions from Section 3.2.2 of 849 [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host. 851 Otherwise, if the substring does not congruently match a Known HSTS 852 Host's domain name, per the matching procedure specified in 853 Section 8.2 "Known HSTS Host Domain Name Matching", then the UA MUST 854 note this host as a Known HSTS Host, caching the HSTS Host's domain 855 name and noting along with it the expiry time of this information, as 856 effectively stipulated per the given max-age value, as well as 857 whether the includeSubDomains flag is asserted or not. See also 858 Section 11.2 "HSTS Policy expiration time considerations". 860 The UA MUST NOT modify the expiry time nor the includeSubDomains flag 861 of any superdomain matched Known HSTS Host. 863 8.2. Known HSTS Host Domain Name Matching 865 A given domain name may match a Known HSTS Host's domain name in one 866 or both of two fashions: a congruent match, or a superdomain match. 867 Or, there may be no match. 869 The below steps determine whether there are any matches, and if so, 870 of which fashion: 872 Compare the given domain name with the domain name of each of the 873 UA's Known HSTS Hosts. For each Known HSTS Host's domain name, 874 the comparison is done with the given domain name label-by-label 875 (comparing only labels) using an ASCII case-insensitive comparison 876 beginning with the rightmost label, and continuing right-to-left. 877 See also Section 2.3.2.4. of [RFC5890]. 879 * Superdomain Match 881 If a label-for-label match between an entire Known HSTS Host's 882 domain name and a right-hand portion of the given domain name 883 is found, then this Known HSTS Host's domain name is a 884 superdomain match for the given domain name. There could be 885 multiple superdomain matches for a given domain name. 887 For example: 889 Given Domain Name: qaz.bar.foo.example.com 891 Superdomain matched 892 Known HSTS Host DN: bar.foo.example.com 894 Superdomain matched 895 Known HSTS Host DN: foo.example.com 897 * Congruent Match 899 If a label-for-label match between a Known HSTS Host's domain 900 name and the given domain name is found -- i.e., there are no 901 further labels to compare -- then the given domain name 902 congruently matches this Known HSTS Host. 904 For example: 906 Given Domain Name: foo.example.com 908 Congruently matched 909 Known HSTS Host DN: foo.example.com 911 * Otherwise, if no matches are found, the given domain name does 912 not represent a Known HSTS Host. 914 8.3. URI Loading and Port Mapping 916 Whenever the UA prepares to "load", also known as "dereference", any 917 "http" URI [RFC3986] (including when following HTTP redirects 918 [RFC2616]), the UA MUST first determine whether a domain name is 919 given in the URI and whether it matches a Known HSTS Host, using 920 these steps: 922 1. Extract from the URI any substring described by the host 923 component of the authority component of the URI. 925 2. If the substring is null, then there is no match with any Known 926 HSTS Host. 928 3. Else, if the substring is non-null and syntactically matches the 929 IP-literal or IPv4address productions from Section 3.2.2 of 930 [RFC3986], then there is no match with any Known HSTS Host. 932 4. Otherwise, the substring is a given domain name, which MUST be 933 matched against the UA's Known HSTS Hosts using the procedure in 934 Section 8.2 "Known HSTS Host Domain Name Matching". 936 5. If when performing domain name matching, any superdomain match 937 with an asserted includeSubDomains flag is found, or, if no 938 superdomain matches with asserted includeSubDomains flags are 939 found and a congruent match is found (with or without an asserted 940 includeSubDomains flag), then before proceeding with the load: 942 The UA MUST replace the URI scheme with "https" [RFC2818], 943 and, 945 if the URI contains an explicit port component of "80", then 946 the UA MUST convert the port component to be "443", or, 948 if the URI contains an explicit port component that is not 949 equal to "80", the port component value MUST be preserved, 950 otherwise, 952 if the URI does not contain an explicit port component, the UA 953 MUST NOT add one. 955 NOTE: These steps ensure that the HSTS Policy applies to HTTP 956 over any TCP port of an HSTS Host. 958 8.4. Errors in Secure Transport Establishment 960 When connecting to a Known HSTS Host, the UA MUST terminate the 961 connection (see also Section 12 "User Agent Implementation Advice") 962 if there are any errors, whether "warning" or "fatal" or any other 963 error level, with the underlying secure transport. For example, this 964 includes any errors found in certificate validity checking UAs employ 965 such as via Certificate Revocation Lists (CRL) [RFC5280], or via the 966 Online Certificate Status Protocol (OCSP) [RFC2560]. 968 8.5. HTTP-Equiv Element Attribute 970 UAs MUST NOT heed http-equiv="Strict-Transport-Security" attribute 971 settings on elements [W3C.REC-html401-19991224] in received 972 content. 974 8.6. Missing Strict-Transport-Security Response Header Field 976 If a UA receives HTTP responses from a Known HSTS Host over a secure 977 channel, but they are missing the STS header field, the UA MUST 978 continue to treat the host as a Known HSTS Host until the max-age 979 value for the knowledge of that Known HSTS Host is reached. Note 980 that the max-age value could be effectively infinite for a given 981 Known HSTS Host. For example, this would be the case if the Known 982 HSTS Host is part of a pre-configured list that is implemented such 983 that the list entries never "age out". 985 9. Constructing an Effective Request URI 987 This section specifies how an HSTS Host must construct the Effective 988 Request URI for a received HTTP request. 990 HTTP requests often do not carry an absoluteURI for the target 991 resource; instead, the URI needs to be inferred from the Request-URI, 992 Host header field, and connection context ([RFC2616], Sections 3.2.1, 993 5.1.2, and 5.2). The result of this process is called the "effective 994 request URI (ERU)". The "target resource" is the resource identified 995 by the effective request URI. 997 9.1. ERU Fundamental Definitions 999 The first line of an HTTP request message, Request-Line, is specified 1000 by the following ABNF from [RFC2616], Section 5.1: 1002 Request-Line = Method SP Request-URI SP HTTP-Version CRLF 1004 The Request-URI, within the Request-Line, is specified by the 1005 following ABNF from [RFC2616], Section 5.1.2: 1007 Request-URI = "*" | absoluteURI | abs_path | authority 1009 The Host request header field is specified by the following ABNF from 1010 [RFC2616], Section 14.23: 1012 Host = "Host" ":" host [ ":" port ] 1014 9.2. Determining the Effective Request URI 1016 If the Request-URI is an absoluteURI, then the effective request URI 1017 is the Request-URI. 1019 If the Request-URI uses the abs_path form or the asterisk form, and 1020 the Host header field is present, then the effective request URI is 1021 constructed by concatenating: 1023 o the scheme name: "http" if the request was received over an 1024 insecure TCP connection, or "https" when received over a TLS/ 1025 SSL-secured TCP connection, and, 1027 o the octet sequence "://", and, 1029 o the host, and the port (if present), from the Host header field, 1030 and 1032 o the Request-URI obtained from the Request-Line, unless the 1033 Request-URI is just the asterisk "*". 1035 If the Request-URI uses the abs_path form or the asterisk form, and 1036 the Host header field is not present, then the effective request URI 1037 is undefined. 1039 Otherwise, when Request-URI uses the authority form, the effective 1040 request URI is undefined. 1042 Effective request URIs are compared using the rules described in 1043 [RFC2616] Section 3.2.3, except that empty path components MUST NOT 1044 be treated as equivalent to an absolute path of "/". 1046 9.2.1. Effective Request URI Examples 1048 Example 1: the effective request URI for the message 1050 GET /pub/WWW/TheProject.html HTTP/1.1 1051 Host: www.example.org:8080 1053 (received over an insecure TCP connection) is "http", plus "://", 1054 plus the authority component "www.example.org:8080", plus the 1055 request-target "/pub/WWW/TheProject.html". Thus it is: 1056 "http://www.example.org:8080/pub/WWW/TheProject.html". 1058 Example 2: the effective request URI for the message 1060 OPTIONS * HTTP/1.1 1061 Host: www.example.org 1063 (received over an SSL/TLS secured TCP connection) is "https", plus 1064 "://", plus the authority component "www.example.org". Thus it is: 1065 "https://www.example.org". 1067 10. Domain Name IDNA-Canonicalization 1069 An IDNA-canonicalized domain name is the output string generated by 1070 the following steps. The input is a putative domain name string 1071 ostensibly composed of any combination of "A-labels", "U-labels", and 1072 "NR-LDH labels" (see Section 2 of [RFC5890]) concatenated using some 1073 separator character (typically "."). 1075 1. Convert the input putative domain name string to a order- 1076 preserving sequence of individual label strings. 1078 2. When implementing IDNA2008, convert, validate, and test each 1079 A-label and U-label found among the sequence of individual label 1080 strings, using the procedures defined in Sections 5.3 through 5.5 1081 of [RFC5891]. 1083 Otherwise, when implementing IDNA2003, convert each label using 1084 the "ToASCII" conversion in Section 4 of [RFC3490] (see also the 1085 definition of "equivalence of labels" in Section 2 of the latter 1086 specification). 1088 3. If no errors occurred during the foregoing step, concatenate all 1089 the labels in the sequence, in order, into a string, separating 1090 each label from the next with a %x2E (".") character. The 1091 resulting string, known as a IDNA-canonicalized domain name, is 1092 appropriate for use in the context of Section 8 "User Agent 1093 Processing Model". 1095 Otherwise, errors occurred. The input putative domain name 1096 string was not successfully IDNA-canonicalized. Invokers of this 1097 procedure should attempt appropriate error recovery. 1099 See also Section 13 "Internationalized Domain Names for Applications 1100 (IDNA): Dependency and Migration" and Section 14.9 "Internationalized 1101 Domain Names" of this specification for further details and 1102 considerations. 1104 11. Server Implementation and Deployment Advice 1106 This section is non-normative. 1108 11.1. Non-Conformant User Agent Considerations 1110 Non-conformant UAs ignore the Strict-Transport-Security header field, 1111 thus non-conformant user agents do not address the threats described 1112 in Section 2.3.1 "Threats Addressed". Please refer to Section 14.1 1113 "Non-Conformant User Agent Implications" for further discussion. 1115 11.2. HSTS Policy expiration time considerations 1117 Server implementations and deploying web sites need to consider 1118 whether they are setting an expiry time that is a constant value into 1119 the future, or whether they are setting an expiry time that is a 1120 fixed point in time. 1122 The constant value into the future approach can be accomplished by 1123 constantly sending the same max-age value to UAs. 1125 For example, a max-age value of 7776000 seconds is 90 days: 1127 Strict-Transport-Security: max-age=7776000 1129 Note that each receipt of this header by a UA will require the UA to 1130 update its notion of when it must delete its knowledge of this Known 1131 HSTS Host. 1133 The fixed point in time approach can be accomplished by sending max- 1134 age values that represent the remaining time until the desired expiry 1135 time. This would require the HSTS Host to send a newly-calculated 1136 max-age value on each HTTP response. 1138 A consideration here is whether a deployer wishes to have the 1139 signaled HSTS Policy expiry time match that for the web site's domain 1140 certificate. 1142 Additionally, server implementers should consider employing a default 1143 max-age value of zero in their deployment configuration systems. 1144 This will require deployers to wilfully set max-age in order to have 1145 UAs enforce the HSTS Policy for their host, and protects them from 1146 inadvertently enabling HSTS with some arbitrary non-zero duration. 1148 11.3. Using HSTS in conjunction with self-signed public-key 1149 certificates 1151 If all four of the following conditions are true... 1153 o a web site/organization/enterprise is generating its own secure 1154 transport public-key certificates for web sites, and 1156 o that organization's root certification authority (CA) certificate 1157 is not typically embedded by default in browser and/or operating 1158 system CA certificate stores, and 1160 o HSTS Policy is enabled on a host identifying itself using a 1161 certificate signed by the organization's CA (i.e., a "self-signed 1162 certificate"), and 1164 o and this certificate does not match a usable TLS certificate 1165 association (as defined by Section 4 of the TLSA protocol 1166 specification [RFC6698]), 1168 ...then secure connections to that site will fail, per the HSTS 1169 design. This is to protect against various active attacks, as 1170 discussed above. 1172 However, if said organization wishes to employ its own CA, and self- 1173 signed certificates, in concert with HSTS, it can do so by deploying 1174 its root CA certificate to its users' browsers or operating system CA 1175 root certificate stores. It can also, in addition or instead, 1176 distribute to its users' browsers the end-entity certificate(s) for 1177 specific hosts. There are various ways in which this can be 1178 accomplished (details are out of scope for this specification). Once 1179 its root CA certificate is installed in the browsers, it may employ 1180 HSTS Policy on its site(s). 1182 Alternatively, that organization can deploy the TLSA protocol; all 1183 browsers that also use TLSA will then be able to trust the 1184 certificates identified by usable TLS certificate associations as 1185 denoted via TLSA. 1187 NOTE: Interactively distributing root CA certificates to users, 1188 e.g., via email, and having the users install them, is 1189 arguably training the users to be susceptible to a possible 1190 form of phishing attack. See Section 14.7 "Bogus Root CA 1191 Certificate Phish plus DNS Cache Poisoning Attack". Thus care 1192 should be taken in the manner in which such certificates are 1193 distributed and installed on users' systems and browsers. 1195 11.4. Implications of includeSubDomains 1197 The includeSubDomains directive has some practical implications. For 1198 example, if an HSTS Host offers HTTP-based services on various ports 1199 or at various subdomains of its host domain name, then they will all 1200 have to be available over secure transport in order to work properly. 1202 For example, certification authorities often offer their CRL 1203 distribution and OCSP services [RFC2560] over plain HTTP, and 1204 sometimes at a subdomain of a publicly-available web application 1205 which may be secured by TLS/SSL. For example, 1206 is a publicly-available web application for 1207 "Example CA", a certification authority. Customers use this web 1208 application to register their public keys and obtain certificates. 1209 Example CA generates certificates for customers containing 1210 as the value for the "CRL 1211 Distribution Points" and "Authority Information Access:OCSP" 1212 certificate fields. 1214 If ca.example.com were to issue an HSTS Policy with the 1215 includeSubDomains directive, then HTTP-based user agents implementing 1216 HSTS that have interacted with the ca.example.com web application 1217 would fail to retrieve CRLs, and fail to check OCSP for certificates, 1218 because these services are offered over plain HTTP. 1220 In this case, Example CA can either: 1222 o not use the includeSubDomains directive, or, 1224 o ensure HTTP-based services offered at subdomains of ca.example.com 1225 are also uniformly offered over TLS/SSL, or, 1227 o offer plain HTTP-based services at a different domain name, e.g., 1228 crl-and-ocsp.ca.example.NET, or, 1230 o utilize an alternative approach to distributing certificate status 1231 information, obviating the need to offer CRL distribution and OCSP 1232 services over plain HTTP (e.g., the "Certificate Status Request" 1233 TLS extension [RFC6066], often colloquially referred to as "OCSP 1234 Stapling"). 1236 NOTE: The above points are expressly only an example and do not 1237 purport to address all the involved complexities. For 1238 instance, there are many considerations -- on the part of CAs, 1239 certificate deployers, and applications (e.g., browsers) -- 1240 involved in deploying an approach such as "OCSP Stapling". 1241 Such issues are out of scope for this specification. 1243 12. User Agent Implementation Advice 1245 This section is non-normative. 1247 In order to provide users and web sites more effective protection, as 1248 well as controls for managing their UA's caching of HSTS Policy, UA 1249 implementers should consider including features such as: 1251 12.1. No User Recourse 1253 Failing secure connection establishment on any warnings or errors 1254 (per Section 8.4 "Errors in Secure Transport Establishment") should 1255 be done with "no user recourse". This means that the user should not 1256 be presented with a dialog giving her the option to proceed. Rather, 1257 it should be treated similarly to a server error where there is 1258 nothing further the user can do with respect to interacting with the 1259 target web application, other than wait and re-try. 1261 Essentially, "any warnings or errors" means anything that would cause 1262 the UA implementation to announce to the user that something is not 1263 entirely correct with the connection establishment. 1265 Not doing this, i.e., allowing user recourse such as "clicking- 1266 through warning/error dialogs", is a recipe for a Man-in-the-Middle 1267 attack. If a web application issues an HSTS Policy, then it is 1268 opting into this scheme, whereby all certificate errors or warnings 1269 cause a connection termination, with no chance to "fool" the user 1270 into making the wrong decision and compromising themselves. 1272 12.2. User-declared HSTS Policy 1274 A User-declared HSTS Policy is the ability for users to explicitly 1275 declare a given Domain Name as representing an HSTS Host, thus 1276 seeding it as a Known HSTS Host before any actual interaction with 1277 it. This would help protect against the Section 14.5 "Bootstrap MITM 1278 Vulnerability". 1280 NOTE: Such a feature is difficult to get right on a per-site basis. 1281 See the discussion of "rewrite rules" in Section 5.5 of 1282 [ForceHTTPS]. For example, arbitrary web sites may not 1283 materialize all their URIs using the "https" scheme, and thus 1284 could "break" if a UA were to attempt to access the site 1285 exclusively using such URIs. Also note that this feature 1286 would complement, but is independent of, an "HSTS Pre-Loaded 1287 List" feature (see Section 12.3). 1289 12.3. HSTS Pre-Loaded List 1291 An HSTS Pre-Loaded List is a facility whereby web site administrators 1292 can have UAs pre-configured with HSTS Policy for their site(s) by the 1293 UA vendor(s) -- a so-called "pre-loaded list" -- in a manner similar 1294 to how root CA certificates are embedded in browsers "at the 1295 factory". This would help protect against the Section 14.5 1296 "Bootstrap MITM Vulnerability". 1298 NOTE: Such a facility would complement a "User-declared HSTS Policy" 1299 feature. 1301 12.4. Disallow Mixed Security Context Loads 1303 "Mixed security context" loads happen when an web application 1304 resource, fetched by the UA over a secure transport, subsequently 1305 causes the fetching of one or more other resources without using 1306 secure transport. This is also generally referred to as "mixed 1307 content" loads (see Section 5.3 "Mixed Content" in 1308 [W3C.REC-wsc-ui-20100812]), but should not be confused with the same 1309 "mixed content" term that is also used in the context of markup 1310 languages such as XML and HTML. 1312 NOTE: In order to provide behavioral uniformity across UA 1313 implementations, the notion of mixed security context will 1314 require further standardization work, e.g., to define the 1315 term(s) more clearly and to define specific behaviors with 1316 respect to it. 1318 12.5. HSTS Policy Deletion 1320 HSTS Policy Deletion is the ability to delete a UA's cached HSTS 1321 Policy on a per HSTS Host basis. 1323 NOTE: Adding such a feature should be done very carefully in both 1324 the user interface and security senses. Deleting a cache 1325 entry for a Known HSTS Host should be a very deliberate and 1326 well-considered act -- it shouldn't be something users get 1327 used to just "clicking through" in order to get work done. 1328 Also, implementations need to guard against allowing an 1329 attacker to inject code, e.g. ECMAscript, into the UA that 1330 silently and programmatically removes entries from the UA's 1331 cache of Known HSTS Hosts. 1333 13. Internationalized Domain Names for Applications (IDNA): Dependency 1334 and Migration 1336 Textual domain names on the modern Internet may contain one or more 1337 "internationalized" domain name labels. Such domain names are 1338 referred to as "internationalized domain names" (IDNs). The 1339 specification suites defining IDNs and the protocols for their use 1340 are named "Internationalized Domain Names for Applications (IDNA)". 1341 At this time, there are two such specification suites: IDNA2008 1342 [RFC5890] and its predecessor IDNA2003 [RFC3490]. 1344 IDNA2008 obsoletes IDNA2003, but there are differences between the 1345 two specifications, and thus there can be differences in processing 1346 (e.g., converting) domain name labels that have been registered under 1347 one from those registered under the other. There will be a 1348 transition period of some time during which IDNA2003-based domain 1349 name labels will exist in the wild. In order to facilitate their 1350 IDNA transition, user agents SHOULD implement IDNA2008 [RFC5890] and 1351 MAY implement [RFC5895] (see also Section 7 of [RFC5894]) or [UTS46]. 1352 If a user agent does not implement IDNA2008, the user agent MUST 1353 implement IDNA2003. 1355 14. Security Considerations 1357 This specification concerns the expression, conveyance, and 1358 enforcement of the HSTS Policy. The overall HSTS Policy threat 1359 model, including addressed and unaddressed threats, is given in 1360 Section 2.3 "Threat Model". 1362 Additionally, the below sections discuss operational ramifications of 1363 the HSTS Policy, provide feature rationale, discuss potential HSTS 1364 Policy misuse, and highlight some known vulnerabilities in the HSTS 1365 Policy regime. 1367 14.1. Non-Conformant User Agent Implications 1369 Non-conformant user agents ignore the Strict-Transport-Security 1370 header field, thus non-conformant user agents do not address the 1371 threats described in Section 2.3.1 "Threats Addressed". 1373 This means that the web application and its users wielding non- 1374 conformant UAs will be vulnerable to both: 1376 o Passive network attacks due to web site development and deployment 1377 bugs: 1379 For example, if the web application contains any insecure, 1380 non-"https", references to the web application server, and if 1381 not all of its cookies are flagged as "Secure", then its 1382 cookies will be vulnerable to passive network sniffing, and 1383 potentially subsequent misuse of user credentials. 1385 o Active network attacks: 1387 For example, if an attacker is able to place a man-in-the- 1388 middle, secure transport connection attempts will likely yield 1389 warnings to the user, but without HSTS Policy being enforced, 1390 the present common practice is to allow the user to "click- 1391 through" and proceed. This renders the user and possibly the 1392 web application open to abuse by such an attacker. 1394 This is essentially the status-quo for all web applications and their 1395 users in the absence of HSTS Policy. Since web application providers 1396 typically do not control the type or version of UAs their web 1397 applications interact with, the implication is that HSTS Host 1398 deployers must generally exercise the same level of care to avoid web 1399 site development and deployment bugs (see Section 2.3.1.3) as they 1400 would if they were not asserting HSTS Policy. 1402 14.2. Ramifications of HSTS Policy Establishment only over Error-free 1403 Secure Transport 1405 The User Agent Processing Model defined in Section 8, stipulates that 1406 a host is initially noted as a Known HSTS Host, or that updates are 1407 made to a Known HSTS Host's cached information, only if the UA 1408 receives the STS header field over a secure transport connection 1409 having no underlying secure transport errors or warnings. 1411 The rationale behind this is that if there is a man-in-the-middle 1412 (MITM) -- whether a legitimately deployed proxy or an illegitimate 1413 entity -- it could cause various mischief (see also Appendix A 1414 "Design Decision Notes", item 3, as well as Section 14.5 "Bootstrap 1415 MITM Vulnerability"), for example: 1417 o Unauthorized notation of the host as a Known HSTS Host, 1418 potentially leading to a denial of service situation if the host 1419 does not uniformly offer its services over secure transport (see 1420 also Section 14.4 "Denial of Service"). 1422 o Resetting the time-to-live for the host's designation as a Known 1423 HSTS Host by manipulating the max-age header field parameter value 1424 that is returned to the UA. If max-age is returned as zero, this 1425 will cause the host to cease being regarded as an Known HSTS Host 1426 by the UA, leading to either insecure connections to the host or 1427 possibly denial-of-service if the host delivers its services only 1428 over secure transport. 1430 However, this means that if a UA is "behind" a MITM non-transparent 1431 TLS proxy -- within a corporate intranet, for example -- and 1432 interacts with an unknown HSTS Host beyond the proxy, the user could 1433 possibly be presented with the legacy secure connection error 1434 dialogs. Even if the risk is accepted and the user clicks-through, 1435 the host will not be noted as an HSTS Host. Thus, as long as the UA 1436 is behind such a proxy the user will be vulnerable, and possibly be 1437 presented with the legacy secure connection error dialogs for as yet 1438 unknown HSTS Hosts. 1440 Once the UA successfully connects to an unknown HSTS Host over error- 1441 free secure transport, the host will be noted as a Known HSTS Host. 1442 This will result in the failure of subsequent connection attempts 1443 from behind interfering proxies. 1445 The above discussion relates to the recommendation in Section 12 1446 "User Agent Implementation Advice" that the secure connection be 1447 terminated with "no user recourse" whenever there are warnings and 1448 errors and the host is a Known HSTS Host. Such a posture protects 1449 users from "clicking through" security warnings and putting 1450 themselves at risk. 1452 14.3. The Need for includeSubDomains 1454 Without the includeSubDomains directive, a web application would not 1455 be able to adequately protect so-called "domain cookies" (even if 1456 these cookies have their "Secure" flag set and thus are conveyed only 1457 on secure channels). These are cookies the web application expects 1458 UAs to return to any and all subdomains of the web application. 1460 For example, suppose example.com represents the top-level DNS name 1461 for a web application. Further suppose that this cookie is set for 1462 the entire example.com domain, i.e. it is a "domain cookie", and it 1463 has its Secure flag set. Suppose example.com is a Known HSTS Host 1464 for this UA, but the includeSubDomains flag is not set. 1466 Now, if an attacker causes the UA to request a subdomain name that is 1467 unlikely to already exist in the web application, such as 1468 "https://uxdhbpahpdsf.example.com/", but that the attacker has 1469 managed to register in the DNS and point at an HTTP server under the 1470 attacker's control, then: 1472 1. The UA is unlikely to already have an HSTS Policy established for 1473 "uxdhbpahpdsf.example.com", and, 1475 2. The HTTP request sent to uxdhbpahpdsf.example.com will include 1476 the Secure-flagged domain cookie. 1478 3. If "uxdhbpahpdsf.example.com" returns a certificate during TLS 1479 establishment, and the user clicks through any warning that might 1480 be presented (it is possible, but not certain, that one may 1481 obtain a requisite certificate for such a domain name such that a 1482 warning may or may not appear), then the attacker can obtain the 1483 Secure-flagged domain cookie that's ostensibly being protected. 1485 Without the "includeSubDomains" directive, HSTS is unable to protect 1486 such Secure-flagged domain cookies. 1488 14.4. Denial of Service 1490 HSTS could be used to mount certain forms of Denial-of- Service (DoS) 1491 attacks against web sites. A DoS attack is an attack in which one or 1492 more network entities target a victim entity and attempt to prevent 1493 the victim from doing useful work. This section discusses such 1494 scenarios in terms of HSTS, though this list is not exhaustive. See 1495 also [RFC4732] for a discussion of overall Internet DoS 1496 considerations. 1498 o Web applications available over HTTP 1500 There is an opportunity for perpetrating DoS attacks with web 1501 applications that are -- or critical portions of them are -- 1502 available only over HTTP without secure transport, if attackers 1503 can cause UAs to set HSTS Policy for such web applications' 1504 host(s). 1506 This is because once the HSTS Policy is set for a web 1507 application's host in a UA, the UA will only use secure transport 1508 to communicate with the host. If the host is not using secure 1509 transport, or is not for critical portions of its web application, 1510 then the web application will be rendered unusable for the UA's 1511 user. 1513 An HSTS Policy can be set for a victim host in various ways: 1515 * If the web application has a HTTP response splitting 1516 vulnerability [CWE-113] (which can be abused in order to 1517 facilitate "HTTP Header Injection"). 1519 * If an attacker can spoof a redirect from an insecure victim 1520 site, e.g., to , 1521 where the latter is attacker-controlled and has an apparently 1522 valid certificate, then the attacker can set an HSTS Policy for 1523 example.com, and also for all subdomains of example.com. 1525 * If an attacker can convince users to manually configure HSTS 1526 Policy for a victim host. This assumes their UAs offer such a 1527 capability (see Section 12 "User Agent Implementation Advice"). 1528 Or, if such UA configuration is scriptable, then an attacker 1529 can cause UAs to execute his script and set HSTS Policies for 1530 whichever desired domains. 1532 o Inadvertent use of includeSubDomains 1534 The includeSubDomains directive instructs UAs to automatically 1535 regard all subdomains of the given HSTS Host as Known HSTS Hosts. 1536 If any such subdomains do not support properly configured secure 1537 transport, then they will be rendered unreachable from such UAs. 1539 14.5. Bootstrap MITM Vulnerability 1541 The bootstrap MITM (Man-In-The-Middle) vulnerability is a 1542 vulnerability users and HSTS Hosts encounter in the situation where 1543 the user manually enters, or follows a link, to an unknown HSTS Host 1544 using a "http" URI rather than a "https" URI. Because the UA uses an 1545 insecure channel in the initial attempt to interact with the 1546 specified server, such an initial interaction is vulnerable to 1547 various attacks (see Section 5.3 of [ForceHTTPS]). 1549 NOTE: There are various features/facilities that UA implementations 1550 may employ in order to mitigate this vulnerability. Please 1551 see Section 12 "User Agent Implementation Advice". 1553 14.6. Network Time Attacks 1555 Active network attacks can subvert network time protocols (such as 1556 Network Time Protocol (NTP) [RFC5905]) - making HSTS less effective 1557 against clients that trust NTP or lack a real time clock. Network 1558 time attacks are beyond the scope of this specification. Note that 1559 modern operating systems use NTP by default. See also Section 2.10 1560 of [RFC4732]. 1562 14.7. Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack 1564 An attacker could conceivably obtain a victim HSTS-protected web 1565 application's users' login credentials via a bogus root CA 1566 certificate phish plus DNS cache poisoning attack. 1568 For example, the attacker could first convince users of a victim web 1569 application (which is protected by HSTS Policy) to install the 1570 attacker's version of a root CA certificate purporting (falsely) to 1571 represent the CA of the victim web application. This might be 1572 accomplished by sending the users a phishing email message with a 1573 link to such a certificate, which their browsers may offer to install 1574 if clicked on. 1576 Then, if the attacker can perform an attack on the users' DNS 1577 servers, (e.g., via cache poisoning) and turn on HSTS Policy for 1578 their fake web application, the affected users' browsers would access 1579 the attackers' web application rather than the legitimate web 1580 application. 1582 This type of attack leverages vectors that are outside of the scope 1583 of HSTS. However, the feasibility such threats can be mitigated by 1584 including in a web application's overall deployment approach 1585 appropriate employment, in addition to HSTS, of security facilities 1586 such as DNS Security Extensions [RFC4033], plus techniques to block 1587 email phishing and fake certificate injection. 1589 14.8. Creative Manipulation of HSTS Policy Store 1591 Since an HSTS Host may select its own host name and subdomains 1592 thereof, and this information is cached in the HSTS Policy store of 1593 conforming UAs, it is possible for those who control an HSTS Host(s) 1594 to encode information into domain names they control and cause such 1595 UAs to cache this information as a matter of course in the process of 1596 noting the HSTS Host. This information can be retrieved by other 1597 hosts through clever loaded page construction causing the UA to send 1598 queries to (variations of) the encoded domain names. Such queries 1599 can reveal whether the UA had prior visited the original HSTS Host 1600 (and subdomains). 1602 Such a technique could potentially be abused as yet another form of 1603 "web tracking" [WebTracking]. 1605 14.9. Internationalized Domain Names 1607 Internet security relies in part on the DNS and the domain names it 1608 hosts. Domain names are used by users to identify and connect to 1609 Internet hosts and other network resources. For example, Internet 1610 security is compromised if a user entering an internationalized 1611 domain name (IDN) is connected to different hosts based on different 1612 interpretations of the IDN. 1614 The processing models specified in this specification assume that the 1615 domain names they manipulate are IDNA-canonicalized, and that the 1616 canonicalization process correctly performed all appropriate IDNA and 1617 Unicode validations and character list testing per the requisite 1618 specifications (e.g., as noted in Section 10 "Domain Name IDNA- 1619 Canonicalization"). These steps are necessary in order to avoid 1620 various potentially compromising situations. 1622 In brief, some examples of issues that could stem from lack of 1623 careful and consistent Unicode and IDNA validations are things such 1624 as unexpected processing exceptions, truncation errors, and buffer 1625 overflows, as well as false-positive and/or false-negative domain 1626 name matching results. Any of the foregoing issues could possibly be 1627 leveraged by attackers in various ways. 1629 Additionally, IDNA2008 [RFC5890] differs from IDNA2003 [RFC3490] in 1630 terms of disallowed characters and character mapping conventions. 1631 This situation can also lead to false-positive and/or false-negative 1632 domain name matching results, resulting in, for example, users 1633 possibly communicating with unintended hosts, or not being able to 1634 reach intended hosts. 1636 For details, refer to the Security Considerations sections of 1637 [RFC5890], [RFC5891], and [RFC3490], as well as the specifications 1638 they normatively reference. Additionally, [RFC5894] provides 1639 detailed background and rationale for IDNA2008 in particular, as well 1640 as IDNA and its issues in general, and should be consulted in 1641 conjunction with the former specifications. 1643 15. IANA Considerations 1645 Below is the Internet Assigned Numbers Authority (IANA) Permanent 1646 Message Header Field registration information per [RFC3864]. 1648 Header field name: Strict-Transport-Security 1649 Applicable protocol: HTTP 1650 Status: standard 1651 Author/Change controller: IETF 1652 Specification document(s): this one 1654 16. References 1656 16.1. Normative References 1658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1659 Requirement Levels", BCP 14, RFC 2119, March 1997. 1661 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1662 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1663 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1665 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1667 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1668 "Internationalizing Domain Names in Applications (IDNA)", 1669 RFC 3490, March 2003. 1671 This specification is referenced due to its ongoing 1672 relevance to actual deployments for the foreseeable 1673 future. 1675 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1676 for Internationalized Domain Names in Applications 1677 (IDNA)", RFC 3492, March 2003. 1679 This specification is referenced due to its ongoing 1680 relevance to actual deployments for the foreseeable 1681 future. 1683 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1684 Procedures for Message Header Fields", BCP 90, RFC 3864, 1685 September 2004. 1687 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1688 Resource Identifier (URI): Generic Syntax", STD 66, 1689 RFC 3986, January 2005. 1691 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1692 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1694 [RFC5890] Klensin, J., "Internationalized Domain Names for 1695 Applications (IDNA): Definitions and Document Framework", 1696 RFC 5890, August 2010. 1698 [RFC5891] Klensin, J., "Internationalized Domain Names in 1699 Applications (IDNA): Protocol", RFC 5891, August 2010. 1701 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 1702 Internationalized Domain Names in Applications (IDNA) 1703 2008", RFC 5895, September 2010. 1705 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1706 of Named Entities (DANE) Transport Layer Security (TLS) 1707 Protocol: TLSA", RFC 6698, August 2012. 1709 [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility 1710 Processing", Unicode Technical Standards # 46, 1711 . 1713 [Unicode] The Unicode Consortium, "The Unicode Standard", 1714 . 1716 [W3C.REC-html401-19991224] 1717 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 1718 Specification", World Wide Web Consortium 1719 Recommendation REC-html401-19991224, December 1999, 1720 . 1722 16.2. Informative References 1724 [Aircrack-ng] 1725 d'Otreppe, T., "Aircrack-ng", Accessed: 11-Jul-2010, 1726 . 1728 [BeckTews09] 1729 Beck, M. and E. Tews, "Practical Attacks Against WEP and 1730 WPA", Second ACM Conference on Wireless Network 1731 Security Zurich, Switzerland, 2009, . 1735 [CWE-113] "CWE-113: Improper Neutralization of CRLF Sequences in 1736 HTTP Headers ('HTTP Response Splitting')", Common Weakness 1737 Enumeration , The Mitre 1738 Corporation , 1739 . 1741 [Firesheep] 1742 Various, "Firesheep", Wikipedia Online, on-going, 1743 . 1746 [ForceHTTPS] 1747 Jackson, C. and A. Barth, "ForceHTTPS: Protecting High- 1748 Security Web Sites from Network Attacks", In Proceedings 1749 of the 17th International World Wide Web Conference 1750 (WWW2008) , 2008, 1751 . 1753 [GoodDhamijaEtAl05] 1754 Good, N., Dhamija, R., Grossklags, J., Thaw, D., 1755 Aronowitz, S., Mulligan, D., and J. Konstan, "Stopping 1756 Spyware at the Gate: A User Study of Privacy, Notice and 1757 Spyware", In Proceedings of Symposium On Usable Privacy 1758 and Security (SOUPS) Pittsburgh, PA, USA, July 2005, . 1762 [JacksonBarth2008] 1763 Jackson, C. and A. Barth, "Beware of Finer-Grained 1764 Origins", Web 2.0 Security and Privacy Oakland, CA, USA, 1765 2008, 1766 . 1769 [RFC1035] Mockapetris, P., "Domain names - implementation and 1770 specification", STD 13, RFC 1035, November 1987. 1772 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1773 Adams, "X.509 Internet Public Key Infrastructure Online 1774 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1776 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1777 Rose, "DNS Security Introduction and Requirements", 1778 RFC 4033, March 2005. 1780 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 1781 Service Considerations", RFC 4732, December 2006. 1783 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1784 RFC 4949, August 2007. 1786 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1787 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1788 May 2008. 1790 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1791 Housley, R., and W. Polk, "Internet X.509 Public Key 1792 Infrastructure Certificate and Certificate Revocation List 1793 (CRL) Profile", RFC 5280, May 2008. 1795 [RFC5894] Klensin, J., "Internationalized Domain Names for 1796 Applications (IDNA): Background, Explanation, and 1797 Rationale", RFC 5894, August 2010. 1799 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1800 Time Protocol Version 4: Protocol and Algorithms 1801 Specification", RFC 5905, June 2010. 1803 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1804 Extension Definitions", RFC 6066, January 2011. 1806 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 1807 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 1808 August 2011. 1810 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1811 April 2011. 1813 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1814 December 2011. 1816 [SunshineEgelmanEtAl09] 1817 Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and 1818 L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning 1819 Effectiveness", In Proceedings of 18th USENIX Security 1820 Symposium Montreal, Canada, Augus 2009, . 1824 [W3C.REC-wsc-ui-20100812] 1825 Saldhana, A. and T. Roessler, "Web Security Context: User 1826 Interface Guidelines", World Wide Web Consortium 1827 Recommendation REC-wsc-ui-20100812, August 2010, 1828 . 1830 [WebTracking] 1831 Schmucker, N., "Web Tracking", SNET2 Seminar Paper Summer 1832 Term, 2011, . 1835 [owaspTLSGuide] 1836 Coates, M., Wichers, d., Boberski, M., and T. Reguly, 1837 "Transport Layer Protection Cheat Sheet", Accessed: 11- 1838 Jul-2010, . 1841 Appendix A. Design Decision Notes 1843 This appendix documents various design decisions. 1845 1. Cookies aren't appropriate for HSTS Policy expression as they are 1846 potentially mutable (while stored in the UA), therefore an HTTP 1847 header field is employed. 1849 2. We chose to not attempt to specify how "mixed security context 1850 loads" (AMA "mixed content loads") are handled due to UA 1851 implementation considerations as well as classification 1852 difficulties. 1854 3. An HSTS Host may update UA notions of HSTS Policy via new HSTS 1855 header field parameter values. We chose to have UAs honor the 1856 "freshest" information received from a server because there is 1857 the chance of a web site sending out an erroneous HSTS Policy, 1858 such as a multi-year max-age value, and/or an incorrect 1859 includeSubDomains flag. If the HSTS Host couldn't correct such 1860 errors over protocol, it would require some form of annunciation 1861 to users and manual intervention on the users' part, which could 1862 be a non-trivial problem for both web application providers and 1863 their users. 1865 4. HSTS Hosts are identified only via domain names -- explicit IP 1866 address identification of all forms is excluded. This is for 1867 simplification and also is in recognition of various issues with 1868 using direct IP address identification in concert with PKI-based 1869 security. 1871 5. The max-age approach of having the HSTS Host provide a simple 1872 integer number of seconds for a cached HSTS Policy time-to-live 1873 value, as opposed to an approach of stating an expiration time in 1874 the future was chosen for various reasons. Amongst the reasons 1875 are no need for clock synchronization, no need to define date and 1876 time value syntaxes (specification simplicity), and 1877 implementation simplicity. 1879 Appendix B. Differences between HSTS Policy and Same-Origin Policy 1881 HSTS Policy has the following primary characteristics: 1883 HSTS Policy stipulates requirements for the security 1884 characteristics of UA-to-host connection establishment, on a per- 1885 host basis. 1887 Hosts explicitly declare HSTS Policy to UAs. Conformant UAs are 1888 obliged to implement hosts' declared HSTS Policies. 1890 HSTS Policy is conveyed over protocol from the host to the UA. 1892 The UA maintains a cache of Known HSTS Hosts. 1894 UAs apply HSTS Policy whenever making a HTTP connection to a Known 1895 HSTS Host, regardless of host port number. I.e., it applies to 1896 all ports on a Known HSTS Host. Hosts are unable to affect this 1897 aspect of HSTS Policy. 1899 Hosts may optionally declare that their HSTS Policy applies to all 1900 subdomains of their host domain name. 1902 In contrast, the Same-Origin Policy (SOP) [RFC6454] has the following 1903 primary characteristics: 1905 An origin is the scheme, host, and port of a URI identifying a 1906 resource. 1908 A UA may dereference a URI, thus loading a representation of the 1909 resource the URI identifies. UAs label resource representations 1910 with their origins, which are derived from their URIs. 1912 The SOP refers to a collection of principles, implemented within 1913 UAs, governing the isolation of and communication between resource 1914 representations within the UA, as well as resource 1915 representations' access to network resources. 1917 In summary, although both HSTS Policy and SOP are enforced by UAs, 1918 HSTS Policy is optionally declared by hosts and is not origin-based, 1919 while the SOP applies to all resource representations loaded from all 1920 hosts by conformant UAs. 1922 Appendix C. Acknowledgments 1924 The authors thank Devdatta Akhawe, Michael Barrett, Ben Campbell, 1925 Tobias Gondrom, Paul Hoffman, Murray Kucherawy, Barry Leiba, James 1926 Manger, Alexey Melnikov, Haevard Molland, Yoav Nir, Yngve N. 1927 Pettersen, Laksh Raghavan, Marsh Ray, Julian Reschke, Tom Ritter, 1928 Peter Saint-Andre, Brian Smith, Maciej Stachowiak, Sid Stamm, Andy 1929 Steingrubl, Brandon Sterne, Martin Thomson, Daniel Veditz, Jan 1930 Wrobel, as well as all the websec working group participants and 1931 others for their various reviews and helpful contributions. 1933 Thanks to Julian Reschke for his elegant re-writing of the effective 1934 request URI text, which he did when incorporating the ERU notion into 1935 the HTTPbis work. Subsequently, the ERU text in this spec was lifted 1936 from Julian's work in the updated HTTP/1.1 (part 1) specification and 1937 adapted to the [RFC2616] ABNF. 1939 Appendix D. Change Log 1941 [RFCEditor: please remove this section upon publication as an RFC.] 1943 Changes are grouped by spec revision listed in reverse issuance 1944 order. 1946 D.1. For draft-ietf-websec-strict-transport-sec 1948 Changes from -12 to -13: 1950 1. Addressed the IANA registry and IANA registry policy questions 1951 raised in Ben Campbel's Gen-ART LC review. Selected "IETF 1952 Review" for IANA policy. See the portion of this thread from 1953 this message onwards for details: 1956 2. Clarified the questions regarding max-age=0 interacting with 1957 includeSubdomains. Expanded section 5. HSTS Mechanism 1958 Overview, Added clarification text and forward ref to S 8.1 1959 from S 6.1.1. Added two additional examples to S 6.2 which 1960 contain max-age=0. See the thread rooted here for questions 1961 that informed this: 1964 3. upgraded ref to draft-ietf-dane-protocol to be to RFC6698. 1966 Changes from -11 to -12: 1968 1. Addressed various issues in Ben Campbel's Gen-ART LC review. 1969 See this message for details: 1972 Changes from -10 to -11: 1974 1. Various minor editorial fixes based on Barry Leiba's AD 1975 review, as well as ID-Nits warnings. 1977 2. Clarification addition of directive-name and directive-value 1978 to Strict-Transport-Security ABNF in Section 6.1, from Barry's 1979 AD review. 1982 3. Moved ref to RFC5894 to Informational since it is a truly 1983 informational reference. 1985 Changes from -09 to -10: 1987 1. Added "(including when following HTTP redirects [RFC2616])" to 1988 section 8.3. This addresses issue ticket #47. 1989 1991 2. Fixed max-age value in section 10.1. Substituted 7776000 1992 (actually 90 days) for 778000 (only 9 days). This addresses 1993 issue ticket #48. 1994 1996 3. Added mention of "Certificate Status Request" TLS extension 1997 [RFC6066] aka "OCSP stapling" to example in section 10.3. 1998 This addresses issue ticket #49. 1999 2001 Changes from -08 to -09: 2003 1. Added IESG Note to Section 3 "Conformance Criteria" per Barry 2004 Leiba's suggestion on the mailing list. 2007 2. Added additional requirement #5 to requirements for STS header 2008 field directives in Section 6.1 per Alexey's review. This 2009 completes the addressing of issue ticket #45. 2010 2012 3. Addressed editorial feedback in Murray's AppsDir review of 2013 -06. 2015 Most all of these changes were addressing detailed/small 2016 editorial items, however note the addition of a couple of 2017 introductory paragraphs in the Security Considerations 2018 section, as well as a re-written and expanded Section 14.6 2019 "Bogus Root CA Certificate Phish plus DNS Cache Poisoning 2020 Attack", as well the new item #5 to Appendix A "Design 2021 Decision Notes". 2023 This addresses issue ticket #46. 2024 2026 Changes from -07 to -08: 2028 1. Clarified requirement #4 for STS header field directives in 2029 Section 6.1, and removed "(which "update" this 2030 specification)". Also added explicit "max-age=0" to Section 2031 6.1.1. Reworked final sentence in 2nd para of Section 13. 2032 This addresses issue ticket #45. 2033 2035 Changes from -06 to -07: 2037 1. Various minor/modest editorial tweaks throughout as I went 2038 through it pursuing the below issue tickets. Viewing a visual 2039 diff against -06 revision recommended. 2041 2. fixed some minor editorial issues noted in review by Alexey, 2042 fixes noted in here: 2045 3. Addressed ABNF exposition issues, specifically inclusion of 2046 quoted-string syntax for directive values. Fix STS header 2047 ABNF such that a leading ";" isn't required. Add example of 2048 quoted-string-encoded max-age-value. This addresses (re- 2049 opened) issue ticket #33. 2050 2052 4. Reworked sections 8.1 through 8.3 to ensure matching algorithm 2053 and resultant HSTS Policy application is more clear, and that 2054 it is explicitly stipulated to not muck with attributes of 2055 superdomain matching Known HSTS Hosts. This addresses issue 2056 ticket #37. 2057 2059 5. Added reference to draft-ietf-dane-protocol, pared back 2060 extraneous discussion in section 2.2, and updated discussion 2061 in 10.2 to accomodate TLSA (nee DANE). This addresses issue 2062 ticket #39. 2063 2065 6. Addressed various editorial items from issue ticket #40. 2066 2068 7. Loosened up the language regarding redirecting "http" requests 2069 to "https" in section 7.2 such that future flavors of 2070 permanent redirects are accommodated. This addresses issue 2071 ticket #43. 2072 2074 8. Reworked the terminology and language in Section 9, in 2075 particular defining the term "putative domain name string" to 2076 replace "valid Unicode-encoded string-serialized domain name". 2077 This addresses issue ticket #44. 2078 2080 Changes from -05 to -06: 2082 1. Addressed various editorial comments provided by Tobias G. 2083 This addresses issue ticket #38. 2084 2086 Changes from -04 to -05: 2088 1. Fixed up references to move certain ones back to the normative 2089 section -- as requested by Alexey M. Added explanation for 2090 referencing obsoleted [RFC3490] and [RFC3492]. This addresses 2091 issue ticket #36. 2092 2094 2. Made minor change to Strict-Transport-Security header field 2095 ABNF in order to address further feedback as appended to 2096 ticket #33. This addresses issue ticket #33. 2097 2099 Changes from -03 to -04: 2101 1. Clarified that max-age=0 will cause UA to forget a known HSTS 2102 Host, and more generally clarified that the "freshest" info 2103 from the HSTS Host is cached, and thus HSTS Hosts are able to 2104 alter the cached max-age in UAs. This addresses issue ticket 2105 #13. 2107 2. Updated section on "Constructing an Effective Request URI" to 2108 remove remaining reference to RFC3986 and reference RFC2616 2109 instead. Further addresses issue ticket #14. 2110 2112 3. Addresses further ABNF issues noted in comment:1 of issue 2113 ticket #27. 2116 4. Reworked the introduction to clarify the denotation of "HSTS 2117 Policy" and added the new Appendix B summarizing the primary 2118 characteristics of HSTS Policy and Same-Origin Policy, and 2119 identifying their differences. Added ref to [RFC4732]. This 2120 addresses issue ticket #28. 2121 2123 5. Reworked language in Section 2.3.1.3. wrt "mixed content", 2124 more clearly explain such vulnerability, disambiguate "mixed 2125 content" in web security context from its usage in markup 2126 language context. This addresses issue ticket #29. 2127 2129 6. Expanded Denial of Service discussion in Security 2130 Considerations. Added refs to [RFC4732] and [CWE-113]. This 2131 addresses issue ticket #30. 2132 2134 7. Mentioned in prose the case-insensitivity of directive names. 2135 This addresses issue ticket #31. 2136 2138 8. Added Section 11.4 "Implications of includeSubDomains". This 2139 addresses issue ticket #32. 2140 2142 9. Further refines text and ABNF definitions of STS header field 2143 directives. Retains use of quoted-string in directive 2144 grammar. This addresses issue ticket #33. 2145 2147 10. Added Section 14.8 "Creative Manipulation of HSTS Policy 2148 Store", including reference to [WebTracking]. This addresses 2149 issue ticket #34. 2150 2152 11. Added Section 14.2 "Ramifications of HSTS Policy 2153 Establishment only over Error-free Secure Transport" and made 2154 some accompanying editorial fixes in some other sections. 2155 This addresses issue ticket #35. 2156 2158 12. Refined references. Cleaned out un-used ones, updated to 2159 latest RFCs for others, consigned many to Informational. 2160 This addresses issue ticket #36. 2161 2163 13. Fixed-up some inaccuracies in the "Changes from -02 to -03" 2164 section. 2166 Changes from -02 to -03: 2168 1. Updated section on "Constructing an Effective Request URI" to 2169 remove references to RFC3986. Addresses issue ticket #14. 2170 2172 2. Reference RFC5890 for IDNA, retaining subordinate refs to 2173 RFC3490. Updated IDNA-specific language, e.g. domain name 2174 canonicalization and IDNA dependencies. Addresses issue 2175 ticket #26 2176 . 2178 3. Completely re-wrote the STS header ABNF to be fully based on 2179 RFC2616, rather than a hybrid of RFC2616 and httpbis. 2180 Addresses issue ticket #27 2181 . 2183 Changes from -01 to -02: 2185 1. Updated Section 8.3 "URI Loading and Port Mapping" fairly 2186 thoroughly in terms of refining the presentation of the 2187 steps, and to ensure the various aspects of port mapping are 2188 clear. Nominally fixes issue ticket #1 2189 2191 2. Removed dependencies on 2192 [I-D.draft-ietf-httpbis-p1-messaging-15]. Thus updated STS 2193 ABNF in Section 6.1 "Strict-Transport-Security HTTP Response 2194 Header Field" by lifting some productions entirely from 2195 [I-D.draft-ietf-httpbis-p1-messaging-15] and leveraging 2196 [RFC2616]. Addresses issue ticket #2 2197 . 2199 3. Updated Effective Request URI section and definition to use 2200 language from [I-D.draft-ietf-httpbis-p1-messaging-15] and 2201 ABNF from [RFC2616]. Fixes issue ticket #3 2202 . 2204 4. Added explicit mention that the HSTS Policy applies to all 2205 TCP ports of a host advertising the HSTS Policy. Nominally 2206 fixes issue ticket #4 2207 2209 5. Clarified the need for the "includeSubDomains" directive, 2210 e.g. to protect Secure-flagged domain cookies. In 2211 Section 14.3 "The Need for includeSubDomains". Nominally 2212 fixes issue ticket #5 2213 2215 6. Cited Firesheep as real-live threat in Section 2.3.1.1 2216 "Passive Network Attackers". Nominally fixes issue ticket #6 2217 . 2219 7. Added text to Section 12 "User Agent Implementation Advice" 2220 justifying connection termination due to tls warnings/errors. 2221 Nominally fixes issue ticket #7 2222 . 2224 8. Added new subsection Section 8.6 "Missing Strict-Transport- 2225 Security Response Header Field". Nominally fixes issue 2226 ticket #8 2227 . 2229 9. Added text to Section 8.4 "Errors in Secure Transport 2230 Establishment" explicitly note revocation check failures as 2231 errors causing connection termination. Added references to 2232 [RFC5280] and [RFC2560]. Nominally fixes issue ticket #9 2233 . 2235 10. Added a sentence, noting that distributing specific end- 2236 entity certificates to browsers will also work for self- 2237 signed/private-CA cases, to Section 11 "Server Implementation 2238 and Deployment Advice" Nominally fixes issue ticket #10 2239 . 2241 11. Moved "with no user recourse" language from Section 8.4 2242 "Errors in Secure Transport Establishment" to Section 12 2243 "User Agent Implementation Advice". This nominally fixes 2244 issue ticket #11 2245 . 2247 12. Removed any and all dependencies on 2248 [I-D.draft-ietf-httpbis-p1-messaging-15], instead depending 2249 on [RFC2616] only. Fixes issue ticket #12 2250 . 2252 13. Removed the inline "XXX1" issue because no one had commented 2253 on it and it seems reasonable to suggest as a SHOULD that web 2254 apps should redirect incoming insecure connections to secure 2255 connections. 2257 14. Removed the inline "XXX2" issue because it was simply for 2258 raising consciousness about having some means for 2259 distributing secure web application metadata. 2261 15. Removed "TODO1" because description prose for "max-age" in 2262 the Note following the ABNF in Section 6 seems to be fine. 2264 16. Decided for "TODO2" that "the first STS header field wins". 2265 TODO2 had read: "Decide UA behavior in face of encountering 2266 multiple HSTS headers in a message. Use first header? 2267 Last?". Removed TODO2. 2269 17. Added Section 1.1 "Organization of this specification" for 2270 readers' convenience. 2272 18. Moved design decision notes to be a proper appendix 2273 Appendix A. 2275 Changes from -00 to -01: 2277 1. Changed the "URI Loading" section to be "URI Loading and Port 2278 Mapping". 2280 2. (HASMAT) reference changed to (WEBSEC). 2282 3. Changed "server" -> "host" where applicable, notably when 2283 discussing "HSTS Hosts". Left as "server" when discussing 2284 e.g. "http server"s. 2286 4. Fixed minor editorial nits. 2288 Changes from draft-hodges-strict-transport-sec-02 to 2289 draft-ietf-websec-strict-transport-sec-00: 2291 1. Altered spec metadata (e.g. filename, date) in order to submit 2292 as a WebSec working group Internet-Draft. 2294 D.2. For draft-hodges-strict-transport-sec 2296 Changes from -01 to -02: 2298 1. updated abstract such that means for expressing HSTS Policy 2299 other than via HSTS header field is noted. 2301 2. Changed spec title to "HTTP Strict Transport Security (HSTS)" 2302 from "Strict Transport Security". Updated use of "STS" 2303 acronym throughout spec to HSTS (except for when specifically 2304 discussing syntax of Strict-Transport-Security HTTP Response 2305 Header field), updated "Terminology" appropriately. 2307 3. Updated the discussion of "Passive Network Attackers" to be 2308 more precise and offered references. 2310 4. Removed para on nomative/non-normative from "Conformance 2311 Criteria" pending polishing said section to IETF RFC norms. 2313 5. Added examples subsection to "Syntax" section. 2315 6. Added OWS to maxAge production in Strict-Transport-Security 2316 ABNF. 2318 7. Cleaned up explanation in the "Note:" in the "HTTP-over- 2319 Secure-Transport Request Type" section, folded 3d para into 2320 "Note:", added conformance clauses to the latter. 2322 8. Added exaplanatory "Note:" and reference to "HTTP Request 2323 Type" section. Added "XXX1" issue. 2325 9. Added conformance clause to "URI Loading". 2327 10. Moved "Notes for STS Server implementers:" from "UA 2328 Implementation dvice " to "HSTS Policy expiration time 2329 considerations:" in "Server Implementation Advice", and also 2330 noted another option. 2332 11. Added cautionary "Note:" to "Ability to delete UA's cached 2333 HSTS Policy on a per HSTS Server basis". 2335 12. Added some informative references. 2337 13. Various minor editorial fixes. 2339 Changes from -00 to -01: 2341 1. Added reference to HASMAT mailing list and request that this 2342 spec be discussed there. 2344 Authors' Addresses 2346 Jeff Hodges 2347 PayPal 2348 2211 North First Street 2349 San Jose, California 95131 2350 US 2352 Email: Jeff.Hodges@PayPal.com 2354 Collin Jackson 2355 Carnegie Mellon University 2357 Email: collin.jackson@sv.cmu.edu 2358 Adam Barth 2359 Google, Inc. 2361 Email: ietf@adambarth.com 2362 URI: http://www.adambarth.com/