idnits 2.17.1 draft-ietf-websec-strict-transport-sec-04.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 == Line 523 has weird spacing: '...TS Host is a...' -- The document date (January 28, 2012) is 4471 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-17' is mentioned on line 1707, but not defined == Missing Reference: 'I-D.draft-ietf-httpbis-p1-messaging-15' is mentioned on line 1868, but not defined == Missing Reference: 'HASMAT' is mentioned on line 1900, but not defined == Unused Reference: 'RFC3454' is defined on line 1529, but no explicit reference was found in the text == Unused Reference: 'RFC3492' is defined on line 1539, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 3454 (Obsoleted by RFC 7564) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hodges 3 Internet-Draft PayPal 4 Intended status: Standards Track C. Jackson 5 Expires: July 31, 2012 Carnegie Mellon University 6 A. Barth 7 Google, Inc. 8 January 28, 2012 10 HTTP Strict Transport Security (HSTS) 11 draft-ietf-websec-strict-transport-sec-04 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 July 31, 2012. 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 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. HTTP Strict Transport Security Policy Effects . . . . . . 6 62 2.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.3.1. Threats Addressed . . . . . . . . . . . . . . . . . . 6 64 2.3.1.1. Passive Network Attackers . . . . . . . . . . . . 6 65 2.3.1.2. Active Network Attackers . . . . . . . . . . . . . 7 66 2.3.1.3. Web Site Development and Deployment Bugs . . . . . 7 67 2.3.2. Threats Not Addressed . . . . . . . . . . . . . . . . 8 68 2.3.2.1. Phishing . . . . . . . . . . . . . . . . . . . . . 8 69 2.3.2.2. Malware and Browser Vulnerabilities . . . . . . . 8 70 2.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 71 2.4.1. Overall Requirement . . . . . . . . . . . . . . . . . 8 72 2.4.1.1. Detailed Core Requirements . . . . . . . . . . . . 8 73 2.4.1.2. Detailed Ancillary Requirements . . . . . . . . . 9 74 3. Conformance Criteria . . . . . . . . . . . . . . . . . . . . . 10 75 3.1. Document Conventions . . . . . . . . . . . . . . . . . . . 10 76 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5. HSTS Mechanism Overview . . . . . . . . . . . . . . . . . . . 12 78 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 6.1. Strict-Transport-Security HTTP Response Header Field . . . 13 80 6.1.1. The max-age Directive . . . . . . . . . . . . . . . . 14 81 6.1.2. The includeSubDomains Directive . . . . . . . . . . . 14 82 6.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 7. Server Processing Model . . . . . . . . . . . . . . . . . . . 15 84 7.1. HTTP-over-Secure-Transport Request Type . . . . . . . . . 15 85 7.2. HTTP Request Type . . . . . . . . . . . . . . . . . . . . 15 86 8. User Agent Processing Model . . . . . . . . . . . . . . . . . 16 87 8.1. Strict-Transport-Security Response Header Field 88 Processing . . . . . . . . . . . . . . . . . . . . . . . . 16 89 8.1.1. Noting a HSTS Host . . . . . . . . . . . . . . . . . . 17 90 8.1.2. Known HSTS Host Domain Name Matching . . . . . . . . . 18 91 8.2. URI Loading and Port Mapping . . . . . . . . . . . . . . . 19 92 8.3. Errors in Secure Transport Establishment . . . . . . . . . 19 93 8.4. HTTP-Equiv Element Attribute . . . . . . . . . . . 19 94 8.5. Interstitially Missing Strict-Transport-Security 95 Response Header Field . . . . . . . . . . . . . . . . . . 20 97 9. Domain Name IDNA-Canonicalization . . . . . . . . . . . . . . 20 98 10. Server Implementation and Deployment Advice . . . . . . . . . 20 99 10.1. HSTS Policy expiration time considerations . . . . . . . . 21 100 10.2. Using HSTS in conjunction with self-signed public-key 101 certificates . . . . . . . . . . . . . . . . . . . . . . . 21 102 10.3. Implications of includeSubDomains . . . . . . . . . . . . 22 103 11. User Agent Implementation Advice . . . . . . . . . . . . . . . 23 104 11.1. No User Recourse . . . . . . . . . . . . . . . . . . . . . 23 105 11.2. User-declared HSTS Policy . . . . . . . . . . . . . . . . 23 106 11.3. HSTS Pre-Loaded List . . . . . . . . . . . . . . . . . . . 24 107 11.4. Disallow Mixed Security Context . . . . . . . . . . . . . 24 108 11.5. HSTS Policy Deletion . . . . . . . . . . . . . . . . . . . 24 109 12. Constructing an Effective Request URI . . . . . . . . . . . . 24 110 12.1. ERU Fundamental Definitions . . . . . . . . . . . . . . . 25 111 12.2. Determining the Effective Requrest URI . . . . . . . . . . 25 112 12.2.1. Effective Requrest URI Examples . . . . . . . . . . . 26 113 13. Internationalized Domain Names for Applications (IDNA): 114 Dependency and Migration . . . . . . . . . . . . . . . . . . . 26 115 14. Security Considerations . . . . . . . . . . . . . . . . . . . 26 116 14.1. Ramifications of HSTS Policy Establishment only over 117 Error-free Secure Transport . . . . . . . . . . . . . . . 27 118 14.2. The Need for includeSubDomains . . . . . . . . . . . . . . 28 119 14.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 28 120 14.4. Bootstrap MITM Vulnerability . . . . . . . . . . . . . . . 29 121 14.5. Network Time Attacks . . . . . . . . . . . . . . . . . . . 30 122 14.6. Bogus Root CA Certificate Phish plus DNS Cache 123 Poisoning Attack . . . . . . . . . . . . . . . . . . . . . 30 124 14.7. Creative Manipulation of HSTS Policy Store . . . . . . . . 30 125 14.8. Internationalized Domain Names . . . . . . . . . . . . . . 30 126 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 127 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 128 16.1. Normative References . . . . . . . . . . . . . . . . . . . 31 129 16.2. Informative References . . . . . . . . . . . . . . . . . . 32 130 Appendix A. Design Decision Notes . . . . . . . . . . . . . . . . 35 131 Appendix B. Differences between HSTS Policy and Same-Origin 132 Policy . . . . . . . . . . . . . . . . . . . . . . . 36 133 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . . 37 134 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 37 135 D.1. For draft-ietf-websec-strict-transport-sec . . . . . . . . 37 136 D.2. For draft-hodges-strict-transport-sec . . . . . . . . . . 41 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 139 1. Introduction 141 [ Please discuss this draft on the WebSec@ietf.org mailing list 142 [WEBSEC]. ] 144 The HTTP protocol [RFC2616] may be used over various transports, 145 typically the Transmission Control Protocol (TCP) [RFC0793]. 146 However, TCP does not provide channel integrity protection, 147 confidentiality, nor secure host identification. Thus the Secure 148 Sockets Layer (SSL) protocol [I-D.ietf-tls-ssl-version3] and its 149 successor Transport Layer Security (TLS) [RFC5246], were developed in 150 order to provide channel-oriented security, and are typically layered 151 between application protocols and TCP. [RFC2818] specifies how HTTP 152 is layered onto TLS, and defines the Uniform Resource Identifier 153 (URI) scheme of "https" (in practice however, HTTP user agents (UAs) 154 typically offer their users choices among SSL2, SSL3, and TLS for 155 secure transport). 157 UAs employ various local security policies with respect to the 158 characteristics of their interactions with web resources depending on 159 (in part) whether they are communicating with a given web resource's 160 host using HTTP or HTTP-over-a-Secure-Transport. For example, 161 cookies ([RFC6265]) may be flagged as Secure. UAs are to send such 162 Secure cookies to their addressed host only over a secure transport. 163 This is in contrast to non-Secure cookies, which are returned to the 164 host regardless of transport (although modulo other rules). 166 UAs typically annunciate to their users any issues with secure 167 connection establishment, such as being unable to validate a TLS 168 server certificate trust chain, or if a TLS server certificate is 169 expired, or if a TLS host's domain name appears incorrectly in the 170 TLS server certificate (see section 3.1 of [RFC2818]). Often, UAs 171 enable users to elect to continue to interact with a web resource's 172 host in the face of such issues. This behavior is sometimes referred 173 to as "click(ing) through" security [GoodDhamijaEtAl05] 174 [SunshineEgelmanEtAl09], and thus can be described as "click-through 175 insecurity". 177 A key vulnerability enabled by click-through insecurity is the 178 leaking of any cookies the web resource may be using to manage a 179 user's session. The threat here is that an attacker could obtain the 180 cookies and then interact with the legitimate web resource while 181 impersonating the user. 183 Jackson and Barth proposed an approach, in [ForceHTTPS], to enable 184 web resources to declare that any interactions by UAs with the web 185 resource must be conducted securely, and that any issues with 186 establishing a secure transport session are to be treated as fatal 187 and without direct user recourse. The aim is to prevent click- 188 through insecurity, and address other potential threats. 190 This specification embodies and refines the approach proposed in 191 [ForceHTTPS]. For example, rather than using a cookie to convey 192 policy from a web resource's host to a UA, it defines an HTTP 193 response header field for this purpose. Additionally, a web 194 resource's host may declare its policy to apply to the entire domain 195 name subtree rooted at its host name. This enables HSTS to protect 196 so-called "domain cookies", which are applied to all subdomains of a 197 given web resource's host name. 199 This specification also incorporates notions from [JacksonBarth2008] 200 in that policy is applied on an "entire-host" basis: it applies to 201 all TCP ports of the issuing host. 203 Note that the policy defined by this specification is distinctly 204 different than the "same-origin policy" defined in "The Web Origin 205 Concept" [RFC6454]. These differences are summarized below in 206 Appendix B. 208 1.1. Organization of this specification 210 This specification begins with an overview of the use cases, policy 211 effects, threat models, and requirements for HSTS (in Section 2). 212 Then, Section 3 defines conformance requirements. The HSTS mechanism 213 itself is formally specified in Section 4 through Section 15. 215 2. Overview 217 This section discusses the use cases, summarizes the HTTP Strict 218 Transport Security (HSTS) policy, and continues with a discussion of 219 the threat model, non-addressed threats, and derived requirements. 221 2.1. Use Cases 223 The high-level use case is a combination of: 225 o Web browser user wishes to interact with various web sites (some 226 arbitrary, some known) in a secure fashion. 228 o Web site deployer wishes to offer their site in an explicitly 229 secure fashion for both their own, as well as their users', 230 benefit. 232 2.2. HTTP Strict Transport Security Policy Effects 234 The effects of the HTTP Strict Transport Security (HSTS) Policy, as 235 applied by a UA in interactions with a web resource host wielding 236 such policy (known as a HSTS Host), are summarized as follows: 238 1. All insecure ("http") connections to any TCP ports on a HSTS Host 239 are redirected by the HSTS Host to be secure connections 240 ("https"). 242 2. The UA terminates any secure transport connection attempts upon 243 any and all secure transport errors or warnings, including those 244 caused by a web application presenting self-signed certificates. 246 3. UAs transform insecure URI references to a HSTS Host into secure 247 URI references before dereferencing them. 249 2.3. Threat Model 251 HSTS is concerned with three threat classes: passive network 252 attackers, active network attackers, and imperfect web developers. 253 However, it is explicitly not a remedy for two other classes of 254 threats: phishing and malware. Addressed and not addressed threats 255 are briefly discussed below. Readers may wish refer to [ForceHTTPS] 256 for details as well as relevant citations. 258 2.3.1. Threats Addressed 260 2.3.1.1. Passive Network Attackers 262 When a user browses the web on a local wireless network (e.g., an 263 802.11-based wireless local area network) a nearby attacker can 264 possibly eavesdrop on the user's unencrypted Internet Protocol-based 265 connections, such as HTTP, regardless of whether or not the local 266 wireless network itself is secured [BeckTews09]. Freely available 267 wireless sniffing toolkits (e.g., [Aircrack-ng]) enable such passive 268 eavesdropping attacks, even if the local wireless network is 269 operating in a secure fashion. A passive network attacker using such 270 tools can steal session identifiers/cookies and hijack the user's web 271 session(s), by obtaining cookies containing authentication 272 credentials [ForceHTTPS]. For example, there exist widely-available 273 tools, such as Firesheep (a Firefox extension) [Firesheep], which 274 enable their wielder to obtain other local users' session cookies for 275 various web applications. 277 To mitigate such threats, some Web sites support, but usually do not 278 force, access using end-to-end secure transport -- e.g., signaled 279 through URIs constructed with the "https" scheme [RFC2818]. This can 280 lead users to believe that accessing such services using secure 281 transport protects them from passive network attackers. 282 Unfortunately, this is often not the case in real-world deployments 283 as session identifiers are often stored in non-Secure cookies to 284 permit interoperability with versions of the service offered over 285 insecure transport ("Secure cookies" are those cookies containing the 286 "Secure" attribute [RFC6265]). For example, if the session 287 identifier for a web site (an email service, say) is stored in a non- 288 Secure cookie, it permits an attacker to hijack the user's session if 289 the user's UA makes a single insecure HTTP request to the site. 291 2.3.1.2. Active Network Attackers 293 A determined attacker can mount an active attack, either by 294 impersonating a user's DNS server or, in a wireless network, by 295 spoofing network frames or offering a similarly-named evil twin 296 access point. If the user is behind a wireless home router, an 297 attacker can attempt to reconfigure the router using default 298 passwords and other vulnerabilities. Some sites, such as banks, rely 299 on end-to-end secure transport to protect themselves and their users 300 from such active attackers. Unfortunately, browsers allow their 301 users to easily opt-out of these protections in order to be usable 302 for sites that incorrectly deploy secure transport, for example by 303 generating and self-signing their own certificates (without also 304 distributing their CA certificate to their users' browsers). 306 2.3.1.3. Web Site Development and Deployment Bugs 308 The security of an otherwise uniformly secure site (i.e. all of its 309 content is materialized via "https" URIs), can be compromised 310 completely by an active attacker exploiting a simple mistake, such as 311 the loading of a cascading style sheet or a SWF movie over an 312 insecure connection (both cascading style sheets and SWF movies can 313 script the embedding page, to the surprise of many web developers, 314 plus some browsers do not issue so-called "mixed content warnings" 315 when SWF files are embedded via insecure connections). Even if the 316 site's developers carefully scrutinize their login page for "mixed 317 content", a single insecure embedding anywhere on the overall site 318 compromises the security of their login page because an attacker can 319 script (i.e., control) the login page by injecting script into 320 another, insecurely loaded, site page. 322 Note: "Mixed content" as used above (see also section 5.3 in 323 [W3C.REC-wsc-ui-20100812]) refers to the notion termed "mixed 324 security context" in this specification, and should not be 325 confused with the same "mixed content" term used in the 326 context of markup languages such as XML and HTML. 328 2.3.2. Threats Not Addressed 330 2.3.2.1. Phishing 332 Phishing attacks occur when an attacker solicits authentication 333 credentials from the user by hosting a fake site located on a 334 different domain than the real site, perhaps driving traffic to the 335 fake site by sending a link in an email message. Phishing attacks 336 can be very effective because users find it difficult to distinguish 337 the real site from a fake site. HSTS is not a defense against 338 phishing per se; rather, it complements many existing phishing 339 defenses by instructing the browser to protect session integrity and 340 long-lived authentication tokens [ForceHTTPS]. 342 2.3.2.2. Malware and Browser Vulnerabilities 344 Because HSTS is implemented as a browser security mechanism, it 345 relies on the trustworthiness of the user's system to protect the 346 session. Malicious code executing on the user's system can 347 compromise a browser session, regardless of whether HSTS is used. 349 2.4. Requirements 351 This section identifies and enumerates various requirements derived 352 from the use cases and the threats discussed above, and lists the 353 detailed core requirements HTTP Strict Transport Security addresses, 354 as well as ancillary requirements that are not directly addressed. 356 2.4.1. Overall Requirement 358 o Minimize the risks to web browser users and web site deployers 359 that are derived from passive and active network attackers, web 360 site development and deployment bugs, as well as insecure user 361 actions. 363 2.4.1.1. Detailed Core Requirements 365 These core requirements are derived from the overall requirement, and 366 are addressed by this specification. 368 1. Web sites need to be able to declare to UAs that they should be 369 interacted with using a strict security policy. 371 2. Web sites need to be able to instruct UAs that contact them 372 insecurely to do so securely. 374 3. UAs need to persistently remember web sites that signal strict 375 security policy enablement, for a web site declared time span. 377 Additionally, UAs need to cache the "freshest" strict security 378 policy information, in order to allow web sites to update the 379 information. 381 4. UAs need to re-write all insecure UA "http" URI loads to use the 382 "https" secure scheme for those web sites for which secure policy 383 is enabled. 385 5. Web site administrators need to be able to signal strict security 386 policy application to subdomains of higher-level domains for 387 which strict security policy is enabled, and UAs need to enforce 388 such policy. 390 For example, both example.com and foo.example.com could set 391 policy for bar.foo.example.com. 393 6. UAs need to disallow security policy application to peer domains, 394 and/or higher-level domains, by domains for which strict security 395 policy is enabled. 397 For example, neither bar.foo.example.com nor foo.example.com can 398 set policy for example.com, nor can bar.foo.example.com set 399 policy for foo.example.com. Also, foo.example.com cannot set 400 policy for sibling.example.com. 402 7. UAs need to prevent users from clicking-through security 403 warnings. Halting connection attempts in the face of secure 404 transport exceptions is acceptable. 406 Note: A means for uniformly securely meeting the first core 407 requirement above is not specifically addressed by this 408 specification (see Section 14.4 "Bootstrap MITM 409 Vulnerability"). It may be addressed by a future revision of 410 this specification or some other specification. Note also 411 that there are means by which UA implementations may more 412 fully meet the first core requirement, see Section 11 "User 413 Agent Implementation Advice". 415 2.4.1.2. Detailed Ancillary Requirements 417 These ancillary requirements are also derived from the overall 418 requirement. They are not normatively addressed in this 419 specification, but could be met by UA implementations at their 420 implementor's discretion, although meeting these requirements may be 421 complex. 423 1. Disallow "mixed security context" loads (see Section 2.3.1.3, 424 above). 426 2. Facilitate user declaration of web sites for which strict 427 security policy is enabled, regardless of whether the sites 428 signal HSTS Policy. 430 3. Conformance Criteria 432 This specification is written for hosts and user agents (UAs). 434 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 435 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 436 document are to be interpreted as described in [RFC2119]. 438 A conformant host is one that implements all the requirements listed 439 in this specification that are applicable to hosts. 441 A conformant user agent is one that implements all the requirements 442 listed in this specification that are applicable to user agents. 444 3.1. Document Conventions 446 Note: ..is a note to the reader. These are points that should be 447 expressly kept in mind and/or considered. 449 Warning: This is how a warning is shown. These are things that can 450 have suboptimal downside risks if not heeded. 452 4. Terminology 454 Terminology is defined in this section. 456 ASCII case-insensitive comparison 457 means comparing two strings exactly, codepoint for 458 codepoint, except that the characters in the range 459 U+0041 .. U+005A (i.e. LATIN CAPITAL LETTER A to 460 LATIN CAPITAL LETTER Z) and the corresponding 461 characters in the range U+0061 .. U+007A (i.e. 462 LATIN SMALL LETTER A to LATIN SMALL LETTER Z) are 463 considered to also match. See [Unicode6] for 464 details. 466 codepoint is a colloquial contraction of Code Point, which is 467 any value in the Unicode codespace; that is, the 468 range of integers from 0 to 10FFFF(hex) [Unicode6]. 470 domain name domain names, also referred to as DNS Names, are 471 defined in [RFC1035] to be represented outside of 472 the DNS protocol itself (and implementations 473 thereof) as a series of labels separated by dots, 474 e.g., "example.com" or "yet.another.example.org". 475 In the context of this specification, domain names 476 appear in that portion of a URI satisfying the reg- 477 name production in "Appendix A. Collected ABNF for 478 URI" in [RFC3986], and the host component from the 479 Host HTTP header field production in section 14.23 480 of [RFC2616]. 482 Note: The domain names appearing in actual URI 483 instances and matching the aforementioned 484 production components may or may not be a 485 fully qualified domain name. 487 domain name label is that portion of a domain name appearing "between 488 the dots", i.e. consider "foo.example.com": "foo", 489 "example", and "com" are all domain name labels. 491 Effective Request URI 492 is a URI, identifying the target resource, that can 493 be inferred by an HTTP host for any given HTTP 494 request it receives. Such inference is necessary 495 because HTTP requests often do not contain a 496 complete "absolute" URI identifying the target 497 resource. See Section 12 "Constructing an 498 Effective Request URI", below. 500 HTTP Strict Transport Security 501 is the overall name for the combined UA- and 502 server-side security policy defined by this 503 specification. 505 HTTP Strict Transport Security Host 506 is a HTTP host implementing the server aspects of 507 the HSTS policy. This means that an HSTS Host 508 returns the "Strict-Transport-Security" HTTP 509 response header field in its HTTP response messages 510 sent over secure transport. 512 HTTP Strict Transport Security Policy 513 is the name of the combined overall UA- and server- 514 side facets of the behavior specified in this 515 specification. 517 HSTS See HTTP Strict Transport Security. 519 HSTS Host See HTTP Strict Transport Security Host. 521 HSTS Policy See HTTP Strict Transport Security Policy. 523 Known HSTS Host is a HSTS Host for which the UA has a HSTS Policy 524 in effect. I.e., the UA has noted this host as a 525 Known HSTS Host. 527 Local policy is comprised of policy rules deployers specify and 528 which are often manifested as "configuration 529 settings". 531 MITM is an acronym for man-in-the-middle. See "man-in- 532 the-middle attack" in [RFC4949]. 534 Request URI is the URI used to cause a UA to issue an HTTP 535 request message. 537 UA is a an acronym for user agent. For the purposes 538 of this specification, a UA is an HTTP client 539 application typically actively manipulated by a 540 user [RFC2616] . 542 unknown HSTS Host is a HSTS Host that the user agent in question has 543 not yet noted. 545 5. HSTS Mechanism Overview 547 This section provides an overview of the mechanism by which an HSTS 548 Host conveys its HSTS Policy to UAs, and how UAs process the HSTS 549 Policies received from HSTS Hosts. The mechanism details are 550 specified in Section 6 through Section 15. 552 An HSTS Host conveys its HSTS Policy to UAs, only over secure 553 transport (e.g., TLS), via the Strict-Transport-Security HTTP 554 response header field. Receipt of this header field signals to UAs 555 to enforce the HSTS Policy for all subsequent secure transport 556 connections made to the HSTS Host, for a specified time duration. 557 Application of the HSTS Policy to subdomains of the HSTS Host name 558 may optionally be specified. 560 HSTS Hosts manage their advertised HSTS Policies by sending Strict- 561 Transport-Security HTTP response header fields to UAs with new values 562 for policy time duration and application to subdomains. UAs cache 563 the "freshest" HSTS Policy information on behalf of an HSTS Host. 564 Specifying a zero time duration signals to the UA to delete the HSTS 565 policy for that HSTS host. 567 Section 6.2 presents examples of Strict-Transport-Security HTTP 568 response header fields. 570 6. Syntax 572 This section defines the syntax of the new header this specification 573 introduces. It also provides a short description of the function the 574 header. 576 The Section 7 "Server Processing Model" section details how hosts are 577 to use this header. Likewise, the Section 8 "User Agent Processing 578 Model" section details how user agents are to use this header. 580 6.1. Strict-Transport-Security HTTP Response Header Field 582 The Strict-Transport-Security HTTP response header field (STS header 583 field) indicates to a UA that it MUST enforce the HSTS Policy in 584 regards to the host emitting the response message containing this 585 header field. 587 The ABNF syntax for the STS header field is: 589 Strict-Transport-Security = "Strict-Transport-Security" ":" 590 directive *( ";" [ directive ] ) 592 directive = token [ "=" ( token | quoted-string ) ] 594 where: 596 token = 597 quoted-string = 599 The two directives defined in this specification are described below. 600 The overall requirements for directives are: 602 o The order of appearance of directives is not significant. 604 o All directives MUST appear only once in an STS header field. 606 o Directive names are case-insensitive. 608 o UAs MUST ignore any STS header fields containing directives that 609 do not conform to their ABNF definition. 611 Additional directives extending the the semantic functionality of the 612 STS header field may be defined in other specifications (which 613 "update" this specification), using the STS directive extension 614 point. 616 6.1.1. The max-age Directive 618 The REQUIRED max-age directive specifies the number of seconds, after 619 the reception of the STS header field, during which the UA regards 620 the host, from whom the message was received, as a Known HSTS Host 621 (see also Section 8.1.1 "Noting a HSTS Host", below). The delta- 622 seconds production is specified in [RFC2616]. 624 The syntax of the max-age directive is defined as: 626 max-age = "max-age" "=" delta-seconds 628 delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2> 630 Note: A max-age value of zero signals the UA to cease regarding the 631 host as a Known HSTS Host. 633 6.1.2. The includeSubDomains Directive 635 The OPTIONAL includeSubDomains directive is a flag which, if present, 636 signals to the UA that the HSTS Policy applies to this HSTS Host as 637 well as any subdomains of the host's domain name. 639 The syntax of the includeSubDomains directive is defined as: 641 includeSubDomains = "includeSubDomains" 643 6.2. Examples 645 The below HSTS header field stipulates that the HSTS policy is to 646 remain in effect for one year (there are approximately 31 536 000 647 seconds in a year), and the policy applies only to the domain of the 648 HSTS Host issuing it: 650 Strict-Transport-Security: max-age=31536000 652 The below HSTS header field stipulates that the HSTS policy is to 653 remain in effect for approximately six months and the policy applies 654 only to the domain of the issuing HSTS Host and all of its 655 subdomains: 657 Strict-Transport-Security: max-age=15768000 ; includeSubDomains 659 7. Server Processing Model 661 This section describes the processing model that HSTS Hosts 662 implement. The model is comprised of two facets: the first being the 663 processing rules for HTTP request messages received over a secure 664 transport (e.g., TLS [RFC5246], SSL [I-D.ietf-tls-ssl-version3], or 665 perhaps others, the second being the processing rules for HTTP 666 request messages received over non-secure transports, i.e. over 667 TCP/IP [RFC0793]. 669 7.1. HTTP-over-Secure-Transport Request Type 671 When replying to an HTTP request that was conveyed over a secure 672 transport, a HSTS Host SHOULD include in its response message a STS 673 header field that MUST satisfy the grammar specified above in 674 Section 6.1 "Strict-Transport-Security HTTP Response Header Field". 675 If a STS header field is included, the HSTS Host MUST include only 676 one such header field. 678 Note: Including the STS header field is stipulated as a "SHOULD" in 679 order to accommodate various server- and network-side caches 680 and load-balancing configurations where it may be difficult to 681 uniformly emit STS header fields on behalf of a given HSTS 682 Host. 684 Establishing a given host as a Known HSTS Host, in the context 685 of a given UA, MAY be accomplished over the HTTP protocol by 686 correctly returning, per this specification, at least one 687 valid STS header field to the UA. Other mechanisms, such as a 688 client-side pre-loaded Known HSTS Host list MAY also be used. 689 E.g., see Section 11 "User Agent Implementation Advice". 691 7.2. HTTP Request Type 693 If a HSTS Host receives a HTTP request message over a non-secure 694 transport, it SHOULD send a HTTP response message containing a 695 Status-Code of 301 and a Location header field value containing 696 either the HTTP request's original Effective Request URI (see 697 Section 12 "Constructing an Effective Request URI", below) altered as 698 necessary to have a URI scheme of "https", or a URI generated 699 according to local policy (which SHOULD employ a URI scheme of 700 "https"). 702 Note: The above behavior is a "SHOULD" rather than a "MUST" because: 704 * There are risks in server-side non-secure-to-secure redirects 705 [owaspTLSGuide]. 707 * Site deployment characteristics -- e.g., a site that 708 incorporates third-party components may not behave correctly 709 when doing server-side non-secure-to-secure redirects in the 710 case of being accessed over non-secure transport, but does 711 behave correctly when accessed uniformly over secure transport. 712 The latter is the case given a HSTS-capable UA that has already 713 noted the site as a Known HSTS Host (by whatever means, e.g., 714 prior interaction or UA configuration). 716 A HSTS Host MUST NOT include the STS header field in HTTP responses 717 conveyed over non-secure transport. 719 8. User Agent Processing Model 721 This section describes the HTTP Strict Transport Security processing 722 model for UAs. There are several facets to the model, enumerated by 723 the following subsections. 725 This processing model assumes that the UA implements IDNA2008 726 [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 13 727 "Internationalized Domain Names for Applications (IDNA): Dependency 728 and Migration". It also assumes that all domain names manipulated in 729 this specification's context are already IDNA-canonicalized as 730 outlined in Section 9 "Domain Name IDNA-Canonicalization" prior to 731 the processing specified in this section. 733 The above assumptions mean that this processing model also 734 specifically assumes that appropriate IDNA and Unicode validations 735 and character list testing have occurred on the domain names, in 736 conjunction with their IDNA-canonicalization, prior to the processing 737 specified in this section. See the IDNA-specific security 738 considerations in Section 14.8 "Internationalized Domain Names" for 739 rationale and further details. 741 8.1. Strict-Transport-Security Response Header Field Processing 743 If an HTTP response, received over a secure transport, includes a STS 744 header field, conforming to the grammar specified in Section 6.1 745 "Strict-Transport-Security HTTP Response Header Field" (above), and 746 there are no underlying secure transport errors or warnings (see 747 Section 8.3, below), the UA MUST either: 749 o Note the host as a Known HSTS Host if it is not already so noted 750 (see Section 8.1.1 "Noting a HSTS Host", below), 752 or, 754 o Update its cached information for the Known HSTS Host if the max- 755 age and/or includeSubDomains header field value tokens are 756 conveying information different than that already maintained by 757 the UA. 759 Note: The max-age value is essentially a "time to live" value 760 relative to the reception time of the STS header field. 762 If the max-age header field value token has a value of zero, 763 the UA MUST remove its cached HSTS Policy information if the 764 HSTS Host is known, or, MUST NOT note this HSTS Host if it is 765 not yet known. 767 If a UA receives more than one STS header field in a HTTP 768 response message over secure transport, then the UA MUST 769 process only the first such header field. 771 Otherwise: 773 o If an HTTP response is received over insecure transport, the UA 774 MUST ignore any present STS header field(s). 776 o The UA MUST ignore any STS header fields not conforming to the 777 grammar specified in Section 6.1 "Strict-Transport-Security HTTP 778 Response Header Field" (above). 780 8.1.1. Noting a HSTS Host 782 If the substring matching the host production from the Request-URI, 783 that the host responded to, syntactically matches the IP-literal or 784 IPv4address productions from section 3.2.2 of [RFC3986], then the UA 785 MUST NOT note this host as a Known HSTS Host. 787 Otherwise, if the substring does not congruently match a presently 788 known HSTS Host, per the matching procedure specified in 789 Section 8.1.2 "Known HSTS Host Domain Name Matching" below, then the 790 UA MUST note this host as a Known HSTS Host, caching the HSTS Host's 791 domain name and noting along with it the expiry time of this 792 information, as effectively stipulated per the given max-age value, 793 as well as whether the includeSubDomains flag is asserted or not. 795 8.1.2. Known HSTS Host Domain Name Matching 797 A UA determines whether a domain name represents a Known HSTS Host by 798 looking for a match between the query Domain Name and the UA's set of 799 Known HSTS Hosts. 801 1. Compare the query domain name string with the Domain Names of the 802 UA's set of Known HSTS Hosts. For each Known HSTS Host's domain 803 name, the comparison is done with the query domain name label-by- 804 label using an ASCII case-insensitive comparison beginning with 805 the rightmost label, and continuing right-to-left, and ignoring 806 separator characters (see clause 3.1(4) of [RFC3986]. 808 * If a label-for-label match between an entire Known HSTS Host's 809 domain name and a right-hand portion of the query domain name 810 is found, then the Known HSTS Host's domain name is a 811 superdomain match for the query domain name. 813 For example: 815 Query Domain Name: bar.foo.example.com 817 Superdomain matched 818 Known HSTS Host DN: foo.example.com 820 At this point, the query domain name is ascertained to 821 effectively represent a Known HSTS Host. There may also be 822 additional matches further down the domain name label tree, up 823 to and including a congruent match. 825 * If a label-for-label match between a Known HSTS Host's domain 826 name and the query domain name is found, i.e. there are no 827 further labels to compare, then the query domain name 828 congruently matches this Known HSTS Host. 830 For example: 832 Query Domain Name: foo.example.com 834 Congruently matched 835 Known HSTS Host DN: foo.example.com 837 The query domain name is ascertained to represent a Known HSTS 838 Host. However, if there are also superdomain matches, the one 839 highest in the tree asserts the HSTS Policy for this Known 840 HSTS Host. 842 * Otherwise, if no matches are found, the query domain name does 843 not represent a Known HSTS Host. 845 8.2. URI Loading and Port Mapping 847 Whenever the UA prepares to "load", also known as "dereference", any 848 URI where the host component of the authority component of the URI 849 [RFC3986] matches that of a Known HSTS Host (either as a congruent 850 match or as a superdomain match where the superdomain Known HSTS Host 851 has includeSubDomains asserted), then before proceeding with the 852 load: 854 If the URI's scheme is "http", then the UA MUST replace the URI 855 scheme with "https", and, 857 if the URI contains an explicit port component [RFC3986] of 858 "80", then the UA MUST convert the port component to be "443", 859 or, 861 if the URI contains an explicit port component that is not 862 equal to "80", the port component value MUST be preserved, 863 otherwise, 865 if the URI does not contain an explicit port component, the UA 866 MUST NOT add one. 868 Otherwise, if the URI's scheme is "https", then the UA MUST NOT 869 modify the URI before dereferencing it. 871 Note that the implication of the above steps is that the HSTS policy 872 applies to all TCP ports on a host advertising the HSTS policy. 874 8.3. Errors in Secure Transport Establishment 876 When connecting to a Known HSTS Host, the UA MUST terminate the 877 connection (see also Section 11 "User Agent Implementation Advice", 878 below) if there are any errors (e.g., certificate errors), whether 879 "warning" or "fatal" or any other error level, with the underlying 880 secure transport. This includes any issues with certificate 881 revocation checking whether via the Certificate Revocation List (CRL) 882 [RFC5280], or via the Online Certificate Status Protocol (OCSP) 883 [RFC2560]. 885 8.4. HTTP-Equiv Element Attribute 887 UAs MUST NOT heed http-equiv="Strict-Transport-Security" attribute 888 settings on elements in received content. 890 8.5. Interstitially Missing Strict-Transport-Security Response Header 891 Field 893 If a UA receives HTTP responses from a Known HSTS Host over a secure 894 channel, but they are missing the STS header field, the UA MUST 895 continue to treat the host as a Known HSTS Host until the max-age 896 value for the knowledge that Known HSTS Host is reached. Note that 897 the max age could be infinite for a given Known HSTS Host. For 898 example, if the Known HSTS Host is part of a pre-configured list that 899 is implemented such that the list entries never "age out". 901 9. Domain Name IDNA-Canonicalization 903 An IDNA-canonicalized domain name is the string generated by the 904 following algorithm, whose input must be a valid Unicode-encoded (in 905 NFC form [Unicode6]) string-serialized domain name: 907 1. Convert the domain name to a sequence of individual domain name 908 label strings. 910 2. When implementing IDNA2008, convert each label that is not a Non- 911 Reserved LDH (NR-LDH) label, to an A-label. See Section 2.3.2 of 912 [RFC5890] for definitions of the former and latter, refer to 913 Sections 5.3 through 5.5 of [RFC5891] for the conversion 914 algorithm and requisite input validation and character list 915 testing procedures. 917 Otherwise, when implementing IDNA2003, convert each label using 918 the "ToASCII" conversion in Section 4 of [RFC3490] (see also the 919 definition of "equivalence of labels" in Section 2 of the latter 920 specification). 922 3. Concatenate the resulting labels, separating each label from the 923 next with (".") a %x2E character. 925 See also Section 13 "Internationalized Domain Names for Applications 926 (IDNA): Dependency and Migration" and Section 14.8 "Internationalized 927 Domain Names" of this specification for further details and 928 considerations. 930 10. Server Implementation and Deployment Advice 932 This section is non-normative. 934 10.1. HSTS Policy expiration time considerations 936 Server implementations and deploying web sites need to consider 937 whether they are setting an expiry time that is a constant value into 938 the future, e.g., by constantly sending the same max-age value to 939 UAs. 941 For example, a max-age value of 778000 is 90 days: 943 Strict-Transport-Security: max-age=778000 945 Note that each receipt of this header by a UA will require the UA to 946 update its notion of when it must delete its knowledge of this Known 947 HSTS Host. The specifics of how this is accomplished is out of the 948 scope of this specification. 950 Or, whether they are setting an expiry time that is a fixed point in 951 time, e.g., by sending max-age values that represent the remaining 952 time until the expiry time. 954 A consideration here is whether a deployer wishes to have the 955 signaled HSTS Policy expiry time match that for the web site's domain 956 certificate. 958 Additionally, server implementers should consider employing a default 959 max-age value of zero in their deployment configuration systems. 960 This will require deployers to wilfully set max-age in order to have 961 UAs enforce the HSTS Policy for their host, and protects them from 962 inadvertently enabling HSTS with some arbitrary non-zero duration. 964 10.2. Using HSTS in conjunction with self-signed public-key 965 certificates 967 If a web site/organization/enterprise is generating their own secure 968 transport public-key certificates for web sites, and that 969 organization's root certification authority (CA) certificate is not 970 typically embedded by default in browser CA certificate stores, and 971 if HSTS Policy is enabled on a site identifying itself using a self- 972 signed certificate, then secure connections to that site will fail, 973 per the HSTS design. This is to protect against various active 974 attacks, as discussed above. 976 However, if said organization strongly wishes to employ self-signed 977 certificates, and their own CA in concert with HSTS, they can do so 978 by deploying their root CA certificate to their users' browsers. 979 They can also, in addition or instead, distribute to their users' 980 browsers the end-entity certificate(s) for specific hosts. There are 981 various ways in which this can be accomplished (details are out of 982 scope for this specification). Once their root CA certificate is 983 installed in the browsers, they may employ HSTS Policy on their 984 site(s). 986 Note: Interactively distributing root CA certificates to users, 987 e.g., via email, and having the users install them, is 988 arguably training the users to be susceptible to a possible 989 form of phishing attack, see Section 14.6 "Bogus Root CA 990 Certificate Phish plus DNS Cache Poisoning Attack". 992 10.3. Implications of includeSubDomains 994 The includeSubDomains directive has some practical implications -- 995 for example, if a HSTS Host offers HTTP-based services on various 996 ports or at various subdomains of its host domain name, then they 997 will all have to be available over secure transport in order to work 998 properly. 1000 For example, certification authorities often offer their CRL 1001 distribution and OCSP services over plain HTTP, and sometimes at a 1002 subdomain of a publicly-available web application which may be 1003 secured by TLS/SSL. For example, is a 1004 publicly-available web application for "Example CA", a certification 1005 authority. Customers use this web application to register their 1006 public keys and obtain certificates. Example CA generates 1007 certificates for customers containing 1008 as the value for the "CRL 1009 Distribution Points" and "Authority Information Access:OCSP" 1010 certificate fields. 1012 If example-ca.com were to issue an HSTS Policy with the 1013 includeSubDomains directive, then HTTP-based user agents implementing 1014 HSTS, and that have interacted with the example-ca.com web 1015 application, would fail to retrieve CRLs and fail to check OCSP for 1016 certificates because these services are offered over plain HTTP. 1018 In this case, Example CA can either: 1020 o not use the includeSubDomains directive, or, 1022 o ensure HTTP-based services offered at subdomains of example-ca.com 1023 are uniformly offered over TLS/SSL, or, 1025 o offer plain HTTP-based services at a different domain name, e.g., 1026 example-ca-services.net. 1028 11. User Agent Implementation Advice 1030 This section is non-normative. 1032 In order to provide users and web sites more effective protection, as 1033 well as controls for managing their UA's caching of HSTS Policy, UA 1034 implementors should consider including features such as: 1036 11.1. No User Recourse 1038 Failing secure connection establishment on any warnings or errors 1039 (per Section 8.3 "Errors in Secure Transport Establishment"), should 1040 be done with "no user recourse". This means that the user should not 1041 be presented with an explanatory dialog giving her the option to 1042 proceed. Rather, it should be treated similarly to a server error 1043 where there is nothing further the user can do with respect to 1044 interacting with the target web application, other than wait and re- 1045 try. 1047 Essentially, "any warnings or errors" means anything that would cause 1048 the UA implementation to annunciate to the user that something is not 1049 entirely correct with the connection establishment. 1051 Not doing this, i.e., allowing user recourse such as "clicking- 1052 through warning/error dialogs", is a recipe for a Man-in-the-Middle 1053 attack. If a web application advertises HSTS, then it is opting into 1054 this scheme, whereby all certificate errors or warnings cause a 1055 connection termination, with no chance to "fool" the user into making 1056 the wrong decision and compromising themselves. 1058 11.2. User-declared HSTS Policy 1060 Ability for users to explicitly declare a given Domain Name as 1061 representing a HSTS Host, thus seeding it as a Known HSTS Host before 1062 any actual interaction with it. This would help protect against the 1063 Section 14.4 "Bootstrap MITM Vulnerability". 1065 Note: Such a feature is difficult to get right on a per-site basis 1066 -- see the discussion of "rewrite rules" in section 5.5 of 1067 [ForceHTTPS]. For example, arbitrary web sites may not 1068 materialize all their URIs using the "https" scheme, and thus 1069 could "break" if a UA were to attempt to access the site 1070 exclusively using such URIs. Also note that this feature 1071 would complement, but is independent of the following 1072 described facility. 1074 11.3. HSTS Pre-Loaded List 1076 Facility whereby web site administrators can have UAs pre-configured 1077 with HSTS Policy for their site(s) by the UA vendor(s) -- a so-called 1078 "pre-loaded list" -- in a manner similar to how root CA certificates 1079 are embedded in browsers "at the factory". This would help protect 1080 against the Section 14.4 "Bootstrap MITM Vulnerability". 1082 Note: Such a facility would complement a "User-declared HSTS Policy" 1083 feature. 1085 11.4. Disallow Mixed Security Context 1087 Disallowing "mixed security context" (also known as "mixed content") 1088 loads (see section 5.3 "Mixed Content" in [W3C.REC-wsc-ui-20100812]). 1090 Note: In order to provide behavioral uniformity across UA 1091 implementations, the notion of mixed security context will 1092 require further standardization work, e.g., to more clearly 1093 define the term(s) and to define specific behaviors with 1094 respect to it. 1096 11.5. HSTS Policy Deletion 1098 Ability to delete UA's cached HSTS Policy on a per HSTS Host basis. 1100 Note: Adding such a feature should be done very carefully in both 1101 the user interface and security senses. Deleting a cache 1102 entry for a Known HSTS Host should be a very deliberate and 1103 well-considered act -- it shouldn't be something users get 1104 used to just "clicking through" in order to get work done. 1105 Also, it shouldn't be possible for an attacker to inject 1106 script into the UA that silently and programmatically removes 1107 entries from the UA's cache of Known HSTS Hosts. 1109 12. Constructing an Effective Request URI 1111 This section specifies how an HSTS Host must construct the Effective 1112 Request URI for a received HTTP request. 1114 HTTP requests often do not carry an absoluteURI for the target 1115 resource; instead, the URI needs to be inferred from the Request-URI, 1116 Host header field, and connection context ([RFC2616], Sections 3.2.1 1117 and 5.1.2). The result of this process is called the "effective 1118 request URI (ERU)". The "target resource" is the resource identified 1119 by the effective request URI. 1121 12.1. ERU Fundamental Definitions 1123 The first line of an HTTP request message, Request-Line, is specified 1124 by the following ABNF from [RFC2616], section 5.1: 1126 Request-Line = Method SP Request-URI SP HTTP-Version CRLF 1128 The Request-URI, within the Request-Line, is specified by the 1129 following ABNF from [RFC2616], section 5.1.2: 1131 Request-URI = "*" | absoluteURI | abs_path | authority 1133 The Host request header field is specified by the following ABNF from 1134 [RFC2616], section 14.23: 1136 Host = "Host" ":" host [ ":" port ] 1138 12.2. Determining the Effective Requrest URI 1140 If the Request-URI is an absoluteURI, then the effective request URI 1141 is the Request-URI. 1143 If the Request-URI uses the abs_path form or the asterisk form, and 1144 the Host header field is present, then the effective request URI is 1145 constructed by concatenating: 1147 o the scheme name: "http" if the request was received over an 1148 insecure TCP connection, or "https" when received over a TLS/ 1149 SSL-secured TCP connection, and, 1151 o the octet sequence "://", and, 1153 o the host, and the port (if present), from the Host header field, 1154 and 1156 o the Request-URI obtained from the Request-Line, unless the 1157 Request-URI is just the asterisk "*". 1159 If the Request-URI uses the abs_path form or the asterisk form, and 1160 the Host header field is not present, then the effective request URI 1161 is undefined. 1163 Otherwise, when Request-URI uses the authority form, the effective 1164 request URI is undefined. 1166 Effective request URIs are compared using the rules described in 1167 [RFC2616] Section 3.2.3, except that empty path components MUST NOT 1168 be treated as equivalent to an absolute path of "/". 1170 12.2.1. Effective Requrest URI Examples 1172 Example 1: the effective request URI for the message 1174 GET /pub/WWW/TheProject.html HTTP/1.1 1175 Host: www.example.org:8080 1177 (received over an insecure TCP connection) is "http", plus "://", 1178 plus the authority component "www.example.org:8080", plus the 1179 request-target "/pub/WWW/TheProject.html". Thus it is: 1180 "http://www.example.org:8080/pub/WWW/TheProject.html". 1182 Example 2: the effective request URI for the message 1184 OPTIONS * HTTP/1.1 1185 Host: www.example.org 1187 (received over an SSL/TLS secured TCP connection) is "https", plus 1188 "://", plus the authority component "www.example.org". Thus it is: 1189 "https://www.example.org". 1191 13. Internationalized Domain Names for Applications (IDNA): Dependency 1192 and Migration 1194 Textual domain names on the modern Internet may contain one or more 1195 "internationalized" domain name labels. Such domain names are 1196 referred to as "internationalized domain names" (IDNs). The 1197 specification suites defining IDNs and the protocols for their use 1198 are named "Internationalized Domain Names for Applications (IDNA)". 1199 At this time, there are two such specification suites: IDNA2008 1200 [RFC5890] and its predecessor IDNA2003 [RFC3490]. 1202 IDNA2008 obsoletes IDNA2003, but there are differences between the 1203 two specifications, and thus there can be differences in processing 1204 (e.g., converting) domain name labels that have been registered under 1205 one from those registered under the other. There will be a 1206 transition period of some time during which IDNA2003-based domain 1207 name labels will exist in the wild. User agents SHOULD implement 1208 IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of 1209 [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. 1210 If a user agent does not implement IDNA2008, the user agent MUST 1211 implement IDNA2003. 1213 14. Security Considerations 1214 14.1. Ramifications of HSTS Policy Establishment only over Error-free 1215 Secure Transport 1217 The User Agent Processing Model defined in Section 8, stipulates that 1218 a host is initially noted as a Known HSTS Host, or that updates are 1219 made to a Known HSTS Host's cached information, only if the UA 1220 receives the STS header field over a secure transport connection 1221 having no underlying secure transport errors or warnings. 1223 The rationale behind this is that if there is a man-in-the-middle 1224 (MITM) -- whether a legitimately deployed proxy or an illegitimate 1225 entity -- it could cause various mischief (see also Appendix A 1226 "Design Decision Notes", item 3, as well as Section 14.4 "Bootstrap 1227 MITM Vulnerability" ), for example: 1229 o Unauthorized notation of the host as a Known HSTS Host, 1230 potentially leading to a denial of service situation if the host 1231 does not uniformly offer its services over secure transport (see 1232 also Section 14.3 "Denial of Service". 1234 o Resetting the time-to-live for the host's designation as a Known 1235 HSTS Host by manipulating the max-age header field parameter value 1236 that is returned to the UA. If max-age is returned as zero, this 1237 will cause the host to no longer be regarded as an Known HSTS Host 1238 by the UA, leading to either insecure connections to the host or 1239 possibly denial-of-service if the host delivers its services only 1240 over secure transport. 1242 However, this means that if a UA is "behind" a proxy -- within a 1243 corporate intranet, for example -- and interacts with an unknown HSTS 1244 Host beyond the proxy, the user will possibly be presented with the 1245 legacy secure connection error dialogs. And even if the risk is 1246 accepted and the user clicks-through, the host will not be noted as a 1247 HSTS Host. Thus as long as the UA is behind such a proxy the user 1248 will be vulnerable, and possibly be presented with the legacy secure 1249 connection error dialogs for as yet unknown HSTS Hosts. 1251 But once the UA successfully connects to an unknown HSTS Host over 1252 error-free secure transport, the host will be noted as a Known HSTS 1253 Host. This will result in the failure of subsequent connection 1254 attempts from behind interfering proxies. 1256 The above discussion relates to the recommendation in Section 11 1257 "User Agent Implementation Advice" that the secure connection be 1258 terminated with "no user recourse" whenever there are warnings and 1259 errors and the host is a Known HSTS Host. Such a posture protects 1260 users from "clicking through" security warnings and putting 1261 themselves at risk. 1263 14.2. The Need for includeSubDomains 1265 Without the includeSubDomains directive, a web application would not 1266 be able to adequately protect so-called "domain cookies" (even if 1267 these cookies have their "Secure" flag set and thus are conveyed only 1268 on secure channels). These are cookies the web application expects 1269 UAs to return to any and all subdomains of the web application. 1271 For example, suppose example.com represents the top-level DNS name 1272 for a web application. Further suppose that this cookie is set for 1273 the entire example.com domain, i.e. it is a "domain cookie", and it 1274 has its Secure flag set. Suppose example.com is a Known HSTS Host 1275 for this UA, but the includeSubDomains flag is not set. 1277 Now, if an attacker causes the UA to request a subdomain name that is 1278 unlikely to already exist in the web application, such as 1279 "https://uxdhbpahpdsf.example.com/", but the attacker has established 1280 somewhere and registered in the DNS, then: 1282 1. The UA is unlikely to already have an HSTS policy established for 1283 "uxdhbpahpdsf.example.com", and, 1285 2. The HTTP request sent to uxdhbpahpdsf.example.com will include 1286 the Secure-flagged domain cookie. 1288 3. If "uxdhbpahpdsf.example.com" returns a certificate during TLS 1289 establishment, and the user clicks through any warning that might 1290 be annunciated (it is possible, but not certain, that one may 1291 obtain a requisite certificate for such a domain name such that a 1292 warning may or may not appear), then the attacker can obtain the 1293 Secure-flagged domain cookie that's ostensibly being protected. 1295 Without the "includeSubDomains" directive, HSTS is unable to protect 1296 such Secure-flagged domain cookies. 1298 14.3. Denial of Service 1300 HSTS could be used to mount certain forms of Denial-of- Service (DoS) 1301 attacks against web sites. A DoS attack is an attack in which one or 1302 more network entities target a victim entity and attempt to prevent 1303 the victim from doing useful work. This section discusses such 1304 scenarios in terms of HSTS, though this list is not exhaustive. See 1305 also [RFC4732] for a discussion of overall Internet DoS 1306 considerations. 1308 o Web applications available over HTTP 1310 There is an opportunity for perpetrating DoS attacks with web 1311 applications that are -- or critical portions of them are -- 1312 available only over HTTP without secure transport, if attackers 1313 can cause UAs to set HSTS Policy for such web applications' 1314 host(s). 1316 This is because once the HSTS Policy is set for a web 1317 application's host in a UA, the UA will only use secure transport 1318 to communicate with the host. If the host is not using secure 1319 transport, or is not for critical portions of its web application, 1320 then the web application will be rendered unusable for the UA's 1321 user. 1323 An HSTS Policy can be set for a victim host in various ways: 1325 * If the web application has a HTTP response splitting 1326 vulnerability [CWE-113] (which can be abused in order to 1327 facilitate "HTTP Header Injection"). 1329 * If an attacker can spoof a redirect from an insecure victim 1330 site, e.g., to , 1331 where the latter is attacker-controlled and has an apparently 1332 valid certificate, then the attacker can set an HSTS Policy for 1333 example.com, and also for all subdomains of example.com. 1335 * If an attacker can convince users to manually configure HSTS 1336 Policy for a victim host, assuming their UAs offer this 1337 capability (see Section 11 "User Agent Implementation Advice"). 1338 Or if such UA configuration is scriptable, and the attacker can 1339 cause UAs to execute his script. 1341 o Inadvertent use of includeSubDomains 1343 The includeSubDomains directive instructs UAs to automatically 1344 regard all subdomains of the given HSTS Host as Known HSTS Hosts. 1345 If any such subdomains do not support properly configured secure 1346 transport, then they will be rendered unreachable from such UAs. 1348 14.4. Bootstrap MITM Vulnerability 1350 The bootstrap MITM (Man-In-The-Middle) vulnerability is a 1351 vulnerability users and HSTS Hosts encounter in the situation where 1352 the user manually enters, or follows a link, to an unknown HSTS Host 1353 using a "http" URI rather than a "https" URI. Because the UA uses an 1354 insecure channel in the initial attempt to interact with the 1355 specified server, such an initial interaction is vulnerable to 1356 various attacks [ForceHTTPS] . 1358 Note: There are various features/facilities that UA implementations 1359 may employ in order to mitigate this vulnerability. Please 1360 see Section 11 "User Agent Implementation Advice". 1362 14.5. Network Time Attacks 1364 Active network attacks can subvert network time protocols (such as 1365 NTP) - making HSTS less effective against clients that trust NTP or 1366 lack a real time clock. Network time attacks are beyond the scope of 1367 this specification. Note that modern operating systems use NTP by 1368 default. See also section 2.10 of [RFC4732]. 1370 14.6. Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack 1372 If an attacker can convince users of, say, https://bank.example.com 1373 (which is protected by HSTS Policy), to install their own version of 1374 a root CA certificate purporting to be bank.example.com's CA, e.g., 1375 via a phishing email message with a link to such a certificate. 1376 Then, if they can perform an attack on the users' DNS, (e.g., via 1377 cache poisoning) and turn on HSTS Policy for their fake 1378 bank.example.com site, then they have themselves some new users. 1380 14.7. Creative Manipulation of HSTS Policy Store 1382 Since an HSTS Host may select its own host name and subdomains 1383 thereof, and this information is cached in the HSTS Policy store of 1384 conforming UAs, it is possible for those who control a HSTS Host(s) 1385 to encode information into domain names they control and cause such 1386 UAs to cache this information as a matter of course in the process of 1387 noting the HSTS Host. This information can be retrieved by other 1388 hosts through clever loaded page construction causing the UA to send 1389 queries to (variations of) the encoded domain names. Such queries 1390 can reveal whether the UA had prior visited the original HSTS Host 1391 (and subdomains). 1393 Such a technique could potentially be abused as yet another form of 1394 "web tracking" [WebTracking]. 1396 14.8. Internationalized Domain Names 1398 Internet security relies in part on the DNS and the domain names it 1399 hosts. Domain names are used by users to identify and connect to 1400 Internet hosts and other network resources. For example, Internet 1401 security is compromised if a user entering an internationalized 1402 domain name (IDN) is connected to different hosts based on different 1403 interpretations of the IDN. 1405 The processing models specified in this specification assume that the 1406 domain names they manipulate are IDNA-canonicalized, and that the 1407 canonicalization process correctly performed all appropriate IDNA and 1408 Unicode validations and character list testing per the requisite 1409 specifications (e.g., as noted in Section 9 "Domain Name IDNA- 1410 Canonicalization"). These steps are necessary in order to avoid 1411 various potentially compromising situations. 1413 In brief, some examples of issues that could stem from lack of 1414 careful and consistent Unicode and IDNA validations are things such 1415 as unexpected processing exceptions, truncation errors, and buffer 1416 overflows, as well as false-positive and/or false-negative domain 1417 name matching results. Any of the foregoing issues could possibly be 1418 leveraged by attackers in various ways. 1420 Additionally, IDNA2008 [RFC5890] differs from IDNA2003 [RFC3490] in 1421 terms of disallowed characters and character mapping conventions. 1422 This situation can also lead to false-positive and/or false-negative 1423 domain name matching results, resulting in, for example, users 1424 possibly communicating with unintended hosts, or not being able to 1425 reach intended hosts. 1427 For details, refer to the Security Considerations sections of 1428 [RFC5890], [RFC5891], and [RFC3490], as well as the specifications 1429 they normatively reference. Additionally, [RFC5894] provides 1430 detailed background and rationale for IDNA2008 in particular, as well 1431 as IDNA and its issues in general, and should be consulted in 1432 conjunction with the former specifications. 1434 15. IANA Considerations 1436 Below is the Internet Assigned Numbers Authority (IANA) Provisional 1437 Message Header Field registration information per [RFC3864]. 1439 Header field name: Strict-Transport-Security 1440 Applicable protocol: HTTP 1441 Status: provisional 1442 Author/Change controller: TBD 1443 Specification document(s): this one 1445 16. References 1447 16.1. Normative References 1449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1450 Requirement Levels", BCP 14, RFC 2119, March 1997. 1452 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1453 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1454 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1456 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1457 Procedures for Message Header Fields", BCP 90, RFC 3864, 1458 September 2004. 1460 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1461 Resource Identifier (URI): Generic Syntax", STD 66, 1462 RFC 3986, January 2005. 1464 16.2. Informative References 1466 [Aircrack-ng] 1467 d'Otreppe, T., "Aircrack-ng", Accessed: 11-Jul-2010, 1468 . 1470 [BeckTews09] 1471 Beck, M. and E. Tews, "Practical Attacks Against WEP and 1472 WPA", Second ACM Conference on Wireless Network 1473 Security Zurich, Switzerland, 2009, . 1477 [CWE-113] "CWE-113: Improper Neutralization of CRLF Sequences in 1478 HTTP Headers ('HTTP Response Splitting')", Common Weakness 1479 Enumeration , The Mitre 1480 Corporation , 1481 . 1483 [Firesheep] 1484 Various, "Firesheep", Wikipedia Online, on-going, 1485 . 1488 [ForceHTTPS] 1489 Jackson, C. and A. Barth, "ForceHTTPS: Protecting High- 1490 Security Web Sites from Network Attacks", In Proceedings 1491 of the 17th International World Wide Web Conference 1492 (WWW2008) , 2008, 1493 . 1495 [GoodDhamijaEtAl05] 1496 Good, N., Dhamija, R., Grossklags, J., Thaw, D., 1497 Aronowitz, S., Mulligan, D., and J. Konstan, "Stopping 1498 Spyware at the Gate: A User Study of Privacy, Notice and 1499 Spyware", In Proceedings of Symposium On Usable Privacy 1500 and Security (SOUPS) Pittsburgh, PA, USA, July 2005, . 1504 [I-D.ietf-tls-ssl-version3] 1505 Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol 1506 Version 3.0", draft-ietf-tls-ssl-version3-00 (work in 1507 progress), November 1996, . 1510 [JacksonBarth2008] 1511 Jackson, C. and A. Barth, "Beware of Finer-Grained 1512 Origins", Web 2.0 Security and Privacy Oakland, CA, USA, 1513 2008, 1514 . 1517 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1518 RFC 793, September 1981. 1520 [RFC1035] Mockapetris, P., "Domain names - implementation and 1521 specification", STD 13, RFC 1035, November 1987. 1523 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1524 Adams, "X.509 Internet Public Key Infrastructure Online 1525 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1527 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1529 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1530 Internationalized Strings ("stringprep")", RFC 3454, 1531 December 2002. 1533 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1534 "Internationalizing Domain Names in Applications (IDNA)", 1535 RFC 3490, March 2003. 1537 TODO: explanation of including this obsoleted reference 1539 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1540 for Internationalized Domain Names in Applications 1541 (IDNA)", RFC 3492, March 2003. 1543 TODO: explanation of including this obsoleted reference 1545 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 1546 Service Considerations", RFC 4732, December 2006. 1548 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1549 RFC 4949, August 2007. 1551 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1552 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1554 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1555 Housley, R., and W. Polk, "Internet X.509 Public Key 1556 Infrastructure Certificate and Certificate Revocation List 1557 (CRL) Profile", RFC 5280, May 2008. 1559 [RFC5890] Klensin, J., "Internationalized Domain Names for 1560 Applications (IDNA): Definitions and Document Framework", 1561 RFC 5890, August 2010. 1563 [RFC5891] Klensin, J., "Internationalized Domain Names in 1564 Applications (IDNA): Protocol", RFC 5891, August 2010. 1566 [RFC5894] Klensin, J., "Internationalized Domain Names for 1567 Applications (IDNA): Background, Explanation, and 1568 Rationale", RFC 5894, August 2010. 1570 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 1571 Internationalized Domain Names in Applications (IDNA) 1572 2008", RFC 5895, September 2010. 1574 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1575 April 2011. 1577 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1578 December 2011. 1580 [SunshineEgelmanEtAl09] 1581 Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and 1582 L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning 1583 Effectiveness", In Proceedings of 18th USENIX Security 1584 Symposium Montreal, Canada, Augus 2009, . 1588 [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility 1589 Processing", Unicode Technical Standards # 46, 2010, 1590 . 1592 [Unicode6] 1593 The Unicode Consortium, "The Unicode Standard, Version 6.0 1594 - Core Specification", Unicode 6.0.0, Mountain View, CA, 1595 The Unicode Consortium ISBN 978-1-936213-01-6, 2011, 1596 . 1598 [W3C.REC-wsc-ui-20100812] 1599 Saldhana, A. and T. Roessler, "Web Security Context: User 1600 Interface Guidelines", World Wide Web Consortium 1601 Recommendation REC-wsc-ui-20100812, August 2010, 1602 . 1604 [WEBSEC] "WebSec -- HTTP Application Security Minus Authentication 1605 and Transport", 1606 . 1608 Mailing list for IETF WebSec Working Group. [RFCEditor: 1609 please remove this reference upon publication as an RFC.] 1611 [WebTracking] 1612 Schmucker, N., "Web Tracking", SNET2 Seminar Paper Summer 1613 Term, 2011, . 1616 [owaspTLSGuide] 1617 Coates, M., Wichers, d., Boberski, M., and T. Reguly, 1618 "Transport Layer Protection Cheat Sheet", Accessed: 11- 1619 Jul-2010, . 1622 Appendix A. Design Decision Notes 1624 This appendix documents various design decisions. 1626 1. Cookies aren't appropriate for HSTS Policy expression as they are 1627 potentially mutable (while stored in the UA), therefore an HTTP 1628 header field is employed. 1630 2. We chose to not attempt to specify how "mixed security context 1631 loads" (aka "mixed content loads") are handled due to UA 1632 implementation considerations as well as classification 1633 difficulties. 1635 3. A HSTS Host may update UA notions of HSTS Policy via new HSTS 1636 header field parameter values. We chose to have UAs honor the 1637 "freshest" information received from a server because there is 1638 the chance of a web site sending out an errornous HSTS Policy, 1639 such as a multi-year max-age value, and/or an incorrect 1640 includeSubDomains flag. If the HSTS Host couldn't correct such 1641 errors over protocol, it would require some form of annunciation 1642 to users and manual intervention on the users' part, which could 1643 be a non-trivial problem for both web application providers and 1644 their users. 1646 4. HSTS Hosts are identified only via domain names -- explicit IP 1647 address identification of all forms is excluded. This is for 1648 simplification and also is in recognition of various issues with 1649 using direct IP address identification in concert with PKI-based 1650 security. 1652 Appendix B. Differences between HSTS Policy and Same-Origin Policy 1654 HSTS Policy has the following primary characteristics: 1656 HSTS Policy stipulates requirements for the security 1657 characteristics of UA-to-host connection establishment, on a per- 1658 host basis. 1660 Hosts explicitly declare HSTS Policy to UAs. Conformant UAs are 1661 obliged to implement hosts' declared HSTS Policies. 1663 HSTS Policy is conveyed over protocol from the host to the UA. 1665 The UA maintains a cache of Known HSTS Hosts. 1667 UAs apply HSTS Policy whenever making a HTTP connection to a Known 1668 HSTS Host, regardless of host port number. I.e., it applies to 1669 all ports on a Known HSTS Host. Hosts are unable to affect this 1670 aspect of HSTS Policy. 1672 Hosts may optionally declare that their HSTS Policy applies to all 1673 subdomains of their host domain name. 1675 In contrast, the Same-Origin Policy (SOP) [RFC6454] has the following 1676 primary characteristics: 1678 An origin is the scheme, host, and port of a URI identifying a 1679 resource. 1681 A UA may dereference a URI, thus loading a representation of the 1682 resource the URI identifies. UAs label resource representations 1683 with their origins, which are derived from their URIs. 1685 The SOP refers to a collection of principles, implemented within 1686 UAs, governing the isolation of and communication between resource 1687 representations within the UA, as well as resource 1688 representations' access to network resources. 1690 In summary, although both HSTS Policy and SOP are enforced by by UAs, 1691 HSTS Policy is optionally declared by hosts and is not origin-based, 1692 while the SOP applies to all resource representations loaded from all 1693 hosts by conformant UAs. 1695 Appendix C. Acknowledgments 1697 The authors thank Devdatta Akhawe, Michael Barrett, Paul Hoffman, 1698 Yoav Nir, Laksh Raghavan, Marsh Ray, Julian Reschke, Tom Ritter, 1699 Peter Saint-Andre, Sid Stamm, Maciej Stachowiak, Andy Steingrubl, 1700 Brandon Sterne, Martin Thomson, Daniel Veditz, as well as all the 1701 websec working group participants and others for their review and 1702 contributions. 1704 Thanks to Julian Reschke for his elegant re-writing of the effective 1705 request URI text, which he did when incorporating the ERU notion into 1706 the HTTPbis work. Subsequently, the ERU text in this spec was lifted 1707 from Julian's work in [I-D.draft-ietf-httpbis-p1-messaging-17] and 1708 adapted to the [RFC2616] ABNF. 1710 Appendix D. Change Log 1712 [RFCEditor: please remove this section upon publication as an RFC.] 1714 Changes are grouped by spec revision listed in reverse issuance 1715 order. 1717 D.1. For draft-ietf-websec-strict-transport-sec 1719 Changes from -03 to -04: 1721 1. Clarified that max-age=0 will cause UA to forget a known HSTS 1722 host, and more generally clarified that the "freshest" info 1723 from the HSTS host is cached, and thus HSTS hosts are able to 1724 alter the cached max-age in UAs. This addresses issue ticket 1725 #13. 1727 2. Updated section on "Constructing an Effective Request URI" to 1728 remove remaining reference to RFC3986 and reference RFC2616 1729 instead. Further addresses issue ticket #14. 1730 1732 3. Addresses further ABNF issues noted in comment:1 of issue 1733 ticket #27. 1736 4. Reworked the introduction to clarify the denotation of "HSTS 1737 policy" and added the new Appendix B summarizing the primary 1738 characteristics of HSTS Policy and Same-Origin Policy, and 1739 identifying their differences. Added ref to [RFC4732]. This 1740 addresses issue ticket #28. 1741 1743 5. Reworked language in Section 2.3.1.3. wrt "mixed content", 1744 more clearly explain such vulnerability, disambiguate "mixed 1745 content" in web security context from its usage in markup 1746 language context. This addresses issue ticket #29. 1747 1749 6. Expanded Denial of Service discussion in Security 1750 Considerations. Added refs to [RFC4732] and [CWE-113]. This 1751 addresses issue ticket #30. 1752 1754 7. Mentioned in prose the case-insensitivity of directive names. 1755 This addresses issue ticket #31. 1756 1758 8. Added Section 10.3 "Implications of includeSubDomains". This 1759 addresses issue ticket #32. 1760 1762 9. Further refines text and ABNF definitions of STS header field 1763 directives. Retains use of quoted-string in directive 1764 grammar. This addresses issue ticket #33. 1765 1767 10. Added Section 14.7 "Creative Manipulation of HSTS Policy 1768 Store", including reference to [WebTracking]. This addresses 1769 issue ticket #34. 1770 1772 11. Added Section 14.1 "Ramifications of HSTS Policy 1773 Establishment only over Error-free Secure Transport" and made 1774 some accompanying editorial fixes in some other sections. 1775 This addresses issue ticket #35. 1776 1778 12. Refined references. Cleaned out un-used ones, updated to 1779 latest RFCs for others, consigned many to Informational. 1780 This addresses issue ticket #36. 1781 1783 13. Fixed-up some inaccuracies in the "Changes from -02 to -03" 1784 section. 1786 Changes from -02 to -03: 1788 1. Updated section on "Constructing an Effective Request URI" to 1789 remove references to RFC3986. Addresses issue ticket #14. 1790 1792 2. Reference RFC5890 for IDNA, retaining subordinate refs to 1793 RFC3490. Updated IDNA-specific language, e.g. domain name 1794 canonicalization and IDNA dependencies. Addresses issue 1795 ticket #26 1796 . 1798 3. Completely re-wrote the STS header ABNF to be fully based on 1799 RFC2616, rather than a hybrid of RFC2616 and httpbis. 1800 Addresses issue ticket #27 1801 . 1803 Changes from -01 to -02: 1805 1. Updated Section 8.2 "URI Loading and Port Mapping" fairly 1806 thoroughly in terms of refining the presentation of the 1807 steps, and to ensure the various aspects of port mapping are 1808 clear. Nominally fixes issue ticket #1 1809 1811 2. Removed dependencies on 1812 [I-D.draft-ietf-httpbis-p1-messaging-15]. Thus updated STS 1813 ABNF in Section 6.1 "Strict-Transport-Security HTTP Response 1814 Header Field" by lifting some productions entirely from 1815 [I-D.draft-ietf-httpbis-p1-messaging-15] and leveraging 1816 [RFC2616]. Addresses issue ticket #2 1817 . 1819 3. Updated Effective Request URI section and definition to use 1820 language from [I-D.draft-ietf-httpbis-p1-messaging-15] and 1821 ABNF from [RFC2616]. Fixes issue ticket #3 1822 . 1824 4. Added explicit mention that the HSTS policy applies to all 1825 TCP ports of a host advertising the HSTS policy. Nominally 1826 fixes issue ticket #4 1827 1829 5. Clarified the need for the "includeSubDomains" directive, 1830 e.g. to protect Secure-flagged domain cookies. In 1831 Section 14.2 "The Need for includeSubDomains". Nominally 1832 fixes issue ticket #5 1833 1835 6. Cited Firesheep as real-live threat in Section 2.3.1.1 1836 "Passive Network Attackers". Nominally fixes issue ticket #6 1837 . 1839 7. Added text to Section 11 "User Agent Implementation Advice" 1840 justifying connection termination due to tls warnings/errors. 1841 Nominally fixes issue ticket #7 1842 . 1844 8. Added new subsection Section 8.5 "Interstitially Missing 1845 Strict-Transport-Security Response Header Field". Nominally 1846 fixes issue ticket #8 1847 . 1849 9. Added text to Section 8.3 "Errors in Secure Transport 1850 Establishment" explicitly note revocation check failures as 1851 errors causing connection termination. Added references to 1852 [RFC5280] and [RFC2560]. Nominally fixes issue ticket #9 1853 . 1855 10. Added a sentence, noting that distributing specific end- 1856 entity certificates to browsers will also work for self- 1857 signed/private-CA cases, to Section 10 "Server Implementation 1858 and Deployment Advice" Nominally fixes issue ticket #10 1859 . 1861 11. Moved "with no user recourse" language from Section 8.3 1862 "Errors in Secure Transport Establishment" to Section 11 1863 "User Agent Implementation Advice". This nominally fixes 1864 issue ticket #11 1865 . 1867 12. Removed any and all dependencies on 1868 [I-D.draft-ietf-httpbis-p1-messaging-15], instead depending 1869 on [RFC2616] only. Fixes issue ticket #12 1870 . 1872 13. Removed the inline "XXX1" issue because no one had commented 1873 on it and it seems reasonable to suggest as a SHOULD that web 1874 apps should redirect incoming insecure connections to secure 1875 connections. 1877 14. Removed the inline "XXX2" issue because it was simply for 1878 raising consciousness about having some means for 1879 distributing secure web application metadata. 1881 15. Removed "TODO1" because description prose for "max-age" in 1882 the Note following the ABNF in Section 6 seems to be fine. 1884 16. Decided for "TODO2" that "the first STS header field wins". 1885 TODO2 had read: "Decide UA behavior in face of encountering 1886 multiple HSTS headers in a message. Use first header? 1887 Last?". Removed TODO2. 1889 17. Added Section 1.1 "Organization of this specification" for 1890 readers' convenience. 1892 18. Moved design decision notes to be a proper appendix 1893 Appendix A. 1895 Changes from -00 to -01: 1897 1. Changed the "URI Loading" section to be "URI Loading and Port 1898 Mapping". 1900 2. [HASMAT] reference changed to [WEBSEC]. 1902 3. Changed "server" -> "host" where applicable, notably when 1903 discussing "HSTS Hosts". Left as "server" when discussing 1904 e.g. "http server"s. 1906 4. Fixed minor editorial nits. 1908 Changes from draft-hodges-strict-transport-sec-02 to 1909 draft-ietf-websec-strict-transport-sec-00: 1911 1. Altered spec metadata (e.g. filename, date) in order to submit 1912 as a WebSec working group Internet-Draft. 1914 D.2. For draft-hodges-strict-transport-sec 1916 Changes from -01 to -02: 1918 1. updated abstract such that means for expressing HSTS Policy 1919 other than via HSTS header field is noted. 1921 2. Changed spec title to "HTTP Strict Transport Security (HSTS)" 1922 from "Strict Transport Security". Updated use of "STS" 1923 acronym throughout spec to HSTS (except for when specifically 1924 discussing syntax of Strict-Transport-Security HTTP Response 1925 Header field), updated "Terminology" appropriately. 1927 3. Updated the discussion of "Passive Network Attackers" to be 1928 more precise and offered references. 1930 4. Removed para on nomative/non-normative from "Conformance 1931 Criteria" pending polishing said section to IETF RFC norms. 1933 5. Added examples subsection to "Syntax" section. 1935 6. Added OWS to maxAge production in Strict-Transport-Security 1936 ABNF. 1938 7. Cleaned up explanation in the "Note:" in the "HTTP-over- 1939 Secure-Transport Request Type" section, folded 3d para into 1940 "Note:", added conformance clauses to the latter. 1942 8. Added exaplanatory "Note:" and reference to "HTTP Request 1943 Type" section. Added "XXX1" issue. 1945 9. Added conformance clause to "URI Loading". 1947 10. Moved "Notes for STS Server implementors:" from "UA 1948 Implementation dvice " to "HSTS Policy expiration time 1949 considerations:" in "Server Implementation Advice", and also 1950 noted another option. 1952 11. Added cautionary "Note:" to "Ability to delete UA's cached 1953 HSTS Policy on a per HSTS Server basis". 1955 12. Added some informative references. 1957 13. Various minor editorial fixes. 1959 Changes from -00 to -01: 1961 1. Added reference to HASMAT mailing list and request that this 1962 spec be discussed there. 1964 Authors' Addresses 1966 Jeff Hodges 1967 PayPal 1968 2211 North First Street 1969 San Jose, California 95131 1970 US 1972 Email: Jeff.Hodges@PayPal.com 1973 Collin Jackson 1974 Carnegie Mellon University 1976 Email: collin.jackson@sv.cmu.edu 1978 Adam Barth 1979 Google, Inc. 1981 Email: ietf@adambarth.com 1982 URI: http://www.adambarth.com/