idnits 2.17.1 draft-ietf-websec-strict-transport-sec-05.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 522 has weird spacing: '...TS Host is a...' -- The document date (March 9, 2012) is 4431 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 1701, but not defined == Missing Reference: 'I-D.draft-ietf-httpbis-p1-messaging-15' is mentioned on line 1875, but not defined == Missing Reference: 'HASMAT' is mentioned on line 1907, but not defined ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** 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 5894 ** Downref: Normative reference to an Informational RFC: RFC 5895 -- Possible downref: Non-RFC (?) normative reference: ref. 'UTS46' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode6' Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 4 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: September 10, 2012 Carnegie Mellon University 6 A. Barth 7 Google, Inc. 8 March 9, 2012 10 HTTP Strict Transport Security (HSTS) 11 draft-ietf-websec-strict-transport-sec-05 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 September 10, 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 . . . . . . . . . . . . . . . . . . 33 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). However, TCP does 146 not provide channel integrity protection, confidentiality, nor secure 147 host identification. Thus the Secure Sockets Layer (SSL) protocol 148 [I-D.ietf-tls-ssl-version3] and its successor Transport Layer 149 Security (TLS) [RFC5246], were developed in order to provide channel- 150 oriented security, and are typically layered between application 151 protocols and TCP. [RFC2818] specifies how HTTP is layered onto TLS, 152 and defines the Uniform Resource Identifier (URI) scheme of "https" 153 (in practice however, HTTP user agents (UAs) typically offer their 154 users choices among SSL2, SSL3, and TLS for secure transport). 156 UAs employ various local security policies with respect to the 157 characteristics of their interactions with web resources depending on 158 (in part) whether they are communicating with a given web resource's 159 host using HTTP or HTTP-over-a-Secure-Transport. For example, 160 cookies ([RFC6265]) may be flagged as Secure. UAs are to send such 161 Secure cookies to their addressed host only over a secure transport. 162 This is in contrast to non-Secure cookies, which are returned to the 163 host regardless of transport (although modulo other rules). 165 UAs typically annunciate to their users any issues with secure 166 connection establishment, such as being unable to validate a TLS 167 server certificate trust chain, or if a TLS server certificate is 168 expired, or if a TLS host's domain name appears incorrectly in the 169 TLS server certificate (see section 3.1 of [RFC2818]). Often, UAs 170 enable users to elect to continue to interact with a web resource's 171 host in the face of such issues. This behavior is sometimes referred 172 to as "click(ing) through" security [GoodDhamijaEtAl05] 173 [SunshineEgelmanEtAl09], and thus can be described as "click-through 174 insecurity". 176 A key vulnerability enabled by click-through insecurity is the 177 leaking of any cookies the web resource may be using to manage a 178 user's session. The threat here is that an attacker could obtain the 179 cookies and then interact with the legitimate web resource while 180 impersonating the user. 182 Jackson and Barth proposed an approach, in [ForceHTTPS], to enable 183 web resources to declare that any interactions by UAs with the web 184 resource must be conducted securely, and that any issues with 185 establishing a secure transport session are to be treated as fatal 186 and without direct user recourse. The aim is to prevent click- 187 through insecurity, and address other potential threats. 189 This specification embodies and refines the approach proposed in 190 [ForceHTTPS]. For example, rather than using a cookie to convey 191 policy from a web resource's host to a UA, it defines an HTTP 192 response header field for this purpose. Additionally, a web 193 resource's host may declare its policy to apply to the entire domain 194 name subtree rooted at its host name. This enables HSTS to protect 195 so-called "domain cookies", which are applied to all subdomains of a 196 given web resource's host name. 198 This specification also incorporates notions from [JacksonBarth2008] 199 in that policy is applied on an "entire-host" basis: it applies to 200 all TCP ports of the issuing host. 202 Note that the policy defined by this specification is distinctly 203 different than the "same-origin policy" defined in "The Web Origin 204 Concept" [RFC6454]. These differences are summarized below in 205 Appendix B. 207 1.1. Organization of this specification 209 This specification begins with an overview of the use cases, policy 210 effects, threat models, and requirements for HSTS (in Section 2). 211 Then, Section 3 defines conformance requirements. The HSTS mechanism 212 itself is formally specified in Section 4 through Section 15. 214 2. Overview 216 This section discusses the use cases, summarizes the HTTP Strict 217 Transport Security (HSTS) policy, and continues with a discussion of 218 the threat model, non-addressed threats, and derived requirements. 220 2.1. Use Cases 222 The high-level use case is a combination of: 224 o Web browser user wishes to interact with various web sites (some 225 arbitrary, some known) in a secure fashion. 227 o Web site deployer wishes to offer their site in an explicitly 228 secure fashion for both their own, as well as their users', 229 benefit. 231 2.2. HTTP Strict Transport Security Policy Effects 233 The effects of the HTTP Strict Transport Security (HSTS) Policy, as 234 applied by a UA in interactions with a web resource host wielding 235 such policy (known as a HSTS Host), are summarized as follows: 237 1. All insecure ("http") connections to any TCP ports on a HSTS Host 238 are redirected by the HSTS Host to be secure connections 239 ("https"). 241 2. The UA terminates any secure transport connection attempts upon 242 any and all secure transport errors or warnings, including those 243 caused by a web application presenting self-signed certificates. 245 3. UAs transform insecure URI references to a HSTS Host into secure 246 URI references before dereferencing them. 248 2.3. Threat Model 250 HSTS is concerned with three threat classes: passive network 251 attackers, active network attackers, and imperfect web developers. 252 However, it is explicitly not a remedy for two other classes of 253 threats: phishing and malware. Addressed and not addressed threats 254 are briefly discussed below. Readers may wish refer to [ForceHTTPS] 255 for details as well as relevant citations. 257 2.3.1. Threats Addressed 259 2.3.1.1. Passive Network Attackers 261 When a user browses the web on a local wireless network (e.g., an 262 802.11-based wireless local area network) a nearby attacker can 263 possibly eavesdrop on the user's unencrypted Internet Protocol-based 264 connections, such as HTTP, regardless of whether or not the local 265 wireless network itself is secured [BeckTews09]. Freely available 266 wireless sniffing toolkits (e.g., [Aircrack-ng]) enable such passive 267 eavesdropping attacks, even if the local wireless network is 268 operating in a secure fashion. A passive network attacker using such 269 tools can steal session identifiers/cookies and hijack the user's web 270 session(s), by obtaining cookies containing authentication 271 credentials [ForceHTTPS]. For example, there exist widely-available 272 tools, such as Firesheep (a Firefox extension) [Firesheep], which 273 enable their wielder to obtain other local users' session cookies for 274 various web applications. 276 To mitigate such threats, some Web sites support, but usually do not 277 force, access using end-to-end secure transport -- e.g., signaled 278 through URIs constructed with the "https" scheme [RFC2818]. This can 279 lead users to believe that accessing such services using secure 280 transport protects them from passive network attackers. 281 Unfortunately, this is often not the case in real-world deployments 282 as session identifiers are often stored in non-Secure cookies to 283 permit interoperability with versions of the service offered over 284 insecure transport ("Secure cookies" are those cookies containing the 285 "Secure" attribute [RFC6265]). For example, if the session 286 identifier for a web site (an email service, say) is stored in a non- 287 Secure cookie, it permits an attacker to hijack the user's session if 288 the user's UA makes a single insecure HTTP request to the site. 290 2.3.1.2. Active Network Attackers 292 A determined attacker can mount an active attack, either by 293 impersonating a user's DNS server or, in a wireless network, by 294 spoofing network frames or offering a similarly-named evil twin 295 access point. If the user is behind a wireless home router, an 296 attacker can attempt to reconfigure the router using default 297 passwords and other vulnerabilities. Some sites, such as banks, rely 298 on end-to-end secure transport to protect themselves and their users 299 from such active attackers. Unfortunately, browsers allow their 300 users to easily opt-out of these protections in order to be usable 301 for sites that incorrectly deploy secure transport, for example by 302 generating and self-signing their own certificates (without also 303 distributing their CA certificate to their users' browsers). 305 2.3.1.3. Web Site Development and Deployment Bugs 307 The security of an otherwise uniformly secure site (i.e. all of its 308 content is materialized via "https" URIs), can be compromised 309 completely by an active attacker exploiting a simple mistake, such as 310 the loading of a cascading style sheet or a SWF movie over an 311 insecure connection (both cascading style sheets and SWF movies can 312 script the embedding page, to the surprise of many web developers, 313 plus some browsers do not issue so-called "mixed content warnings" 314 when SWF files are embedded via insecure connections). Even if the 315 site's developers carefully scrutinize their login page for "mixed 316 content", a single insecure embedding anywhere on the overall site 317 compromises the security of their login page because an attacker can 318 script (i.e., control) the login page by injecting script into 319 another, insecurely loaded, site page. 321 Note: "Mixed content" as used above (see also section 5.3 in 322 [W3C.REC-wsc-ui-20100812]) refers to the notion termed "mixed 323 security context" in this specification, and should not be 324 confused with the same "mixed content" term used in the 325 context of markup languages such as XML and HTML. 327 2.3.2. Threats Not Addressed 329 2.3.2.1. Phishing 331 Phishing attacks occur when an attacker solicits authentication 332 credentials from the user by hosting a fake site located on a 333 different domain than the real site, perhaps driving traffic to the 334 fake site by sending a link in an email message. Phishing attacks 335 can be very effective because users find it difficult to distinguish 336 the real site from a fake site. HSTS is not a defense against 337 phishing per se; rather, it complements many existing phishing 338 defenses by instructing the browser to protect session integrity and 339 long-lived authentication tokens [ForceHTTPS]. 341 2.3.2.2. Malware and Browser Vulnerabilities 343 Because HSTS is implemented as a browser security mechanism, it 344 relies on the trustworthiness of the user's system to protect the 345 session. Malicious code executing on the user's system can 346 compromise a browser session, regardless of whether HSTS is used. 348 2.4. Requirements 350 This section identifies and enumerates various requirements derived 351 from the use cases and the threats discussed above, and lists the 352 detailed core requirements HTTP Strict Transport Security addresses, 353 as well as ancillary requirements that are not directly addressed. 355 2.4.1. Overall Requirement 357 o Minimize the risks to web browser users and web site deployers 358 that are derived from passive and active network attackers, web 359 site development and deployment bugs, as well as insecure user 360 actions. 362 2.4.1.1. Detailed Core Requirements 364 These core requirements are derived from the overall requirement, and 365 are addressed by this specification. 367 1. Web sites need to be able to declare to UAs that they should be 368 interacted with using a strict security policy. 370 2. Web sites need to be able to instruct UAs that contact them 371 insecurely to do so securely. 373 3. UAs need to persistently remember web sites that signal strict 374 security policy enablement, for a web site declared time span. 376 Additionally, UAs need to cache the "freshest" strict security 377 policy information, in order to allow web sites to update the 378 information. 380 4. UAs need to re-write all insecure UA "http" URI loads to use the 381 "https" secure scheme for those web sites for which secure policy 382 is enabled. 384 5. Web site administrators need to be able to signal strict security 385 policy application to subdomains of higher-level domains for 386 which strict security policy is enabled, and UAs need to enforce 387 such policy. 389 For example, both example.com and foo.example.com could set 390 policy for bar.foo.example.com. 392 6. UAs need to disallow security policy application to peer domains, 393 and/or higher-level domains, by domains for which strict security 394 policy is enabled. 396 For example, neither bar.foo.example.com nor foo.example.com can 397 set policy for example.com, nor can bar.foo.example.com set 398 policy for foo.example.com. Also, foo.example.com cannot set 399 policy for sibling.example.com. 401 7. UAs need to prevent users from clicking-through security 402 warnings. Halting connection attempts in the face of secure 403 transport exceptions is acceptable. 405 Note: A means for uniformly securely meeting the first core 406 requirement above is not specifically addressed by this 407 specification (see Section 14.4 "Bootstrap MITM 408 Vulnerability"). It may be addressed by a future revision of 409 this specification or some other specification. Note also 410 that there are means by which UA implementations may more 411 fully meet the first core requirement, see Section 11 "User 412 Agent Implementation Advice". 414 2.4.1.2. Detailed Ancillary Requirements 416 These ancillary requirements are also derived from the overall 417 requirement. They are not normatively addressed in this 418 specification, but could be met by UA implementations at their 419 implementor's discretion, although meeting these requirements may be 420 complex. 422 1. Disallow "mixed security context" loads (see Section 2.3.1.3, 423 above). 425 2. Facilitate user declaration of web sites for which strict 426 security policy is enabled, regardless of whether the sites 427 signal HSTS Policy. 429 3. Conformance Criteria 431 This specification is written for hosts and user agents (UAs). 433 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 434 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 435 document are to be interpreted as described in [RFC2119]. 437 A conformant host is one that implements all the requirements listed 438 in this specification that are applicable to hosts. 440 A conformant user agent is one that implements all the requirements 441 listed in this specification that are applicable to user agents. 443 3.1. Document Conventions 445 Note: ..is a note to the reader. These are points that should be 446 expressly kept in mind and/or considered. 448 Warning: This is how a warning is shown. These are things that can 449 have suboptimal downside risks if not heeded. 451 4. Terminology 453 Terminology is defined in this section. 455 ASCII case-insensitive comparison 456 means comparing two strings exactly, codepoint for 457 codepoint, except that the characters in the range 458 U+0041 .. U+005A (i.e. LATIN CAPITAL LETTER A to 459 LATIN CAPITAL LETTER Z) and the corresponding 460 characters in the range U+0061 .. U+007A (i.e. 461 LATIN SMALL LETTER A to LATIN SMALL LETTER Z) are 462 considered to also match. See [Unicode6] for 463 details. 465 codepoint is a colloquial contraction of Code Point, which is 466 any value in the Unicode codespace; that is, the 467 range of integers from 0 to 10FFFF(hex) [Unicode6]. 469 domain name domain names, also referred to as DNS Names, are 470 defined in [RFC1035] to be represented outside of 471 the DNS protocol itself (and implementations 472 thereof) as a series of labels separated by dots, 473 e.g., "example.com" or "yet.another.example.org". 474 In the context of this specification, domain names 475 appear in that portion of a URI satisfying the reg- 476 name production in "Appendix A. Collected ABNF for 477 URI" in [RFC3986], and the host component from the 478 Host HTTP header field production in section 14.23 479 of [RFC2616]. 481 Note: The domain names appearing in actual URI 482 instances and matching the aforementioned 483 production components may or may not be a 484 fully qualified domain name. 486 domain name label is that portion of a domain name appearing "between 487 the dots", i.e. consider "foo.example.com": "foo", 488 "example", and "com" are all domain name labels. 490 Effective Request URI 491 is a URI, identifying the target resource, that can 492 be inferred by an HTTP host for any given HTTP 493 request it receives. Such inference is necessary 494 because HTTP requests often do not contain a 495 complete "absolute" URI identifying the target 496 resource. See Section 12 "Constructing an 497 Effective Request URI", below. 499 HTTP Strict Transport Security 500 is the overall name for the combined UA- and 501 server-side security policy defined by this 502 specification. 504 HTTP Strict Transport Security Host 505 is a HTTP host implementing the server aspects of 506 the HSTS policy. This means that an HSTS Host 507 returns the "Strict-Transport-Security" HTTP 508 response header field in its HTTP response messages 509 sent over secure transport. 511 HTTP Strict Transport Security Policy 512 is the name of the combined overall UA- and server- 513 side facets of the behavior specified in this 514 specification. 516 HSTS See HTTP Strict Transport Security. 518 HSTS Host See HTTP Strict Transport Security Host. 520 HSTS Policy See HTTP Strict Transport Security Policy. 522 Known HSTS Host is a HSTS Host for which the UA has a HSTS Policy 523 in effect. I.e., the UA has noted this host as a 524 Known HSTS Host. 526 Local policy is comprised of policy rules deployers specify and 527 which are often manifested as "configuration 528 settings". 530 MITM is an acronym for man-in-the-middle. See "man-in- 531 the-middle attack" in [RFC4949]. 533 Request URI is the URI used to cause a UA to issue an HTTP 534 request message. 536 UA is a an acronym for user agent. For the purposes 537 of this specification, a UA is an HTTP client 538 application typically actively manipulated by a 539 user [RFC2616] . 541 unknown HSTS Host is a HSTS Host that the user agent in question has 542 not yet noted. 544 5. HSTS Mechanism Overview 546 This section provides an overview of the mechanism by which an HSTS 547 Host conveys its HSTS Policy to UAs, and how UAs process the HSTS 548 Policies received from HSTS Hosts. The mechanism details are 549 specified in Section 6 through Section 15. 551 An HSTS Host conveys its HSTS Policy to UAs, only over secure 552 transport (e.g., TLS), via the Strict-Transport-Security HTTP 553 response header field. Receipt of this header field signals to UAs 554 to enforce the HSTS Policy for all subsequent secure transport 555 connections made to the HSTS Host, for a specified time duration. 556 Application of the HSTS Policy to subdomains of the HSTS Host name 557 may optionally be specified. 559 HSTS Hosts manage their advertised HSTS Policies by sending Strict- 560 Transport-Security HTTP response header fields to UAs with new values 561 for policy time duration and application to subdomains. UAs cache 562 the "freshest" HSTS Policy information on behalf of an HSTS Host. 563 Specifying a zero time duration signals to the UA to delete the HSTS 564 policy for that HSTS host. 566 Section 6.2 presents examples of Strict-Transport-Security HTTP 567 response header fields. 569 6. Syntax 571 This section defines the syntax of the new header this specification 572 introduces. It also provides a short description of the function the 573 header. 575 The Section 7 "Server Processing Model" section details how hosts are 576 to use this header. Likewise, the Section 8 "User Agent Processing 577 Model" section details how user agents are to use this header. 579 6.1. Strict-Transport-Security HTTP Response Header Field 581 The Strict-Transport-Security HTTP response header field (STS header 582 field) indicates to a UA that it MUST enforce the HSTS Policy in 583 regards to the host emitting the response message containing this 584 header field. 586 The ABNF syntax for the STS header field is: 588 Strict-Transport-Security = "Strict-Transport-Security" ":" 589 *( ";" [ directive ] ) 591 directive = token [ "=" ( token | quoted-string ) ] 593 where: 595 token = 596 quoted-string = 598 The two directives defined in this specification are described below. 599 The overall requirements for directives are: 601 o The order of appearance of directives is not significant. 603 o All directives MUST appear only once in an STS header field. 605 o Directive names are case-insensitive. 607 o UAs MUST ignore any STS header fields containing directives that 608 do not conform to their ABNF definition. 610 Additional directives extending the the semantic functionality of the 611 STS header field may be defined in other specifications (which 612 "update" this specification), using the STS directive extension 613 point. 615 6.1.1. The max-age Directive 617 The REQUIRED max-age directive specifies the number of seconds, after 618 the reception of the STS header field, during which the UA regards 619 the host, from whom the message was received, as a Known HSTS Host 620 (see also Section 8.1.1 "Noting a HSTS Host", below). The delta- 621 seconds production is specified in [RFC2616]. 623 The syntax of the max-age directive is defined as: 625 max-age = "max-age" "=" delta-seconds 627 delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2> 629 Note: A max-age value of zero signals the UA to cease regarding the 630 host as a Known HSTS Host. 632 6.1.2. The includeSubDomains Directive 634 The OPTIONAL includeSubDomains directive is a flag which, if present, 635 signals to the UA that the HSTS Policy applies to this HSTS Host as 636 well as any subdomains of the host's domain name. 638 The syntax of the includeSubDomains directive is defined as: 640 includeSubDomains = "includeSubDomains" 642 6.2. Examples 644 The below HSTS header field stipulates that the HSTS policy is to 645 remain in effect for one year (there are approximately 31 536 000 646 seconds in a year), and the policy applies only to the domain of the 647 HSTS Host issuing it: 649 Strict-Transport-Security: max-age=31536000 651 The below HSTS header field stipulates that the HSTS policy is to 652 remain in effect for approximately six months and the policy applies 653 only to the domain of the issuing HSTS Host and all of its 654 subdomains: 656 Strict-Transport-Security: max-age=15768000 ; includeSubDomains 658 7. Server Processing Model 660 This section describes the processing model that HSTS Hosts 661 implement. The model is comprised of two facets: the first being the 662 processing rules for HTTP request messages received over a secure 663 transport (e.g., TLS [RFC5246], SSL [I-D.ietf-tls-ssl-version3], or 664 perhaps others), the second being the processing rules for HTTP 665 request messages received over non-secure transports, i.e. over 666 TCP/IP. 668 7.1. HTTP-over-Secure-Transport Request Type 670 When replying to an HTTP request that was conveyed over a secure 671 transport, a HSTS Host SHOULD include in its response message a STS 672 header field that MUST satisfy the grammar specified above in 673 Section 6.1 "Strict-Transport-Security HTTP Response Header Field". 674 If a STS header field is included, the HSTS Host MUST include only 675 one such header field. 677 Note: Including the STS header field is stipulated as a "SHOULD" in 678 order to accommodate various server- and network-side caches 679 and load-balancing configurations where it may be difficult to 680 uniformly emit STS header fields on behalf of a given HSTS 681 Host. 683 Establishing a given host as a Known HSTS Host, in the context 684 of a given UA, MAY be accomplished over the HTTP protocol by 685 correctly returning, per this specification, at least one 686 valid STS header field to the UA. Other mechanisms, such as a 687 client-side pre-loaded Known HSTS Host list MAY also be used. 688 E.g., see Section 11 "User Agent Implementation Advice". 690 7.2. HTTP Request Type 692 If a HSTS Host receives a HTTP request message over a non-secure 693 transport, it SHOULD send a HTTP response message containing a 694 Status-Code of 301 and a Location header field value containing 695 either the HTTP request's original Effective Request URI (see 696 Section 12 "Constructing an Effective Request URI", below) altered as 697 necessary to have a URI scheme of "https", or a URI generated 698 according to local policy (which SHOULD employ a URI scheme of 699 "https"). 701 Note: The above behavior is a "SHOULD" rather than a "MUST" because: 703 * There are risks in server-side non-secure-to-secure redirects 704 [owaspTLSGuide]. 706 * Site deployment characteristics -- e.g., a site that 707 incorporates third-party components may not behave correctly 708 when doing server-side non-secure-to-secure redirects in the 709 case of being accessed over non-secure transport, but does 710 behave correctly when accessed uniformly over secure transport. 711 The latter is the case given a HSTS-capable UA that has already 712 noted the site as a Known HSTS Host (by whatever means, e.g., 713 prior interaction or UA configuration). 715 A HSTS Host MUST NOT include the STS header field in HTTP responses 716 conveyed over non-secure transport. 718 8. User Agent Processing Model 720 This section describes the HTTP Strict Transport Security processing 721 model for UAs. There are several facets to the model, enumerated by 722 the following subsections. 724 This processing model assumes that the UA implements IDNA2008 725 [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 13 726 "Internationalized Domain Names for Applications (IDNA): Dependency 727 and Migration". It also assumes that all domain names manipulated in 728 this specification's context are already IDNA-canonicalized as 729 outlined in Section 9 "Domain Name IDNA-Canonicalization" prior to 730 the processing specified in this section. 732 The above assumptions mean that this processing model also 733 specifically assumes that appropriate IDNA and Unicode validations 734 and character list testing have occurred on the domain names, in 735 conjunction with their IDNA-canonicalization, prior to the processing 736 specified in this section. See the IDNA-specific security 737 considerations in Section 14.8 "Internationalized Domain Names" for 738 rationale and further details. 740 8.1. Strict-Transport-Security Response Header Field Processing 742 If an HTTP response, received over a secure transport, includes a STS 743 header field, conforming to the grammar specified in Section 6.1 744 "Strict-Transport-Security HTTP Response Header Field" (above), and 745 there are no underlying secure transport errors or warnings (see 746 Section 8.3, below), the UA MUST either: 748 o Note the host as a Known HSTS Host if it is not already so noted 749 (see Section 8.1.1 "Noting a HSTS Host", below), 751 or, 753 o Update its cached information for the Known HSTS Host if the max- 754 age and/or includeSubDomains header field value tokens are 755 conveying information different than that already maintained by 756 the UA. 758 Note: The max-age value is essentially a "time to live" value 759 relative to the reception time of the STS header field. 761 If the max-age header field value token has a value of zero, 762 the UA MUST remove its cached HSTS Policy information if the 763 HSTS Host is known, or, MUST NOT note this HSTS Host if it is 764 not yet known. 766 If a UA receives more than one STS header field in a HTTP 767 response message over secure transport, then the UA MUST 768 process only the first such header field. 770 Otherwise: 772 o If an HTTP response is received over insecure transport, the UA 773 MUST ignore any present STS header field(s). 775 o The UA MUST ignore any STS header fields not conforming to the 776 grammar specified in Section 6.1 "Strict-Transport-Security HTTP 777 Response Header Field" (above). 779 8.1.1. Noting a HSTS Host 781 If the substring matching the host production from the Request-URI, 782 that the host responded to, syntactically matches the IP-literal or 783 IPv4address productions from section 3.2.2 of [RFC3986], then the UA 784 MUST NOT note this host as a Known HSTS Host. 786 Otherwise, if the substring does not congruently match a presently 787 known HSTS Host, per the matching procedure specified in 788 Section 8.1.2 "Known HSTS Host Domain Name Matching" below, then the 789 UA MUST note this host as a Known HSTS Host, caching the HSTS Host's 790 domain name and noting along with it the expiry time of this 791 information, as effectively stipulated per the given max-age value, 792 as well as whether the includeSubDomains flag is asserted or not. 794 8.1.2. Known HSTS Host Domain Name Matching 796 A UA determines whether a domain name represents a Known HSTS Host by 797 looking for a match between the query Domain Name and the UA's set of 798 Known HSTS Hosts. 800 1. Compare the query domain name string with the Domain Names of the 801 UA's set of Known HSTS Hosts. For each Known HSTS Host's domain 802 name, the comparison is done with the query domain name label-by- 803 label using an ASCII case-insensitive comparison beginning with 804 the rightmost label, and continuing right-to-left, and ignoring 805 separator characters (see clause 3.1(4) of [RFC3986]. 807 * If a label-for-label match between an entire Known HSTS Host's 808 domain name and a right-hand portion of the query domain name 809 is found, then the Known HSTS Host's domain name is a 810 superdomain match for the query domain name. 812 For example: 814 Query Domain Name: bar.foo.example.com 816 Superdomain matched 817 Known HSTS Host DN: foo.example.com 819 At this point, the query domain name is ascertained to 820 effectively represent a Known HSTS Host. There may also be 821 additional matches further down the domain name label tree, up 822 to and including a congruent match. 824 * If a label-for-label match between a Known HSTS Host's domain 825 name and the query domain name is found, i.e. there are no 826 further labels to compare, then the query domain name 827 congruently matches this Known HSTS Host. 829 For example: 831 Query Domain Name: foo.example.com 833 Congruently matched 834 Known HSTS Host DN: foo.example.com 836 The query domain name is ascertained to represent a Known HSTS 837 Host. However, if there are also superdomain matches, the one 838 highest in the tree asserts the HSTS Policy for this Known 839 HSTS Host. 841 * Otherwise, if no matches are found, the query domain name does 842 not represent a Known HSTS Host. 844 8.2. URI Loading and Port Mapping 846 Whenever the UA prepares to "load", also known as "dereference", any 847 URI where the host component of the authority component of the URI 848 [RFC3986] matches that of a Known HSTS Host (either as a congruent 849 match or as a superdomain match where the superdomain Known HSTS Host 850 has includeSubDomains asserted), then before proceeding with the 851 load: 853 If the URI's scheme is "http", then the UA MUST replace the URI 854 scheme with "https" [RFC2818], and, 856 if the URI contains an explicit port component [RFC3986] of 857 "80", then the UA MUST convert the port component to be "443", 858 or, 860 if the URI contains an explicit port component that is not 861 equal to "80", the port component value MUST be preserved, 862 otherwise, 864 if the URI does not contain an explicit port component, the UA 865 MUST NOT add one. 867 Otherwise, if the URI's scheme is "https", then the UA MUST NOT 868 modify the URI before dereferencing it. 870 Note that the implication of the above steps is that the HSTS policy 871 applies to all TCP ports on a host advertising the HSTS policy. 873 8.3. Errors in Secure Transport Establishment 875 When connecting to a Known HSTS Host, the UA MUST terminate the 876 connection (see also Section 11 "User Agent Implementation Advice", 877 below) if there are any errors (e.g., certificate errors), whether 878 "warning" or "fatal" or any other error level, with the underlying 879 secure transport. This includes any issues with certificate 880 revocation checking whether via the Certificate Revocation List (CRL) 881 [RFC5280], or via the Online Certificate Status Protocol (OCSP) 882 [RFC2560]. 884 8.4. HTTP-Equiv Element Attribute 886 UAs MUST NOT heed http-equiv="Strict-Transport-Security" attribute 887 settings on elements in received content. 889 8.5. Interstitially Missing Strict-Transport-Security Response Header 890 Field 892 If a UA receives HTTP responses from a Known HSTS Host over a secure 893 channel, but they are missing the STS header field, the UA MUST 894 continue to treat the host as a Known HSTS Host until the max-age 895 value for the knowledge that Known HSTS Host is reached. Note that 896 the max age could be infinite for a given Known HSTS Host. For 897 example, if the Known HSTS Host is part of a pre-configured list that 898 is implemented such that the list entries never "age out". 900 9. Domain Name IDNA-Canonicalization 902 An IDNA-canonicalized domain name is the string generated by the 903 following algorithm, whose input must be a valid Unicode-encoded (in 904 NFC form [Unicode6]) string-serialized domain name: 906 1. Convert the domain name to a sequence of individual domain name 907 label strings. 909 2. When implementing IDNA2008, convert each label that is not a Non- 910 Reserved LDH (NR-LDH) label, to an A-label. See Section 2.3.2 of 911 [RFC5890] for definitions of the former and latter, refer to 912 Sections 5.3 through 5.5 of [RFC5891] for the conversion 913 algorithm and requisite input validation and character list 914 testing procedures. 916 Otherwise, when implementing IDNA2003, convert each label using 917 the "ToASCII" conversion in Section 4 of [RFC3490] (see also the 918 definition of "equivalence of labels" in Section 2 of the latter 919 specification). 921 3. Concatenate the resulting labels, separating each label from the 922 next with (".") a %x2E character. 924 See also Section 13 "Internationalized Domain Names for Applications 925 (IDNA): Dependency and Migration" and Section 14.8 "Internationalized 926 Domain Names" of this specification for further details and 927 considerations. 929 10. Server Implementation and Deployment Advice 931 This section is non-normative. 933 10.1. HSTS Policy expiration time considerations 935 Server implementations and deploying web sites need to consider 936 whether they are setting an expiry time that is a constant value into 937 the future, e.g., by constantly sending the same max-age value to 938 UAs. 940 For example, a max-age value of 778000 is 90 days: 942 Strict-Transport-Security: max-age=778000 944 Note that each receipt of this header by a UA will require the UA to 945 update its notion of when it must delete its knowledge of this Known 946 HSTS Host. The specifics of how this is accomplished is out of the 947 scope of this specification. 949 Or, whether they are setting an expiry time that is a fixed point in 950 time, e.g., by sending max-age values that represent the remaining 951 time until the expiry time. 953 A consideration here is whether a deployer wishes to have the 954 signaled HSTS Policy expiry time match that for the web site's domain 955 certificate. 957 Additionally, server implementers should consider employing a default 958 max-age value of zero in their deployment configuration systems. 959 This will require deployers to wilfully set max-age in order to have 960 UAs enforce the HSTS Policy for their host, and protects them from 961 inadvertently enabling HSTS with some arbitrary non-zero duration. 963 10.2. Using HSTS in conjunction with self-signed public-key 964 certificates 966 If a web site/organization/enterprise is generating their own secure 967 transport public-key certificates for web sites, and that 968 organization's root certification authority (CA) certificate is not 969 typically embedded by default in browser CA certificate stores, and 970 if HSTS Policy is enabled on a site identifying itself using a self- 971 signed certificate, then secure connections to that site will fail, 972 per the HSTS design. This is to protect against various active 973 attacks, as discussed above. 975 However, if said organization strongly wishes to employ self-signed 976 certificates, and their own CA in concert with HSTS, they can do so 977 by deploying their root CA certificate to their users' browsers. 978 They can also, in addition or instead, distribute to their users' 979 browsers the end-entity certificate(s) for specific hosts. There are 980 various ways in which this can be accomplished (details are out of 981 scope for this specification). Once their root CA certificate is 982 installed in the browsers, they may employ HSTS Policy on their 983 site(s). 985 Note: Interactively distributing root CA certificates to users, 986 e.g., via email, and having the users install them, is 987 arguably training the users to be susceptible to a possible 988 form of phishing attack, see Section 14.6 "Bogus Root CA 989 Certificate Phish plus DNS Cache Poisoning Attack". 991 10.3. Implications of includeSubDomains 993 The includeSubDomains directive has some practical implications -- 994 for example, if a HSTS Host offers HTTP-based services on various 995 ports or at various subdomains of its host domain name, then they 996 will all have to be available over secure transport in order to work 997 properly. 999 For example, certification authorities often offer their CRL 1000 distribution and OCSP services over plain HTTP, and sometimes at a 1001 subdomain of a publicly-available web application which may be 1002 secured by TLS/SSL. For example, is a 1003 publicly-available web application for "Example CA", a certification 1004 authority. Customers use this web application to register their 1005 public keys and obtain certificates. Example CA generates 1006 certificates for customers containing 1007 as the value for the "CRL 1008 Distribution Points" and "Authority Information Access:OCSP" 1009 certificate fields. 1011 If example-ca.com were to issue an HSTS Policy with the 1012 includeSubDomains directive, then HTTP-based user agents implementing 1013 HSTS, and that have interacted with the example-ca.com web 1014 application, would fail to retrieve CRLs and fail to check OCSP for 1015 certificates because these services are offered over plain HTTP. 1017 In this case, Example CA can either: 1019 o not use the includeSubDomains directive, or, 1021 o ensure HTTP-based services offered at subdomains of example-ca.com 1022 are uniformly offered over TLS/SSL, or, 1024 o offer plain HTTP-based services at a different domain name, e.g., 1025 example-ca-services.net. 1027 11. User Agent Implementation Advice 1029 This section is non-normative. 1031 In order to provide users and web sites more effective protection, as 1032 well as controls for managing their UA's caching of HSTS Policy, UA 1033 implementors should consider including features such as: 1035 11.1. No User Recourse 1037 Failing secure connection establishment on any warnings or errors 1038 (per Section 8.3 "Errors in Secure Transport Establishment"), should 1039 be done with "no user recourse". This means that the user should not 1040 be presented with an explanatory dialog giving her the option to 1041 proceed. Rather, it should be treated similarly to a server error 1042 where there is nothing further the user can do with respect to 1043 interacting with the target web application, other than wait and re- 1044 try. 1046 Essentially, "any warnings or errors" means anything that would cause 1047 the UA implementation to annunciate to the user that something is not 1048 entirely correct with the connection establishment. 1050 Not doing this, i.e., allowing user recourse such as "clicking- 1051 through warning/error dialogs", is a recipe for a Man-in-the-Middle 1052 attack. If a web application advertises HSTS, then it is opting into 1053 this scheme, whereby all certificate errors or warnings cause a 1054 connection termination, with no chance to "fool" the user into making 1055 the wrong decision and compromising themselves. 1057 11.2. User-declared HSTS Policy 1059 Ability for users to explicitly declare a given Domain Name as 1060 representing a HSTS Host, thus seeding it as a Known HSTS Host before 1061 any actual interaction with it. This would help protect against the 1062 Section 14.4 "Bootstrap MITM Vulnerability". 1064 Note: Such a feature is difficult to get right on a per-site basis 1065 -- see the discussion of "rewrite rules" in section 5.5 of 1066 [ForceHTTPS]. For example, arbitrary web sites may not 1067 materialize all their URIs using the "https" scheme, and thus 1068 could "break" if a UA were to attempt to access the site 1069 exclusively using such URIs. Also note that this feature 1070 would complement, but is independent of the following 1071 described facility. 1073 11.3. HSTS Pre-Loaded List 1075 Facility whereby web site administrators can have UAs pre-configured 1076 with HSTS Policy for their site(s) by the UA vendor(s) -- a so-called 1077 "pre-loaded list" -- in a manner similar to how root CA certificates 1078 are embedded in browsers "at the factory". This would help protect 1079 against the Section 14.4 "Bootstrap MITM Vulnerability". 1081 Note: Such a facility would complement a "User-declared HSTS Policy" 1082 feature. 1084 11.4. Disallow Mixed Security Context 1086 Disallowing "mixed security context" (also known as "mixed content") 1087 loads (see section 5.3 "Mixed Content" in [W3C.REC-wsc-ui-20100812]). 1089 Note: In order to provide behavioral uniformity across UA 1090 implementations, the notion of mixed security context will 1091 require further standardization work, e.g., to more clearly 1092 define the term(s) and to define specific behaviors with 1093 respect to it. 1095 11.5. HSTS Policy Deletion 1097 Ability to delete UA's cached HSTS Policy on a per HSTS Host basis. 1099 Note: Adding such a feature should be done very carefully in both 1100 the user interface and security senses. Deleting a cache 1101 entry for a Known HSTS Host should be a very deliberate and 1102 well-considered act -- it shouldn't be something users get 1103 used to just "clicking through" in order to get work done. 1104 Also, it shouldn't be possible for an attacker to inject 1105 script into the UA that silently and programmatically removes 1106 entries from the UA's cache of Known HSTS Hosts. 1108 12. Constructing an Effective Request URI 1110 This section specifies how an HSTS Host must construct the Effective 1111 Request URI for a received HTTP request. 1113 HTTP requests often do not carry an absoluteURI for the target 1114 resource; instead, the URI needs to be inferred from the Request-URI, 1115 Host header field, and connection context ([RFC2616], Sections 3.2.1 1116 and 5.1.2). The result of this process is called the "effective 1117 request URI (ERU)". The "target resource" is the resource identified 1118 by the effective request URI. 1120 12.1. ERU Fundamental Definitions 1122 The first line of an HTTP request message, Request-Line, is specified 1123 by the following ABNF from [RFC2616], section 5.1: 1125 Request-Line = Method SP Request-URI SP HTTP-Version CRLF 1127 The Request-URI, within the Request-Line, is specified by the 1128 following ABNF from [RFC2616], section 5.1.2: 1130 Request-URI = "*" | absoluteURI | abs_path | authority 1132 The Host request header field is specified by the following ABNF from 1133 [RFC2616], section 14.23: 1135 Host = "Host" ":" host [ ":" port ] 1137 12.2. Determining the Effective Requrest URI 1139 If the Request-URI is an absoluteURI, then the effective request URI 1140 is the Request-URI. 1142 If the Request-URI uses the abs_path form or the asterisk form, and 1143 the Host header field is present, then the effective request URI is 1144 constructed by concatenating: 1146 o the scheme name: "http" if the request was received over an 1147 insecure TCP connection, or "https" when received over a TLS/ 1148 SSL-secured TCP connection, and, 1150 o the octet sequence "://", and, 1152 o the host, and the port (if present), from the Host header field, 1153 and 1155 o the Request-URI obtained from the Request-Line, unless the 1156 Request-URI is just the asterisk "*". 1158 If the Request-URI uses the abs_path form or the asterisk form, and 1159 the Host header field is not present, then the effective request URI 1160 is undefined. 1162 Otherwise, when Request-URI uses the authority form, the effective 1163 request URI is undefined. 1165 Effective request URIs are compared using the rules described in 1166 [RFC2616] Section 3.2.3, except that empty path components MUST NOT 1167 be treated as equivalent to an absolute path of "/". 1169 12.2.1. Effective Requrest URI Examples 1171 Example 1: the effective request URI for the message 1173 GET /pub/WWW/TheProject.html HTTP/1.1 1174 Host: www.example.org:8080 1176 (received over an insecure TCP connection) is "http", plus "://", 1177 plus the authority component "www.example.org:8080", plus the 1178 request-target "/pub/WWW/TheProject.html". Thus it is: 1179 "http://www.example.org:8080/pub/WWW/TheProject.html". 1181 Example 2: the effective request URI for the message 1183 OPTIONS * HTTP/1.1 1184 Host: www.example.org 1186 (received over an SSL/TLS secured TCP connection) is "https", plus 1187 "://", plus the authority component "www.example.org". Thus it is: 1188 "https://www.example.org". 1190 13. Internationalized Domain Names for Applications (IDNA): Dependency 1191 and Migration 1193 Textual domain names on the modern Internet may contain one or more 1194 "internationalized" domain name labels. Such domain names are 1195 referred to as "internationalized domain names" (IDNs). The 1196 specification suites defining IDNs and the protocols for their use 1197 are named "Internationalized Domain Names for Applications (IDNA)". 1198 At this time, there are two such specification suites: IDNA2008 1199 [RFC5890] and its predecessor IDNA2003 [RFC3490]. 1201 IDNA2008 obsoletes IDNA2003, but there are differences between the 1202 two specifications, and thus there can be differences in processing 1203 (e.g., converting) domain name labels that have been registered under 1204 one from those registered under the other. There will be a 1205 transition period of some time during which IDNA2003-based domain 1206 name labels will exist in the wild. User agents SHOULD implement 1207 IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of 1208 [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. 1209 If a user agent does not implement IDNA2008, the user agent MUST 1210 implement IDNA2003. 1212 14. Security Considerations 1213 14.1. Ramifications of HSTS Policy Establishment only over Error-free 1214 Secure Transport 1216 The User Agent Processing Model defined in Section 8, stipulates that 1217 a host is initially noted as a Known HSTS Host, or that updates are 1218 made to a Known HSTS Host's cached information, only if the UA 1219 receives the STS header field over a secure transport connection 1220 having no underlying secure transport errors or warnings. 1222 The rationale behind this is that if there is a man-in-the-middle 1223 (MITM) -- whether a legitimately deployed proxy or an illegitimate 1224 entity -- it could cause various mischief (see also Appendix A 1225 "Design Decision Notes", item 3, as well as Section 14.4 "Bootstrap 1226 MITM Vulnerability" ), for example: 1228 o Unauthorized notation of the host as a Known HSTS Host, 1229 potentially leading to a denial of service situation if the host 1230 does not uniformly offer its services over secure transport (see 1231 also Section 14.3 "Denial of Service". 1233 o Resetting the time-to-live for the host's designation as a Known 1234 HSTS Host by manipulating the max-age header field parameter value 1235 that is returned to the UA. If max-age is returned as zero, this 1236 will cause the host to no longer be regarded as an Known HSTS Host 1237 by the UA, leading to either insecure connections to the host or 1238 possibly denial-of-service if the host delivers its services only 1239 over secure transport. 1241 However, this means that if a UA is "behind" a proxy -- within a 1242 corporate intranet, for example -- and interacts with an unknown HSTS 1243 Host beyond the proxy, the user will possibly be presented with the 1244 legacy secure connection error dialogs. And even if the risk is 1245 accepted and the user clicks-through, the host will not be noted as a 1246 HSTS Host. Thus as long as the UA is behind such a proxy the user 1247 will be vulnerable, and possibly be presented with the legacy secure 1248 connection error dialogs for as yet unknown HSTS Hosts. 1250 But once the UA successfully connects to an unknown HSTS Host over 1251 error-free secure transport, the host will be noted as a Known HSTS 1252 Host. This will result in the failure of subsequent connection 1253 attempts from behind interfering proxies. 1255 The above discussion relates to the recommendation in Section 11 1256 "User Agent Implementation Advice" that the secure connection be 1257 terminated with "no user recourse" whenever there are warnings and 1258 errors and the host is a Known HSTS Host. Such a posture protects 1259 users from "clicking through" security warnings and putting 1260 themselves at risk. 1262 14.2. The Need for includeSubDomains 1264 Without the includeSubDomains directive, a web application would not 1265 be able to adequately protect so-called "domain cookies" (even if 1266 these cookies have their "Secure" flag set and thus are conveyed only 1267 on secure channels). These are cookies the web application expects 1268 UAs to return to any and all subdomains of the web application. 1270 For example, suppose example.com represents the top-level DNS name 1271 for a web application. Further suppose that this cookie is set for 1272 the entire example.com domain, i.e. it is a "domain cookie", and it 1273 has its Secure flag set. Suppose example.com is a Known HSTS Host 1274 for this UA, but the includeSubDomains flag is not set. 1276 Now, if an attacker causes the UA to request a subdomain name that is 1277 unlikely to already exist in the web application, such as 1278 "https://uxdhbpahpdsf.example.com/", but the attacker has established 1279 somewhere and registered in the DNS, then: 1281 1. The UA is unlikely to already have an HSTS policy established for 1282 "uxdhbpahpdsf.example.com", and, 1284 2. The HTTP request sent to uxdhbpahpdsf.example.com will include 1285 the Secure-flagged domain cookie. 1287 3. If "uxdhbpahpdsf.example.com" returns a certificate during TLS 1288 establishment, and the user clicks through any warning that might 1289 be annunciated (it is possible, but not certain, that one may 1290 obtain a requisite certificate for such a domain name such that a 1291 warning may or may not appear), then the attacker can obtain the 1292 Secure-flagged domain cookie that's ostensibly being protected. 1294 Without the "includeSubDomains" directive, HSTS is unable to protect 1295 such Secure-flagged domain cookies. 1297 14.3. Denial of Service 1299 HSTS could be used to mount certain forms of Denial-of- Service (DoS) 1300 attacks against web sites. A DoS attack is an attack in which one or 1301 more network entities target a victim entity and attempt to prevent 1302 the victim from doing useful work. This section discusses such 1303 scenarios in terms of HSTS, though this list is not exhaustive. See 1304 also [RFC4732] for a discussion of overall Internet DoS 1305 considerations. 1307 o Web applications available over HTTP 1309 There is an opportunity for perpetrating DoS attacks with web 1310 applications that are -- or critical portions of them are -- 1311 available only over HTTP without secure transport, if attackers 1312 can cause UAs to set HSTS Policy for such web applications' 1313 host(s). 1315 This is because once the HSTS Policy is set for a web 1316 application's host in a UA, the UA will only use secure transport 1317 to communicate with the host. If the host is not using secure 1318 transport, or is not for critical portions of its web application, 1319 then the web application will be rendered unusable for the UA's 1320 user. 1322 An HSTS Policy can be set for a victim host in various ways: 1324 * If the web application has a HTTP response splitting 1325 vulnerability [CWE-113] (which can be abused in order to 1326 facilitate "HTTP Header Injection"). 1328 * If an attacker can spoof a redirect from an insecure victim 1329 site, e.g., to , 1330 where the latter is attacker-controlled and has an apparently 1331 valid certificate, then the attacker can set an HSTS Policy for 1332 example.com, and also for all subdomains of example.com. 1334 * If an attacker can convince users to manually configure HSTS 1335 Policy for a victim host, assuming their UAs offer this 1336 capability (see Section 11 "User Agent Implementation Advice"). 1337 Or if such UA configuration is scriptable, and the attacker can 1338 cause UAs to execute his script. 1340 o Inadvertent use of includeSubDomains 1342 The includeSubDomains directive instructs UAs to automatically 1343 regard all subdomains of the given HSTS Host as Known HSTS Hosts. 1344 If any such subdomains do not support properly configured secure 1345 transport, then they will be rendered unreachable from such UAs. 1347 14.4. Bootstrap MITM Vulnerability 1349 The bootstrap MITM (Man-In-The-Middle) vulnerability is a 1350 vulnerability users and HSTS Hosts encounter in the situation where 1351 the user manually enters, or follows a link, to an unknown HSTS Host 1352 using a "http" URI rather than a "https" URI. Because the UA uses an 1353 insecure channel in the initial attempt to interact with the 1354 specified server, such an initial interaction is vulnerable to 1355 various attacks [ForceHTTPS] . 1357 Note: There are various features/facilities that UA implementations 1358 may employ in order to mitigate this vulnerability. Please 1359 see Section 11 "User Agent Implementation Advice". 1361 14.5. Network Time Attacks 1363 Active network attacks can subvert network time protocols (such as 1364 NTP) - making HSTS less effective against clients that trust NTP or 1365 lack a real time clock. Network time attacks are beyond the scope of 1366 this specification. Note that modern operating systems use NTP by 1367 default. See also section 2.10 of [RFC4732]. 1369 14.6. Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack 1371 If an attacker can convince users of, say, https://bank.example.com 1372 (which is protected by HSTS Policy), to install their own version of 1373 a root CA certificate purporting to be bank.example.com's CA, e.g., 1374 via a phishing email message with a link to such a certificate. 1375 Then, if they can perform an attack on the users' DNS, (e.g., via 1376 cache poisoning) and turn on HSTS Policy for their fake 1377 bank.example.com site, then they have themselves some new users. 1379 14.7. Creative Manipulation of HSTS Policy Store 1381 Since an HSTS Host may select its own host name and subdomains 1382 thereof, and this information is cached in the HSTS Policy store of 1383 conforming UAs, it is possible for those who control a HSTS Host(s) 1384 to encode information into domain names they control and cause such 1385 UAs to cache this information as a matter of course in the process of 1386 noting the HSTS Host. This information can be retrieved by other 1387 hosts through clever loaded page construction causing the UA to send 1388 queries to (variations of) the encoded domain names. Such queries 1389 can reveal whether the UA had prior visited the original HSTS Host 1390 (and subdomains). 1392 Such a technique could potentially be abused as yet another form of 1393 "web tracking" [WebTracking]. 1395 14.8. Internationalized Domain Names 1397 Internet security relies in part on the DNS and the domain names it 1398 hosts. Domain names are used by users to identify and connect to 1399 Internet hosts and other network resources. For example, Internet 1400 security is compromised if a user entering an internationalized 1401 domain name (IDN) is connected to different hosts based on different 1402 interpretations of the IDN. 1404 The processing models specified in this specification assume that the 1405 domain names they manipulate are IDNA-canonicalized, and that the 1406 canonicalization process correctly performed all appropriate IDNA and 1407 Unicode validations and character list testing per the requisite 1408 specifications (e.g., as noted in Section 9 "Domain Name IDNA- 1409 Canonicalization"). These steps are necessary in order to avoid 1410 various potentially compromising situations. 1412 In brief, some examples of issues that could stem from lack of 1413 careful and consistent Unicode and IDNA validations are things such 1414 as unexpected processing exceptions, truncation errors, and buffer 1415 overflows, as well as false-positive and/or false-negative domain 1416 name matching results. Any of the foregoing issues could possibly be 1417 leveraged by attackers in various ways. 1419 Additionally, IDNA2008 [RFC5890] differs from IDNA2003 [RFC3490] in 1420 terms of disallowed characters and character mapping conventions. 1421 This situation can also lead to false-positive and/or false-negative 1422 domain name matching results, resulting in, for example, users 1423 possibly communicating with unintended hosts, or not being able to 1424 reach intended hosts. 1426 For details, refer to the Security Considerations sections of 1427 [RFC5890], [RFC5891], and [RFC3490], as well as the specifications 1428 they normatively reference. Additionally, [RFC5894] provides 1429 detailed background and rationale for IDNA2008 in particular, as well 1430 as IDNA and its issues in general, and should be consulted in 1431 conjunction with the former specifications. 1433 15. IANA Considerations 1435 Below is the Internet Assigned Numbers Authority (IANA) Provisional 1436 Message Header Field registration information per [RFC3864]. 1438 Header field name: Strict-Transport-Security 1439 Applicable protocol: HTTP 1440 Status: provisional 1441 Author/Change controller: TBD 1442 Specification document(s): this one 1444 16. References 1446 16.1. Normative References 1448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1449 Requirement Levels", BCP 14, RFC 2119, March 1997. 1451 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1452 Adams, "X.509 Internet Public Key Infrastructure Online 1453 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1455 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1456 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1457 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1459 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1461 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1462 "Internationalizing Domain Names in Applications (IDNA)", 1463 RFC 3490, March 2003. 1465 This specification is referenced due to its ongoing 1466 relevance to actual deployments for the forseeable future. 1468 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1469 for Internationalized Domain Names in Applications 1470 (IDNA)", RFC 3492, March 2003. 1472 This specification is referenced due to its ongoing 1473 relevance to actual deployments for the forseeable future. 1475 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1476 Procedures for Message Header Fields", BCP 90, RFC 3864, 1477 September 2004. 1479 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1480 Resource Identifier (URI): Generic Syntax", STD 66, 1481 RFC 3986, January 2005. 1483 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1484 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1486 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1487 Housley, R., and W. Polk, "Internet X.509 Public Key 1488 Infrastructure Certificate and Certificate Revocation List 1489 (CRL) Profile", RFC 5280, May 2008. 1491 [RFC5890] Klensin, J., "Internationalized Domain Names for 1492 Applications (IDNA): Definitions and Document Framework", 1493 RFC 5890, August 2010. 1495 [RFC5891] Klensin, J., "Internationalized Domain Names in 1496 Applications (IDNA): Protocol", RFC 5891, August 2010. 1498 [RFC5894] Klensin, J., "Internationalized Domain Names for 1499 Applications (IDNA): Background, Explanation, and 1500 Rationale", RFC 5894, August 2010. 1502 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 1503 Internationalized Domain Names in Applications (IDNA) 1504 2008", RFC 5895, September 2010. 1506 [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility 1507 Processing", Unicode Technical Standards # 46, 2010, 1508 . 1510 [Unicode6] 1511 The Unicode Consortium, "The Unicode Standard, Version 6.0 1512 - Core Specification", Unicode 6.0.0, Mountain View, CA, 1513 The Unicode Consortium ISBN 978-1-936213-01-6, 2011, 1514 . 1516 16.2. Informative References 1518 [Aircrack-ng] 1519 d'Otreppe, T., "Aircrack-ng", Accessed: 11-Jul-2010, 1520 . 1522 [BeckTews09] 1523 Beck, M. and E. Tews, "Practical Attacks Against WEP and 1524 WPA", Second ACM Conference on Wireless Network 1525 Security Zurich, Switzerland, 2009, . 1529 [CWE-113] "CWE-113: Improper Neutralization of CRLF Sequences in 1530 HTTP Headers ('HTTP Response Splitting')", Common Weakness 1531 Enumeration , The Mitre 1532 Corporation , 1533 . 1535 [Firesheep] 1536 Various, "Firesheep", Wikipedia Online, on-going, 1537 . 1540 [ForceHTTPS] 1541 Jackson, C. and A. Barth, "ForceHTTPS: Protecting High- 1542 Security Web Sites from Network Attacks", In Proceedings 1543 of the 17th International World Wide Web Conference 1544 (WWW2008) , 2008, 1545 . 1547 [GoodDhamijaEtAl05] 1548 Good, N., Dhamija, R., Grossklags, J., Thaw, D., 1549 Aronowitz, S., Mulligan, D., and J. Konstan, "Stopping 1550 Spyware at the Gate: A User Study of Privacy, Notice and 1551 Spyware", In Proceedings of Symposium On Usable Privacy 1552 and Security (SOUPS) Pittsburgh, PA, USA, July 2005, . 1556 [I-D.ietf-tls-ssl-version3] 1557 Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol 1558 Version 3.0", draft-ietf-tls-ssl-version3-00 (work in 1559 progress), November 1996, . 1562 [JacksonBarth2008] 1563 Jackson, C. and A. Barth, "Beware of Finer-Grained 1564 Origins", Web 2.0 Security and Privacy Oakland, CA, USA, 1565 2008, 1566 . 1569 [RFC1035] Mockapetris, P., "Domain names - implementation and 1570 specification", STD 13, RFC 1035, November 1987. 1572 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 1573 Service Considerations", RFC 4732, December 2006. 1575 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1576 RFC 4949, August 2007. 1578 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1579 April 2011. 1581 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1582 December 2011. 1584 [SunshineEgelmanEtAl09] 1585 Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and 1586 L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning 1587 Effectiveness", In Proceedings of 18th USENIX Security 1588 Symposium Montreal, Canada, Augus 2009, . 1592 [W3C.REC-wsc-ui-20100812] 1593 Saldhana, A. and T. Roessler, "Web Security Context: User 1594 Interface Guidelines", World Wide Web Consortium 1595 Recommendation REC-wsc-ui-20100812, August 2010, 1596 . 1598 [WEBSEC] "WebSec -- HTTP Application Security Minus Authentication 1599 and Transport", 1600 . 1602 Mailing list for IETF WebSec Working Group. [RFCEditor: 1603 please remove this reference upon publication as an RFC.] 1605 [WebTracking] 1606 Schmucker, N., "Web Tracking", SNET2 Seminar Paper Summer 1607 Term, 2011, . 1610 [owaspTLSGuide] 1611 Coates, M., Wichers, d., Boberski, M., and T. Reguly, 1612 "Transport Layer Protection Cheat Sheet", Accessed: 11- 1613 Jul-2010, . 1616 Appendix A. Design Decision Notes 1618 This appendix documents various design decisions. 1620 1. Cookies aren't appropriate for HSTS Policy expression as they are 1621 potentially mutable (while stored in the UA), therefore an HTTP 1622 header field is employed. 1624 2. We chose to not attempt to specify how "mixed security context 1625 loads" (aka "mixed content loads") are handled due to UA 1626 implementation considerations as well as classification 1627 difficulties. 1629 3. A HSTS Host may update UA notions of HSTS Policy via new HSTS 1630 header field parameter values. We chose to have UAs honor the 1631 "freshest" information received from a server because there is 1632 the chance of a web site sending out an errornous HSTS Policy, 1633 such as a multi-year max-age value, and/or an incorrect 1634 includeSubDomains flag. If the HSTS Host couldn't correct such 1635 errors over protocol, it would require some form of annunciation 1636 to users and manual intervention on the users' part, which could 1637 be a non-trivial problem for both web application providers and 1638 their users. 1640 4. HSTS Hosts are identified only via domain names -- explicit IP 1641 address identification of all forms is excluded. This is for 1642 simplification and also is in recognition of various issues with 1643 using direct IP address identification in concert with PKI-based 1644 security. 1646 Appendix B. Differences between HSTS Policy and Same-Origin Policy 1648 HSTS Policy has the following primary characteristics: 1650 HSTS Policy stipulates requirements for the security 1651 characteristics of UA-to-host connection establishment, on a per- 1652 host basis. 1654 Hosts explicitly declare HSTS Policy to UAs. Conformant UAs are 1655 obliged to implement hosts' declared HSTS Policies. 1657 HSTS Policy is conveyed over protocol from the host to the UA. 1659 The UA maintains a cache of Known HSTS Hosts. 1661 UAs apply HSTS Policy whenever making a HTTP connection to a Known 1662 HSTS Host, regardless of host port number. I.e., it applies to 1663 all ports on a Known HSTS Host. Hosts are unable to affect this 1664 aspect of HSTS Policy. 1666 Hosts may optionally declare that their HSTS Policy applies to all 1667 subdomains of their host domain name. 1669 In contrast, the Same-Origin Policy (SOP) [RFC6454] has the following 1670 primary characteristics: 1672 An origin is the scheme, host, and port of a URI identifying a 1673 resource. 1675 A UA may dereference a URI, thus loading a representation of the 1676 resource the URI identifies. UAs label resource representations 1677 with their origins, which are derived from their URIs. 1679 The SOP refers to a collection of principles, implemented within 1680 UAs, governing the isolation of and communication between resource 1681 representations within the UA, as well as resource 1682 representations' access to network resources. 1684 In summary, although both HSTS Policy and SOP are enforced by by UAs, 1685 HSTS Policy is optionally declared by hosts and is not origin-based, 1686 while the SOP applies to all resource representations loaded from all 1687 hosts by conformant UAs. 1689 Appendix C. Acknowledgments 1691 The authors thank Devdatta Akhawe, Michael Barrett, Paul Hoffman, 1692 Alexey Melnikov, Yoav Nir, Laksh Raghavan, Marsh Ray, Julian Reschke, 1693 Tom Ritter, Peter Saint-Andre, Sid Stamm, Maciej Stachowiak, Andy 1694 Steingrubl, Brandon Sterne, Martin Thomson, Daniel Veditz, as well as 1695 all the websec working group participants and others for their review 1696 and contributions. 1698 Thanks to Julian Reschke for his elegant re-writing of the effective 1699 request URI text, which he did when incorporating the ERU notion into 1700 the HTTPbis work. Subsequently, the ERU text in this spec was lifted 1701 from Julian's work in [I-D.draft-ietf-httpbis-p1-messaging-17] and 1702 adapted to the [RFC2616] ABNF. 1704 Appendix D. Change Log 1706 [RFCEditor: please remove this section upon publication as an RFC.] 1708 Changes are grouped by spec revision listed in reverse issuance 1709 order. 1711 D.1. For draft-ietf-websec-strict-transport-sec 1713 Changes from -04 to -05: 1715 1. Fixed up references to move certain ones back to the normative 1716 section -- as requested by Alexey M. Added explanation for 1717 referencing obsoleted [RFC3490] and [RFC3492]. This addresses 1718 issue ticket #36. 1719 1721 2. Made minor change to Strict-Transport-Security header field 1722 ABNF in order to address further feedback as appended to 1723 ticket #33. This addresses issue ticket #33. 1724 1726 Changes from -03 to -04: 1728 1. Clarified that max-age=0 will cause UA to forget a known HSTS 1729 host, and more generally clarified that the "freshest" info 1730 from the HSTS host is cached, and thus HSTS hosts are able to 1731 alter the cached max-age in UAs. This addresses issue ticket 1732 #13. 1734 2. Updated section on "Constructing an Effective Request URI" to 1735 remove remaining reference to RFC3986 and reference RFC2616 1736 instead. Further addresses issue ticket #14. 1737 1739 3. Addresses further ABNF issues noted in comment:1 of issue 1740 ticket #27. 1743 4. Reworked the introduction to clarify the denotation of "HSTS 1744 policy" and added the new Appendix B summarizing the primary 1745 characteristics of HSTS Policy and Same-Origin Policy, and 1746 identifying their differences. Added ref to [RFC4732]. This 1747 addresses issue ticket #28. 1748 1750 5. Reworked language in Section 2.3.1.3. wrt "mixed content", 1751 more clearly explain such vulnerability, disambiguate "mixed 1752 content" in web security context from its usage in markup 1753 language context. This addresses issue ticket #29. 1754 1756 6. Expanded Denial of Service discussion in Security 1757 Considerations. Added refs to [RFC4732] and [CWE-113]. This 1758 addresses issue ticket #30. 1759 1761 7. Mentioned in prose the case-insensitivity of directive names. 1762 This addresses issue ticket #31. 1763 1765 8. Added Section 10.3 "Implications of includeSubDomains". This 1766 addresses issue ticket #32. 1767 1769 9. Further refines text and ABNF definitions of STS header field 1770 directives. Retains use of quoted-string in directive 1771 grammar. This addresses issue ticket #33. 1772 1774 10. Added Section 14.7 "Creative Manipulation of HSTS Policy 1775 Store", including reference to [WebTracking]. This addresses 1776 issue ticket #34. 1777 1779 11. Added Section 14.1 "Ramifications of HSTS Policy 1780 Establishment only over Error-free Secure Transport" and made 1781 some accompanying editorial fixes in some other sections. 1782 This addresses issue ticket #35. 1783 1785 12. Refined references. Cleaned out un-used ones, updated to 1786 latest RFCs for others, consigned many to Informational. 1787 This addresses issue ticket #36. 1788 1790 13. Fixed-up some inaccuracies in the "Changes from -02 to -03" 1791 section. 1793 Changes from -02 to -03: 1795 1. Updated section on "Constructing an Effective Request URI" to 1796 remove references to RFC3986. Addresses issue ticket #14. 1797 1799 2. Reference RFC5890 for IDNA, retaining subordinate refs to 1800 RFC3490. Updated IDNA-specific language, e.g. domain name 1801 canonicalization and IDNA dependencies. Addresses issue 1802 ticket #26 1803 . 1805 3. Completely re-wrote the STS header ABNF to be fully based on 1806 RFC2616, rather than a hybrid of RFC2616 and httpbis. 1807 Addresses issue ticket #27 1808 . 1810 Changes from -01 to -02: 1812 1. Updated Section 8.2 "URI Loading and Port Mapping" fairly 1813 thoroughly in terms of refining the presentation of the 1814 steps, and to ensure the various aspects of port mapping are 1815 clear. Nominally fixes issue ticket #1 1816 1818 2. Removed dependencies on 1819 [I-D.draft-ietf-httpbis-p1-messaging-15]. Thus updated STS 1820 ABNF in Section 6.1 "Strict-Transport-Security HTTP Response 1821 Header Field" by lifting some productions entirely from 1822 [I-D.draft-ietf-httpbis-p1-messaging-15] and leveraging 1823 [RFC2616]. Addresses issue ticket #2 1824 . 1826 3. Updated Effective Request URI section and definition to use 1827 language from [I-D.draft-ietf-httpbis-p1-messaging-15] and 1828 ABNF from [RFC2616]. Fixes issue ticket #3 1829 . 1831 4. Added explicit mention that the HSTS policy applies to all 1832 TCP ports of a host advertising the HSTS policy. Nominally 1833 fixes issue ticket #4 1834 1836 5. Clarified the need for the "includeSubDomains" directive, 1837 e.g. to protect Secure-flagged domain cookies. In 1838 Section 14.2 "The Need for includeSubDomains". Nominally 1839 fixes issue ticket #5 1840 1842 6. Cited Firesheep as real-live threat in Section 2.3.1.1 1843 "Passive Network Attackers". Nominally fixes issue ticket #6 1844 . 1846 7. Added text to Section 11 "User Agent Implementation Advice" 1847 justifying connection termination due to tls warnings/errors. 1848 Nominally fixes issue ticket #7 1849 . 1851 8. Added new subsection Section 8.5 "Interstitially Missing 1852 Strict-Transport-Security Response Header Field". Nominally 1853 fixes issue ticket #8 1854 . 1856 9. Added text to Section 8.3 "Errors in Secure Transport 1857 Establishment" explicitly note revocation check failures as 1858 errors causing connection termination. Added references to 1859 [RFC5280] and [RFC2560]. Nominally fixes issue ticket #9 1860 . 1862 10. Added a sentence, noting that distributing specific end- 1863 entity certificates to browsers will also work for self- 1864 signed/private-CA cases, to Section 10 "Server Implementation 1865 and Deployment Advice" Nominally fixes issue ticket #10 1866 . 1868 11. Moved "with no user recourse" language from Section 8.3 1869 "Errors in Secure Transport Establishment" to Section 11 1870 "User Agent Implementation Advice". This nominally fixes 1871 issue ticket #11 1872 . 1874 12. Removed any and all dependencies on 1875 [I-D.draft-ietf-httpbis-p1-messaging-15], instead depending 1876 on [RFC2616] only. Fixes issue ticket #12 1877 . 1879 13. Removed the inline "XXX1" issue because no one had commented 1880 on it and it seems reasonable to suggest as a SHOULD that web 1881 apps should redirect incoming insecure connections to secure 1882 connections. 1884 14. Removed the inline "XXX2" issue because it was simply for 1885 raising consciousness about having some means for 1886 distributing secure web application metadata. 1888 15. Removed "TODO1" because description prose for "max-age" in 1889 the Note following the ABNF in Section 6 seems to be fine. 1891 16. Decided for "TODO2" that "the first STS header field wins". 1892 TODO2 had read: "Decide UA behavior in face of encountering 1893 multiple HSTS headers in a message. Use first header? 1894 Last?". Removed TODO2. 1896 17. Added Section 1.1 "Organization of this specification" for 1897 readers' convenience. 1899 18. Moved design decision notes to be a proper appendix 1900 Appendix A. 1902 Changes from -00 to -01: 1904 1. Changed the "URI Loading" section to be "URI Loading and Port 1905 Mapping". 1907 2. [HASMAT] reference changed to [WEBSEC]. 1909 3. Changed "server" -> "host" where applicable, notably when 1910 discussing "HSTS Hosts". Left as "server" when discussing 1911 e.g. "http server"s. 1913 4. Fixed minor editorial nits. 1915 Changes from draft-hodges-strict-transport-sec-02 to 1916 draft-ietf-websec-strict-transport-sec-00: 1918 1. Altered spec metadata (e.g. filename, date) in order to submit 1919 as a WebSec working group Internet-Draft. 1921 D.2. For draft-hodges-strict-transport-sec 1923 Changes from -01 to -02: 1925 1. updated abstract such that means for expressing HSTS Policy 1926 other than via HSTS header field is noted. 1928 2. Changed spec title to "HTTP Strict Transport Security (HSTS)" 1929 from "Strict Transport Security". Updated use of "STS" 1930 acronym throughout spec to HSTS (except for when specifically 1931 discussing syntax of Strict-Transport-Security HTTP Response 1932 Header field), updated "Terminology" appropriately. 1934 3. Updated the discussion of "Passive Network Attackers" to be 1935 more precise and offered references. 1937 4. Removed para on nomative/non-normative from "Conformance 1938 Criteria" pending polishing said section to IETF RFC norms. 1940 5. Added examples subsection to "Syntax" section. 1942 6. Added OWS to maxAge production in Strict-Transport-Security 1943 ABNF. 1945 7. Cleaned up explanation in the "Note:" in the "HTTP-over- 1946 Secure-Transport Request Type" section, folded 3d para into 1947 "Note:", added conformance clauses to the latter. 1949 8. Added exaplanatory "Note:" and reference to "HTTP Request 1950 Type" section. Added "XXX1" issue. 1952 9. Added conformance clause to "URI Loading". 1954 10. Moved "Notes for STS Server implementors:" from "UA 1955 Implementation dvice " to "HSTS Policy expiration time 1956 considerations:" in "Server Implementation Advice", and also 1957 noted another option. 1959 11. Added cautionary "Note:" to "Ability to delete UA's cached 1960 HSTS Policy on a per HSTS Server basis". 1962 12. Added some informative references. 1964 13. Various minor editorial fixes. 1966 Changes from -00 to -01: 1968 1. Added reference to HASMAT mailing list and request that this 1969 spec be discussed there. 1971 Authors' Addresses 1973 Jeff Hodges 1974 PayPal 1975 2211 North First Street 1976 San Jose, California 95131 1977 US 1979 Email: Jeff.Hodges@PayPal.com 1981 Collin Jackson 1982 Carnegie Mellon University 1984 Email: collin.jackson@sv.cmu.edu 1986 Adam Barth 1987 Google, Inc. 1989 Email: ietf@adambarth.com 1990 URI: http://www.adambarth.com/