idnits 2.17.1 draft-ietf-websec-strict-transport-sec-03.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 507 has weird spacing: '...TS Host is a...' -- The document date (October 31, 2011) is 4554 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-16' is mentioned on line 1451, but not defined == Missing Reference: 'I-D.draft-ietf-httpbis-p1-messaging-15' is mentioned on line 1541, but not defined == Missing Reference: 'HASMAT' is mentioned on line 1573, but not defined == Unused Reference: 'RFC1983' is defined on line 1251, but no explicit reference was found in the text == Unused Reference: 'RFC3454' is defined on line 1273, but no explicit reference was found in the text == Unused Reference: 'RFC3492' is defined on line 1281, but no explicit reference was found in the text == Unused Reference: 'RFC2396' is defined on line 1380, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1594 (Obsoleted by RFC 2664) ** Downref: Normative reference to an Informational RFC: RFC 1983 ** Obsolete normative reference: RFC 2109 (Obsoleted by RFC 2965) ** 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 2965 (Obsoleted by RFC 6265) ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Downref: Normative reference to an Informational RFC: RFC 4949 ** 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. 'Unicode6' -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2396 (Obsoleted by RFC 3986) Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hodges 3 Internet-Draft PayPal 4 Intended status: Standards Track C. Jackson 5 Expires: May 3, 2012 Carnegie Mellon University 6 A. Barth 7 Google, Inc. 8 October 31, 2011 10 HTTP Strict Transport Security (HSTS) 11 draft-ietf-websec-strict-transport-sec-03 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, e.g. user agent configuration. 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 May 3, 2012. 40 Copyright Notice 42 Copyright (c) 2011 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. 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. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 5.1. Strict-Transport-Security HTTP Response Header Field . . . 12 79 5.1.1. max-age . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.1.2. includeSubDomains . . . . . . . . . . . . . . . . . . 13 81 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 6. Server Processing Model . . . . . . . . . . . . . . . . . . . 14 83 6.1. HTTP-over-Secure-Transport Request Type . . . . . . . . . 14 84 6.2. HTTP Request Type . . . . . . . . . . . . . . . . . . . . 15 85 7. User Agent Processing Model . . . . . . . . . . . . . . . . . 15 86 7.1. Strict-Transport-Security Response Header Field 87 Processing . . . . . . . . . . . . . . . . . . . . . . . . 16 88 7.1.1. Noting a HSTS Host . . . . . . . . . . . . . . . . . . 17 89 7.1.2. Known HSTS Host Domain Name Matching . . . . . . . . . 17 90 7.2. URI Loading and Port Mapping . . . . . . . . . . . . . . . 18 91 7.3. Errors in Secure Transport Establishment . . . . . . . . . 19 92 7.4. HTTP-Equiv Element Attribute . . . . . . . . . . . 19 93 7.5. Interstitially Missing Strict-Transport-Security 94 Response Header Field . . . . . . . . . . . . . . . . . . 19 95 8. Domain Name IDNA-Canonicalization . . . . . . . . . . . . . . 19 96 9. Server Implementation Advice . . . . . . . . . . . . . . . . . 20 97 10. UA Implementation Advice . . . . . . . . . . . . . . . . . . . 21 98 11. Internationalized Domain Names for Applications (IDNA): 99 Dependency and Migration . . . . . . . . . . . . . . . . . . . 23 100 12. Constructing an Effective Request URI . . . . . . . . . . . . 23 101 12.1. ERU Fundamental Definitions . . . . . . . . . . . . . . . 23 102 12.2. Determining the Effective Requrest URI . . . . . . . . . . 24 103 12.2.1. Effective Requrest URI Examples . . . . . . . . . . . 24 104 13. Security Considerations . . . . . . . . . . . . . . . . . . . 25 105 13.1. The Need for includeSubDomains . . . . . . . . . . . . . . 25 106 13.2. Internationalized Domain Names . . . . . . . . . . . . . . 26 107 13.3. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 26 108 13.4. Bootstrap MITM Vulnerability . . . . . . . . . . . . . . . 27 109 13.5. Network Time Attacks . . . . . . . . . . . . . . . . . . . 27 110 13.6. Bogus Root CA Certificate Phish plus DNS Cache 111 Poisoning Attack . . . . . . . . . . . . . . . . . . . . . 27 112 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 113 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 114 15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 115 15.2. Informative References . . . . . . . . . . . . . . . . . . 29 116 Appendix A. Design Decision Notes . . . . . . . . . . . . . . . . 31 117 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 32 118 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 32 119 C.1. For draft-ietf-websec-strict-transport-sec . . . . . . . . 32 120 C.2. For draft-hodges-strict-transport-sec . . . . . . . . . . 35 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 123 1. Introduction 125 [ Please disscuss this draft on the WebSec@ietf.org mailing list 126 [WEBSEC]. ] 128 The HTTP protocol [RFC2616] may be used over various transports, 129 typically the Transmission Control Protocol (TCP) [RFC0793]. 130 However, TCP does not provide channel integrity protection, 131 confidentiality, nor secure host identification. Thus the Secure 132 Sockets Layer (SSL) protocol [I-D.ietf-tls-ssl-version3] and its 133 successor Transport Layer Security (TLS) [RFC4346], were developed in 134 order to provide channel-oriented security, and are typically layered 135 between application protocols and TCP. [RFC2818] specifies how HTTP 136 is layered onto TLS, and defines the Uniform Resource Identifier 137 (URI) scheme of "https" (in practice however, HTTP user agents (UAs) 138 typically offer their users choices among SSL2, SSL3, and TLS for 139 secure transport). URIs themselves are specified in [RFC3986]. 141 UAs employ various local security policies with respect to the 142 characteristics of their interactions with web resources depending on 143 (in part) whether they are communicating with a given web resource 144 using HTTP or HTTP-over-a-Secure-Transport. For example, cookies 145 ([RFC2109] and [RFC2965]) may be flagged as Secure. UAs are to send 146 such Secure cookies to their addressed host only over a secure 147 transport. This is in contrast to non-Secure cookies, which are 148 returned to the host regardless of transport (although modulo other 149 rules). 151 UAs typically annunciate to their users any issues with secure 152 connection establishment, such as being unable to validate a TLS 153 server certificate trust chain, or if a TLS server certificate is 154 expired, or if a TLS server's domain name appears incorrectly in the 155 TLS server certificate (see section 3.1 of [RFC2818]). Often, UAs 156 enable users to elect to continue to interact with a web resource in 157 the face of such issues. This behavior is sometimes referred to as 158 "click(ing) through" security [GoodDhamijaEtAl05] 159 [SunshineEgelmanEtAl09], and thus can be described as "click-through 160 insecurity". 162 A key vulnerability enabled by click-through insecurity is the 163 leaking of any cookies the web application may be using to manage a 164 user's session. The threat here is that the attacker could obtain 165 the cookies and then interact with the legitimate web application 166 while posing as the user. 168 Jackson and Barth proposed an approach, in [ForceHTTPS], to enable 169 web applications and/or users to declare that any interactions with 170 the web application must be conducted securely, and that any issues 171 with establishing a secure session are to be treated as fatal and 172 without direct user recourse. The aim is to prevent users from 173 unintentionally downgrading their security. 175 This specification embodies and refines the approach proposed in 176 [ForceHTTPS], i.e. instead of using a cookie it defines and uses an 177 HTTP response header field, named "Strict-Transport-Security", to 178 convey the site HSTS policy to the UA. This specification also 179 incorporates notions from [JacksonBarth2008] in that the HSTS policy 180 is applied on an "entire-host" basis: it applies to all TCP ports on 181 the host. Additionally, HSTS policy can be applied to the entire 182 domain name subtree rooted at a given host name. This enables HSTS 183 to protect so-called "domain cookies", which are applied to all 184 subdomains of a given domain. 186 1.1. Organization of this specification 188 This specification begins with an overview of the use cases, policy 189 effects, threat models, and requirements for HSTS (in Section 2). 190 Then, Section 3 defines conformance requirements. The HSTS mechanism 191 itself is formally specified in Section 4 through Section 14. 193 2. Overview 195 This section discusses the use cases, summarizes the HTTP Strict 196 Transport Security (HSTS) policy, and continues with a discussion of 197 the threat model, non-addressed threats, and derived requirements. 199 2.1. Use Cases 201 The high-level use case is a combination of: 203 o Web browser user wishes to interact with various web sites (some 204 arbitrary, some known) in a secure fashion. 206 o Web site deployer wishes to offer their site in an explicitly 207 secure fashion for both their own, as well as their users', 208 benefit. 210 2.2. Strict Transport Security Policy Effects 212 The characteristics of the HTTP Strict Transport Security policy, as 213 applied by a UA in its interactions with a web site wielding HSTS 214 Policy, known as a HSTS Host, is summarized as follows: 216 1. All insecure ("http") connections to any TCP ports on a HSTS Host 217 are redirected by the HSTS Host to be secure connections 218 ("https"). 220 2. The UA terminates any secure transport connection attempts upon 221 any and all secure transport errors or warnings, including those 222 caused by a web application presenting self-signed certificates. 224 3. UAs transform insecure URI references to a HSTS Host into secure 225 URI references before dereferencing them. 227 2.3. Threat Model 229 HSTS is concerned with three threat classes: passive network 230 attackers, active network attackers, and imperfect web developers. 231 However, it is explicitly not a remedy for two other classes of 232 threats: phishing and malware. Addressed and not addressed threats 233 are briefly discussed below. Readers may wish refer to [ForceHTTPS] 234 for details as well as relevant citations. 236 2.3.1. Threats Addressed 238 2.3.1.1. Passive Network Attackers 240 When a user browses the web on a local wireless network (e.g. an 241 802.11-based wireless local area network) a nearby attacker can 242 possibly eavesdrop on the user's unencrypted Internet Protocol-based 243 connections, such as HTTP, regardless of whether or not the local 244 wireless network itself is secured [BeckTews09]. Freely available 245 wireless sniffing toolkits, e.g. [Aircrack-ng], enable such passive 246 eavesdropping attacks, even if the local wireless network is 247 operating in a secure fashion. A passive network attacker using such 248 tools can steal session identifiers/cookies and hijack the user's web 249 session(s), by obtaining cookies containing authentication 250 credentials [ForceHTTPS]. For example, there exist widely-available 251 tools, such as Firesheep (a Firefox extension) [Firesheep], which 252 enable their wielder to obtain other local users' session cookies for 253 various web applications. 255 To mitigate such threats, some Web sites support, but usually do not 256 force, access using end-to-end secure transport -- e.g. signaled 257 through URIs constructed with the "https" scheme [RFC2818]. This can 258 lead users to believe that accessing such services using secure 259 transport protects them from passive network attackers. 260 Unfortunately, this is often not the case in real-world deployments 261 as session identifiers are often stored in non-Secure cookies to 262 permit interoperability with versions of the service offered over 263 insecure transport ("Secure cookes" are those cookies containing the 264 "Secure" attribute [RFC2109]). For example, if the session 265 identifier for a web site (an email service, say) is stored in a non- 266 Secure cookie, it permits an attacker to hijack the user's session if 267 the user's UA makes a single insecure HTTP request to the site. 269 2.3.1.2. Active Network Attackers 271 A determined attacker can mount an active attack, either by 272 impersonating a user's DNS server or, in a wireless network, by 273 spoofing network frames or offering a similarly-named evil twin 274 access point. If the user is behind a wireless home router, an 275 attacker can attempt to reconfigure the router using default 276 passwords and other vulnerabilities. Some sites, such as banks, rely 277 on end-to-end secure transport to protect themselves and their users 278 from such active attackers. Unfortunately, browsers allow their 279 users to easily opt-out of these protections in order to be usable 280 for sites that incorrectly deploy secure transport, for example by 281 generating and self-signing their own certificates (without also 282 distributing their CA certificate to their users' browsers). 284 2.3.1.3. Web Site Development and Deployment Bugs 286 The security of an otherwise uniformly secure site (i.e. all of its 287 content is materialized via "https" URIs), can be compromised 288 completely by an active attacker exploiting a simple mistake, such as 289 the loading of a cascading style sheet or a SWF movie over an 290 insecure connection (both cascading style sheets and SWF movies can 291 script the embedding page, to the surprise of many web developers -- 292 most browsers do not issue mixed content warnings when insecure SWF 293 files are embedded). Even if the site's developers carefully 294 scrutinize their login page for mixed content, a single insecure 295 embedding anywhere on the site compromises the security of their 296 login page because an attacker can script (control) the login page by 297 injecting script into the page with mixed content. 299 Note: "Mixed content" here refers to the same notion referred to as 300 "mixed security context" later elsewhere in this 301 specification. 303 2.3.2. Threats Not Addressed 305 2.3.2.1. Phishing 307 Phishing attacks occur when an attacker solicits authentication 308 credentials from the user by hosting a fake site located on a 309 different domain than the real site, perhaps driving traffic to the 310 fake site by sending a link in an email message. Phishing attacks 311 can be very effective because users find it difficult to distinguish 312 the real site from a fake site. HSTS is not a defense against 313 phishing per se; rather, it complements many existing phishing 314 defenses by instructing the browser to protect session integrity and 315 long-lived authentication tokens [ForceHTTPS]. 317 2.3.2.2. Malware and Browser Vulnerabilities 319 Because HSTS is implemented as a browser security mechanism, it 320 relies on the trustworthiness of the user's system to protect the 321 session. Malicious code executing on the user's system can 322 compromise a browser session, regardless of whether HSTS is used. 324 2.4. Requirements 326 This section identifies and enumerates various requirements derived 327 from the use cases and the threats discussed above, and lists the 328 detailed core requirements HTTP Strict Transport Security addresses, 329 as well as ancillary requirements that are not directly addressed. 331 2.4.1. Overall Requirement 333 o Minimize the risks to web browser users and web site deployers 334 that are derived from passive and active network attackers, web 335 site development and deployment bugs, as well as insecure user 336 actions. 338 2.4.1.1. Detailed Core Requirements 340 These core requirements are derived from the overall requirement, and 341 are addressed by this specification. 343 1. Web sites need to be able to declare to UAs that they should be 344 interacted with using a strict security policy. 346 2. Web sites need to be able to instruct UAs that contact them 347 insecurely to do so securely. 349 3. UAs need to note web sites that signal strict security policy 350 enablement, for a web site declared time span. 352 4. UAs need to re-write all insecure UA "http" URI loads to use the 353 "https" secure scheme for those web sites for which secure policy 354 is enabled. 356 5. Web site administrators need to be able to signal strict security 357 policy application to subdomains of higher-level domains for 358 which strict security policy is enabled, and UAs need to enforce 359 such policy. 361 6. For example, both example.com and foo.example.com could set 362 policy for bar.foo.example.com. 364 7. UAs need to disallow security policy application to peer domains, 365 and/or higher-level domains, by domains for which strict security 366 policy is enabled. 368 8. For example, neither bar.foo.example.com nor foo.example.com can 369 set policy for example.com, nor can bar.foo.example.com set 370 policy for foo.example.com. Also, foo.example.com cannot set 371 policy for sibling.example.com. 373 9. UAs need to prevent users from clicking-through security 374 warnings. Halting connection attempts in the face of secure 375 transport exceptions is acceptable. 377 Note: A means for uniformly securely meeting the first core 378 requirement above is not specifically addressed by this 379 specification (see Section 13.4 "Bootstrap MITM 380 Vulnerability"). It may be addressed by a future revision of 381 this specification or some other specification. Note also 382 that there are means by which UA implementations may more 383 fully meet the first core requirement, see Section 10 "UA 384 Implementation Advice". 386 2.4.1.2. Detailed Ancillary Requirements 388 These ancillary requirements are also derived from the overall 389 requirement. They are not normatively addressed in this 390 specification, but could be met by UA implementations at their 391 implementor's discretion, although meeting these requirements may be 392 complex. 394 1. Disallow "mixed security context" (also known as "mixed-content") 395 loads (see section 5.3 "Mixed Content" in 396 [W3C.WD-wsc-ui-20100309]). 398 2. Facilitate user declaration of web sites for which strict 399 security policy is enabled, regardless of whether the sites 400 signal HSTS Policy. 402 3. Conformance Criteria 404 This specification is written for hosts and user agents (UAs). 406 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 407 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 408 document are to be interpreted as described in [RFC2119]. 410 A conformant host is one that implements all the requirements listed 411 in this specification that are applicable to hosts. 413 A conformant user agent is one that implements all the requirements 414 listed in this specification that are applicable to user agents. 416 3.1. Document Conventions 418 Note: ..is a note to the reader. These are points that should be 419 expressly kept in mind and/or considered. 421 Warning: This is how a warning is shown. These are things that can 422 have suboptimal downside risks if not heeded. 424 4. Terminology 426 Terminology is defined in this section. 428 ASCII case-insensitive comparison 429 means comparing two strings exactly, codepoint for 430 codepoint, except that the characters in the range 431 U+0041 .. U+005A (i.e. LATIN CAPITAL LETTER A to 432 LATIN CAPITAL LETTER Z) and the corresponding 433 characters in the range U+0061 .. U+007A (i.e. 434 LATIN SMALL LETTER A to LATIN SMALL LETTER Z) are 435 considered to also match. See [Unicode6] for 436 details. 438 codepoint is a colloquial contraction of Code Point, which is 439 any value in the Unicode codespace; that is, the 440 range of integers from 0 to 10FFFF(hex) [Unicode6]. 442 domain name domain names, also referred to as DNS Names, are 443 defined in [RFC1035] to be represented outside of 444 the DNS protocol itself (and implementations 445 thereof) as a series of labels separated by dots, 446 e.g. "example.com" or "yet.another.example.org". 447 In the context of this specification, domain names 448 appear in that portion of a URI satisfying the reg- 449 name production in "Appendix A. Collected ABNF for 450 URI" in [RFC3986], and the host component from the 451 Host HTTP header field production in section 14.23 452 of [RFC2616]. 454 Note: The domain names appearing in actual URI 455 instances and matching the aforementioned 456 production components may or may not be 457 FQDNs. 459 domain name label is that portion of a domain name appearing "between 460 the dots", i.e. consider "foo.example.com": "foo", 461 "example", and "com" are all domain name labels. 463 Effective Request URI 464 is a URI, identifying the target resource, that can 465 be inferred by an HTTP host for any given HTTP 466 request it receives. Such inference is necessary 467 because HTTP requests often do not contain a 468 complete "absolute" URI identifying the target 469 resource. See Section 12 "Constructing an 470 Effective Request URI", below. 472 FQDN is an acronym for Fully-qualified domain name. A 473 FQDN is a domain name that includes all higher 474 level domains relevant to the named entity 475 (typically a HSTS Host in the context of this 476 specification). If one thinks of the DNS as a 477 tree-structure with each node having its own domain 478 name label, a FQDN for a specific node would be its 479 label followed by the labels of all the other nodes 480 between it and the root of the tree. For example, 481 for a host, a FQDN would include the label that 482 identifies the particular host, plus all domains of 483 which the host is a part, up to and including the 484 top-level domain (the root domain is always null) 485 [RFC1594]. 487 HTTP Strict Transport Security 488 is the overall name for the combined UA- and 489 server-side security policy defined by this 490 specification. 492 HTTP Strict Transport Security Host 493 is a HTTP host implementing the server aspects of 494 the HSTS policy. 496 HTTP Strict Transport Security Policy 497 is the name of the combined overall UA- and server- 498 side facets of the behavior specified in this 499 specification. 501 HSTS See HTTP Strict Transport Security. 503 HSTS Host See HTTP Strict Transport Security Host. 505 HSTS Policy See HTTP Strict Transport Security Policy. 507 Known HSTS Host is a HSTS Host for which the UA has a HSTS Policy 508 in effect. 510 Local policy is comprised of policy rules deployers specify and 511 which are often manifested as "configuration 512 settings". 514 MITM is an acronym for man-in-the-middle. See "man-in- 515 the-middle attack" in [RFC4949]. 517 Request URI is the URI used to cause a UA to issue an HTTP 518 request message. 520 UA is a an acronym for user agent. For the purposes 521 of this specification, a UA is an HTTP client 522 application typically actively manipulated by a 523 user [RFC2616] . 525 5. Syntax 527 This section defines the syntax of the new header this specification 528 introduces. It also provides a short description of the function the 529 header. 531 The Section 6 "Server Processing Model" section details how hosts are 532 to use this header. Likewise, the Section 7 "User Agent Processing 533 Model" section details how user agents are to use this header. 535 5.1. Strict-Transport-Security HTTP Response Header Field 537 The Strict-Transport-Security HTTP response header field indicates to 538 a UA that it MUST enforce the HSTS Policy in regards to the host 539 emitting the response message containing this header field. 541 The ABNF syntax for the Strict-Transport-Security HTTP Response 542 Header field is: 544 Strict-Transport-Security = "Strict-Transport-Security" ":" 545 directive *( ";" [ directive ] ) 547 STS directives: 549 directive = max-age | includeSubDomains | STS-d-ext 551 max-age = "max-age" "=" delta-seconds 553 includeSubDomains = "includeSubDomains" 555 The max-age directive MUST appear once in the Strict-Transport- 556 Security header field value. The includeSubDomains directive MAY 557 appear once. The order of appearance of directives in the Strict- 558 Transport-Security header field value is not significant. 560 Additional directives extending the the semantic functionality of the 561 Strict-Transport-Security header field may be defined in other 562 specifications, using the STS directive extension point (STS-d-ext) 563 syntax: 565 STS-d-ext = token [ "=" ( token | quoted-string ) ] 567 Defined in [RFC2616]: 569 delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2> 570 token = 571 quoted-string = 573 5.1.1. max-age 575 max-age specifies the number of seconds, after the recption of the 576 Strict-Transport-Security HTTP Response Header, during which the UA 577 regards the host the message was received from as a Known HSTS Host 578 (see also Section 7.1.1 "Noting a HSTS Host", below). The delta- 579 seconds production is specified in [RFC2616]. 581 5.1.2. includeSubDomains 583 includeSubDomains is a flag which, if present, signals to the UA that 584 the HSTS Policy applies to this HSTS Host as well as any subdomains 585 of the host's FQDN. 587 5.2. Examples 589 The below HSTS header field stipulates that the HSTS policy is to 590 remain in effect for one year (there are approximately 31 536 000 591 seconds in a year), and the policy applies only to the domain of the 592 HSTS Host issuing it: 594 Strict-Transport-Security: max-age=31536000 596 The below HSTS header field stipulates that the HSTS policy is to 597 remain in effect for approximately six months and the policy applies 598 only to the domain of the issuing HSTS Host and all of its 599 subdomains: 601 Strict-Transport-Security: max-age=15768000 ; includeSubDomains 603 6. Server Processing Model 605 This section describes the processing model that HSTS Hosts 606 implement. The model is comprised of two facets: the first being the 607 processing rules for HTTP request messages received over a secure 608 transport (e.g. TLS [RFC4346], SSL [I-D.ietf-tls-ssl-version3], or 609 perhaps others, the second being the processing rules for HTTP 610 request messages received over non-secure transports, i.e. over 611 TCP/IP [RFC0793]. 613 6.1. HTTP-over-Secure-Transport Request Type 615 When replying to an HTTP request that was conveyed over a secure 616 transport, a HSTS Host SHOULD include in its response message a 617 Strict-Transport-Security HTTP Response Header that MUST satisfy the 618 grammar specified above in Section 5.1 "Strict-Transport-Security 619 HTTP Response Header Field". If a Strict-Transport-Security HTTP 620 Response Header is included, the HSTS Host MUST include only one such 621 header. 623 Note: Including the Strict-Transport-Security HTTP Response Header 624 is stipulated as a "SHOULD" in order to accomodate various 625 server- and network-side caches and load-balancing 626 configurations where it may be difficult to uniformly emit 627 Strict-Transport-Security HTTP Response Headers on behalf of a 628 given HSTS Host. 630 Establishing a given host as a Known HSTS Host, in the context 631 of a given UA, MAY be accomplished over the HTTP protocol by 632 correctly returning, per this specification, at least one 633 valid Strict-Transport-Security HTTP Response Header to the 634 UA. Other mechanisms, such as a client-side pre-loaded Known 635 HSTS Host list MAY also be used. E.g. see Section 10 "UA 636 Implementation Advice". 638 6.2. HTTP Request Type 640 If a HSTS Host receives a HTTP request message over a non-secure 641 transport, it SHOULD send a HTTP response message containing a 642 Status-Code of 301 and a Location header field value containing 643 either the HTTP request's original Effective Request URI (see 644 Section 12 "Constructing an Effective Request URI", below) altered as 645 necessary to have a URI scheme of "https", or a URI generated 646 according to local policy (which SHOULD employ a URI scheme of 647 "https"). 649 Note: The above behavior is a "SHOULD" rather than a "MUST" because: 651 * There are risks in server-side non-secure-to-secure redirects 652 [owaspTLSGuide]. 654 * Site deployment characteristics -- e.g. a site that 655 incorporates third-party components may not behave correctly 656 when doing server-side non-secure-to-secure redirects in the 657 case of being accessed over non-secure transport, but does 658 behave correctly when accessed uniformly over secure transport. 659 The latter is the case given a HSTS-capapble UA that has 660 already noted the site as a Known HSTS Host (by whatever means, 661 e.g. prior interaction or UA configuration). 663 A HSTS Host MUST NOT include the Strict-Transport-Security HTTP 664 Response Header in HTTP responses conveyed over non-secure transport. 666 7. User Agent Processing Model 668 This section describes the HTTP Strict Transport Security processing 669 model for UAs. There are several facets to the model, enumerated by 670 the following subsections. 672 This processing model assumes that the UA implements IDNA2008 673 [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 11 674 "Internationalized Domain Names for Applications (IDNA): Dependency 675 and Migration". It also assumes that all domain names manipulated in 676 this specification's context are already IDNA-canonicalized as 677 outlined in Section 8 "Domain Name IDNA-Canonicalization" prior to 678 the processing specified in this section. 680 The above assumptions mean that this processing model also 681 specifically assumes that appropriate IDNA and Unicode validations 682 and character list testing have occured on the domain names, in 683 conjunction with their IDNA-canonicalization, prior to the processing 684 specified in this section. See the IDNA-specific security 685 considerations in Section 13.2 "Internationalized Domain Names" for 686 rationale and further details. 688 7.1. Strict-Transport-Security Response Header Field Processing 690 If an HTTP response, received over a secure transport, includes a 691 Strict-Transport-Security HTTP Response Header field, conforming to 692 the grammar specified in Section 5.1 "Strict-Transport-Security HTTP 693 Response Header Field" (above), and there are no underlying secure 694 transport errors or warnings (see Section 7.3, below), the UA MUST 695 either: 697 o Note the host as a Known HSTS Host if it is not already so noted 698 (see Section 7.1.1 "Noting a HSTS Host", below), 700 or, 702 o Update its cached information for the Known HSTS Host if the max- 703 age and/or includeSubDomains header field value tokens are 704 conveying information different than that already maintained by 705 the UA. 707 Note: The max-age value is essentially a "time to live" value 708 relative to the reception time of the Strict-Transport- 709 Security HTTP Response Header. 711 If a UA receives more than one Strict-Transport-Security 712 header field in a HTTP response message over secure transport, 713 then the UA MUST process only the first such header field. 715 Otherwise: 717 o If an HTTP response is received over insecure transport, the UA 718 MUST ignore any present Strict-Transport-Security HTTP Response 719 Header(s). 721 o The UA MUST ignore any Strict-Transport-Security HTTP Response 722 Headers not conforming to the grammar specified in Section 5.1 723 "Strict-Transport-Security HTTP Response Header Field" (above). 725 7.1.1. Noting a HSTS Host 727 If the substring matching the host production from the Request-URI, 728 that the host responded to, syntactically matches the IP-literal or 729 IPv4address productions from section 3.2.2 of [RFC3986], then the UA 730 MUST NOT note this host as a Known HSTS Host. 732 Otherwise, if the substring does not congruently match a presently 733 known HSTS Host, per the matching procedure specified in 734 Section 7.1.2 "Known HSTS Host Domain Name Matching" below, then the 735 UA MUST note this host as a Known HSTS Host, caching the HSTS Host's 736 domain name and noting along with it the expiry time of this 737 information, as effectively stipulated per the given max-age value, 738 as well as whether the includeSubDomains flag is asserted or not. 740 7.1.2. Known HSTS Host Domain Name Matching 742 A UA determines whether a domain name represents a Known HSTS Host by 743 looking for a match between the query Domain Name and the UA's set of 744 Known HSTS Hosts. 746 1. Compare the query domain name string with the Domain Names of the 747 UA's set of Known HSTS Hosts. For each Known HSTS Host's domain 748 name, the comparison is done with the query domain name label-by- 749 label using an ASCII case-insensitive comparison beginning with 750 the rightmost label, and continuing right-to-left, and ignoring 751 separator characters (see clause 3.1(4) of [RFC3986]. 753 * If a label-for-label match between an entire Known HSTS Host's 754 domain name and a right-hand portion of the query domain name 755 is found, then the Known HSTS Host's domain name is a 756 superdomain match for the query domain name. 758 For example: 760 Query Domain Name: bar.foo.example.com 762 Superdomain matched 763 Known HSTS Host DN: foo.example.com 765 At this point, the query domain name is ascertained to 766 effectively represent a Known HSTS Host. There may also be 767 additional matches further down the domain name label tree, up 768 to and including a congruent match. 770 * If a label-for-label match between a Known HSTS Host's domain 771 name and the query domain name is found, i.e. there are no 772 further labels to compare, then the query domain name 773 congruently matches this Known HSTS Host. 775 For example: 777 Query Domain Name: foo.example.com 779 Congruently matched 780 Known HSTS Host DN: foo.example.com 782 The query domain name is ascertained to represent a Known HSTS 783 Host. However, if there are also superdomain matches, the one 784 highest in the tree asserts the HSTS Policy for this Known 785 HSTS Host. 787 * Otherwise, if no matches are found, the query domain name does 788 not represent a Known HSTS Host. 790 7.2. URI Loading and Port Mapping 792 Whenever the UA prepares to "load", also known as "dereference", any 793 URI where the host component of the authority component of the URI 794 [RFC3986] matches that of a Known HSTS Host (either as a congruent 795 match or as a superdomain match where the superdomain Known HSTS Host 796 has includeSubDomains asserted), then before proceeding with the 797 load: 799 If the URI's scheme is "http", then the UA MUST replace the URI 800 scheme with "https", and, 802 if the URI contains an explicit port component [RFC3986] of 803 "80", then the UA MUST convert the port component to be "443", 804 or, 806 if the URI contains an explicit port component that is not 807 equal to "80", the port component value MUST be preserved, 808 otherwise, 810 if the URI does not contain an explicit port component, the UA 811 MUST NOT add one. 813 Otherwise, if the URI's scheme is "https", then the UA MUST NOT 814 modify the URI before dereferencing it. 816 Note that the implication of the above steps is that the HSTS policy 817 applies to all TCP ports on a host advertising the HSTS policy. 819 7.3. Errors in Secure Transport Establishment 821 When connecting to a Known HSTS Host, the UA MUST terminate the 822 connection (see also Section 10 "UA Implementation Advice", below) if 823 there are any errors (e.g. certificate errors), whether "warning" or 824 "fatal" or any other error level, with the underlying secure 825 transport. This includes any issues with certificate revocation 826 checking whether via the Certificate Revocation List (CRL) [RFC5280], 827 or via the Online Certificate Status Protocol (OCSP) [RFC2560]. 829 7.4. HTTP-Equiv Element Attribute 831 UAs MUST NOT heed http-equiv="Strict-Transport-Security" attribute 832 settings on elements in received content. 834 7.5. Interstitially Missing Strict-Transport-Security Response Header 835 Field 837 If a UA receives HTTP responses from a Known HSTS Host over a secure 838 channel, but they are missing the Strict-Transport-Security Response 839 Header Field, the UA MUST continue to treat the host as a Known HSTS 840 Host until the max-age value for the knowledge that Known HSTS Host 841 is reached. Note that the max age could be infinite for a given 842 Known HSTS Host. For example, if the Known HSTS Host is part of a 843 pre-configured list that is implemented such that the list entries 844 never "age out". 846 8. Domain Name IDNA-Canonicalization 848 An IDNA-canonicalized domain name is the string generated by the 849 following algorithm, whose input must be a valid Unicode-encoded (in 850 NFC form [Unicode6]) string-serialized domain name: 852 1. Convert the domain name to a sequence of individual domain name 853 label strings. 855 2. When implementing IDNA2008, convert each label that is not a Non- 856 Reserved LDH (NR-LDH) label, to an A-label. See Section 2.3.2 of 857 [RFC5890] for definitions of the former and latter, refer to 858 Sections 5.3 through 5.5 of [RFC5891] for the conversion 859 algorithm and requisite input validation and character list 860 testing procedures. 862 Otherwise, when implementing IDNA2003, convert each label using 863 the "ToASCII" conversion in Section 4 of [RFC3490] (see also the 864 definition of "equivalence of labels" in Section 2 of the latter 865 specification). 867 3. Concatenate the resulting labels, separating each label from the 868 next with (".") a %x2E character. 870 See also Section 11 "Internationalized Domain Names for Applications 871 (IDNA): Dependency and Migration" and Section 13.2 "Internationalized 872 Domain Names" of this specification for further details and 873 considerations. 875 9. Server Implementation Advice 877 This section is non-normative. 879 HSTS Policy expiration time considerations: 881 o Server implementations and deploying web sites need to consider 882 whether they are setting an expiry time that is a constant value 883 into the future, e.g. by constantly sending the same max-age value 884 to UAs. For exmple: 886 Strict-Transport-Security: max-age=778000 888 A max-age value of 778000 is 90 days. Note that each receipt of 889 this header by a UA will require the UA to update its notion of 890 when it must delete its knowledge of this Known HSTS Host. The 891 specifics of how this is accomplished is out of the scope of this 892 specification. 894 o Or, whether they are setting an expiry time that is a fixed point 895 in time, e.g. by sending max-age values that represent the 896 remaining time until the expiry time. 898 o A consideration here is whether a deployer wishes to have signaled 899 HSTS Policy expiry time match that for the web site's domain 900 certificate. 902 Considerations for using HTTP Strict Transport Security in 903 conjunction with self-signed public-key certificates: 905 o If a web site/organization/enterprise is generating their own 906 secure transport public-key certificates for web sites, and that 907 organization's root certificate authority (CA) certificate is not 908 typically embedded by default in browser CA certificate stores, 909 and if HSTS Policy is enabled on a site identifying itself using a 910 self-signed certificate, then secure connections to that site will 911 fail, per the HSTS design. This is to protect against various 912 active attacks, as discussed above. 914 o However, if said organization strongly wishes to employ self- 915 signed certificates, and their own CA in concert with HSTS, they 916 can do so by deploying their root CA certificate to their users' 917 browsers. They can also, in addition or instead, distribute to 918 their users' browsers the end-entity certificate(s) for specific 919 hosts. There are various ways in which this can be accomplished 920 (details are out of scope for this specification). Once their 921 root CA cert is installed in the browsers, they may employ HSTS 922 Policy on their site(s). 924 Note: Interactively distributing root CA certs to users, e.g. via 925 email, and having the users install them, is arguably 926 training the users to be susceptible to a possible form of 927 phishing attack, see Section 13.6 "Bogus Root CA 928 Certificate Phish plus DNS Cache Poisoning Attack". 930 10. UA Implementation Advice 932 This section is non-normative. 934 In order to provide users and web sites more effective protection, UA 935 implementors should consider including features such as: 937 o Failing secure connection establishment on any warnings or errors, 938 as noted in Section 7.3 "Errors in Secure Transport 939 Establishment", should be done with no user recourse. This means 940 that the user should not be presented with an explanatory dialog 941 giving her the option to proceed. Rather, it should be treated 942 similarly to a server error where there is nothing further the 943 user can do with respect to interacting with the target web 944 application, other than wait and re-try. 946 Essentially, "any warnings or errors" means anything that would 947 cause the UA implementation to annunciate to the user that 948 something is not entirely correct with the connection 949 establishment. 951 Not doing this, i.e., allowing user recourse such as "clicking- 952 through warning/error dialogs", is a recipe for a Man-in-the- 953 Middle attack. If a web application advertises HSTS, then it is 954 opting into this scheme, whereby all certificate errors or 955 warnings cause a connection termination, with no chance to "fool" 956 the user into making the wrong decision and compromising 957 themselves. 959 o Disallowing "mixed security context" (also known as "mixed- 960 content") loads (see section 5.3 "Mixed Content" in 962 [W3C.WD-wsc-ui-20100309]). 964 Note: In order to provide behavioral uniformity across UA 965 implementations, the notion of mixed security context aka 966 mixed-content will require (further) standardization work, 967 e.g. to more clearly define the term(s) and to define 968 specific behaviors with respect to it. 970 In order to provide users effective controls for managing their UA's 971 caching of HSTS Policy, UA implementors should consider including 972 features such as: 974 o Ability to delete UA's cached HSTS Policy on a per HSTS Host 975 basis. 977 Note: Adding such a feature should be done very carefully in both 978 the user interface and security senses. Deleting a cache 979 entry for a Known HSTS Host should be a very deliberate and 980 well-considered act -- it shouldn't be something users get 981 used to just "clicking through" in order to get work done. 982 Also, it shouldn't be possible for an attacker to inject 983 script into the UA that silently and programmatically 984 removes entries from the UA's cache of Known HSTS Hosts. 986 In order to provide users and web sites more complete protection, UAs 987 could offer advanced features such as these: 989 o Ability for users to explicitly declare a given Domain Name as 990 representing a HSTS Host, thus seeding it as a Known HSTS Host 991 before any actual interaction with it. This would help protect 992 against the Section 13.4 "Bootstrap MITM Vulnerability". 994 Note: Such a feature is difficult to get right on a per-site 995 basis -- see the discussion of "rewrite rules" in section 996 5.5 of [ForceHTTPS]. For example, arbitrary web sites may 997 not materialize all their URIs using the "https" scheme, 998 and thus could "break" if a UA were to attempt to access 999 the site exclusively using such URIs. Also note that this 1000 feature would complement, but is independent of the 1001 following described facility. 1003 o Facility whereby web site administrators can have UAs pre- 1004 configured with HSTS Policy for their site(s) by the UA vendor(s) 1005 -- in a manner similar to how root CA certificates are embedded in 1006 browsers "at the factory". This would help protect against the 1007 Section 13.4 "Bootstrap MITM Vulnerability". 1009 Note: Such a facility complements the preceding described 1010 feature. 1012 11. Internationalized Domain Names for Applications (IDNA): Dependency 1013 and Migration 1015 Textual domain names on the modern Internet may contain one or more 1016 "internationalized" domain name labels. Such domain names are 1017 referred to as "internationalized domain names" (IDNs). The 1018 specification suites defining IDNs and the protocols for their use 1019 are named "Internationalized Domain Names for Applications (IDNA)". 1020 At this time, there are two such specification suites: IDNA2008 1021 [RFC5890] and its predecessor IDNA2003 [RFC3490]. 1023 IDNA2008 obsoletes IDNA2003, but there are differences between the 1024 two specifications, and thus there can be differences in processing 1025 (e.g. converting) domain name labels that have been registered under 1026 one from those registered under the other. There will be a 1027 transition period of some time during which IDNA2003-based domain 1028 name labels will exist in the wild. User agents SHOULD implement 1029 IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of 1030 [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. 1031 If a user agent does not implement IDNA2008, the user agent MUST 1032 implement IDNA2003. 1034 12. Constructing an Effective Request URI 1036 This section specifies how an HSTS Host must construct the Effective 1037 Request URI for a received HTTP request. 1039 HTTP requests often do not carry an absolute-URI ([RFC3986], Section 1040 4.3) for the target resource; instead, the URI needs to be inferred 1041 from the Request-URI, Host header field, and connection context. The 1042 result of this process is called the "effective request URI (ERU)". 1043 The "target resource" is the resource identified by the effective 1044 request URI. 1046 12.1. ERU Fundamental Definitions 1048 The first line of an HTTP request message, Request-Line, is specified 1049 by the following ABNF from [RFC2616], section 5.1: 1051 Request-Line = Method SP Request-URI SP HTTP-Version CRLF 1053 The Request-URI, within the Request-Line, is specified by the 1054 following ABNF from [RFC2616], section 5.1.2: 1056 Request-URI = "*" | absoluteURI | abs_path | authority 1058 The Host request header field is specified by the following ABNF from 1059 [RFC2616], section 14.23: 1061 Host = "Host" ":" host [ ":" port ] 1063 12.2. Determining the Effective Requrest URI 1065 If the Request-URI is an absoluteURI, then the effective request URI 1066 is the Request-URI. 1068 If the Request-URI uses the abs_path form or the asterisk form, and 1069 the Host header field is present, then the effective request URI is 1070 constructed by concatenating: 1072 o the scheme name: "http" if the request was received over an 1073 insecure TCP connection, or "https" when received over a TLS/ 1074 SSL-secured TCP connection, and, 1076 o the octet sequence "://", and, 1078 o the host, and the port (if present), from the Host header field, 1079 and 1081 o the Request-URI obtained from the Request-Line, unless the 1082 Request-URI is just the asterisk "*". 1084 If the Request-URI uses the abs_path form or the asterisk form, and 1085 the Host header field is not present, then the effective request URI 1086 is undefined. 1088 Otherwise, when Request-URI uses the authority form, the effective 1089 request URI is undefined. 1091 Effective request URIs are compared using the rules described in 1092 [RFC2616] Section 3.2.3, except that empty path components MUST NOT 1093 be treated as equivalent to an absolute path of "/". 1095 12.2.1. Effective Requrest URI Examples 1097 Example 1: the effective request URI for the message 1099 GET /pub/WWW/TheProject.html HTTP/1.1 1100 Host: www.example.org:8080 1102 (received over an insecure TCP connection) is "http", plus "://", 1103 plus the authority component "www.example.org:8080", plus the 1104 request-target "/pub/WWW/TheProject.html". Thus it is: 1105 "http://www.example.org:8080/pub/WWW/TheProject.html". 1107 Example 2: the effective request URI for the message 1109 OPTIONS * HTTP/1.1 1110 Host: www.example.org 1112 (received over an SSL/TLS secured TCP connection) is "https", plus 1113 "://", plus the authority component "www.example.org". Thus it is: 1114 "https://www.example.org". 1116 13. Security Considerations 1118 13.1. The Need for includeSubDomains 1120 Without the includeSubDomains directive, a web application would not 1121 be able to adequately protect so-called "domain cookies" (even if 1122 these cookies have their "Secure" flag set and thus are conveyed only 1123 on secure channels). These are cookies the web application expects 1124 UAs to return to any and all subdomains of the web application. 1126 For example, suppose example.com represents the top-level DNS name 1127 for a web application. Further suppose that this cookie is set for 1128 the entire example.com domain, i.e. it is a "domain cookie", and it 1129 has its Secure flag set. Suppose example.com is a Known HSTS Host 1130 for this UA, but the includeSubDomains flag is not set. 1132 Now, if an attacker causes the UA to request a subdomain name that is 1133 unlikely to already exist in the web application, such as 1134 "https://uxdhbpahpdsf.example.com/", but the attacker has established 1135 somewhere and registered in the DNS, then: 1137 1. The UA is unlikely to already have an HSTS policy established for 1138 "uxdhbpahpdsf.example.com", and, 1140 2. The HTTP request sent to uxdhbpahpdsf.example.com will include 1141 the Secure-flagged domain cookie. 1143 3. If "uxdhbpahpdsf.example.com" returns a certificate during TLS 1144 establishment, and the user clicks through any warning that might 1145 be annunciated (it is possible, but not certain, that one may 1146 obtain a requisite certificate for such a domain name such that a 1147 warning may or may not appear), then the attacker can obtain the 1148 Secure-flagged domain cookie that's ostensibly being protected. 1150 Without the "includeSubDomains" directive, HSTS is unable to protect 1151 such Secure-flagged domain cookies. 1153 13.2. Internationalized Domain Names 1155 Internet security relies in part on the DNS and the domain names it 1156 hosts. Domain names are used by users to identify and connect to 1157 Internet hosts and other network resources. For example, Internet 1158 security is compromised if a user entering an internationalized 1159 domain name (IDN) is connected to different hosts based on different 1160 interpretations of the IDN. 1162 The processing models specified in this specification assume that the 1163 domain names they manipulate are IDNA-canonicalized, and that the 1164 canonicalization process correctly performed all appropriate IDNA and 1165 Unicode validations and character list testing per the requisite 1166 specifications (e.g., as noted in Section 8 "Domain Name IDNA- 1167 Canonicalization"). These steps are necessary in order to avoid 1168 various potentially compromising situations. 1170 In brief, some examples of issues that could stem from lack of 1171 careful and consistent Unicode and IDNA validations are things such 1172 as unexpected processing exceptions, truncation errors, and buffer 1173 overflows, as well as false-positive and/or false-negative domain 1174 name matching results. Any of the foregoing issues could possibly be 1175 leveraged by attackers in various ways. 1177 Additionally, IDNA2008 [RFC5890] differs from IDNA2003 [RFC3490] in 1178 terms of disallowed characters and character mapping conventions. 1179 This situation can also lead to false-positive and/or false-negative 1180 domain name matching results, resulting in, for example, users 1181 possibly communicating with unintended hosts, or not being able to 1182 reach intended hosts. 1184 For details, refer to the Security Considerations sections of 1185 [RFC5890], [RFC5891], and [RFC3490], as well as the specifications 1186 they normatively reference. Additionally, [RFC5894] provides 1187 detailed background and rationale for IDNA2008 in particular, as well 1188 as IDNA and its issues in general, and should be consulted in 1189 conjunction with the former specifications. 1191 13.3. Denial of Service (DoS) 1193 HSTS could be used to mount certain forms of DoS attacks, where 1194 attackers cause UAs to set fake HSTS headers for legitimate sites 1195 available only insecurely (e.g. social network service sites, wikis, 1196 etc.). 1198 13.4. Bootstrap MITM Vulnerability 1200 The bootstrap MITM (Man-In-The-Middle) vulnerability is a 1201 vulnerability users and HSTS Hosts encounter in the situation where 1202 the user manually enters, or follows a link, to a HSTS Host using a 1203 "http" URI rather than a "https" URI. Because the UA uses an 1204 insecure channel in the initial attempt to interact with the 1205 specified serve, such an initial interaction is vulnerable to various 1206 attacks [ForceHTTPS] . 1208 Note: There are various features/facilities that UA implementations 1209 may employ in order to mitigate this vulnerability. Please 1210 see Section 10 UA Implementation Advice. 1212 13.5. Network Time Attacks 1214 Active network attacks can subvert network time protocols (like NTP) 1215 - making this header less effective against clients that trust NTP 1216 and/or lack a real time clock. Network time attacks are therefore 1217 beyond the scope of the defense. Note that modern operating systems 1218 use NTP by default. 1220 13.6. Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack 1222 If an attacker can convince users of, say, https://bank.example.com 1223 (which is protected by HSTS Policy), to install their own version of 1224 a root CA certificate purporting to be bank.example.com's CA, e.g. 1225 via a phishing email message with a link to such a certificate -- 1226 then, if they can perform an attack on the users' DNS, e.g. via cache 1227 poisoning, and turn on HSTS Policy for their fake bank.example.com 1228 site, then they have themselves some new users. 1230 14. IANA Considerations 1232 Below is the Internet Assigned Numbers Authority (IANA) Provisional 1233 Message Header Field registration information per [RFC3864]. 1235 Header field name: Strict-Transport-Security 1236 Applicable protocol: HTTP 1237 Status: provisional 1238 Author/Change controller: TBD 1239 Specification document(s): this one 1241 15. References 1242 15.1. Normative References 1244 [RFC1035] Mockapetris, P., "Domain names - implementation and 1245 specification", STD 13, RFC 1035, November 1987. 1247 [RFC1594] Marine, A., Reynolds, J., and G. Malkin, "FYI on Questions 1248 and Answers - Answers to Commonly asked "New Internet 1249 User" Questions", RFC 1594, March 1994. 1251 [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, 1252 August 1996. 1254 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 1255 Mechanism", RFC 2109, February 1997. 1257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1258 Requirement Levels", BCP 14, RFC 2119, March 1997. 1260 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1261 Adams, "X.509 Internet Public Key Infrastructure Online 1262 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1264 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1265 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1266 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1268 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1270 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 1271 Mechanism", RFC 2965, October 2000. 1273 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1274 Internationalized Strings ("stringprep")", RFC 3454, 1275 December 2002. 1277 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1278 "Internationalizing Domain Names in Applications (IDNA)", 1279 RFC 3490, March 2003. 1281 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1282 for Internationalized Domain Names in Applications 1283 (IDNA)", RFC 3492, March 2003. 1285 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1286 Procedures for Message Header Fields", BCP 90, RFC 3864, 1287 September 2004. 1289 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1290 Resource Identifier (URI): Generic Syntax", STD 66, 1291 RFC 3986, January 2005. 1293 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1294 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1296 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1297 RFC 4949, August 2007. 1299 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1300 Housley, R., and W. Polk, "Internet X.509 Public Key 1301 Infrastructure Certificate and Certificate Revocation List 1302 (CRL) Profile", RFC 5280, May 2008. 1304 [RFC5890] Klensin, J., "Internationalized Domain Names for 1305 Applications (IDNA): Definitions and Document Framework", 1306 RFC 5890, August 2010. 1308 [RFC5891] Klensin, J., "Internationalized Domain Names in 1309 Applications (IDNA): Protocol", RFC 5891, August 2010. 1311 [RFC5894] Klensin, J., "Internationalized Domain Names for 1312 Applications (IDNA): Background, Explanation, and 1313 Rationale", RFC 5894, August 2010. 1315 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 1316 Internationalized Domain Names in Applications (IDNA) 1317 2008", RFC 5895, September 2010. 1319 [Unicode6] 1320 The Unicode Consortium, "The Unicode Standard, Version 6.0 1321 - Core Specification", Unicode 6.0.0, Mountain View, CA, 1322 The Unicode Consortium ISBN 978-1-936213-01-6, 2011, 1323 . 1325 [W3C.WD-html5-20100304] 1326 Hyatt, D. and I. Hickson, "HTML5", World Wide Web 1327 Consortium WD WD-html5-20100304, March 2010, 1328 . 1330 15.2. Informative References 1332 [Aircrack-ng] 1333 d'Otreppe, T., "Aircrack-ng", Accessed: 11-Jul-2010, 1334 . 1336 [BeckTews09] 1337 Beck, M. and E. Tews, "Practical Attacks Against WEP and 1338 WPA", Second ACM Conference on Wireless Network 1339 Security Zurich, Switzerland, 2009, . 1343 [Firesheep] 1344 Various, "Firesheep", Wikipedia Online, on-going, 1345 . 1348 [ForceHTTPS] 1349 Jackson, C. and A. Barth, "ForceHTTPS: Protecting High- 1350 Security Web Sites from Network Attacks", In Proceedings 1351 of the 17th International World Wide Web Conference 1352 (WWW2008) , 2008, 1353 . 1355 [GoodDhamijaEtAl05] 1356 Good, N., Dhamija, R., Grossklags, J., Thaw, D., 1357 Aronowitz, S., Mulligan, D., and J. Konstan, "Stopping 1358 Spyware at the Gate: A User Study of Privacy, Notice and 1359 Spyware", In Proceedings of Symposium On Usable Privacy 1360 and Security (SOUPS) Pittsburgh, PA, USA, July 2005, . 1364 [I-D.ietf-tls-ssl-version3] 1365 Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol 1366 Version 3.0", draft-ietf-tls-ssl-version3 (work in 1367 progress), November 1996, . 1370 [JacksonBarth2008] 1371 Jackson, C. and A. Barth, "Beware of Finer-Grained 1372 Origins", Web 2.0 Security and Privacy Oakland, CA, USA, 1373 2008, 1374 . 1377 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1378 RFC 793, September 1981. 1380 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1381 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1382 August 1998. 1384 [SunshineEgelmanEtAl09] 1385 Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and 1386 L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning 1387 Effectiveness", In Proceedings of 18th USENIX Security 1388 Symposium Montreal, Canada, Augus 2009, . 1392 [UTS46] Davis, M. and M. Suignard, "Unicode IDNA Compatibility 1393 Processing", Unicode Technical Standards # 46, 2010, 1394 . 1396 [W3C.WD-wsc-ui-20100309] 1397 Saldhana, A. and T. Roessler, "Web Security Context: User 1398 Interface Guidelines", World Wide Web Consortium 1399 LastCall WD-wsc-ui-20100309, March 2010, 1400 . 1402 [WEBSEC] "WebSec -- HTTP Application Security Minus Authentication 1403 and Transport", 1404 . 1406 [owaspTLSGuide] 1407 Coates, M., Wichers, d., Boberski, M., and T. Reguly, 1408 "Transport Layer Protection Cheat Sheet", Accessed: 11- 1409 Jul-2010, . 1412 Appendix A. Design Decision Notes 1414 This appendix documents various design decisions. 1416 1. Cookies aren't appropriate for HSTS Policy expression as they are 1417 potentially mutable (while stored in the UA), therefore an HTTP 1418 header field is employed. 1420 2. We chose to not attempt to specify how "mixed security context 1421 loads" (aka "mixed-content loads") are handled due to UA 1422 implementation considerations as well as classification 1423 difficulties. 1425 3. A HSTS Host may update UA notions of HSTS Policy via new HSTS 1426 header field values. We chose to have UAs honor the "freshest" 1427 information received from a server because there is the chance of 1428 a web site sending out an errornous HSTS Policy, such as a multi- 1429 year max-age value, and/or an incorrect includeSubDomains flag. 1430 If the HSTS Host couldn't correct such errors over protocol, it 1431 would require some form of annunciation to users and manual 1432 intervention on their part, which could be a non-trivial problem. 1434 4. HSTS Hosts are identified only via domain names -- explicit IP 1435 address identification of all forms is excluded. This is for 1436 simplification and also is in recognition of various issues with 1437 using direct IP address identification in concert with PKI-based 1438 security. 1440 Appendix B. Acknowledgments 1442 The authors thank Devdatta Akhawe, Michael Barrett, Paul Hoffman, 1443 Yoav Nir, Julian Reschke, Tom Ritter, Peter Saint-Andre, Sid Stamm, 1444 Maciej Stachowiak, Andy Steingrubl, Brandon Sterne, Martin Thomson, 1445 Daniel Veditz, and all the other websec working group participants 1446 for their review and contributions. 1448 Thanks to Julian Reschke for his elegant re-writing of the effective 1449 request URI text, which he did when incorporating the ERU notion into 1450 the HTTPbis work. Subsequently, the ERU text in this spec was lifted 1451 from Julian's work in [I-D.draft-ietf-httpbis-p1-messaging-16] and 1452 adapted to the [RFC2616] ABNF. 1454 Appendix C. Change Log 1456 [RFCEditor: please remove this section upon publication as an RFC.] 1458 Changes are grouped by spec revision listed in reverse issuance 1459 order. 1461 C.1. For draft-ietf-websec-strict-transport-sec 1463 Changes from -02 to -03: 1465 1. Completely re-wrote the STS header ABNF to be fully based on 1466 RFC2616, rather than a hybrid of RFC2616 and httpbis. [ no 1467 submitted issue ticket as yet ] 1469 2. Updated section on "Constructing an Effective Request URI" to 1470 remove references to RFC3986. Addresses issue ticket #14. 1471 1473 3. Reference RFC5890 rather than RFC3490 for IDNA. Updated IDNA- 1474 specific language, e.g. domain name canonicalization and IDNA 1475 dependencies. [ no submitted issue ticket as yet ] 1477 Changes from -01 to -02: 1479 1. Updated Section 7.2 "URI Loading and Port Mapping" fairly 1480 thoroughly in terms of refining the presentation of the 1481 steps, and to ensure the various aspects of port mapping are 1482 clear. Nominally fixes issue ticket #1 1483 1485 2. Removed dependencies on 1486 [I-D.draft-ietf-httpbis-p1-messaging-15]. Thus updated STS 1487 ABNF in Section 5.1 "Strict-Transport-Security HTTP Response 1488 Header Field" by lifting some productions entirely from 1489 [I-D.draft-ietf-httpbis-p1-messaging-15] and leveraging 1490 [RFC2616]. Addresses issue ticket #2 1491 . 1493 3. Updated Effective Request URI section and definition to use 1494 language from [I-D.draft-ietf-httpbis-p1-messaging-15] and 1495 ABNF from [RFC2616]. Fixes issue ticket #3 1496 . 1498 4. Added explicit mention that the HSTS policy applies to all 1499 TCP ports of a host advertising the HSTS policy. Nominally 1500 fixes issue ticket #4 1501 1503 5. Clarified the need for the "includeSubDomains" directive, 1504 e.g. to protect Secure-flagged domain cookies. In 1505 Section 13.1 "The Need for includeSubDomains". Nominally 1506 fixes issue ticket #5 1507 1509 6. Cited Firesheep as real-live threat in Section 2.3.1.1 1510 "Passive Network Attackers". Nominally fixes issue ticket #6 1511 . 1513 7. Added text to Section 10 "UA Implementation Advice" 1514 justifying connection termination due to tls warnings/errors. 1515 Nominally fixes issue ticket #7 1516 . 1518 8. Added new subsection Section 7.5 "Interstitially Missing 1519 Strict-Transport-Security Response Header Field". Nominally 1520 fixes issue ticket #8 1521 . 1523 9. Added text to Section 7.3 "Errors in Secure Transport 1524 Establishment" explicitly note revocation check failures as 1525 errors causing connection termination. Added references to 1526 [RFC5280] and [RFC2560]. Nominally fixes issue ticket #9 1527 . 1529 10. Added a sentence, noting that distributing specific end- 1530 entity certs to browsers will also work for self-signed/ 1531 private-CA cases, to Section 9 "Server Implementation Advice" 1532 Nominally fixes issue ticket #10 1533 . 1535 11. Moved "with no user recourse" language from Section 7.3 1536 "Errors in Secure Transport Establishment" to Section 10 "UA 1537 Implementation Advice". This nominally fixes issue ticket 1538 #11 . 1540 12. Removed any and all dependencies on 1541 [I-D.draft-ietf-httpbis-p1-messaging-15], instead depending 1542 on [RFC2616] only. Fixes issue ticket #12 1543 . 1545 13. Removed the inline "XXX1" issue because no one had commented 1546 on it and it seems reasonable to suggest as a SHOULD that web 1547 apps should redirect incoming insecure connections to secure 1548 connections. 1550 14. Removed the inline "XXX2" issue because it was simply for 1551 raising consciousness about having some means for 1552 distributing secure web application metadata. 1554 15. Removed "TODO1" because description prose for "max-age" in 1555 the Note following the ABNF in Section 5 seems to be fine. 1557 16. Decided for "TODO2" that "the first STS header field wins". 1558 TODO2 had read: "Decide UA behavior in face of encountering 1559 multiple HSTS headers in a message. Use first header? 1560 Last?". Removed TODO2. 1562 17. Added Section 1.1 "Organization of this specification" for 1563 readers' convenience. 1565 18. Moved design decision notes to be a proper appendix 1566 Appendix A. 1568 Changes from -00 to -01: 1570 1. Changed the "URI Loading" section to be "URI Loading and Port 1571 Mapping". 1573 2. [HASMAT] reference changed to [WEBSEC]. 1575 3. Changed "server" -> "host" where applicable, notably when 1576 discussing "HSTS Hosts". Left as "server" when discussing 1577 e.g. "http server"s. 1579 4. Fixed minor editorial nits. 1581 Changes from draft-hodges-strict-transport-sec-02 to 1582 draft-ietf-websec-strict-transport-sec-00: 1584 1. Altered spec metadata (e.g. filename, date) in order to submit 1585 as a WebSec working group Internet-Draft. 1587 C.2. For draft-hodges-strict-transport-sec 1589 Changes from -01 to -02: 1591 1. updated abstract such that means for expressing HSTS Policy 1592 other than via HSTS header field is noted. 1594 2. Changed spec title to "HTTP Strict Transport Security (HSTS)" 1595 from "Strict Transport Security". Updated use of "STS" 1596 acronym throughout spec to HSTS (except for when specifically 1597 discussing syntax of Strict-Transport-Security HTTP Response 1598 Header field), updated "Terminology" appropriately. 1600 3. Updated the discussion of "Passive Network Attackers" to be 1601 more precise and offered references. 1603 4. Removed para on nomative/non-normative from "Conformance 1604 Criteria" pending polishing said section to IETF RFC norms. 1606 5. Added examples subsection to "Syntax" section. 1608 6. Added OWS to maxAge production in Strict-Transport-Security 1609 ABNF. 1611 7. Cleaned up explanation in the "Note:" in the "HTTP-over- 1612 Secure-Transport Request Type" section, folded 3d para into 1613 "Note:", added conformance clauses to the latter. 1615 8. Added exaplanatory "Note:" and reference to "HTTP Request 1616 Type" section. Added "XXX1" issue. 1618 9. Added conformance clause to "URI Loading". 1620 10. Moved "Notes for STS Server implementors:" from "UA 1621 Implementation dvice " to "HSTS Policy expiration time 1622 considerations:" in "Server Implementation Advice", and also 1623 noted another option. 1625 11. Added cautionary "Note:" to "Ability to delete UA's cached 1626 HSTS Policy on a per HSTS Server basis". 1628 12. Added some informative references. 1630 13. Various minor editorial fixes. 1632 Changes from -00 to -01: 1634 1. Added reference to HASMAT mailing list and request that this 1635 spec be discussed there. 1637 Authors' Addresses 1639 Jeff Hodges 1640 PayPal 1641 2211 North First Street 1642 San Jose, California 95131 1643 US 1645 Email: Jeff.Hodges@PayPal.com 1647 Collin Jackson 1648 Carnegie Mellon University 1650 Email: collin.jackson@sv.cmu.edu 1652 Adam Barth 1653 Google, Inc. 1655 Email: ietf@adambarth.com 1656 URI: http://www.adambarth.com/