idnits 2.17.1 draft-ietf-websec-strict-transport-sec-07.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 512 has weird spacing: '...TS Host is a...' -- The document date (May 2, 2012) is 4370 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 1763, but not defined == Missing Reference: 'I-D.draft-ietf-httpbis-p1-messaging-15' is mentioned on line 1988, but not defined == Missing Reference: 'HASMAT' is mentioned on line 2020, but not defined == Outdated reference: A later version (-23) exists of draft-ietf-dane-protocol-19 ** 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. 'Unicode' Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBSEC Working Group J. Hodges 3 Internet-Draft PayPal 4 Intended status: Standards Track C. Jackson 5 Expires: November 3, 2012 Carnegie Mellon University 6 A. Barth 7 Google, Inc. 8 May 2, 2012 10 HTTP Strict Transport Security (HSTS) 11 draft-ietf-websec-strict-transport-sec-07 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 November 3, 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 . . . . . . 5 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 . . . . . . . . . . . . . . . . 7 68 2.3.2.1. Phishing . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 9 75 3.1. Document Conventions . . . . . . . . . . . . . . . . . . . 10 76 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5. HSTS Mechanism Overview . . . . . . . . . . . . . . . . . . . 12 78 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 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.2. Known HSTS Host Domain Name Matching . . . . . . . . . . . 18 91 8.3. URI Loading and Port Mapping . . . . . . . . . . . . . . . 19 92 8.4. Errors in Secure Transport Establishment . . . . . . . . . 20 93 8.5. HTTP-Equiv Element Attribute . . . . . . . . . . . 20 94 8.6. Missing Strict-Transport-Security Response Header Field . 20 95 9. Domain Name IDNA-Canonicalization . . . . . . . . . . . . . . 20 96 10. Server Implementation and Deployment Advice . . . . . . . . . 21 97 10.1. HSTS Policy expiration time considerations . . . . . . . . 21 98 10.2. Using HSTS in conjunction with self-signed public-key 99 certificates . . . . . . . . . . . . . . . . . . . . . . . 22 100 10.3. Implications of includeSubDomains . . . . . . . . . . . . 23 101 11. User Agent Implementation Advice . . . . . . . . . . . . . . . 23 102 11.1. No User Recourse . . . . . . . . . . . . . . . . . . . . . 24 103 11.2. User-declared HSTS Policy . . . . . . . . . . . . . . . . 24 104 11.3. HSTS Pre-Loaded List . . . . . . . . . . . . . . . . . . . 24 105 11.4. Disallow Mixed Security Context Loads . . . . . . . . . . 25 106 11.5. HSTS Policy Deletion . . . . . . . . . . . . . . . . . . . 25 107 12. Constructing an Effective Request URI . . . . . . . . . . . . 25 108 12.1. ERU Fundamental Definitions . . . . . . . . . . . . . . . 26 109 12.2. Determining the Effective Request URI . . . . . . . . . . 26 110 12.2.1. Effective Request URI Examples . . . . . . . . . . . . 27 111 13. Internationalized Domain Names for Applications (IDNA): 112 Dependency and Migration . . . . . . . . . . . . . . . . . . . 27 113 14. Security Considerations . . . . . . . . . . . . . . . . . . . 27 114 14.1. Ramifications of HSTS Policy Establishment only over 115 Error-free Secure Transport . . . . . . . . . . . . . . . 28 116 14.2. The Need for includeSubDomains . . . . . . . . . . . . . . 29 117 14.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 29 118 14.4. Bootstrap MITM Vulnerability . . . . . . . . . . . . . . . 30 119 14.5. Network Time Attacks . . . . . . . . . . . . . . . . . . . 31 120 14.6. Bogus Root CA Certificate Phish plus DNS Cache 121 Poisoning Attack . . . . . . . . . . . . . . . . . . . . . 31 122 14.7. Creative Manipulation of HSTS Policy Store . . . . . . . . 31 123 14.8. Internationalized Domain Names . . . . . . . . . . . . . . 31 124 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 125 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 126 16.1. Normative References . . . . . . . . . . . . . . . . . . . 32 127 16.2. Informative References . . . . . . . . . . . . . . . . . . 34 128 Appendix A. Design Decision Notes . . . . . . . . . . . . . . . . 36 129 Appendix B. Differences between HSTS Policy and Same-Origin 130 Policy . . . . . . . . . . . . . . . . . . . . . . . 37 131 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . . 38 132 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 38 133 D.1. For draft-ietf-websec-strict-transport-sec . . . . . . . . 39 134 D.2. For draft-hodges-strict-transport-sec . . . . . . . . . . 44 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 137 1. Introduction 139 The HTTP protocol [RFC2616] may be used over various transports, 140 typically the Transmission Control Protocol (TCP). However, TCP does 141 not provide channel integrity protection, confidentiality, nor secure 142 host identification. Thus the Secure Sockets Layer (SSL) protocol 143 [RFC6101] and its successor Transport Layer Security (TLS) [RFC5246], 144 were developed in order to provide channel-oriented security, and are 145 typically layered between application protocols and TCP. [RFC2818] 146 specifies how HTTP is layered onto TLS, and defines the Uniform 147 Resource Identifier (URI) scheme of "https" (in practice however, 148 HTTP user agents (UAs) typically offer their users choices among 149 SSL2, SSL3, and TLS for secure transport). 151 UAs employ various local security policies with respect to the 152 characteristics of their interactions with web resources depending on 153 (in part) whether they are communicating with a given web resource's 154 host using HTTP or HTTP-over-a-Secure-Transport. For example, 155 cookies ([RFC6265]) may be flagged as Secure. UAs are to send such 156 Secure cookies to their addressed host only over a secure transport. 157 This is in contrast to non-Secure cookies, which are returned to the 158 host regardless of transport (although subject to other rules). 160 UAs typically announce to their users any issues with secure 161 connection establishment, such as being unable to validate a TLS 162 server certificate trust chain, or if a TLS server certificate is 163 expired, or if a TLS host's domain name appears incorrectly in the 164 TLS server certificate (see Section 3.1 of [RFC2818]). Often, UAs 165 enable users to elect to continue to interact with a web resource's 166 host in the face of such issues. This behavior is sometimes referred 167 to as "click(ing) through" security [GoodDhamijaEtAl05] 168 [SunshineEgelmanEtAl09], and thus can be described as "click-through 169 insecurity". 171 A key vulnerability enabled by click-through insecurity is the 172 leaking of any cookies the web resource may be using to manage a 173 user's session. The threat here is that an attacker could obtain the 174 cookies and then interact with the legitimate web resource while 175 impersonating the user. 177 Jackson and Barth proposed an approach, in [ForceHTTPS], to enable 178 web resources to declare that any interactions by UAs with the web 179 resource must be conducted securely, and that any issues with 180 establishing a secure transport session are to be treated as fatal 181 and without direct user recourse. The aim is to prevent click- 182 through insecurity, and address other potential threats. 184 This specification embodies and refines the approach proposed in 186 [ForceHTTPS]. For example, rather than using a cookie to convey 187 policy from a web resource's host to a UA, it defines an HTTP 188 response header field for this purpose. Additionally, a web 189 resource's host may declare its policy to apply to the entire domain 190 name subtree rooted at its host name. This enables HSTS to protect 191 so-called "domain cookies", which are applied to all subdomains of a 192 given web resource's host name. 194 This specification also incorporates notions from [JacksonBarth2008] 195 in that policy is applied on an "entire-host" basis: it applies to 196 HTTP (only) over any TCP port of the issuing host. 198 Note that the policy defined by this specification is distinctly 199 different than the "same-origin policy" defined in "The Web Origin 200 Concept" [RFC6454]. These differences are summarized below in 201 Appendix B. 203 1.1. Organization of this specification 205 This specification begins with an overview of the use cases, policy 206 effects, threat models, and requirements for HSTS (in Section 2). 207 Then, Section 3 defines conformance requirements. The HSTS mechanism 208 itself is formally specified in Section 4 through Section 15. 210 2. Overview 212 This section discusses the use cases, summarizes the HTTP Strict 213 Transport Security (HSTS) policy, and continues with a discussion of 214 the threat model, non-addressed threats, and derived requirements. 216 2.1. Use Cases 218 The high-level use case is a combination of: 220 o Web browser user wishes to interact with various web sites (some 221 arbitrary, some known) in a secure fashion. 223 o Web site deployer wishes to offer their site in an explicitly 224 secure fashion for both their own, as well as their users', 225 benefit. 227 2.2. HTTP Strict Transport Security Policy Effects 229 The effects of the HTTP Strict Transport Security (HSTS) Policy, as 230 applied by a conformant UA in interactions with a web resource host 231 wielding such policy (known as a HSTS Host), are summarized as 232 follows: 234 1. UAs transform insecure URI references to a HSTS Host into secure 235 URI references before dereferencing them. 237 2. The UA terminates any secure transport connection attempts upon 238 any and all secure transport errors or warnings. 240 2.3. Threat Model 242 HSTS is concerned with three threat classes: passive network 243 attackers, active network attackers, and imperfect web developers. 244 However, it is explicitly not a remedy for two other classes of 245 threats: phishing and malware. Addressed and not addressed threats 246 are briefly discussed below. Readers may wish refer to [ForceHTTPS] 247 for details as well as relevant citations. 249 2.3.1. Threats Addressed 251 2.3.1.1. Passive Network Attackers 253 When a user browses the web on a local wireless network (e.g., an 254 802.11-based wireless local area network) a nearby attacker can 255 possibly eavesdrop on the user's unencrypted Internet Protocol-based 256 connections, such as HTTP, regardless of whether or not the local 257 wireless network itself is secured [BeckTews09]. Freely available 258 wireless sniffing toolkits (e.g., [Aircrack-ng]) enable such passive 259 eavesdropping attacks, even if the local wireless network is 260 operating in a secure fashion. A passive network attacker using such 261 tools can steal session identifiers/cookies and hijack the user's web 262 session(s), by obtaining cookies containing authentication 263 credentials [ForceHTTPS]. For example, there exist widely-available 264 tools, such as Firesheep (a Firefox extension) [Firesheep], which 265 enable their wielder to obtain other local users' session cookies for 266 various web applications. 268 To mitigate such threats, some Web sites support, but usually do not 269 force, access using end-to-end secure transport -- e.g., signaled 270 through URIs constructed with the "https" scheme [RFC2818]. This can 271 lead users to believe that accessing such services using secure 272 transport protects them from passive network attackers. 273 Unfortunately, this is often not the case in real-world deployments 274 as session identifiers are often stored in non-Secure cookies to 275 permit interoperability with versions of the service offered over 276 insecure transport ("Secure cookies" are those cookies containing the 277 "Secure" attribute [RFC6265]). For example, if the session 278 identifier for a web site (an email service, say) is stored in a non- 279 Secure cookie, it permits an attacker to hijack the user's session if 280 the user's UA makes a single insecure HTTP request to the site. 282 2.3.1.2. Active Network Attackers 284 A determined attacker can mount an active attack, either by 285 impersonating a user's DNS server or, in a wireless network, by 286 spoofing network frames or offering a similarly-named evil twin 287 access point. If the user is behind a wireless home router, an 288 attacker can attempt to reconfigure the router using default 289 passwords and other vulnerabilities. Some sites, such as banks, rely 290 on end-to-end secure transport to protect themselves and their users 291 from such active attackers. Unfortunately, browsers allow their 292 users to easily opt-out of these protections in order to be usable 293 for sites that incorrectly deploy secure transport, for example by 294 generating and self-signing their own certificates (without also 295 distributing their CA certificate to their users' browsers). 297 2.3.1.3. Web Site Development and Deployment Bugs 299 The security of an otherwise uniformly secure site (i.e. all of its 300 content is materialized via "https" URIs), can be compromised 301 completely by an active attacker exploiting a simple mistake, such as 302 the loading of a cascading style sheet or a SWF movie over an 303 insecure connection (both cascading style sheets and SWF movies can 304 script the embedding page, to the surprise of many web developers, 305 plus some browsers do not issue so-called "mixed content warnings" 306 when SWF files are embedded via insecure connections). Even if the 307 site's developers carefully scrutinize their login page for "mixed 308 content", a single insecure embedding anywhere on the overall site 309 compromises the security of their login page because an attacker can 310 script (i.e., control) the login page by injecting script into 311 another, insecurely loaded, site page. 313 Note: "Mixed content" as used above (see also Section 5.3 in 314 [W3C.REC-wsc-ui-20100812]) refers to the notion termed "mixed 315 security context" in this specification, and should not be 316 confused with the same "mixed content" term used in the 317 context of markup languages such as XML and HTML. 319 2.3.2. Threats Not Addressed 321 2.3.2.1. Phishing 323 Phishing attacks occur when an attacker solicits authentication 324 credentials from the user by hosting a fake site located on a 325 different domain than the real site, perhaps driving traffic to the 326 fake site by sending a link in an email message. Phishing attacks 327 can be very effective because users find it difficult to distinguish 328 the real site from a fake site. HSTS is not a defense against 329 phishing per se; rather, it complements many existing phishing 330 defenses by instructing the browser to protect session integrity and 331 long-lived authentication tokens [ForceHTTPS]. 333 2.3.2.2. Malware and Browser Vulnerabilities 335 Because HSTS is implemented as a browser security mechanism, it 336 relies on the trustworthiness of the user's system to protect the 337 session. Malicious code executing on the user's system can 338 compromise a browser session, regardless of whether HSTS is used. 340 2.4. Requirements 342 This section identifies and enumerates various requirements derived 343 from the use cases and the threats discussed above, and lists the 344 detailed core requirements HTTP Strict Transport Security addresses, 345 as well as ancillary requirements that are not directly addressed. 347 2.4.1. Overall Requirement 349 o Minimize the risks to web browser users and web site deployers 350 that are derived from passive and active network attackers, web 351 site development and deployment bugs, as well as insecure user 352 actions. 354 2.4.1.1. Detailed Core Requirements 356 These core requirements are derived from the overall requirement, and 357 are addressed by this specification. 359 1. Web sites need to be able to declare to UAs that they should be 360 interacted with using a strict security policy. 362 2. Web sites need to be able to instruct UAs that contact them 363 insecurely to do so securely. 365 3. UAs need to persistently remember web sites that signal strict 366 security policy enablement, for time spans declared by the web 367 sites. Additionally, UAs need to cache the "freshest" strict 368 security policy information, in order to allow web sites to 369 update the information. 371 4. UAs need to re-write all insecure UA "http" URI loads to use the 372 "https" secure scheme for those web sites for which secure policy 373 is enabled. 375 5. Web site administrators need to be able to signal strict security 376 policy application to subdomains of higher-level domains for 377 which strict security policy is enabled, and UAs need to enforce 378 such policy. 380 For example, both example.com and foo.example.com could set 381 policy for bar.foo.example.com. 383 6. UAs need to disallow security policy application to peer domains, 384 and/or higher-level domains, by domains for which strict security 385 policy is enabled. 387 For example, neither bar.foo.example.com nor foo.example.com can 388 set policy for example.com, nor can bar.foo.example.com set 389 policy for foo.example.com. Also, foo.example.com cannot set 390 policy for sibling.example.com. 392 7. UAs need to prevent users from clicking-through security 393 warnings. Halting connection attempts in the face of secure 394 transport exceptions is acceptable. 396 Note: A means for uniformly securely meeting the first core 397 requirement above is not specifically addressed by this 398 specification (see Section 14.4 "Bootstrap MITM 399 Vulnerability"). It may be addressed by a future revision of 400 this specification or some other specification. Note also 401 that there are means by which UA implementations may more 402 fully meet the first core requirement, see Section 11 "User 403 Agent Implementation Advice". 405 2.4.1.2. Detailed Ancillary Requirements 407 These ancillary requirements are also derived from the overall 408 requirement. They are not normatively addressed in this 409 specification, but could be met by UA implementations at their 410 implementor's discretion, although meeting these requirements may be 411 complex. 413 1. Disallow "mixed security context" loads (see Section 2.3.1.3). 415 2. Facilitate user declaration of web sites for which strict 416 security policy is enabled, regardless of whether the sites 417 signal HSTS Policy. 419 3. Conformance Criteria 421 This specification is written for hosts and user agents (UAs). 423 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 424 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 425 document are to be interpreted as described in [RFC2119]. 427 A conformant host is one that implements all the requirements listed 428 in this specification that are applicable to hosts. 430 A conformant user agent is one that implements all the requirements 431 listed in this specification that are applicable to user agents. 433 3.1. Document Conventions 435 Note: This is a note to the reader. These are points that should be 436 expressly kept in mind and/or considered. 438 Warning: This is how a warning is shown. These are things that can 439 have negative downside risks if not heeded. 441 4. Terminology 443 Terminology is defined in this section. 445 ASCII case-insensitive comparison 446 means comparing two strings exactly, codepoint for 447 codepoint, except that the characters in the range 448 U+0041 .. U+005A (i.e. LATIN CAPITAL LETTER A to 449 LATIN CAPITAL LETTER Z) and the corresponding 450 characters in the range U+0061 .. U+007A (i.e. 451 LATIN SMALL LETTER A to LATIN SMALL LETTER Z) are 452 considered to also match. See [Unicode] for 453 details. 455 codepoint is a colloquial contraction of Code Point, which is 456 any value in the Unicode codespace; that is, the 457 range of integers from 0 to 10FFFF(hex) [Unicode]. 459 domain name domain names, also referred to as DNS Names, are 460 defined in [RFC1035] to be represented outside of 461 the DNS protocol itself (and implementations 462 thereof) as a series of labels separated by dots, 463 e.g., "example.com" or "yet.another.example.org". 464 In the context of this specification, domain names 465 appear in that portion of a URI satisfying the reg- 466 name production in "Appendix A. Collected ABNF for 467 URI" in [RFC3986], and the host component from the 468 Host HTTP header field production in Section 14.23 469 of [RFC2616]. 471 Note: The domain names appearing in actual URI 472 instances and matching the aforementioned 473 production components may or may not be a 474 fully qualified domain name. 476 domain name label is that portion of a domain name appearing "between 477 the dots", i.e. consider "foo.example.com": "foo", 478 "example", and "com" are all domain name labels. 480 Effective Request URI 481 is a URI, identifying the target resource, that can 482 be inferred by an HTTP host for any given HTTP 483 request it receives. Such inference is necessary 484 because HTTP requests often do not contain a 485 complete "absolute" URI identifying the target 486 resource. See Section 12 "Constructing an 487 Effective Request URI". 489 HTTP Strict Transport Security 490 is the overall name for the combined UA- and 491 server-side security policy defined by this 492 specification. 494 HTTP Strict Transport Security Host 495 is a HTTP host implementing the server aspects of 496 the HSTS policy. This means that an HSTS Host 497 returns the "Strict-Transport-Security" HTTP 498 response header field in its HTTP response messages 499 sent over secure transport. 501 HTTP Strict Transport Security Policy 502 is the name of the combined overall UA- and server- 503 side facets of the behavior specified in this 504 specification. 506 HSTS See HTTP Strict Transport Security. 508 HSTS Host See HTTP Strict Transport Security Host. 510 HSTS Policy See HTTP Strict Transport Security Policy. 512 Known HSTS Host is a HSTS Host for which the UA has a HSTS Policy 513 in effect. I.e., the UA has noted this host as a 514 Known HSTS Host. 516 Local policy is comprised of policy rules deployers specify and 517 which are often manifested as "configuration 518 settings". 520 MITM is an acronym for man-in-the-middle. See "man-in- 521 the-middle attack" in [RFC4949]. 523 Request URI is the URI used to cause a UA to issue an HTTP 524 request message. 526 UA is a an acronym for user agent. For the purposes 527 of this specification, a UA is an HTTP client 528 application typically actively manipulated by a 529 user [RFC2616] . 531 unknown HSTS Host is a HSTS Host that the user agent in question has 532 not yet noted. 534 5. HSTS Mechanism Overview 536 This section provides an overview of the mechanism by which an HSTS 537 Host conveys its HSTS Policy to UAs, and how UAs process the HSTS 538 Policies received from HSTS Hosts. The mechanism details are 539 specified in Section 6 through Section 15. 541 An HSTS Host conveys its HSTS Policy to UAs via the Strict-Transport- 542 Security HTTP response header field over secure transport (e.g., 543 TLS). Receipt of this header field signals to UAs to enforce the 544 HSTS Policy for all subsequent connections made to the HSTS Host, for 545 a specified time duration. Application of the HSTS Policy to 546 subdomains of the HSTS Host name may optionally be specified. 548 HSTS Hosts manage their advertised HSTS Policies by sending Strict- 549 Transport-Security HTTP response header fields to UAs with new values 550 for policy time duration and application to subdomains. UAs cache 551 the "freshest" HSTS Policy information on behalf of an HSTS Host. 552 Specifying a zero time duration signals to the UA to delete the HSTS 553 policy for that HSTS host. 555 Section 6.2 presents examples of Strict-Transport-Security HTTP 556 response header fields. 558 6. Syntax 560 This section defines the syntax of the Strict-Transport-Security HTTP 561 response header field and its directives, and presents some examples. 563 Section 7 "Server Processing Model" then details how hosts employ 564 this header field to declare their HSTS Policy, and Section 8 "User 565 Agent Processing Model" details how user agents process the header 566 field and apply the HSTS Policy. 568 6.1. Strict-Transport-Security HTTP Response Header Field 570 The Strict-Transport-Security HTTP response header field (STS header 571 field) indicates to a UA that it MUST enforce the HSTS Policy in 572 regards to the host emitting the response message containing this 573 header field. 575 The ABNF syntax for the STS header field is given below. It is based 576 on the Generic Grammar defined in Section 2 of [RFC2616] (which 577 includes a notion of "implied linear whitespace", also known as 578 "implied *LWS"). 580 Strict-Transport-Security = "Strict-Transport-Security" ":" 581 [ directive ] *( ";" [ directive ] ) 583 directive = token [ "=" ( token | quoted-string ) ] 585 where: 587 token = 588 quoted-string = 590 The two directives defined in this specification are described below. 591 The overall requirements for directives are: 593 o The order of appearance of directives is not significant. 595 o All directives MUST appear only once in an STS header field. 596 Directives are either optional or required, as stipulated in their 597 definitions. 599 o Directive names are case-insensitive. 601 o UAs MUST ignore any STS header fields containing directives that 602 do not conform to their ABNF definition. 604 Additional directives extending the semantic functionality of the STS 605 header field can be defined in other specifications (which "update" 606 this specification). 608 6.1.1. The max-age Directive 610 The REQUIRED "max-age" directive specifies the number of seconds, 611 after the reception of the STS header field, during which the UA 612 regards the host (from whom the message was received) as a Known HSTS 613 Host. See also Section 8.1.1 "Noting a HSTS Host". The delta- 614 seconds production is specified in [RFC2616]. 616 The syntax of the max-age directive's value (after quoted-string 617 unescaping, if necessary) is defined as: 619 max-age-value = delta-seconds 621 delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2> 623 Note: A max-age value of zero signals the UA to cease regarding the 624 host as a Known HSTS Host. 626 6.1.2. The includeSubDomains Directive 628 The OPTIONAL "includeSubDomains" directive is a valueless flag which, 629 if present, signals to the UA that the HSTS Policy applies to this 630 HSTS Host as well as any subdomains of the host's domain name. 632 6.2. Examples 634 The below HSTS header field stipulates that the HSTS policy is to 635 remain in effect for one year (there are approximately 31 536 000 636 seconds in a year), and the policy applies only to the domain of the 637 HSTS Host issuing it: 639 Strict-Transport-Security: max-age=31536000 641 The below HSTS header field stipulates that the HSTS policy is to 642 remain in effect for approximately six months and the policy applies 643 only to the domain of the issuing HSTS Host and all of its 644 subdomains: 646 Strict-Transport-Security: max-age=15768000 ; includeSubDomains 648 The max-age directive value can optionally be quoted: 650 Strict-Transport-Security: max-age="31536000" 652 7. Server Processing Model 654 This section describes the processing model that HSTS Hosts 655 implement. The model is comprised of two facets: the first being the 656 processing rules for HTTP request messages received over a secure 657 transport (e.g., TLS [RFC5246], SSL [I-D.ietf-tls-ssl-version3], or 658 perhaps others), the second being the processing rules for HTTP 659 request messages received over non-secure transports, i.e. over 660 TCP/IP. 662 7.1. HTTP-over-Secure-Transport Request Type 664 When replying to an HTTP request that was conveyed over a secure 665 transport, a HSTS Host SHOULD include in its response message a STS 666 header field that MUST satisfy the grammar specified above in 667 Section 6.1 "Strict-Transport-Security HTTP Response Header Field". 668 If a STS header field is included, the HSTS Host MUST include only 669 one such header field. 671 Note: Including the STS header field is stipulated as a "SHOULD" in 672 order to accommodate various server- and network-side caches 673 and load-balancing configurations where it may be difficult to 674 uniformly emit STS header fields on behalf of a given HSTS 675 Host. 677 Establishing a given host as a Known HSTS Host, in the context 678 of a given UA, MAY be accomplished over the HTTP protocol by 679 correctly returning, per this specification, at least one 680 valid STS header field to the UA. Other mechanisms, such as a 681 client-side pre-loaded Known HSTS Host list MAY also be used. 682 E.g., see Section 11 "User Agent Implementation Advice". 684 7.2. HTTP Request Type 686 If a HSTS Host receives a HTTP request message over a non-secure 687 transport, it SHOULD send a HTTP response message containing a status 688 code indicating a permanent redirect, such as status code 301 689 (Section 10.3.2 of [RFC2616]), and a Location header field value 690 containing either the HTTP request's original Effective Request URI 691 (see Section 12 "Constructing an Effective Request URI") altered as 692 necessary to have a URI scheme of "https", or a URI generated 693 according to local policy (which SHOULD employ a URI scheme of 694 "https"). 696 Note: The above behavior is a "SHOULD" rather than a "MUST" because: 698 * There are risks in server-side non-secure-to-secure redirects 699 [owaspTLSGuide]. 701 * Site deployment characteristics -- e.g., a site that 702 incorporates third-party components may not behave correctly 703 when doing server-side non-secure-to-secure redirects in the 704 case of being accessed over non-secure transport, but does 705 behave correctly when accessed uniformly over secure transport. 706 The latter is the case given a HSTS-capable UA that has already 707 noted the site as a Known HSTS Host (by whatever means, e.g., 708 prior interaction or UA configuration). 710 A HSTS Host MUST NOT include the STS header field in HTTP responses 711 conveyed over non-secure transport. 713 8. User Agent Processing Model 715 This section describes the HTTP Strict Transport Security processing 716 model for UAs. There are several facets to the model, enumerated by 717 the following subsections. 719 This processing model assumes that the UA implements IDNA2008 720 [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 13 721 "Internationalized Domain Names for Applications (IDNA): Dependency 722 and Migration". It also assumes that all domain names manipulated in 723 this specification's context are already IDNA-canonicalized as 724 outlined in Section 9 "Domain Name IDNA-Canonicalization" prior to 725 the processing specified in this section. 727 The above assumptions mean that this processing model also 728 specifically assumes that appropriate IDNA and Unicode validations 729 and character list testing have occurred on the domain names, in 730 conjunction with their IDNA-canonicalization, prior to the processing 731 specified in this section. See the IDNA-specific security 732 considerations in Section 14.8 "Internationalized Domain Names" for 733 rationale and further details. 735 8.1. Strict-Transport-Security Response Header Field Processing 737 If an HTTP response, received over a secure transport, includes a STS 738 header field, conforming to the grammar specified in Section 6.1 739 "Strict-Transport-Security HTTP Response Header Field", and there are 740 no underlying secure transport errors or warnings (see Section 8.4), 741 the UA MUST either: 743 o Note the host as a Known HSTS Host if it is not already so noted 744 (see Section 8.1.1 "Noting a HSTS Host"), 746 or, 748 o Update the UA's cached information for the Known HSTS Host if 749 either or both of the max-age and includeSubDomains header field 750 value tokens are conveying information different than that already 751 maintained by the UA. 753 Note: The max-age value is essentially a "time to live" value 754 relative to the reception time of the STS header field. 756 If the max-age header field value token has a value of zero, 757 the UA MUST remove its cached HSTS Policy information if the 758 HSTS Host is known, or, MUST NOT note this HSTS Host if it is 759 not yet known. 761 If a UA receives more than one STS header field in a HTTP 762 response message over secure transport, then the UA MUST 763 process only the first such header field. 765 Otherwise: 767 o If an HTTP response is received over insecure transport, the UA 768 MUST ignore any present STS header field(s). 770 o The UA MUST ignore any STS header fields not conforming to the 771 grammar specified in Section 6.1 "Strict-Transport-Security HTTP 772 Response Header Field". 774 8.1.1. Noting a HSTS Host 776 If the substring matching the host production from the Request-URI 777 (of the message that the host responded to) syntactically matches the 778 IP-literal or IPv4address productions from Section 3.2.2 of 779 [RFC3986], then the UA MUST NOT note this host as a Known HSTS Host. 781 Otherwise, if the substring does not congruently match a Known HSTS 782 Host's domain name, per the matching procedure specified in 783 Section 8.2 "Known HSTS Host Domain Name Matching", then the UA MUST 784 note this host as a Known HSTS Host, caching the HSTS Host's domain 785 name and noting along with it the expiry time of this information, as 786 effectively stipulated per the given max-age value, as well as 787 whether the includeSubDomains flag is asserted or not. See also 788 Section 10.1 "HSTS Policy expiration time considerations". 790 Note: The UA MUST NOT modify the expiry time nor the 791 includeSubDomains flag of any superdomain matched Known HSTS 792 Host. 794 8.2. Known HSTS Host Domain Name Matching 796 A given domain name may match a Known HSTS Host's domain name in one 797 or both of two fashions: a congruent match, or a superdomain match. 798 Or, there may be no match. 800 The below steps determine whether there are any matches, and if so, 801 of which fashion: 803 Compare the given domain name with the domain name of each of the 804 UA's Known HSTS Hosts. For each Known HSTS Host's domain name, 805 the comparison is done with the given domain name label-by-label 806 (comparing only labels) using an ASCII case-insensitive comparison 807 beginning with the rightmost label, and continuing right-to-left. 808 See also Section 2.3.2.4. of [RFC5890]. 810 * Superdomain Match 812 If a label-for-label match between an entire Known HSTS Host's 813 domain name and a right-hand portion of the given domain name 814 is found, then this Known HSTS Host's domain name is a 815 superdomain match for the given domain name. There could be 816 multiple superdomain matches for a given domain name. 818 For example: 820 Given Domain Name: qaz.bar.foo.example.com 822 Superdomain matched 823 Known HSTS Host DN: bar.foo.example.com 825 Superdomain matched 826 Known HSTS Host DN: foo.example.com 828 * Congruent Match 830 If a label-for-label match between a Known HSTS Host's domain 831 name and the given domain name is found -- i.e., there are no 832 further labels to compare -- then the given domain name 833 congruently matches this Known HSTS Host. 835 For example: 837 Given Domain Name: foo.example.com 839 Congruently matched 840 Known HSTS Host DN: foo.example.com 842 * Otherwise, if no matches are found, the given domain name does 843 not represent a Known HSTS Host. 845 8.3. URI Loading and Port Mapping 847 Whenever the UA prepares to "load", also known as "dereference", any 848 "http" URI [RFC3986], the UA MUST first determine whether a domain 849 name is given in the URI and whether it matches a Known HSTS Host, 850 using these steps: 852 1. Extract from the URI any substring described by the host 853 component of the authority component of the URI. 855 2. If the substring is null, then there is no match with any Known 856 HSTS Host. 858 3. Else, if the substring is non-null and syntactically matches the 859 IP-literal or IPv4address productions from Section 3.2.2 of 860 [RFC3986], then there is no match with any Known HSTS Host. 862 4. Otherwise, the substring is a given domain name, which MUST be 863 matched against the UA's Known HSTS Hosts using the procedure in 864 Section 8.2 "Known HSTS Host Domain Name Matching". 866 If a superdomain match with an asserted includeSubDomains flag is 867 found, or if a congruent match is found -- without any found 868 superdomain matches having asserted includeSubDomains flags -- then 869 before proceeding with the load: 871 The UA MUST replace the URI scheme with "https" [RFC2818], and, 873 if the URI contains an explicit port component of "80", then the 874 UA MUST convert the port component to be "443", or, 876 if the URI contains an explicit port component that is not equal 877 to "80", the port component value MUST be preserved, otherwise, 879 if the URI does not contain an explicit port component, the UA 880 MUST NOT add one. 882 Note: The the above steps ensure that the HSTS Policy applies to 883 HTTP over any TCP port of a HSTS Host. 885 8.4. Errors in Secure Transport Establishment 887 When connecting to a Known HSTS Host, the UA MUST terminate the 888 connection (see also Section 11 "User Agent Implementation Advice") 889 if there are any errors (e.g., certificate errors), whether "warning" 890 or "fatal" or any other error level, with the underlying secure 891 transport. This includes any issues with certificate revocation 892 checking whether via the Certificate Revocation List (CRL) [RFC5280], 893 or via the Online Certificate Status Protocol (OCSP) [RFC2560]. 895 8.5. HTTP-Equiv Element Attribute 897 UAs MUST NOT heed http-equiv="Strict-Transport-Security" attribute 898 settings on elements [W3C.REC-html401-19991224] in received 899 content. 901 8.6. Missing Strict-Transport-Security Response Header Field 903 If a UA receives HTTP responses from a Known HSTS Host over a secure 904 channel, but they are missing the STS header field, the UA MUST 905 continue to treat the host as a Known HSTS Host until the max-age 906 value for the knowledge of that Known HSTS Host is reached. Note 907 that the max-age could be infinite for a given Known HSTS Host. For 908 example, if the Known HSTS Host is part of a pre-configured list that 909 is implemented such that the list entries never "age out". 911 9. Domain Name IDNA-Canonicalization 913 An IDNA-canonicalized domain name is the output string generated by 914 the following steps. The input is a putative domain name string 915 ostensibly composed of any combination of "A-labels", "U-labels", and 916 "NR-LDH labels" (see Section 2 of [RFC5890]) concatenated using some 917 separator character (typically "."). 919 1. Convert the input putative domain name string to a order- 920 preserving sequence of individual label strings. 922 2. When implementing IDNA2008, convert, validate, and test each 923 A-label and U-label found among the sequence of individual label 924 strings, using the procedures defined in Sections 5.3 through 5.5 925 of [RFC5891]. 927 Otherwise, when implementing IDNA2003, convert each label using 928 the "ToASCII" conversion in Section 4 of [RFC3490] (see also the 929 definition of "equivalence of labels" in Section 2 of the latter 930 specification). 932 3. If no errors occurred during the foregoing step, concatenate all 933 the labels in the sequence, in order, into a string, separating 934 each label from the next with (".") a %x2E character. The 935 resulting string, known as a IDNA-canonicalized domain name, is 936 appropriate for use in the context of Section 8 "User Agent 937 Processing Model". 939 Otherwise, errors occurred. The input putative domain name 940 string was not successfully IDNA-canonicalized. Invokers of this 941 procedure should attempt appropriate error recovery. 943 See also Section 13 "Internationalized Domain Names for Applications 944 (IDNA): Dependency and Migration" and Section 14.8 "Internationalized 945 Domain Names" of this specification for further details and 946 considerations. 948 10. Server Implementation and Deployment Advice 950 This section is non-normative. 952 10.1. HSTS Policy expiration time considerations 954 Server implementations and deploying web sites need to consider 955 whether they are setting an expiry time that is a constant value into 956 the future, or whether they are setting an expiry time that is a 957 fixed point in time. 959 The constant value into the future approach can be accomplished by 960 constantly sending the same max-age value to UAs. 962 For example, a max-age value of 778000 is 90 days: 964 Strict-Transport-Security: max-age=778000 966 Note that each receipt of this header by a UA will require the UA to 967 update its notion of when it must delete its knowledge of this Known 968 HSTS Host. 970 The fixed point in time approach can be accomplished by sending max- 971 age values that represent the remaining time until the desired expiry 972 time. This would require the HSTS Host to send a newly-calculated 973 max-age value on each HTTP response. 975 A consideration here is whether a deployer wishes to have the 976 signaled HSTS Policy expiry time match that for the web site's domain 977 certificate. 979 Additionally, server implementers should consider employing a default 980 max-age value of zero in their deployment configuration systems. 981 This will require deployers to wilfully set max-age in order to have 982 UAs enforce the HSTS Policy for their host, and protects them from 983 inadvertently enabling HSTS with some arbitrary non-zero duration. 985 10.2. Using HSTS in conjunction with self-signed public-key 986 certificates 988 If a web site/organization/enterprise is generating their own secure 989 transport public-key certificates for web sites, and that 990 organization's root certification authority (CA) certificate is not 991 typically embedded by default in browser and/or operating system CA 992 certificate stores, and if HSTS Policy is enabled on a host 993 identifying itself using a certificate signed by the organization's 994 CA (i.e., a "self-signed certificate"), and this certificate does not 995 match a usable TLS certificate association (as defined by Section 4 996 of the TLSA protocol specification [I-D.ietf-dane-protocol]), then 997 secure connections to that site will fail, per the HSTS design. This 998 is to protect against various active attacks, as discussed above. 1000 However, if said organization wishes to employ their own CA, and 1001 self-signed certificates, in concert with HSTS, they can do so by 1002 deploying their root CA certificate to their users' browsers or 1003 operating system CA root certificate stores. They can also, in 1004 addition or instead, distribute to their users' browsers the end- 1005 entity certificate(s) for specific hosts. There are various ways in 1006 which this can be accomplished (details are out of scope for this 1007 specification). Once their root CA certificate is installed in the 1008 browsers, they may employ HSTS Policy on their site(s). 1010 Alternately, that organization can deploy the TLSA protocol; all 1011 browsers that also use TLSA will then be able to trust the 1012 certificates identified by usable TLS certificate associations as 1013 denoted via TLSA. 1015 Note: Interactively distributing root CA certificates to users, 1016 e.g., via email, and having the users install them, is 1017 arguably training the users to be susceptible to a possible 1018 form of phishing attack, see Section 14.6 "Bogus Root CA 1019 Certificate Phish plus DNS Cache Poisoning Attack". Thus care 1020 should be taken in the manner in which such certificates are 1021 distributed and installed on users' systems and browsers. 1023 10.3. Implications of includeSubDomains 1025 The includeSubDomains directive has some practical implications -- 1026 for example, if a HSTS Host offers HTTP-based services on various 1027 ports or at various subdomains of its host domain name, then they 1028 will all have to be available over secure transport in order to work 1029 properly. 1031 For example, certification authorities often offer their CRL 1032 distribution and OCSP services [RFC2560] over plain HTTP, and 1033 sometimes at a subdomain of a publicly-available web application 1034 which may be secured by TLS/SSL. For example, 1035 is a publicly-available web application for 1036 "Example CA", a certification authority. Customers use this web 1037 application to register their public keys and obtain certificates. 1038 Example CA generates certificates for customers containing 1039 as the value for the "CRL 1040 Distribution Points" and "Authority Information Access:OCSP" 1041 certificate fields. 1043 If example-ca.com were to issue an HSTS Policy with the 1044 includeSubDomains directive, then HTTP-based user agents implementing 1045 HSTS, and that have interacted with the example-ca.com web 1046 application, would fail to retrieve CRLs and fail to check OCSP for 1047 certificates because these services are offered over plain HTTP. 1049 In this case, Example CA can either: 1051 o not use the includeSubDomains directive, or, 1053 o ensure HTTP-based services offered at subdomains of example-ca.com 1054 are uniformly offered over TLS/SSL, or, 1056 o offer plain HTTP-based services at a different domain name, e.g., 1057 example-ca-services.net. 1059 11. User Agent Implementation Advice 1061 This section is non-normative. 1063 In order to provide users and web sites more effective protection, as 1064 well as controls for managing their UA's caching of HSTS Policy, UA 1065 implementors should consider including features such as: 1067 11.1. No User Recourse 1069 Failing secure connection establishment on any warnings or errors 1070 (per Section 8.4 "Errors in Secure Transport Establishment"), should 1071 be done with "no user recourse". This means that the user should not 1072 be presented with a dialog giving her the option to proceed. Rather, 1073 it should be treated similarly to a server error where there is 1074 nothing further the user can do with respect to interacting with the 1075 target web application, other than wait and re-try. 1077 Essentially, "any warnings or errors" means anything that would cause 1078 the UA implementation to announce to the user that something is not 1079 entirely correct with the connection establishment. 1081 Not doing this, i.e., allowing user recourse such as "clicking- 1082 through warning/error dialogs", is a recipe for a Man-in-the-Middle 1083 attack. If a web application advertises HSTS, then it is opting into 1084 this scheme, whereby all certificate errors or warnings cause a 1085 connection termination, with no chance to "fool" the user into making 1086 the wrong decision and compromising themselves. 1088 11.2. User-declared HSTS Policy 1090 A User-declared HSTS Policy is the ability for users to explicitly 1091 declare a given Domain Name as representing a HSTS Host, thus seeding 1092 it as a Known HSTS Host before any actual interaction with it. This 1093 would help protect against the Section 14.4 "Bootstrap MITM 1094 Vulnerability". 1096 Note: Such a feature is difficult to get right on a per-site basis 1097 -- see the discussion of "rewrite rules" in Section 5.5 of 1098 [ForceHTTPS]. For example, arbitrary web sites may not 1099 materialize all their URIs using the "https" scheme, and thus 1100 could "break" if a UA were to attempt to access the site 1101 exclusively using such URIs. Also note that this feature 1102 would complement, but is independent of the following 1103 described facility. 1105 11.3. HSTS Pre-Loaded List 1107 A HSTS Pre-Loaded List is a facility whereby web site administrators 1108 can have UAs pre-configured with HSTS Policy for their site(s) by the 1109 UA vendor(s) -- a so-called "pre-loaded list" -- in a manner similar 1110 to how root CA certificates are embedded in browsers "at the 1111 factory". This would help protect against the Section 14.4 1112 "Bootstrap MITM Vulnerability". 1114 Note: Such a facility would complement a "User-declared HSTS Policy" 1115 feature. 1117 11.4. Disallow Mixed Security Context Loads 1119 "Mixed security context" loads are when an web application resource, 1120 fetched by the UA over a secure transport, subsequently fetches and 1121 loads one or more other resources without using secure transport. 1122 This is also generally referred to as "mixed content" loads (see 1123 Section 5.3 "Mixed Content" in [W3C.REC-wsc-ui-20100812]), but should 1124 not be confused with the same "mixed content" term that is also used 1125 in the context of markup languages such as XML and HTML. 1127 Note: In order to provide behavioral uniformity across UA 1128 implementations, the notion of mixed security context will 1129 require further standardization work, e.g., to more clearly 1130 define the term(s) and to define specific behaviors with 1131 respect to it. 1133 11.5. HSTS Policy Deletion 1135 HSTS Policy Deletion is the ability to delete a UA's cached HSTS 1136 Policy on a per HSTS Host basis. 1138 Note: Adding such a feature should be done very carefully in both 1139 the user interface and security senses. Deleting a cache 1140 entry for a Known HSTS Host should be a very deliberate and 1141 well-considered act -- it shouldn't be something users get 1142 used to just "clicking through" in order to get work done. 1143 Also, implementations need to guard against allowing an 1144 attacker to inject code, e.g. ECMAscript, into the UA that 1145 silently and programmatically removes entries from the UA's 1146 cache of Known HSTS Hosts. 1148 12. Constructing an Effective Request URI 1150 This section specifies how an HSTS Host must construct the Effective 1151 Request URI for a received HTTP request. 1153 HTTP requests often do not carry an absoluteURI for the target 1154 resource; instead, the URI needs to be inferred from the Request-URI, 1155 Host header field, and connection context ([RFC2616], Sections 3.2.1 1156 and 5.1.2). The result of this process is called the "effective 1157 request URI (ERU)". The "target resource" is the resource identified 1158 by the effective request URI. 1160 12.1. ERU Fundamental Definitions 1162 The first line of an HTTP request message, Request-Line, is specified 1163 by the following ABNF from [RFC2616], Section 5.1: 1165 Request-Line = Method SP Request-URI SP HTTP-Version CRLF 1167 The Request-URI, within the Request-Line, is specified by the 1168 following ABNF from [RFC2616], Section 5.1.2: 1170 Request-URI = "*" | absoluteURI | abs_path | authority 1172 The Host request header field is specified by the following ABNF from 1173 [RFC2616], Section 14.23: 1175 Host = "Host" ":" host [ ":" port ] 1177 12.2. Determining the Effective Request URI 1179 If the Request-URI is an absoluteURI, then the effective request URI 1180 is the Request-URI. 1182 If the Request-URI uses the abs_path form or the asterisk form, and 1183 the Host header field is present, then the effective request URI is 1184 constructed by concatenating: 1186 o the scheme name: "http" if the request was received over an 1187 insecure TCP connection, or "https" when received over a TLS/ 1188 SSL-secured TCP connection, and, 1190 o the octet sequence "://", and, 1192 o the host, and the port (if present), from the Host header field, 1193 and 1195 o the Request-URI obtained from the Request-Line, unless the 1196 Request-URI is just the asterisk "*". 1198 If the Request-URI uses the abs_path form or the asterisk form, and 1199 the Host header field is not present, then the effective request URI 1200 is undefined. 1202 Otherwise, when Request-URI uses the authority form, the effective 1203 request URI is undefined. 1205 Effective request URIs are compared using the rules described in 1206 [RFC2616] Section 3.2.3, except that empty path components MUST NOT 1207 be treated as equivalent to an absolute path of "/". 1209 12.2.1. Effective Request URI Examples 1211 Example 1: the effective request URI for the message 1213 GET /pub/WWW/TheProject.html HTTP/1.1 1214 Host: www.example.org:8080 1216 (received over an insecure TCP connection) is "http", plus "://", 1217 plus the authority component "www.example.org:8080", plus the 1218 request-target "/pub/WWW/TheProject.html". Thus it is: 1219 "http://www.example.org:8080/pub/WWW/TheProject.html". 1221 Example 2: the effective request URI for the message 1223 OPTIONS * HTTP/1.1 1224 Host: www.example.org 1226 (received over an SSL/TLS secured TCP connection) is "https", plus 1227 "://", plus the authority component "www.example.org". Thus it is: 1228 "https://www.example.org". 1230 13. Internationalized Domain Names for Applications (IDNA): Dependency 1231 and Migration 1233 Textual domain names on the modern Internet may contain one or more 1234 "internationalized" domain name labels. Such domain names are 1235 referred to as "internationalized domain names" (IDNs). The 1236 specification suites defining IDNs and the protocols for their use 1237 are named "Internationalized Domain Names for Applications (IDNA)". 1238 At this time, there are two such specification suites: IDNA2008 1239 [RFC5890] and its predecessor IDNA2003 [RFC3490]. 1241 IDNA2008 obsoletes IDNA2003, but there are differences between the 1242 two specifications, and thus there can be differences in processing 1243 (e.g., converting) domain name labels that have been registered under 1244 one from those registered under the other. There will be a 1245 transition period of some time during which IDNA2003-based domain 1246 name labels will exist in the wild. User agents SHOULD implement 1247 IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of 1248 [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. 1249 If a user agent does not implement IDNA2008, the user agent MUST 1250 implement IDNA2003. 1252 14. Security Considerations 1253 14.1. Ramifications of HSTS Policy Establishment only over Error-free 1254 Secure Transport 1256 The User Agent Processing Model defined in Section 8, stipulates that 1257 a host is initially noted as a Known HSTS Host, or that updates are 1258 made to a Known HSTS Host's cached information, only if the UA 1259 receives the STS header field over a secure transport connection 1260 having no underlying secure transport errors or warnings. 1262 The rationale behind this is that if there is a man-in-the-middle 1263 (MITM) -- whether a legitimately deployed proxy or an illegitimate 1264 entity -- it could cause various mischief (see also Appendix A 1265 "Design Decision Notes", item 3, as well as Section 14.4 "Bootstrap 1266 MITM Vulnerability" ), for example: 1268 o Unauthorized notation of the host as a Known HSTS Host, 1269 potentially leading to a denial of service situation if the host 1270 does not uniformly offer its services over secure transport (see 1271 also Section 14.3 "Denial of Service". 1273 o Resetting the time-to-live for the host's designation as a Known 1274 HSTS Host by manipulating the max-age header field parameter value 1275 that is returned to the UA. If max-age is returned as zero, this 1276 will cause the host to no longer be regarded as an Known HSTS Host 1277 by the UA, leading to either insecure connections to the host or 1278 possibly denial-of-service if the host delivers its services only 1279 over secure transport. 1281 However, this means that if a UA is "behind" a proxy -- within a 1282 corporate intranet, for example -- and interacts with an unknown HSTS 1283 Host beyond the proxy, the user will possibly be presented with the 1284 legacy secure connection error dialogs. And even if the risk is 1285 accepted and the user clicks-through, the host will not be noted as a 1286 HSTS Host. Thus as long as the UA is behind such a proxy the user 1287 will be vulnerable, and possibly be presented with the legacy secure 1288 connection error dialogs for as yet unknown HSTS Hosts. 1290 But once the UA successfully connects to an unknown HSTS Host over 1291 error-free secure transport, the host will be noted as a Known HSTS 1292 Host. This will result in the failure of subsequent connection 1293 attempts from behind interfering proxies. 1295 The above discussion relates to the recommendation in Section 11 1296 "User Agent Implementation Advice" that the secure connection be 1297 terminated with "no user recourse" whenever there are warnings and 1298 errors and the host is a Known HSTS Host. Such a posture protects 1299 users from "clicking through" security warnings and putting 1300 themselves at risk. 1302 14.2. The Need for includeSubDomains 1304 Without the includeSubDomains directive, a web application would not 1305 be able to adequately protect so-called "domain cookies" (even if 1306 these cookies have their "Secure" flag set and thus are conveyed only 1307 on secure channels). These are cookies the web application expects 1308 UAs to return to any and all subdomains of the web application. 1310 For example, suppose example.com represents the top-level DNS name 1311 for a web application. Further suppose that this cookie is set for 1312 the entire example.com domain, i.e. it is a "domain cookie", and it 1313 has its Secure flag set. Suppose example.com is a Known HSTS Host 1314 for this UA, but the includeSubDomains flag is not set. 1316 Now, if an attacker causes the UA to request a subdomain name that is 1317 unlikely to already exist in the web application, such as 1318 "https://uxdhbpahpdsf.example.com/", but the attacker has established 1319 somewhere and registered in the DNS, then: 1321 1. The UA is unlikely to already have an HSTS policy established for 1322 "uxdhbpahpdsf.example.com", and, 1324 2. The HTTP request sent to uxdhbpahpdsf.example.com will include 1325 the Secure-flagged domain cookie. 1327 3. If "uxdhbpahpdsf.example.com" returns a certificate during TLS 1328 establishment, and the user clicks through any warning that might 1329 be annunciated (it is possible, but not certain, that one may 1330 obtain a requisite certificate for such a domain name such that a 1331 warning may or may not appear), then the attacker can obtain the 1332 Secure-flagged domain cookie that's ostensibly being protected. 1334 Without the "includeSubDomains" directive, HSTS is unable to protect 1335 such Secure-flagged domain cookies. 1337 14.3. Denial of Service 1339 HSTS could be used to mount certain forms of Denial-of- Service (DoS) 1340 attacks against web sites. A DoS attack is an attack in which one or 1341 more network entities target a victim entity and attempt to prevent 1342 the victim from doing useful work. This section discusses such 1343 scenarios in terms of HSTS, though this list is not exhaustive. See 1344 also [RFC4732] for a discussion of overall Internet DoS 1345 considerations. 1347 o Web applications available over HTTP 1349 There is an opportunity for perpetrating DoS attacks with web 1350 applications that are -- or critical portions of them are -- 1351 available only over HTTP without secure transport, if attackers 1352 can cause UAs to set HSTS Policy for such web applications' 1353 host(s). 1355 This is because once the HSTS Policy is set for a web 1356 application's host in a UA, the UA will only use secure transport 1357 to communicate with the host. If the host is not using secure 1358 transport, or is not for critical portions of its web application, 1359 then the web application will be rendered unusable for the UA's 1360 user. 1362 An HSTS Policy can be set for a victim host in various ways: 1364 * If the web application has a HTTP response splitting 1365 vulnerability [CWE-113] (which can be abused in order to 1366 facilitate "HTTP Header Injection"). 1368 * If an attacker can spoof a redirect from an insecure victim 1369 site, e.g., to , 1370 where the latter is attacker-controlled and has an apparently 1371 valid certificate, then the attacker can set an HSTS Policy for 1372 example.com, and also for all subdomains of example.com. 1374 * If an attacker can convince users to manually configure HSTS 1375 Policy for a victim host, assuming their UAs offer this 1376 capability (see Section 11 "User Agent Implementation Advice"). 1377 Or if such UA configuration is scriptable, and the attacker can 1378 cause UAs to execute his script. 1380 o Inadvertent use of includeSubDomains 1382 The includeSubDomains directive instructs UAs to automatically 1383 regard all subdomains of the given HSTS Host as Known HSTS Hosts. 1384 If any such subdomains do not support properly configured secure 1385 transport, then they will be rendered unreachable from such UAs. 1387 14.4. Bootstrap MITM Vulnerability 1389 The bootstrap MITM (Man-In-The-Middle) vulnerability is a 1390 vulnerability users and HSTS Hosts encounter in the situation where 1391 the user manually enters, or follows a link, to an unknown HSTS Host 1392 using a "http" URI rather than a "https" URI. Because the UA uses an 1393 insecure channel in the initial attempt to interact with the 1394 specified server, such an initial interaction is vulnerable to 1395 various attacks [ForceHTTPS] . 1397 Note: There are various features/facilities that UA implementations 1398 may employ in order to mitigate this vulnerability. Please 1399 see Section 11 "User Agent Implementation Advice". 1401 14.5. Network Time Attacks 1403 Active network attacks can subvert network time protocols (such as 1404 NTP [RFC5905]) - making HSTS less effective against clients that 1405 trust NTP or lack a real time clock. Network time attacks are beyond 1406 the scope of this specification. Note that modern operating systems 1407 use NTP by default. See also Section 2.10 of [RFC4732]. 1409 14.6. Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack 1411 If an attacker can convince users of, say, https://bank.example.com 1412 (which is protected by HSTS Policy), to install their own version of 1413 a root CA certificate purporting to be bank.example.com's CA, e.g., 1414 via a phishing email message with a link to such a certificate. 1415 Then, if they can perform an attack on the users' DNS, (e.g., via 1416 cache poisoning) and turn on HSTS Policy for their fake 1417 bank.example.com site, then they have themselves some new users. 1419 14.7. Creative Manipulation of HSTS Policy Store 1421 Since an HSTS Host may select its own host name and subdomains 1422 thereof, and this information is cached in the HSTS Policy store of 1423 conforming UAs, it is possible for those who control a HSTS Host(s) 1424 to encode information into domain names they control and cause such 1425 UAs to cache this information as a matter of course in the process of 1426 noting the HSTS Host. This information can be retrieved by other 1427 hosts through clever loaded page construction causing the UA to send 1428 queries to (variations of) the encoded domain names. Such queries 1429 can reveal whether the UA had prior visited the original HSTS Host 1430 (and subdomains). 1432 Such a technique could potentially be abused as yet another form of 1433 "web tracking" [WebTracking]. 1435 14.8. Internationalized Domain Names 1437 Internet security relies in part on the DNS and the domain names it 1438 hosts. Domain names are used by users to identify and connect to 1439 Internet hosts and other network resources. For example, Internet 1440 security is compromised if a user entering an internationalized 1441 domain name (IDN) is connected to different hosts based on different 1442 interpretations of the IDN. 1444 The processing models specified in this specification assume that the 1445 domain names they manipulate are IDNA-canonicalized, and that the 1446 canonicalization process correctly performed all appropriate IDNA and 1447 Unicode validations and character list testing per the requisite 1448 specifications (e.g., as noted in Section 9 "Domain Name IDNA- 1449 Canonicalization"). These steps are necessary in order to avoid 1450 various potentially compromising situations. 1452 In brief, some examples of issues that could stem from lack of 1453 careful and consistent Unicode and IDNA validations are things such 1454 as unexpected processing exceptions, truncation errors, and buffer 1455 overflows, as well as false-positive and/or false-negative domain 1456 name matching results. Any of the foregoing issues could possibly be 1457 leveraged by attackers in various ways. 1459 Additionally, IDNA2008 [RFC5890] differs from IDNA2003 [RFC3490] in 1460 terms of disallowed characters and character mapping conventions. 1461 This situation can also lead to false-positive and/or false-negative 1462 domain name matching results, resulting in, for example, users 1463 possibly communicating with unintended hosts, or not being able to 1464 reach intended hosts. 1466 For details, refer to the Security Considerations sections of 1467 [RFC5890], [RFC5891], and [RFC3490], as well as the specifications 1468 they normatively reference. Additionally, [RFC5894] provides 1469 detailed background and rationale for IDNA2008 in particular, as well 1470 as IDNA and its issues in general, and should be consulted in 1471 conjunction with the former specifications. 1473 15. IANA Considerations 1475 Below is the Internet Assigned Numbers Authority (IANA) Permanent 1476 Message Header Field registration information per [RFC3864]. 1478 Header field name: Strict-Transport-Security 1479 Applicable protocol: HTTP 1480 Status: standard 1481 Author/Change controller: IETF 1482 Specification document(s): this one 1484 16. References 1486 16.1. Normative References 1488 [I-D.ietf-dane-protocol] 1489 Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1490 of Named Entities (DANE) Protocol for Transport Layer 1491 Security (TLS)", draft-ietf-dane-protocol-19 (work in 1492 progress), April 2012. 1494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1495 Requirement Levels", BCP 14, RFC 2119, March 1997. 1497 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1498 Adams, "X.509 Internet Public Key Infrastructure Online 1499 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1501 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1502 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1503 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1505 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1507 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1508 "Internationalizing Domain Names in Applications (IDNA)", 1509 RFC 3490, March 2003. 1511 This specification is referenced due to its ongoing 1512 relevance to actual deployments for the foreseeable 1513 future. 1515 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1516 for Internationalized Domain Names in Applications 1517 (IDNA)", RFC 3492, March 2003. 1519 This specification is referenced due to its ongoing 1520 relevance to actual deployments for the foreseeable 1521 future. 1523 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1524 Procedures for Message Header Fields", BCP 90, RFC 3864, 1525 September 2004. 1527 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1528 Resource Identifier (URI): Generic Syntax", STD 66, 1529 RFC 3986, January 2005. 1531 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1532 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1534 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1535 Housley, R., and W. Polk, "Internet X.509 Public Key 1536 Infrastructure Certificate and Certificate Revocation List 1537 (CRL) Profile", RFC 5280, May 2008. 1539 [RFC5890] Klensin, J., "Internationalized Domain Names for 1540 Applications (IDNA): Definitions and Document Framework", 1541 RFC 5890, August 2010. 1543 [RFC5891] Klensin, J., "Internationalized Domain Names in 1544 Applications (IDNA): Protocol", RFC 5891, August 2010. 1546 [RFC5894] Klensin, J., "Internationalized Domain Names for 1547 Applications (IDNA): Background, Explanation, and 1548 Rationale", RFC 5894, August 2010. 1550 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 1551 Internationalized Domain Names in Applications (IDNA) 1552 2008", RFC 5895, September 2010. 1554 [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility 1555 Processing", Unicode Technical Standards # 46, 2010, 1556 . 1558 [Unicode] The Unicode Consortium, "The Unicode Standard", 1559 . 1561 [W3C.REC-html401-19991224] 1562 Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 1563 Specification", World Wide Web Consortium 1564 Recommendation REC-html401-19991224, December 1999, 1565 . 1567 16.2. Informative References 1569 [Aircrack-ng] 1570 d'Otreppe, T., "Aircrack-ng", Accessed: 11-Jul-2010, 1571 . 1573 [BeckTews09] 1574 Beck, M. and E. Tews, "Practical Attacks Against WEP and 1575 WPA", Second ACM Conference on Wireless Network 1576 Security Zurich, Switzerland, 2009, . 1580 [CWE-113] "CWE-113: Improper Neutralization of CRLF Sequences in 1581 HTTP Headers ('HTTP Response Splitting')", Common Weakness 1582 Enumeration , The Mitre 1583 Corporation , 1584 . 1586 [Firesheep] 1587 Various, "Firesheep", Wikipedia Online, on-going, 1588 . 1591 [ForceHTTPS] 1592 Jackson, C. and A. Barth, "ForceHTTPS: Protecting High- 1593 Security Web Sites from Network Attacks", In Proceedings 1594 of the 17th International World Wide Web Conference 1595 (WWW2008) , 2008, 1596 . 1598 [GoodDhamijaEtAl05] 1599 Good, N., Dhamija, R., Grossklags, J., Thaw, D., 1600 Aronowitz, S., Mulligan, D., and J. Konstan, "Stopping 1601 Spyware at the Gate: A User Study of Privacy, Notice and 1602 Spyware", In Proceedings of Symposium On Usable Privacy 1603 and Security (SOUPS) Pittsburgh, PA, USA, July 2005, . 1607 [I-D.ietf-tls-ssl-version3] 1608 Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol 1609 Version 3.0", draft-ietf-tls-ssl-version3-00 (work in 1610 progress), November 1996, . 1613 This is the canonical reference for SSLv3.0. 1615 [JacksonBarth2008] 1616 Jackson, C. and A. Barth, "Beware of Finer-Grained 1617 Origins", Web 2.0 Security and Privacy Oakland, CA, USA, 1618 2008, 1619 . 1622 [RFC1035] Mockapetris, P., "Domain names - implementation and 1623 specification", STD 13, RFC 1035, November 1987. 1625 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 1626 Service Considerations", RFC 4732, December 2006. 1628 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1629 RFC 4949, August 2007. 1631 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1632 Time Protocol Version 4: Protocol and Algorithms 1633 Specification", RFC 5905, June 2010. 1635 [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure 1636 Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, 1637 August 2011. 1639 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1640 April 2011. 1642 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1643 December 2011. 1645 [SunshineEgelmanEtAl09] 1646 Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and 1647 L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning 1648 Effectiveness", In Proceedings of 18th USENIX Security 1649 Symposium Montreal, Canada, Augus 2009, . 1653 [W3C.REC-wsc-ui-20100812] 1654 Saldhana, A. and T. Roessler, "Web Security Context: User 1655 Interface Guidelines", World Wide Web Consortium 1656 Recommendation REC-wsc-ui-20100812, August 2010, 1657 . 1659 [WEBSEC] "WebSec -- HTTP Application Security Minus Authentication 1660 and Transport", 1661 . 1663 Mailing list for IETF WebSec Working Group. [RFCEditor: 1664 please remove this reference upon publication as an RFC.] 1666 [WebTracking] 1667 Schmucker, N., "Web Tracking", SNET2 Seminar Paper Summer 1668 Term, 2011, . 1671 [owaspTLSGuide] 1672 Coates, M., Wichers, d., Boberski, M., and T. Reguly, 1673 "Transport Layer Protection Cheat Sheet", Accessed: 11- 1674 Jul-2010, . 1677 Appendix A. Design Decision Notes 1679 This appendix documents various design decisions. 1681 1. Cookies aren't appropriate for HSTS Policy expression as they are 1682 potentially mutable (while stored in the UA), therefore an HTTP 1683 header field is employed. 1685 2. We chose to not attempt to specify how "mixed security context 1686 loads" (aka "mixed content loads") are handled due to UA 1687 implementation considerations as well as classification 1688 difficulties. 1690 3. A HSTS Host may update UA notions of HSTS Policy via new HSTS 1691 header field parameter values. We chose to have UAs honor the 1692 "freshest" information received from a server because there is 1693 the chance of a web site sending out an errornous HSTS Policy, 1694 such as a multi-year max-age value, and/or an incorrect 1695 includeSubDomains flag. If the HSTS Host couldn't correct such 1696 errors over protocol, it would require some form of annunciation 1697 to users and manual intervention on the users' part, which could 1698 be a non-trivial problem for both web application providers and 1699 their users. 1701 4. HSTS Hosts are identified only via domain names -- explicit IP 1702 address identification of all forms is excluded. This is for 1703 simplification and also is in recognition of various issues with 1704 using direct IP address identification in concert with PKI-based 1705 security. 1707 Appendix B. Differences between HSTS Policy and Same-Origin Policy 1709 HSTS Policy has the following primary characteristics: 1711 HSTS Policy stipulates requirements for the security 1712 characteristics of UA-to-host connection establishment, on a per- 1713 host basis. 1715 Hosts explicitly declare HSTS Policy to UAs. Conformant UAs are 1716 obliged to implement hosts' declared HSTS Policies. 1718 HSTS Policy is conveyed over protocol from the host to the UA. 1720 The UA maintains a cache of Known HSTS Hosts. 1722 UAs apply HSTS Policy whenever making a HTTP connection to a Known 1723 HSTS Host, regardless of host port number. I.e., it applies to 1724 all ports on a Known HSTS Host. Hosts are unable to affect this 1725 aspect of HSTS Policy. 1727 Hosts may optionally declare that their HSTS Policy applies to all 1728 subdomains of their host domain name. 1730 In contrast, the Same-Origin Policy (SOP) [RFC6454] has the following 1731 primary characteristics: 1733 An origin is the scheme, host, and port of a URI identifying a 1734 resource. 1736 A UA may dereference a URI, thus loading a representation of the 1737 resource the URI identifies. UAs label resource representations 1738 with their origins, which are derived from their URIs. 1740 The SOP refers to a collection of principles, implemented within 1741 UAs, governing the isolation of and communication between resource 1742 representations within the UA, as well as resource 1743 representations' access to network resources. 1745 In summary, although both HSTS Policy and SOP are enforced by UAs, 1746 HSTS Policy is optionally declared by hosts and is not origin-based, 1747 while the SOP applies to all resource representations loaded from all 1748 hosts by conformant UAs. 1750 Appendix C. Acknowledgments 1752 The authors thank Devdatta Akhawe, Michael Barrett, Tobias Gondrom, 1753 Paul Hoffman, Murray Kucherawy, James Manger, Alexey Melnikov, Yoav 1754 Nir, Laksh Raghavan, Marsh Ray, Julian Reschke, Tom Ritter, Peter 1755 Saint-Andre, Sid Stamm, Maciej Stachowiak, Andy Steingrubl, Brandon 1756 Sterne, Martin Thomson, Daniel Veditz, as well as all the websec 1757 working group participants and others for their review and 1758 contributions. 1760 Thanks to Julian Reschke for his elegant re-writing of the effective 1761 request URI text, which he did when incorporating the ERU notion into 1762 the HTTPbis work. Subsequently, the ERU text in this spec was lifted 1763 from Julian's work in [I-D.draft-ietf-httpbis-p1-messaging-17] and 1764 adapted to the [RFC2616] ABNF. 1766 Appendix D. Change Log 1768 [RFCEditor: please remove this section upon publication as an RFC.] 1770 Changes are grouped by spec revision listed in reverse issuance 1771 order. 1773 D.1. For draft-ietf-websec-strict-transport-sec 1775 Changes from -06 to -07: 1777 1. Various minor/modest editorial tweaks throughout as I went 1778 through it pursuing the below issue tickets. Viewing a visual 1779 diff against -06 revision recommended. 1781 2. fixed some minor editorial issues noted in review by Alexey, 1782 fixes noted in here: 1785 3. Addressed ABNF exposition issues, specifically inclusion of 1786 quoted-string syntax for directive values. Fix STS header 1787 ABNF such that a leading ";" isn't required. Add example of 1788 quoted-string-encoded max-age-value. This addresses (re- 1789 opened) issue ticket #33. 1790 1792 4. Reworked sections 8.1 through 8.3 to ensure matching algorithm 1793 and resultant HSTS Policy application is more clear, and that 1794 it is explicitly stipulated to not muck with attributes of 1795 superdomain matching Known HSTS Hosts. This addresses issue 1796 ticket #37. 1797 1799 5. Added reference to [I-D.ietf-dane-protocol], pared back 1800 extraneous discussion in section 2.2, and updated discussion 1801 in 10.2 to accomodate TLSA (nee DANE). This addresses issue 1802 ticket #39. 1803 1805 6. Addressed various editorial items from issue ticket #40. 1806 1808 7. Loosened up the language regarding redirecting "http" requests 1809 to "https" in section 7.2 such that future flavors of 1810 permanent redirects are accommodated. This addresses issue 1811 ticket #43. 1812 1814 8. Reworked the terminology and language in Section 9, in 1815 particular defining the term "putative domain name string" to 1816 replace "valid Unicode-encoded string-serialized domain name". 1817 This addresses issue ticket #44. 1818 1820 Changes from -05 to -06: 1822 1. Addressed various editorial comments provided by Tobias G. 1823 This addresses issue ticket #38. 1824 1826 Changes from -04 to -05: 1828 1. Fixed up references to move certain ones back to the normative 1829 section -- as requested by Alexey M. Added explanation for 1830 referencing obsoleted [RFC3490] and [RFC3492]. This addresses 1831 issue ticket #36. 1832 1834 2. Made minor change to Strict-Transport-Security header field 1835 ABNF in order to address further feedback as appended to 1836 ticket #33. This addresses issue ticket #33. 1837 1839 Changes from -03 to -04: 1841 1. Clarified that max-age=0 will cause UA to forget a known HSTS 1842 host, and more generally clarified that the "freshest" info 1843 from the HSTS host is cached, and thus HSTS hosts are able to 1844 alter the cached max-age in UAs. This addresses issue ticket 1845 #13. 1847 2. Updated section on "Constructing an Effective Request URI" to 1848 remove remaining reference to RFC3986 and reference RFC2616 1849 instead. Further addresses issue ticket #14. 1850 1852 3. Addresses further ABNF issues noted in comment:1 of issue 1853 ticket #27. 1856 4. Reworked the introduction to clarify the denotation of "HSTS 1857 policy" and added the new Appendix B summarizing the primary 1858 characteristics of HSTS Policy and Same-Origin Policy, and 1859 identifying their differences. Added ref to [RFC4732]. This 1860 addresses issue ticket #28. 1861 1863 5. Reworked language in Section 2.3.1.3. wrt "mixed content", 1864 more clearly explain such vulnerability, disambiguate "mixed 1865 content" in web security context from its usage in markup 1866 language context. This addresses issue ticket #29. 1867 1869 6. Expanded Denial of Service discussion in Security 1870 Considerations. Added refs to [RFC4732] and [CWE-113]. This 1871 addresses issue ticket #30. 1872 1874 7. Mentioned in prose the case-insensitivity of directive names. 1875 This addresses issue ticket #31. 1876 1878 8. Added Section 10.3 "Implications of includeSubDomains". This 1879 addresses issue ticket #32. 1880 1882 9. Further refines text and ABNF definitions of STS header field 1883 directives. Retains use of quoted-string in directive 1884 grammar. This addresses issue ticket #33. 1885 1887 10. Added Section 14.7 "Creative Manipulation of HSTS Policy 1888 Store", including reference to [WebTracking]. This addresses 1889 issue ticket #34. 1890 1892 11. Added Section 14.1 "Ramifications of HSTS Policy 1893 Establishment only over Error-free Secure Transport" and made 1894 some accompanying editorial fixes in some other sections. 1895 This addresses issue ticket #35. 1896 1898 12. Refined references. Cleaned out un-used ones, updated to 1899 latest RFCs for others, consigned many to Informational. 1900 This addresses issue ticket #36. 1901 1903 13. Fixed-up some inaccuracies in the "Changes from -02 to -03" 1904 section. 1906 Changes from -02 to -03: 1908 1. Updated section on "Constructing an Effective Request URI" to 1909 remove references to RFC3986. Addresses issue ticket #14. 1910 1912 2. Reference RFC5890 for IDNA, retaining subordinate refs to 1913 RFC3490. Updated IDNA-specific language, e.g. domain name 1914 canonicalization and IDNA dependencies. Addresses issue 1915 ticket #26 1916 . 1918 3. Completely re-wrote the STS header ABNF to be fully based on 1919 RFC2616, rather than a hybrid of RFC2616 and httpbis. 1920 Addresses issue ticket #27 1921 . 1923 Changes from -01 to -02: 1925 1. Updated Section 8.3 "URI Loading and Port Mapping" fairly 1926 thoroughly in terms of refining the presentation of the 1927 steps, and to ensure the various aspects of port mapping are 1928 clear. Nominally fixes issue ticket #1 1929 1931 2. Removed dependencies on 1932 [I-D.draft-ietf-httpbis-p1-messaging-15]. Thus updated STS 1933 ABNF in Section 6.1 "Strict-Transport-Security HTTP Response 1934 Header Field" by lifting some productions entirely from 1935 [I-D.draft-ietf-httpbis-p1-messaging-15] and leveraging 1936 [RFC2616]. Addresses issue ticket #2 1937 . 1939 3. Updated Effective Request URI section and definition to use 1940 language from [I-D.draft-ietf-httpbis-p1-messaging-15] and 1941 ABNF from [RFC2616]. Fixes issue ticket #3 1942 . 1944 4. Added explicit mention that the HSTS policy applies to all 1945 TCP ports of a host advertising the HSTS policy. Nominally 1946 fixes issue ticket #4 1947 1949 5. Clarified the need for the "includeSubDomains" directive, 1950 e.g. to protect Secure-flagged domain cookies. In 1951 Section 14.2 "The Need for includeSubDomains". Nominally 1952 fixes issue ticket #5 1953 1955 6. Cited Firesheep as real-live threat in Section 2.3.1.1 1956 "Passive Network Attackers". Nominally fixes issue ticket #6 1957 . 1959 7. Added text to Section 11 "User Agent Implementation Advice" 1960 justifying connection termination due to tls warnings/errors. 1961 Nominally fixes issue ticket #7 1962 . 1964 8. Added new subsection Section 8.6 "Missing Strict-Transport- 1965 Security Response Header Field". Nominally fixes issue 1966 ticket #8 1967 . 1969 9. Added text to Section 8.4 "Errors in Secure Transport 1970 Establishment" explicitly note revocation check failures as 1971 errors causing connection termination. Added references to 1972 [RFC5280] and [RFC2560]. Nominally fixes issue ticket #9 1973 . 1975 10. Added a sentence, noting that distributing specific end- 1976 entity certificates to browsers will also work for self- 1977 signed/private-CA cases, to Section 10 "Server Implementation 1978 and Deployment Advice" Nominally fixes issue ticket #10 1979 . 1981 11. Moved "with no user recourse" language from Section 8.4 1982 "Errors in Secure Transport Establishment" to Section 11 1983 "User Agent Implementation Advice". This nominally fixes 1984 issue ticket #11 1985 . 1987 12. Removed any and all dependencies on 1988 [I-D.draft-ietf-httpbis-p1-messaging-15], instead depending 1989 on [RFC2616] only. Fixes issue ticket #12 1990 . 1992 13. Removed the inline "XXX1" issue because no one had commented 1993 on it and it seems reasonable to suggest as a SHOULD that web 1994 apps should redirect incoming insecure connections to secure 1995 connections. 1997 14. Removed the inline "XXX2" issue because it was simply for 1998 raising consciousness about having some means for 1999 distributing secure web application metadata. 2001 15. Removed "TODO1" because description prose for "max-age" in 2002 the Note following the ABNF in Section 6 seems to be fine. 2004 16. Decided for "TODO2" that "the first STS header field wins". 2005 TODO2 had read: "Decide UA behavior in face of encountering 2006 multiple HSTS headers in a message. Use first header? 2007 Last?". Removed TODO2. 2009 17. Added Section 1.1 "Organization of this specification" for 2010 readers' convenience. 2012 18. Moved design decision notes to be a proper appendix 2013 Appendix A. 2015 Changes from -00 to -01: 2017 1. Changed the "URI Loading" section to be "URI Loading and Port 2018 Mapping". 2020 2. [HASMAT] reference changed to [WEBSEC]. 2022 3. Changed "server" -> "host" where applicable, notably when 2023 discussing "HSTS Hosts". Left as "server" when discussing 2024 e.g. "http server"s. 2026 4. Fixed minor editorial nits. 2028 Changes from draft-hodges-strict-transport-sec-02 to 2029 draft-ietf-websec-strict-transport-sec-00: 2031 1. Altered spec metadata (e.g. filename, date) in order to submit 2032 as a WebSec working group Internet-Draft. 2034 D.2. For draft-hodges-strict-transport-sec 2036 Changes from -01 to -02: 2038 1. updated abstract such that means for expressing HSTS Policy 2039 other than via HSTS header field is noted. 2041 2. Changed spec title to "HTTP Strict Transport Security (HSTS)" 2042 from "Strict Transport Security". Updated use of "STS" 2043 acronym throughout spec to HSTS (except for when specifically 2044 discussing syntax of Strict-Transport-Security HTTP Response 2045 Header field), updated "Terminology" appropriately. 2047 3. Updated the discussion of "Passive Network Attackers" to be 2048 more precise and offered references. 2050 4. Removed para on nomative/non-normative from "Conformance 2051 Criteria" pending polishing said section to IETF RFC norms. 2053 5. Added examples subsection to "Syntax" section. 2055 6. Added OWS to maxAge production in Strict-Transport-Security 2056 ABNF. 2058 7. Cleaned up explanation in the "Note:" in the "HTTP-over- 2059 Secure-Transport Request Type" section, folded 3d para into 2060 "Note:", added conformance clauses to the latter. 2062 8. Added exaplanatory "Note:" and reference to "HTTP Request 2063 Type" section. Added "XXX1" issue. 2065 9. Added conformance clause to "URI Loading". 2067 10. Moved "Notes for STS Server implementors:" from "UA 2068 Implementation dvice " to "HSTS Policy expiration time 2069 considerations:" in "Server Implementation Advice", and also 2070 noted another option. 2072 11. Added cautionary "Note:" to "Ability to delete UA's cached 2073 HSTS Policy on a per HSTS Server basis". 2075 12. Added some informative references. 2077 13. Various minor editorial fixes. 2079 Changes from -00 to -01: 2081 1. Added reference to HASMAT mailing list and request that this 2082 spec be discussed there. 2084 Authors' Addresses 2086 Jeff Hodges 2087 PayPal 2088 2211 North First Street 2089 San Jose, California 95131 2090 US 2092 Email: Jeff.Hodges@PayPal.com 2094 Collin Jackson 2095 Carnegie Mellon University 2097 Email: collin.jackson@sv.cmu.edu 2099 Adam Barth 2100 Google, Inc. 2102 Email: ietf@adambarth.com 2103 URI: http://www.adambarth.com/