idnits 2.17.1 draft-hodges-strict-transport-sec-02.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 531 has weird spacing: '...seconds v-ext...' == Line 564 has weird spacing: '...max-age speci...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 11, 2010) is 5038 days in the past. Is this intentional? 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: 'ID.ietf-httpbis-p1-messaging' is mentioned on line 545, but not defined == Unused Reference: 'RFC1983' is defined on line 1083, but no explicit reference was found in the text == Unused Reference: 'RFC3454' is defined on line 1101, but no explicit reference was found in the text == Unused Reference: 'RFC3492' is defined on line 1109, but no explicit reference was found in the text == Unused Reference: 'RFC2396' is defined on line 1178, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-09 ** 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 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode5' -- 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: 10 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hodges 3 Internet-Draft PayPal 4 Intended status: Standards Track C. Jackson 5 Expires: January 12, 2011 Carnegie Mellon University 6 A. Barth 7 University of California 8 Berkeley 9 July 11, 2010 11 HTTP Strict Transport Security (HSTS) 12 draft-hodges-strict-transport-sec-02 14 Abstract 16 This specification defines a mechanism enabling Web sites to declare 17 themselves accessible only via secure connections, and/or for users 18 to be able to direct their user agent(s) to interact with given sites 19 only over secure connections. This overall policy is referred to as 20 HTTP Strict Transport Security (HSTS). The policy is declared by Web 21 sites via the Strict-Transport-Security HTTP Response Header Field, 22 and/or by other means, e.g. user agent configuration. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 12, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2. Strict Transport Security Policy Effects . . . . . . . . . 5 62 2.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.3.1. Threats Addressed . . . . . . . . . . . . . . . . . . 5 64 2.3.1.1. Passive Network Attackers . . . . . . . . . . . . 6 65 2.3.1.2. Active Network Attackers . . . . . . . . . . . . . 6 66 2.3.1.3. Web Site Development and Deployment Bugs . . . . . 6 67 2.3.2. Threats Not Addressed . . . . . . . . . . . . . . . . 7 68 2.3.2.1. Phishing . . . . . . . . . . . . . . . . . . . . . 7 69 2.3.2.2. Malware and Browser Vulnerabilities . . . . . . . 7 70 2.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.4.1. Overall Requirement . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 9 76 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 5.1. Strict-Transport-Security HTTP Response Header Field . . . 12 79 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 6. Server Processing Model . . . . . . . . . . . . . . . . . . . 14 81 6.1. HTTP-over-Secure-Transport Request Type . . . . . . . . . 15 82 6.2. HTTP Request Type . . . . . . . . . . . . . . . . . . . . 15 83 7. User Agent Processing Model . . . . . . . . . . . . . . . . . 16 84 7.1. Strict-Transport-Security Response Header Field 85 Processing . . . . . . . . . . . . . . . . . . . . . . . . 16 86 7.1.1. Noting a HSTS Server . . . . . . . . . . . . . . . . . 17 87 7.1.2. Known HSTS Server Domain Name Matching . . . . . . . . 17 88 7.2. URI Loading . . . . . . . . . . . . . . . . . . . . . . . 18 89 7.3. Errors in Secure Transport Establishment . . . . . . . . . 18 90 7.4. HTTP-Equiv Element Attribute . . . . . . . . . . . 19 91 8. Domain Name ToASCII Conversion Operation . . . . . . . . . . . 19 92 9. Server Implementation Advice . . . . . . . . . . . . . . . . . 19 93 10. UA Implementation Advice . . . . . . . . . . . . . . . . . . . 20 94 11. Constructing an Effective Request URI . . . . . . . . . . . . 21 95 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23 96 12.1. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 23 97 12.2. Bootstrap MITM Vulnerability . . . . . . . . . . . . . . . 23 98 12.3. Network Time Attacks . . . . . . . . . . . . . . . . . . . 23 99 12.4. Bogus Root CA Certificate Phish plus DNS Cache 100 Poisoning Attack . . . . . . . . . . . . . . . . . . . . . 23 101 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 102 14. Design Decision Notes . . . . . . . . . . . . . . . . . . . . 24 103 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 104 15.1. Normative References . . . . . . . . . . . . . . . . . . . 25 105 15.2. Informative References . . . . . . . . . . . . . . . . . . 26 106 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 27 107 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 28 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 110 1. Introduction 112 [ Please disscuss this draft on the hasmat@ietf.org mailing list 113 [HASMAT]. ] 115 The HTTP protocol [RFC2616] may be used over various transports, 116 typically the Transmission Control Protocol (TCP) [RFC0793]. 117 However, TCP does not provide channel integrity protection, 118 confidentiality, nor secure server identification. Thus the Secure 119 Sockets Layer (SSL) protocol [I-D.ietf-tls-ssl-version3] and its 120 successor Transport Layer Security (TLS) [RFC4346], were developed in 121 order to provide channel-oriented security, and are typically layered 122 between application protocols and TCP. [RFC2818] specifies how HTTP 123 is layered onto TLS, and defines the Universal Resource Identifier 124 (URI) scheme of "https" (in practice however, HTTP user agents (UAs) 125 typically offer their users choices among SSL2, SSL3, and TLS for 126 secure transport). URIs themselves are specified in [RFC3986]. 128 UAs employ various local security policies with respect to the 129 characteristics of their interactions with web resources depending on 130 (in part) whether they are communicating with a given web resource 131 using HTTP or HTTP-over-a-Secure-Transport. For example, cookies 132 ([RFC2109] and [RFC2965]) may be flagged as Secure. UAs are to send 133 such Secure cookies to their addressed server only over a secure 134 transport. This is in contrast to non-Secure cookies, which are 135 returned to the server regardless of transport (although modulo other 136 rules). 138 UAs typically annunciate to their users any issues with secure 139 connection establishment, such as being unable to validate a server 140 certificate trust chain, or if a server certificate is expired, or if 141 a server's domain name appears incorrectly in the server certificate 142 (see section 3.1 of [RFC2818]). Often, UAs enable users to elect to 143 continue to interact with a web resource in the face of such issues. 144 This behavior is sometimes referred to as "click(ing) through" 145 security [GoodDhamijaEtAl05] [SunshineEgelmanEtAl09], and thus can be 146 described as "click-through insecurity" . 148 Jackson and Barth proposed an approach, in [ForceHTTPS], to enable 149 web sites and/or users to declare that such issues are to be treated 150 as fatal and without direct user recourse. The aim is to prevent 151 users from unintentionally downgrading their security. 153 This specification embodies and refines the approach proposed in 154 [ForceHTTPS], e.g. a HTTP response header field is used to convey 155 site policy to the UA rather than a cookie. 157 2. Overview 159 This section discusses the use cases, summarizes the HTTP Strict 160 Transport Security (HSTS) policy, and continues with a discussion of 161 the threat model, non-addressed threats, and derived requirements. 163 2.1. Use Cases 165 The high-level use case is a combination of: 167 o Web browser user wishes to discover, or be introduced to, and/or 168 utilize various web sites (some arbitrary, some known) in a secure 169 fashion. 171 o Web site deployer wishes to offer their site in an explicitly 172 secure fashion for both their own, as well as their users', 173 benefit. 175 2.2. Strict Transport Security Policy Effects 177 The characteristics of the HTTP Strict Transport Security policy, as 178 applied by a UA in its interactions with a web site wielding HSTS 179 Policy, known as a HSTS Server, is summarized as follows: 181 1. All insecure ("http") connections to a HSTS Server are redirected 182 by the HSTS Server to be secure connections ("https"). 184 2. The UA terminates, without user recourse, any secure transport 185 connection attempts upon any and all secure transport errors or 186 warnings, including those caused by a site presenting self-signed 187 certificates. 189 3. UAs transform insecure URI references to a HSTS Server into 190 secure URI references before dereferencing them. 192 2.3. Threat Model 194 HSTS is concerned with three threat classes: passive network 195 attackers, active network attackers, and imperfect web developers. 196 However, it is explicitly not a remedy for two other classes of 197 threats: phishing and malware. Addressed and not addressed threats 198 are briefly discussed below. Readers may wish refer to [ForceHTTPS] 199 for details as well as relevant citations. 201 2.3.1. Threats Addressed 202 2.3.1.1. Passive Network Attackers 204 When a user browses the web on a local wireless network (e.g. an 205 802.11-based wireless local area network) a nearby attacker can 206 possibly eavesdrop on the user's unencrypted Internet Protocol-based 207 connections, such as HTTP, regardless of whether or not the local 208 wireless network itself is secured [BeckTews09]. Freely available 209 wireless sniffing toolkits, e.g. [Aircrack-ng], enable such passive 210 eavesdropping attacks. A passive network attacker using such tools 211 can steal session identifiers and hijack the user's web session(s), 212 by obtaining cookies containing authentication credentials for 213 example [ForceHTTPS]. 215 To mitigate such threats, some Web sites support, but usually do not 216 force, access using end-to-end secure transport -- e.g. signaled 217 through URIs constructed with the "https" scheme [RFC2818]. This can 218 lead users to believe that accessing such services using secure 219 transport protects them from passive network attackers. 220 Unfortunately, this is often not the case in real-world deployments 221 as session identifiers are often stored in non-Secure cookies to 222 permit interoperability with versions of the service offered over 223 insecure transport ("Secure cookes" are those cookies containing the 224 "Secure" attribute [RFC2109]). For example, if the session 225 identifier for a web site (an email service, say) is stored in a non- 226 Secure cookie, it permits an attacker to hijack the user's session if 227 the user's UA makes a single insecure HTTP request to the site. 229 2.3.1.2. Active Network Attackers 231 A determined attacker can mount an active attack, either by 232 impersonating a user's DNS server or, in a wireless network, by 233 spoofing network frames or offering a similarly-named evil twin 234 access point. If the user is behind a wireless home router, an 235 attacker can attempt to reconfigure the router using default 236 passwords and other vulnerabilities. Some sites, such as banks, rely 237 on end-to-end secure transport to protect themselves and their users 238 from such active attackers. Unfortunately, browsers allow their 239 users to easily opt-out of these protections in order to be usable 240 for sites that incorrectly deploy secure transport, for example by 241 generating and self-signing their own certificates (without also 242 distributing their CA certificate to their users' browsers). 244 2.3.1.3. Web Site Development and Deployment Bugs 246 The security of an otherwise uniformly secure site (i.e. all of its 247 content is materialized via "https" URIs), can be compromised 248 completely by an active attacker exploiting a simple mistake, such as 249 the loading of a cascading style sheet or a SWF movie over an 250 insecure connection (both cascading style sheets and SWF movies can 251 script the embedding page, to the surprise of many web developers -- 252 most browsers do not issue mixed content warnings when insecure SWF 253 files are embedded). Even if the site's developers carefully 254 scrutinize their login page for mixed content, a single insecure 255 embedding anywhere on the site compromises the security of their 256 login page because an attacker can script (control) the login page by 257 injecting script into the page with mixed content. 259 Note: "Mixed content" here refers to the same notion referred to as 260 "mixed security context" later elsewhere in this 261 specification. 263 2.3.2. Threats Not Addressed 265 2.3.2.1. Phishing 267 Phishing attacks occur when an attacker solicits authentication 268 credentials from the user by hosting a fake site located on a 269 different domain than the real site, perhaps driving traffic to the 270 fake site by sending a link in an email message. Phishing attacks 271 can be very effective because users find it difficult to distinguish 272 the real site from a fake site. HSTS is not a defense against 273 phishing per se; rather, it complements many existing phishing 274 defenses by instructing the browser to protect session integrity and 275 long-lived authentication tokens [ForceHTTPS]. 277 2.3.2.2. Malware and Browser Vulnerabilities 279 Because HSTS is implemented as a browser security mechanism, it 280 relies on the trustworthiness of the user's system to protect the 281 session. Malicious code executing on the user's system can 282 compromise a browser session, regardless of whether HSTS is used. 284 2.4. Requirements 286 This section identifies and enumerates various requirements derived 287 from the use cases and the threats discussed above, and lists the 288 detailed core requirements HTTP Strict Transport Security addresses, 289 as well as ancillary requirements that are not directly addressed. 291 2.4.1. Overall Requirement 293 o Minimize the risks to web browser users and web site deployers 294 that are derived from passive and active network attackers, web 295 site development and deployment bugs, as well as insecure user 296 actions. 298 2.4.1.1. Detailed Core Requirements 300 These core requirements are derived from the overall requirement, and 301 are addressed by this specification. 303 1. Web sites need to be able to declare to UAs that they should be 304 interacted with using a strict security policy. 306 2. Web sites need to be able to instruct UAs that contact them 307 insecurely to do so securely. 309 3. UAs need to note web sites that signal strict security policy 310 enablement, for a web site declared time span. 312 4. UAs need to re-write all insecure UA "http" URI loads to use the 313 "https" secure scheme for those web sites for which secure policy 314 is enabled. 316 5. Web site administrators need to be able to signal strict security 317 policy application to subdomains of higher-level domains for 318 which strict security policy is enabled, and UAs need to enforce 319 such policy. 321 6. For example, both example.com and foo.example.com could set 322 policy for bar.foo.example.com. 324 7. UAs need to disallow security policy application to peer domains, 325 and/or higher-level domains, by domains for which strict security 326 policy is enabled. 328 8. For example, neither bar.foo.example.com nor foo.example.com can 329 set policy for example.com, nor can bar.foo.example.com set 330 policy for foo.example.com. Also, foo.example.com cannot set 331 policy for sibling.example.com. 333 9. UAs need to prevent users from clicking-through security 334 warnings. Halting connection attempts in the face of secure 335 transport exceptions is acceptable. 337 Note: A means for uniformly securely meeting the first core 338 requirement above is not specifically addressed by this 339 specification (see Section 12.2 "Bootstrap MITM 340 Vulnerability"). It may be addressed by a future revision of 341 this specification or some other specification. Note also 342 that there are means by which UA implementations may more 343 fully meet the first core requirement, see Section 10 "UA 344 Implementation Advice". 346 2.4.1.2. Detailed Ancillary Requirements 348 These ancillary requirements are also derived from the overall 349 requirement. They are not normatively addressed in this 350 specification, but could be met by UA implementations at their 351 implementor's discretion, although meeting these requirements may be 352 complex. 354 1. Disallow "mixed security context" (also known as "mixed-content") 355 loads (see section 5.3 "Mixed Content" in 356 [W3C.WD-wsc-ui-20100309]). 358 2. Facilitate user declaration of web sites for which strict 359 security policy is enabled, regardless of whether the sites 360 signal HSTS Policy. 362 3. Conformance Criteria 364 This specification is written for servers and user agents (UAs). 366 In this specification, the words MUST, MUST NOT, MAY, and SHOULD are 367 to be interpreted as described in [RFC2119]. 369 A conformant server is one that implements all the requirements 370 listed in this specification that are applicable to servers. 372 A conformant user agent is one that implements all the requirements 373 listed in this specification that are applicable to user agents. 375 3.1. Document Conventions 377 Note: ..is a note to the reader. These are points that should be 378 expressly kept in mind and/or considered. 380 Warning: This is how a warning is shown. These are things that can 381 have suboptimal downside risks if not heeded. 383 [[XXXn: Some of the more major known issues are marked like this 384 (where "n" in "XXXn" is a number). --JeffH]] 386 [[TODOn: Things to fix (where "n" in "TODOn" is a number). --JeffH]] 388 4. Terminology 390 Terminology is defined in this section. 392 ASCII case-insensitive comparison 393 means comparing two strings exactly, codepoint for 394 codepoint, except that the characters in the range 395 U+0041 .. U+005A (i.e. LATIN CAPITAL LETTER A to 396 LATIN CAPITAL LETTER Z) and the corresponding 397 characters in the range U+0061 .. U+007A (i.e. 398 LATIN SMALL LETTER A to LATIN SMALL LETTER Z) are 399 considered to also match. See [Unicode5] for 400 details. 402 codepoint is a colloquial contraction of Code Point, which is 403 any value in the Unicode codespace; that is, the 404 range of integers from 0 to 10FFFF(hex) [Unicode5]. 406 Domain Name Domain Names, also referred to as DNS Names, are 407 defined in [RFC1035] to be represented outside of 408 the DNS protocol itself (and implementations 409 thereof) as a series of labels separated by dots, 410 e.g. "example.com" or "yet.another.example.org". 411 In the context of this specification, Domain Names 412 appear in that portion of a URI satisfying the reg- 413 name production in "Appendix A. Collected ABNF for 414 URI" in [RFC3986], and the host component from the 415 Host HTTP header field production in section 14.23 416 of [RFC2616]. 418 Note: The Domain Names appearing in actual URI 419 instances and matching the aforementioned 420 production components may or may not be 421 FQDNs. 423 Domain Name Label is that portion of a Domain Name appearing "between 424 the dots", i.e. consider "foo.example.com": "foo", 425 "example", and "com" are all domain name labels. 427 Effective Request URI 428 is a URI that can be constructed by an HTTP server 429 for any given HTTP request sent to it. Some HTTP 430 requests do not contain a contiguous representation 431 of the URI identifying the resource being addressed 432 by the HTTP request. Rather, different portions of 433 a resource's URI may be mapped to both the Request- 434 Line header field and the Host header field in an 435 HTTP request message 436 [I-D.ietf-httpbis-p1-messaging]. The HTTP server 437 coalesces these URI fragments and constructs an 438 equivalent of the Request-URI that was used by the 439 UA to generate the received HTTP request message. 441 See Section 11 "Constructing an Effective Request 442 URI", below. 444 FQDN is an acronym for Fully-qualified Domain Name. A 445 FQDN is a Domain Name that includes all higher 446 level domains relevant to the named entity 447 (typically a HSTS Server in the context of this 448 specification). If one thinks of the DNS as a 449 tree-structure with each node having its own Domain 450 Name Label, a FQDN for a specific node would be its 451 label followed by the labels of all the other nodes 452 between it and the root of the tree. For example, 453 for a host, a FQDN would include the label that 454 identifies the particular host, plus all domains of 455 which the host is a part, up to and including the 456 top-level domain (the root domain is always null) 457 [RFC1594]. 459 HTTP Strict Transport Security 460 is the overall name for the combined UA- and 461 server-side security policy defined by this 462 specification. 464 HTTP Strict Transport Security Server 465 is a HTTP server implementing the server aspects of 466 the HSTS policy. 468 HTTP Strict Transport Security Policy 469 is the name of the combined overall UA- and server- 470 side facets of the behavior specified in this 471 specification. 473 HSTS See HTTP Strict Transport Security. 475 HSTS Policy See HTTP Strict Transport Security Policy. 477 HSTS Server See HTTP Strict Transport Security Server. 479 Known HSTS Server is a HSTS Server for which the UA has an HSTS 480 Policy in effect. 482 Local policy is comprised of policy rules deployers specify and 483 which are often manifested as "configuration 484 settings". 486 MITM is an acronym for man-in-the-middle. See "man-in- 487 the-middle attack" in [RFC4949]. 489 Request URI is the URI used to cause a UA to issue an HTTP 490 request message. 492 UA is a an acronym for user agent. For the purposes 493 of this specification, a UA is an HTTP client 494 application typically actively manipulated by a 495 user [RFC2616] . 497 5. Syntax 499 This section defines the syntax of the new header this specification 500 introduces. It also provides a short description of the function the 501 header. 503 The Section 6 "Server Processing Model" section details how servers 504 are to use this header. Likewise, the Section 7 "User Agent 505 Processing Model" section details how user agents are to use this 506 header. 508 5.1. Strict-Transport-Security HTTP Response Header Field 510 The Strict-Transport-Security HTTP response header field indicates to 511 a UA that it MUST enforce the HSTS Policy in regards to the server 512 emitting the response message containing this header field. 514 The ABNF syntax for the Strict-Transport-Security HTTP Response 515 Header field is: 517 Strict-Transport-Security = 519 "Strict-Transport-Security" ":" OWS STS-v OWS 521 ; value 522 STS-v = STS-d 523 / STS-d *( OWS ";" OWS STS-d OWS ) 525 ; STS directive 526 STS-d = STS-d-cur / STS-d-ext 528 ; defined STS directives 529 STS-d-cur = maxAge / includeSubDomains 531 maxAge = "max-age" OWS "=" OWS delta-seconds v-ext 533 includeSubDomains = [ "includeSubDomains" ] v-ext 535 ; extension points 536 STS-d-ext = name ; STS extension directive 538 v-ext = value ; STS extension value 540 name = token 542 value = OWS / %x21-3A / %x3C-7E ; i.e. optional white space, or 543 ; [ ! .. : ] [ < .. ~ ] any visible chars other than ";" 545 ; productions imported from [ID.ietf-httpbis-p1-messaging]: 547 token 549 OWS ; Optional White Space 551 Note: [I-D.ietf-httpbis-p1-messaging] is used as the ABNF basis in 552 order to ensure that the new header has equivalent parsing 553 rules to the header fields defined in that same specification. 554 Also: 556 1. Quoted-string literals in the above ABNF stanza are 557 case-insensitive. 559 2. In order to correctly match the grammar above, the 560 Strict-Transport-Security HTTP Response Header MUST 561 include at least a max-age directive with at least a 562 single-digit value for delta-seconds. 564 max-age specifies the number of seconds, after the recption of the 565 Strict-Transport-Security HTTP Response Header, during which 566 the UA regards the host the message was received from as a 567 Known HSTS Server (see also Section 7.1.1 "Noting a HSTS 568 Server", below). The delta-seconds production is specified 569 in [RFC2616]. 571 [[TODO1: The above para wrt max-age may need further refinement. 572 --JeffH]] 574 includeSubDomains is a flag which, if present, signals to the UA that 575 the HSTS Policy applies to this HSTS Server as well 576 as any subdomains of the server's FQDN. 578 5.2. Examples 580 The below HSTS header field stipulates that the HSTS policy is to 581 remain in effect for one year (there are approximately 31 536 000 582 seconds in a year), and the policy applies only to the domain of the 583 HSTS Server issuing it: 585 Strict-Transport-Security: max-age=31536000 587 The below HSTS header field is stipulates that the HSTS policy is to 588 remain in effect for approximately six months and the policy applies 589 only to the domain of the issuing HSTS Server and all of its 590 subdomains: 592 Strict-Transport-Security: max-age=15768000 ; includeSubDomains 594 6. Server Processing Model 596 This section describes the processing model that HSTS Servers 597 implement. The model is comprised of two facets: the first being the 598 processing rules for HTTP request messages received over a secure 599 transport (e.g. TLS [RFC4346], SSL [I-D.ietf-tls-ssl-version3], or 600 perhaps others, the second being the processing rules for HTTP 601 request messages received over non-secure transports, i.e. over 602 TCP/IP [RFC0793]. 604 6.1. HTTP-over-Secure-Transport Request Type 606 When replying to an HTTP request that was conveyed over a secure 607 transport, a HSTS Server SHOULD include in its response message a 608 Strict-Transport-Security HTTP Response Header that MUST satisfy the 609 grammar specified above in Section 5.1 "Strict-Transport-Security 610 HTTP Response Header Field". If a Strict-Transport-Security HTTP 611 Response Header is included, the HSTS Server MUST include only one 612 such header. 614 Note: Including the Strict-Transport-Security HTTP Response Header 615 is stipulated as a "SHOULD" in order to accomodate various 616 server- and network-side caches and load-balancing 617 configurations where it may be difficult to uniformly emit 618 Strict-Transport-Security HTTP Response Headers on behalf of a 619 given HSTS Server. 621 Establishing a given host as a Known HSTS Server, in the 622 context of a given UA, MAY be accomplished over the HTTP 623 protocol by correctly returning, per this specification, at 624 least one valid Strict-Transport-Security HTTP Response Header 625 to the UA. Other mechanisms, such as a client-side pre-loaded 626 Known HSTS Server list MAY also be used. E.g. see Section 10 627 "UA Implementation Advice". 629 6.2. HTTP Request Type 631 If a HSTS Server receives a HTTP request message over a non-secure 632 transport, it SHOULD send a HTTP response message containing a 633 Status-Code of 301 and a Location header field value containing 634 either the HTTP request's original Effective Request URI (see 635 Section 11 "Constructing an Effective Request URI", below) altered as 636 necessary to have a URI scheme of "https", or a URI generated 637 according to local policy (which SHOULD employ a URI scheme of 638 "https"). 640 Note: The above behavior is a "SHOULD" rather than a "MUST&" 641 because: 643 There are risks in server-side non-secure-to-secure 644 redirects [owaspTLSGuide]. 646 Site deployment characteristics -- e.g. a site that 647 incorporates third-party components may not behave 648 correctly when doing server-side non-secure-to-secure 649 redirects in the case of being accessed over non-secure 650 transport, but does behave correctly when accessed 651 uniformly over secure transport. The latter is the 652 case given a HSTS-capapble UA that has already noted 653 the site as a Known HSTS Server (by whatever means, 654 e.g. prior interaction or UA configuration). 656 [[XXX1: perhaps the "SHOULD" in the above behavior should be a "MAY" 657 given the reasons it's presently not a "MUST". --JeffH]] 659 A HSTS Server MUST NOT include the Strict-Transport-Security HTTP 660 Response Header in HTTP responses conveyed over a non-secure 661 transport. 663 7. User Agent Processing Model 665 This section describes the HTTP Strict Transport Security processing 666 model for UAs. There are several facets to the model, enumerated by 667 the following subsections. 669 Also, this processing model assumes that all Domain Names manipulated 670 in this specification's context are already in ASCII Compatible 671 Encoding (ACE) format as specified in [RFC3490]. If this is not the 672 case in some situation, use the operation given in Section 8 "Domain 673 Name ToASCII Conversion Operation" to convert any encountered 674 internationalized Domain Names to ACE format before processing them. 676 7.1. Strict-Transport-Security Response Header Field Processing 678 If an HTTP response, received over a secure transport, includes a 679 Strict-Transport-Security HTTP Response Header field, conforming to 680 the grammar specified in Section 5.1 "Strict-Transport-Security HTTP 681 Response Header Field" (above), and there are no underlying secure 682 transport errors or warnings, the UA MUST either: 684 o Note the server as a Known HSTS Server if it is not already so 685 noted (see Section 7.1.1 "Noting a HSTS Server", below), 687 or, 689 o Update its cached information for the Known HSTS Server if the 690 max-age and/or includeSubDomains header field value tokens are 691 conveying information different than that already maintained by 692 the UA. 694 Note: The max-age value is essentially a "time to live" value 695 relative to the reception time of the Strict-Transport- 696 Security HTTP Response Header. 698 [[TODO2: Decide UA behavior in face of encountering multiple HSTS 699 headers in a message. Use first header? Last? --JeffH]] 701 Otherwise: 703 o If an HTTP response is received over insecure transport, the UA 704 MUST ignore any present Strict-Transport-Security HTTP Response 705 Header(s). 707 o The UA MUST ignore any Strict-Transport-Security HTTP Response 708 Headers not conforming to the grammar specified in Section 5.1 709 "Strict-Transport-Security HTTP Response Header Field" (above). 711 7.1.1. Noting a HSTS Server 713 If the substring matching the host production from the Request-URI, 714 that the server responded to, syntactically matches the IP-literal or 715 IPv4address productions from section 3.2.2 of [RFC3986], then the UA 716 MUST NOT note this server as a Known HSTS Server. 718 Otherwise, if the substring does not congruently match a presently 719 known HSTS Server, per the matching procedure specified in 720 Section 7.1.2 "Known HSTS Server Domain Name Matching" below, then 721 the UA MUST note this server as a Known HSTS Server, caching the HSTS 722 Server's Domain Name and noting along with it the expiry time of this 723 information, as effectively stipulated per the given max-age value, 724 as well as whether the includeSubDomains flag is asserted or not. 726 7.1.2. Known HSTS Server Domain Name Matching 728 A UA determines whether a Domain Name represents a Known HSTS Server 729 by looking for a match between the query Domain Name and the UA's set 730 of Known HSTS Servers. 732 1. Compare the query Domain Name string with the Domain Names of the 733 UA's set of Known HSTS Servers. For each Known HSTS Server's 734 Domain Name, the comparison is done with the query Domain Name 735 label-by-label using an ASCII case-insensitive comparison 736 beginning with the rightmost label, and continuing right-to-left, 737 and ignoring separator characters (see clause 3.1(4) of 738 [RFC3986]. 740 * If a label-for-label match between an entire Known HSTS 741 Server's Domain Name and a right-hand portion of the query 742 Domain Name is found, then the Known HSTS Server's Domain Name 743 is a superdomain match for the query Domain Name. 745 For example: 747 Query Domain Name: bar.foo.example.com 749 Superdomain matched 750 Known HSTS Server DN: foo.example.com 752 At this point, the query Domain Name is ascertained to 753 effectively represent a Known HSTS Server. There may also be 754 additional matches further down the Domain Name Label tree, up 755 to and including a congruent match. 757 * If a label-for-label match between a Known HSTS Server's 758 Domain Name and the query domain name is found, i.e. there are 759 no further labels to compare, then the query Domain Name 760 congruently matches this Known HSTS Server. 762 For example: 764 Query Domain Name: foo.example.com 766 Congruently matched 767 Known HSTS Server DN: foo.example.com 769 The query Domain Name is ascertained to represent a Known HSTS 770 Server. However, if there are also superdomain matches, the 771 one highest in the tree asserts the HSTS Policy for this Known 772 HSTS Server. 774 * Otherwise, if no matches are found, the query Domain Name does 775 not represent a Known HSTS Server. 777 7.2. URI Loading 779 Whenever the UA prepares to "load", also known as "dereference", any 780 URI where the host production of the URI [RFC3986] matches that of a 781 Known HSTS Server -- either as a congruent match or as a superdomain 782 match where the superdomain Known HSTS Server has includeSubDomains 783 asserted -- and the URI's scheme is "http", then the UA "MUST" 784 replace the URI scheme with "https" before proceeding with the load. 786 7.3. Errors in Secure Transport Establishment 788 When connecting to a Known HSTS Server, the UA MUST terminate the 789 connection with no user recourse if there are any errors (e.g. 790 certificate errors), whether "warning" or "fatal" or any other error 791 level, with the underlying secure transport. 793 7.4. HTTP-Equiv Element Attribute 795 UAs MUST NOT heed http-equiv="Strict-Transport-Security" attribute 796 settings on elements in received content. 798 8. Domain Name ToASCII Conversion Operation 800 This operation converts a string-serialized Domain Name possibly 801 containing arbitrary Unicode characters [Unicode5] into a string- 802 serialized Domain Name in ASCII Compatible Encoding (ACE) format as 803 specified in [RFC3490]. 805 The operation is: 807 o Apply the IDNA conversion operation (section 4 of [RFC3490]) to 808 the string, selecting the ToASCII operation and setting both the 809 AllowUnassigned and UseSTD3ASCIIRules flags. 811 9. Server Implementation Advice 813 HSTS Policy expiration time considerations: 815 o Server implementations and deploying web sites need to consider 816 whether they are setting an expiry time that is a constant value 817 into the future, e.g. by constantly sending the same max-age value 818 to UAs. For exmple: 820 Strict-Transport-Security: max-age=778000 822 A max-age value of 778000 is 90 days. Note that each receipt of 823 this header by a UA will require the UA to update its notion of 824 when it must delete its knowledge of this Known HSTS Server. The 825 specifics of how this is accomplished is out of the scope of this 826 specification. 828 o Or, whether they are setting an expiry time that is a fixed point 829 in time, e.g. by sending max-age values that represent the 830 remaining time until the expiry time. 832 o A consideration here is whether a deployer wishes to have signaled 833 HSTS Policy expiry time match that for the web site's domain 834 certificate. 836 Considerations for using HTTP Strict Transport Security in 837 conjunction with self-signed public-key certificates: 839 o If a web site/organization/enterprise is generating their own 840 secure transport public-key certificates for web sites, and that 841 organization's root certificate authority (CA) certificate is not 842 typically embedded by default in browser CA certificate stores, 843 and if HSTS Policy is enabled on a site identifying itself using a 844 self-signed certificate, then secure connections to that site will 845 fail without user recourse, per the HSTS design. This is to 846 protect against various active attacks, as discussed above. 848 o However, if said organization strongly wishes to employ self- 849 signed certificates, and their own CA in concert with HSTS, they 850 can do so by deploying their root CA certificate to their users' 851 browsers. There are various ways in which this can be 852 accomplished (details are out of scope for this specification). 853 Once their root CA cert is installed in the browsers, they may 854 employ HSTS Policy on their site(s). 856 Note: Interactively distributing root CA certs to users, e.g. via 857 email, and having the users install them, is arguably 858 training the users to be susceptible to a possible form of 859 phishing attack, see Section 12.4 "Bogus Root CA 860 Certificate Phish plus DNS Cache Poisoning Attack". 862 10. UA Implementation Advice 864 In order to provide users and web sites more effective protection, UA 865 implementors should consider including features such as: 867 o Disallowing "mixed security context" (also known as "mixed- 868 content") loads (see section 5.3 "Mixed Content" in 869 [W3C.WD-wsc-ui-20100309]). 871 Note: In order to provide behavioral uniformity across UA 872 implementations, the notion of mixed security context aka 873 mixed-content will require (further) standardization work, 874 e.g. to more clearly define the term(s) and to define 875 specific behaviors with respect to it. 877 In order to provide users effective controls for managing their UA's 878 caching of HSTS Policy, UA implementors should consider including 879 features such as: 881 o Ability to delete UA's cached HSTS Policy on a per HSTS Server 882 basis. 884 Note: Adding such a feature should be done very carefully in both 885 the user interface and security senses. Deleting a cache 886 entry for a Known HSTS Server should be a very deliberate 887 and well-considered act -- it shouldn't be something users 888 get used to just "clicking through" in order to get work 889 done. Also, it shouldn't be possible for an attacker to 890 inject script into the UA that silently and 891 programmatically removes entries from the UA's cache of 892 Known HSTS Servers. 894 In order to provide users and web sites more complete protection, UAs 895 could offer advanced features such as these: 897 o Ability for users to explicitly declare a given Domain Name as 898 representing a HSTS Server, thus seeding it as a Known HSTS Server 899 before any actual interaction with it. This would help protect 900 against the Section 12.2 "Bootstrap MITM Vulnerability". 902 Note: Such a feature is difficult to get right on a per-site 903 basis -- see the discussion of "rewrite rules" in section 904 5.5 of [ForceHTTPS]. For example, arbitrary web sites may 905 not materialize all their URIs using the "https" scheme, 906 and thus could "break" if a UA were to attempt to access 907 the site exclusively using such URIs. Also note that this 908 feature would complement, but is independent of the 909 following described facility. 911 o Facility whereby web site administrators can have UAs pre- 912 configured with HSTS Policy for their site(s) by the UA vendor(s) 913 -- in a manner similar to how root CA certificates are embedded in 914 browsers "at the factory". This would help protect against the 915 Section 12.2 "Bootstrap MITM Vulnerability". 917 Note: Such a facility complements the preceding described 918 feature. 920 [[XXX2: These latter items beg the question of having some means of 921 secure web site metadata and policy discovery and acquisition. There 922 is extant work that may be of interest, e.g. the W3C POWDER work, 923 OASIS XRI/XRD work (as well as XRDS-Simple), and "Link-based Resource 924 Descriptor Discovery" (draft-hammer-discovery). --JeffH]] 926 11. Constructing an Effective Request URI 928 This section specifies how an HSTS Server must construct the 929 Effective Request URI for a received HTTP request. 931 The first line of an HTTP request message is specified by the 932 following ABNF ([I-D.ietf-httpbis-p1-messaging] section 4.1): 934 Request-Line = Method SP request-target SP HTTP-Version CRLF 936 The request-target is following ABNF ([I-D.ietf-httpbis-p1-messaging] 937 section 4.1.2): 939 request-target = "*" 940 / absolute-URI 941 / ( path-absolute [ "?" query ] ) 942 / authority 944 Additionally, many HTTP requests contain an additional Host request 945 header field. It is specified by the following ABNF 946 ([I-D.ietf-httpbis-p1-messaging] section 4.1.2): 948 Host = "Host:" OWS Host-v 949 Host-v = uri-host [ ":" port ] 951 Thus an example HTTP message containing the above header fields is: 953 GET /hello.txt HTTP/1.1 954 Host: www.example.com 956 Another example is: 958 GET HTTP://www.example.com/hello.txt HTTP/1.1 960 An HSTS Server constructs the Effective Request URI using the 961 following ABNF grammar (which imports some productions from the above 962 ABNF for Request-Line, request-target, and Host: 964 Effective-Request-URI = absolute-URI-present / path-absolute-form 966 absolute-URI-present = absolute-URI 968 path-absolute-form = scheme "://" Host-v path-absolute [ "?" query ] 970 where: 972 scheme is "http" if the request was received over 973 insecure transport, or scheme is "https" if the 974 request was received over secure transport. 976 For example, if the request message contains a request-target 977 component that matches the grammar of absolute-URI, then the 978 Effective-Request-URI is simply the value of the absolute-URI 979 component. Otherwise, the Effective-Request-URI is a combination, 980 per the path-absolute-form production, of the Host-v, path-absolute, 981 and query components from the request-target and Host components of 982 the request message. 984 [[TODO3: This is a first SWAG at this section. Fix/add prose as 985 appropriate, fix ABNF as needed per review. --JeffH]] 987 12. Security Considerations 989 12.1. Denial of Service (DoS) 991 HSTS could be used to mount certain forms of DoS attacks, where 992 attackers set fake HSTS headers on legitimate sites available only 993 insecurely (e.g. social network service sites, wikis, etc.). 995 12.2. Bootstrap MITM Vulnerability 997 The bootstrap MITM (Man-In-The-Middle) vulnerability is a 998 vulnerability users and HSTS Servers encounter in the situation where 999 the user manually enters, or follows a link, to a HSTS Server using a 1000 "http" URI rather than a "https" URI. Because the UA uses an 1001 insecure channel in the initial attempt to interact with the 1002 specified serve, such an initial interaction is vulnerable to various 1003 attacks [ForceHTTPS] . 1005 Note: There are various features/facilities that UA implementations 1006 may employ in order to mitigate this vulnerability. Please 1007 see Section 10 UA Implementation Advice. 1009 12.3. Network Time Attacks 1011 Active network attacks can subvert network time protocols (like NTP) 1012 - making this header less effective against clients that trust NTP 1013 and/or lack a real time clock. Network time attacks are therefore 1014 beyond the scope of the defense. Note that modern operating systems 1015 use NTP by default. 1017 12.4. Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack 1019 If an attacker can convince users of, say, https://bank.example.com 1020 (which is protected by HSTS Policy), to install their own version of 1021 a root CA certificate purporting to be bank.example.com's CA, e.g. 1022 via a phishing email message with a link to such a certificate -- 1023 then, if they can perform an attack on the users' DNS, e.g. via cache 1024 poisoning, and turn on HSTS Policy for their fake bank.example.com 1025 site, then they have themselves some new users. 1027 13. IANA Considerations 1029 Below is the Internet Assigned Numbers Authority (IANA) Provisional 1030 Message Header Field registration information per [RFC3864]. 1032 Header field name: Strict-Transport-Security 1033 Applicable protocol: HTTP 1034 Status: provisional 1035 Author/Change controller: TBD 1036 Specification document(s): this one 1038 14. Design Decision Notes 1040 This appendix documents various design decisions. 1042 1. Cookies aren't appropriate for HSTS Policy expression as they are 1043 potentially mutable (while stored in the UA), therefore an HTTP 1044 header field is employed. 1046 2. We chose to not attempt to specify how "mixed security context 1047 loads" (aka "mixed-content loads") are handled due to UA 1048 implementation considerations as well as classification 1049 difficulties. 1051 3. A HSTS Server may update UA notions of HSTS Policy via new HSTS 1052 header field values. We chose to have UAs honor the "freshest" 1053 information received from a server because there is the chance of 1054 a web site sending out an errornous HSTS Policy, such as a multi- 1055 year max-age value, and/or an incorrect includeSubDomains flag. 1056 If the HSTS Server couldn't correct such errors over protocol, it 1057 would require some form of annunciation to users and manual 1058 intervention on their part, which could be a non-trivial problem. 1060 4. HSTS Servers are identified only via Domain Names -- explicit IP 1061 address identification of all forms is excluded. This is for 1062 simplification and also is in recognition of various issues with 1063 using direct IP address identification in concert with PKI-based 1064 security. 1066 15. References 1067 15.1. Normative References 1069 [I-D.ietf-httpbis-p1-messaging] 1070 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 1071 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, 1072 "HTTP/1.1, part 1: URIs, Connections, and Message 1073 Parsing", draft-ietf-httpbis-p1-messaging-09 (work in 1074 progress), March 2010. 1076 [RFC1035] Mockapetris, P., "Domain names - implementation and 1077 specification", STD 13, RFC 1035, November 1987. 1079 [RFC1594] Marine, A., Reynolds, J., and G. Malkin, "FYI on Questions 1080 and Answers - Answers to Commonly asked "New Internet 1081 User" Questions", RFC 1594, March 1994. 1083 [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, 1084 August 1996. 1086 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 1087 Mechanism", RFC 2109, February 1997. 1089 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1090 Requirement Levels", BCP 14, RFC 2119, March 1997. 1092 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1093 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1094 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1096 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1098 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 1099 Mechanism", RFC 2965, October 2000. 1101 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of 1102 Internationalized Strings ("stringprep")", RFC 3454, 1103 December 2002. 1105 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1106 "Internationalizing Domain Names in Applications (IDNA)", 1107 RFC 3490, March 2003. 1109 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 1110 for Internationalized Domain Names in Applications 1111 (IDNA)", RFC 3492, March 2003. 1113 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1114 Procedures for Message Header Fields", BCP 90, RFC 3864, 1115 September 2004. 1117 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1118 Resource Identifier (URI): Generic Syntax", STD 66, 1119 RFC 3986, January 2005. 1121 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1122 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1124 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1125 RFC 4949, August 2007. 1127 [Unicode5] 1128 The Unicode Consortium, "The Unicode Standard, Version 1129 5.0", Boston, MA, Addison-Wesley ISBN 0-321-48091-0, 2007. 1131 [W3C.WD-html5-20100304] 1132 Hyatt, D. and I. Hickson, "HTML5", World Wide Web 1133 Consortium WD WD-html5-20100304, March 2010, 1134 . 1136 15.2. Informative References 1138 [Aircrack-ng] 1139 d'Otreppe, T., "Aircrack-ng", Accessed: 11-Jul-2010, 1140 . 1142 [BeckTews09] 1143 Beck, M. and E. Tews, "Practical Attacks Against WEP and 1144 WPA", Second ACM Conference on Wireless Network 1145 Security Zurich, Switzerland, 2009, . 1149 [ForceHTTPS] 1150 Jackson, C. and A. Barth, "ForceHTTPS: Protecting High- 1151 Security Web Sites from Network Attacks", In Proceedings 1152 of the 17th International World Wide Web Conference 1153 (WWW2008) , 2008, 1154 . 1156 [GoodDhamijaEtAl05] 1157 Good, N., Dhamija, R., Grossklags, J., Thaw, D., 1158 Aronowitz, S., Mulligan, D., and J. Konstan, "Stopping 1159 Spyware at the Gate: A User Study of Privacy, Notice and 1160 Spyware", In Proceedings of Symposium On Usable Privacy 1161 and Security (SOUPS) Pittsburgh, PA, USA, July 2005, . 1165 [HASMAT] "HASMAT -- HTTP Application Security Minus Authentication 1166 and Transport", 1167 . 1169 [I-D.ietf-tls-ssl-version3] 1170 Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol 1171 Version 3.0", draft-ietf-tls-ssl-version3 (work in 1172 progress), November 1996, . 1175 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1176 RFC 793, September 1981. 1178 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1179 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1180 August 1998. 1182 [SunshineEgelmanEtAl09] 1183 Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and 1184 L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning 1185 Effectiveness", In Proceedings of 18th USENIX Security 1186 Symposium Montreal, Canada, Augus 2009, . 1190 [W3C.WD-wsc-ui-20100309] 1191 Saldhana, A. and T. Roessler, "Web Security Context: User 1192 Interface Guidelines", World Wide Web Consortium 1193 LastCall WD-wsc-ui-20100309, March 2010, 1194 . 1196 [owaspTLSGuide] 1197 Coates, M., Wichers, d., Boberski, M., and T. Reguly, 1198 "Transport Layer Protection Cheat Sheet", Accessed: 11- 1199 Jul-2010, . 1202 Appendix A. Acknowledgments 1204 The authors thank Michael Barrett, Sid Stamm, Maciej Stachowiak, Andy 1205 Steingrubl, Brandon Sterne, Daniel Veditz for their review and 1206 contributions. 1208 Appendix B. Change Log 1210 Changes from -01 to -02: 1212 1. updated abstract such that means for expressing HSTS Policy 1213 other than via HSTS header field is noted. 1215 2. Changed spec title to "HTTP Strict Transport Security (HSTS)" 1216 from "Strict Transport Security". Updated use of "STS" 1217 acronym throughout spec to HSTS (except for when specifically 1218 discussing syntax of Strict-Transport-Security HTTP Response 1219 Header field), updated "Terminology" appropriately. 1221 3. Updated the discussion of "Passive Network Attackers" to be 1222 more precise and offered references. 1224 4. Removed para on nomative/non-normative from "Conformance 1225 Criteria" pending polishing said section to IETF RFC norms. 1227 5. Added examples subsection to "Syntax" section. 1229 6. Added OWS to maxAge production in Strict-Transport-Security 1230 ABNF. 1232 7. Cleaned up explanation in the "Note:" in the "HTTP-over- 1233 Secure-Transport Request Type" section, folded 3d para into 1234 "Note:", added conformance clauses to the latter. 1236 8. Added exaplanatory "Note:" and reference to "HTTP Request 1237 Type" section. Added "XXX1" issue. 1239 9. Added conformance clause to "URI Loading". 1241 10. Moved "Notes for STS Server implementors:" from "UA 1242 Implementation dvice " to "HSTS Policy expiration time 1243 considerations:" in "Server Implementation Advice", and also 1244 noted another option. 1246 11. Added cautionary "Note:" to "Ability to delete UA's cached 1247 HSTS Policy on a per HSTS Server basis". 1249 12. Added some informative references. 1251 13. Various minor editorial fixes. 1253 Changes from -00 to -01: 1255 1. Added reference to HASMAT mailing list and request that this 1256 spec be discussed there. 1258 Authors' Addresses 1260 Jeff Hodges 1261 PayPal 1262 2211 North First Street 1263 San Jose, California 95131 1264 US 1266 Email: Jeff.Hodges@PayPal.com 1268 Collin Jackson 1269 Carnegie Mellon University 1271 Email: collin.jackson@sv.cmu.edu 1273 Adam Barth 1274 University of California Berkeley 1276 Email: abarth@eecs.berkeley.edu