idnits 2.17.1
draft-ietf-websec-strict-transport-sec-01.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 481 has weird spacing: '...TS Host is a...'
== Line 532 has weird spacing: '...seconds v-ext...'
== Line 565 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 (March 14, 2011) is 4791 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
546, but not defined
== Missing Reference: 'HASMAT' is mentioned on line 1221, but not defined
== Unused Reference: 'RFC1983' is defined on line 1084, but no explicit
reference was found in the text
== Unused Reference: 'RFC3454' is defined on line 1102, but no explicit
reference was found in the text
== Unused Reference: 'RFC3492' is defined on line 1110, but no explicit
reference was found in the text
== Unused Reference: 'RFC2396' is defined on line 1175, 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 (~~), 12 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Hodges
3 Internet-Draft PayPal
4 Intended status: Standards Track C. Jackson
5 Expires: September 15, 2011 Carnegie Mellon University
6 A. Barth
7 Google, Inc.
8 March 14, 2011
10 HTTP Strict Transport Security (HSTS)
11 draft-ietf-websec-strict-transport-sec-01
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 September 15, 2011.
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 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
59 2.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
60 2.2. Strict Transport Security Policy Effects . . . . . . . . . 5
61 2.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 5
62 2.3.1. Threats Addressed . . . . . . . . . . . . . . . . . . 5
63 2.3.1.1. Passive Network Attackers . . . . . . . . . . . . 6
64 2.3.1.2. Active Network Attackers . . . . . . . . . . . . . 6
65 2.3.1.3. Web Site Development and Deployment Bugs . . . . . 6
66 2.3.2. Threats Not Addressed . . . . . . . . . . . . . . . . 7
67 2.3.2.1. Phishing . . . . . . . . . . . . . . . . . . . . . 7
68 2.3.2.2. Malware and Browser Vulnerabilities . . . . . . . 7
69 2.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
70 2.4.1. Overall Requirement . . . . . . . . . . . . . . . . . 7
71 2.4.1.1. Detailed Core Requirements . . . . . . . . . . . . 8
72 2.4.1.2. Detailed Ancillary Requirements . . . . . . . . . 9
73 3. Conformance Criteria . . . . . . . . . . . . . . . . . . . . . 9
74 3.1. Document Conventions . . . . . . . . . . . . . . . . . . . 9
75 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
76 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
77 5.1. Strict-Transport-Security HTTP Response Header Field . . . 12
78 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14
79 6. Server Processing Model . . . . . . . . . . . . . . . . . . . 14
80 6.1. HTTP-over-Secure-Transport Request Type . . . . . . . . . 15
81 6.2. HTTP Request Type . . . . . . . . . . . . . . . . . . . . 15
82 7. User Agent Processing Model . . . . . . . . . . . . . . . . . 16
83 7.1. Strict-Transport-Security Response Header Field
84 Processing . . . . . . . . . . . . . . . . . . . . . . . . 16
85 7.1.1. Noting a HSTS Host . . . . . . . . . . . . . . . . . . 17
86 7.1.2. Known HSTS Host Domain Name Matching . . . . . . . . . 17
87 7.2. URI Loading and Port Mapping . . . . . . . . . . . . . . . 18
88 7.3. Errors in Secure Transport Establishment . . . . . . . . . 18
89 7.4. HTTP-Equiv Element Attribute . . . . . . . . . . . 19
90 8. Domain Name ToASCII Conversion Operation . . . . . . . . . . . 19
91 9. Server Implementation Advice . . . . . . . . . . . . . . . . . 19
92 10. UA Implementation Advice . . . . . . . . . . . . . . . . . . . 20
93 11. Constructing an Effective Request URI . . . . . . . . . . . . 21
94 12. Security Considerations . . . . . . . . . . . . . . . . . . . 23
95 12.1. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 23
96 12.2. Bootstrap MITM Vulnerability . . . . . . . . . . . . . . . 23
97 12.3. Network Time Attacks . . . . . . . . . . . . . . . . . . . 23
98 12.4. Bogus Root CA Certificate Phish plus DNS Cache
99 Poisoning Attack . . . . . . . . . . . . . . . . . . . . . 23
100 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
101 14. Design Decision Notes . . . . . . . . . . . . . . . . . . . . 24
102 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
103 15.1. Normative References . . . . . . . . . . . . . . . . . . . 25
104 15.2. Informative References . . . . . . . . . . . . . . . . . . 26
105 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 27
106 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 28
107 B.1. For draft-ietf-websec-strict-transport-sec . . . . . . . . 28
108 B.2. For draft-hodges-strict-transport-sec . . . . . . . . . . 28
109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
111 1. Introduction
113 [ Please disscuss this draft on the WebSec@ietf.org mailing list
114 [WEBSEC]. ]
116 The HTTP protocol [RFC2616] may be used over various transports,
117 typically the Transmission Control Protocol (TCP) [RFC0793].
118 However, TCP does not provide channel integrity protection,
119 confidentiality, nor secure host identification. Thus the Secure
120 Sockets Layer (SSL) protocol [I-D.ietf-tls-ssl-version3] and its
121 successor Transport Layer Security (TLS) [RFC4346], were developed in
122 order to provide channel-oriented security, and are typically layered
123 between application protocols and TCP. [RFC2818] specifies how HTTP
124 is layered onto TLS, and defines the Universal Resource Identifier
125 (URI) scheme of "https" (in practice however, HTTP user agents (UAs)
126 typically offer their users choices among SSL2, SSL3, and TLS for
127 secure transport). URIs themselves are specified in [RFC3986].
129 UAs employ various local security policies with respect to the
130 characteristics of their interactions with web resources depending on
131 (in part) whether they are communicating with a given web resource
132 using HTTP or HTTP-over-a-Secure-Transport. For example, cookies
133 ([RFC2109] and [RFC2965]) may be flagged as Secure. UAs are to send
134 such Secure cookies to their addressed host only over a secure
135 transport. This is in contrast to non-Secure cookies, which are
136 returned to the host regardless of transport (although modulo other
137 rules).
139 UAs typically annunciate to their users any issues with secure
140 connection establishment, such as being unable to validate a TLS
141 server certificate trust chain, or if a TLS server certificate is
142 expired, or if a TLS server's domain name appears incorrectly in the
143 TLS server certificate (see section 3.1 of [RFC2818]). Often, UAs
144 enable users to elect to continue to interact with a web resource in
145 the face of such issues. This behavior is sometimes referred to as
146 "click(ing) through" security [GoodDhamijaEtAl05]
147 [SunshineEgelmanEtAl09], and thus can be described as "click-through
148 insecurity" .
150 Jackson and Barth proposed an approach, in [ForceHTTPS], to enable
151 web sites and/or users to declare that such issues are to be treated
152 as fatal and without direct user recourse. The aim is to prevent
153 users from unintentionally downgrading their security.
155 This specification embodies and refines the approach proposed in
156 [ForceHTTPS], e.g. a HTTP response header field is used to convey
157 site policy to the UA rather than a cookie.
159 2. Overview
161 This section discusses the use cases, summarizes the HTTP Strict
162 Transport Security (HSTS) policy, and continues with a discussion of
163 the threat model, non-addressed threats, and derived requirements.
165 2.1. Use Cases
167 The high-level use case is a combination of:
169 o Web browser user wishes to discover, or be introduced to, and/or
170 utilize various web sites (some arbitrary, some known) in a secure
171 fashion.
173 o Web site deployer wishes to offer their site in an explicitly
174 secure fashion for both their own, as well as their users',
175 benefit.
177 2.2. Strict Transport Security Policy Effects
179 The characteristics of the HTTP Strict Transport Security policy, as
180 applied by a UA in its interactions with a web site wielding HSTS
181 Policy, known as a HSTS Host, is summarized as follows:
183 1. All insecure ("http") connections to a HSTS Host are redirected
184 by the HSTS Host to be secure connections ("https").
186 2. The UA terminates, without user recourse, any secure transport
187 connection attempts upon any and all secure transport errors or
188 warnings, including those caused by a site presenting self-signed
189 certificates.
191 3. UAs transform insecure URI references to a HSTS Host into secure
192 URI references before dereferencing them.
194 2.3. Threat Model
196 HSTS is concerned with three threat classes: passive network
197 attackers, active network attackers, and imperfect web developers.
198 However, it is explicitly not a remedy for two other classes of
199 threats: phishing and malware. Addressed and not addressed threats
200 are briefly discussed below. Readers may wish refer to [ForceHTTPS]
201 for details as well as relevant citations.
203 2.3.1. Threats Addressed
204 2.3.1.1. Passive Network Attackers
206 When a user browses the web on a local wireless network (e.g. an
207 802.11-based wireless local area network) a nearby attacker can
208 possibly eavesdrop on the user's unencrypted Internet Protocol-based
209 connections, such as HTTP, regardless of whether or not the local
210 wireless network itself is secured [BeckTews09]. Freely available
211 wireless sniffing toolkits, e.g. [Aircrack-ng], enable such passive
212 eavesdropping attacks. A passive network attacker using such tools
213 can steal session identifiers and hijack the user's web session(s),
214 by obtaining cookies containing authentication credentials for
215 example [ForceHTTPS].
217 To mitigate such threats, some Web sites support, but usually do not
218 force, access using end-to-end secure transport -- e.g. signaled
219 through URIs constructed with the "https" scheme [RFC2818]. This can
220 lead users to believe that accessing such services using secure
221 transport protects them from passive network attackers.
222 Unfortunately, this is often not the case in real-world deployments
223 as session identifiers are often stored in non-Secure cookies to
224 permit interoperability with versions of the service offered over
225 insecure transport ("Secure cookes" are those cookies containing the
226 "Secure" attribute [RFC2109]). For example, if the session
227 identifier for a web site (an email service, say) is stored in a non-
228 Secure cookie, it permits an attacker to hijack the user's session if
229 the user's UA makes a single insecure HTTP request to the site.
231 2.3.1.2. Active Network Attackers
233 A determined attacker can mount an active attack, either by
234 impersonating a user's DNS server or, in a wireless network, by
235 spoofing network frames or offering a similarly-named evil twin
236 access point. If the user is behind a wireless home router, an
237 attacker can attempt to reconfigure the router using default
238 passwords and other vulnerabilities. Some sites, such as banks, rely
239 on end-to-end secure transport to protect themselves and their users
240 from such active attackers. Unfortunately, browsers allow their
241 users to easily opt-out of these protections in order to be usable
242 for sites that incorrectly deploy secure transport, for example by
243 generating and self-signing their own certificates (without also
244 distributing their CA certificate to their users' browsers).
246 2.3.1.3. Web Site Development and Deployment Bugs
248 The security of an otherwise uniformly secure site (i.e. all of its
249 content is materialized via "https" URIs), can be compromised
250 completely by an active attacker exploiting a simple mistake, such as
251 the loading of a cascading style sheet or a SWF movie over an
252 insecure connection (both cascading style sheets and SWF movies can
253 script the embedding page, to the surprise of many web developers --
254 most browsers do not issue mixed content warnings when insecure SWF
255 files are embedded). Even if the site's developers carefully
256 scrutinize their login page for mixed content, a single insecure
257 embedding anywhere on the site compromises the security of their
258 login page because an attacker can script (control) the login page by
259 injecting script into the page with mixed content.
261 Note: "Mixed content" here refers to the same notion referred to as
262 "mixed security context" later elsewhere in this
263 specification.
265 2.3.2. Threats Not Addressed
267 2.3.2.1. Phishing
269 Phishing attacks occur when an attacker solicits authentication
270 credentials from the user by hosting a fake site located on a
271 different domain than the real site, perhaps driving traffic to the
272 fake site by sending a link in an email message. Phishing attacks
273 can be very effective because users find it difficult to distinguish
274 the real site from a fake site. HSTS is not a defense against
275 phishing per se; rather, it complements many existing phishing
276 defenses by instructing the browser to protect session integrity and
277 long-lived authentication tokens [ForceHTTPS].
279 2.3.2.2. Malware and Browser Vulnerabilities
281 Because HSTS is implemented as a browser security mechanism, it
282 relies on the trustworthiness of the user's system to protect the
283 session. Malicious code executing on the user's system can
284 compromise a browser session, regardless of whether HSTS is used.
286 2.4. Requirements
288 This section identifies and enumerates various requirements derived
289 from the use cases and the threats discussed above, and lists the
290 detailed core requirements HTTP Strict Transport Security addresses,
291 as well as ancillary requirements that are not directly addressed.
293 2.4.1. Overall Requirement
295 o Minimize the risks to web browser users and web site deployers
296 that are derived from passive and active network attackers, web
297 site development and deployment bugs, as well as insecure user
298 actions.
300 2.4.1.1. Detailed Core Requirements
302 These core requirements are derived from the overall requirement, and
303 are addressed by this specification.
305 1. Web sites need to be able to declare to UAs that they should be
306 interacted with using a strict security policy.
308 2. Web sites need to be able to instruct UAs that contact them
309 insecurely to do so securely.
311 3. UAs need to note web sites that signal strict security policy
312 enablement, for a web site declared time span.
314 4. UAs need to re-write all insecure UA "http" URI loads to use the
315 "https" secure scheme for those web sites for which secure policy
316 is enabled.
318 5. Web site administrators need to be able to signal strict security
319 policy application to subdomains of higher-level domains for
320 which strict security policy is enabled, and UAs need to enforce
321 such policy.
323 6. For example, both example.com and foo.example.com could set
324 policy for bar.foo.example.com.
326 7. UAs need to disallow security policy application to peer domains,
327 and/or higher-level domains, by domains for which strict security
328 policy is enabled.
330 8. For example, neither bar.foo.example.com nor foo.example.com can
331 set policy for example.com, nor can bar.foo.example.com set
332 policy for foo.example.com. Also, foo.example.com cannot set
333 policy for sibling.example.com.
335 9. UAs need to prevent users from clicking-through security
336 warnings. Halting connection attempts in the face of secure
337 transport exceptions is acceptable.
339 Note: A means for uniformly securely meeting the first core
340 requirement above is not specifically addressed by this
341 specification (see Section 12.2 "Bootstrap MITM
342 Vulnerability"). It may be addressed by a future revision of
343 this specification or some other specification. Note also
344 that there are means by which UA implementations may more
345 fully meet the first core requirement, see Section 10 "UA
346 Implementation Advice".
348 2.4.1.2. Detailed Ancillary Requirements
350 These ancillary requirements are also derived from the overall
351 requirement. They are not normatively addressed in this
352 specification, but could be met by UA implementations at their
353 implementor's discretion, although meeting these requirements may be
354 complex.
356 1. Disallow "mixed security context" (also known as "mixed-content")
357 loads (see section 5.3 "Mixed Content" in
358 [W3C.WD-wsc-ui-20100309]).
360 2. Facilitate user declaration of web sites for which strict
361 security policy is enabled, regardless of whether the sites
362 signal HSTS Policy.
364 3. Conformance Criteria
366 This specification is written for hosts and user agents (UAs).
368 In this specification, the words MUST, MUST NOT, MAY, and SHOULD are
369 to be interpreted as described in [RFC2119].
371 A conformant host is one that implements all the requirements listed
372 in this specification that are applicable to hosts.
374 A conformant user agent is one that implements all the requirements
375 listed in this specification that are applicable to user agents.
377 3.1. Document Conventions
379 Note: ..is a note to the reader. These are points that should be
380 expressly kept in mind and/or considered.
382 Warning: This is how a warning is shown. These are things that can
383 have suboptimal downside risks if not heeded.
385 [[XXXn: Some of the more major known issues are marked like this
386 (where "n" in "XXXn" is a number). --JeffH]]
388 [[TODOn: Things to fix (where "n" in "TODOn" is a number). --JeffH]]
390 4. Terminology
392 Terminology is defined in this section.
394 ASCII case-insensitive comparison
395 means comparing two strings exactly, codepoint for
396 codepoint, except that the characters in the range
397 U+0041 .. U+005A (i.e. LATIN CAPITAL LETTER A to
398 LATIN CAPITAL LETTER Z) and the corresponding
399 characters in the range U+0061 .. U+007A (i.e.
400 LATIN SMALL LETTER A to LATIN SMALL LETTER Z) are
401 considered to also match. See [Unicode5] for
402 details.
404 codepoint is a colloquial contraction of Code Point, which is
405 any value in the Unicode codespace; that is, the
406 range of integers from 0 to 10FFFF(hex) [Unicode5].
408 Domain Name Domain Names, also referred to as DNS Names, are
409 defined in [RFC1035] to be represented outside of
410 the DNS protocol itself (and implementations
411 thereof) as a series of labels separated by dots,
412 e.g. "example.com" or "yet.another.example.org".
413 In the context of this specification, Domain Names
414 appear in that portion of a URI satisfying the reg-
415 name production in "Appendix A. Collected ABNF for
416 URI" in [RFC3986], and the host component from the
417 Host HTTP header field production in section 14.23
418 of [RFC2616].
420 Note: The Domain Names appearing in actual URI
421 instances and matching the aforementioned
422 production components may or may not be
423 FQDNs.
425 Domain Name Label is that portion of a Domain Name appearing "between
426 the dots", i.e. consider "foo.example.com": "foo",
427 "example", and "com" are all domain name labels.
429 Effective Request URI
430 is a URI that can be constructed by an HTTP host
431 for any given HTTP request sent to it. Some HTTP
432 requests do not contain a contiguous representation
433 of the URI identifying the resource being addressed
434 by the HTTP request. Rather, different portions of
435 a resource's URI may be mapped to both the Request-
436 Line header field and the Host header field in an
437 HTTP request message
438 [I-D.ietf-httpbis-p1-messaging]. The HTTP server
439 coalesces these URI fragments and constructs an
440 equivalent of the Request-URI that was used by the
441 UA to generate the received HTTP request message.
443 See Section 11 "Constructing an Effective Request
444 URI", below.
446 FQDN is an acronym for Fully-qualified Domain Name. A
447 FQDN is a Domain Name that includes all higher
448 level domains relevant to the named entity
449 (typically a HSTS Host in the context of this
450 specification). If one thinks of the DNS as a
451 tree-structure with each node having its own Domain
452 Name Label, a FQDN for a specific node would be its
453 label followed by the labels of all the other nodes
454 between it and the root of the tree. For example,
455 for a host, a FQDN would include the label that
456 identifies the particular host, plus all domains of
457 which the host is a part, up to and including the
458 top-level domain (the root domain is always null)
459 [RFC1594].
461 HTTP Strict Transport Security
462 is the overall name for the combined UA- and
463 server-side security policy defined by this
464 specification.
466 HTTP Strict Transport Security Host
467 is a HTTP host implementing the server aspects of
468 the HSTS policy.
470 HTTP Strict Transport Security Policy
471 is the name of the combined overall UA- and server-
472 side facets of the behavior specified in this
473 specification.
475 HSTS See HTTP Strict Transport Security.
477 HSTS Host See HTTP Strict Transport Security Host.
479 HSTS Policy See HTTP Strict Transport Security Policy.
481 Known HSTS Host is a HSTS Host for which the UA has a HSTS Policy
482 in effect.
484 Local policy is comprised of policy rules deployers specify and
485 which are often manifested as "configuration
486 settings".
488 MITM is an acronym for man-in-the-middle. See "man-in-
489 the-middle attack" in [RFC4949].
491 Request URI is the URI used to cause a UA to issue an HTTP
492 request message.
494 UA is a an acronym for user agent. For the purposes
495 of this specification, a UA is an HTTP client
496 application typically actively manipulated by a
497 user [RFC2616] .
499 5. Syntax
501 This section defines the syntax of the new header this specification
502 introduces. It also provides a short description of the function the
503 header.
505 The Section 6 "Server Processing Model" section details how hosts are
506 to use this header. Likewise, the Section 7 "User Agent Processing
507 Model" section details how user agents are to use this header.
509 5.1. Strict-Transport-Security HTTP Response Header Field
511 The Strict-Transport-Security HTTP response header field indicates to
512 a UA that it MUST enforce the HSTS Policy in regards to the host
513 emitting the response message containing this header field.
515 The ABNF syntax for the Strict-Transport-Security HTTP Response
516 Header field is:
518 Strict-Transport-Security =
520 "Strict-Transport-Security" ":" OWS STS-v OWS
522 ; value
523 STS-v = STS-d
524 / STS-d *( OWS ";" OWS STS-d OWS )
526 ; STS directive
527 STS-d = STS-d-cur / STS-d-ext
529 ; defined STS directives
530 STS-d-cur = maxAge / includeSubDomains
532 maxAge = "max-age" OWS "=" OWS delta-seconds v-ext
534 includeSubDomains = [ "includeSubDomains" ] v-ext
536 ; extension points
537 STS-d-ext = name ; STS extension directive
539 v-ext = value ; STS extension value
541 name = token
543 value = OWS / %x21-3A / %x3C-7E ; i.e. optional white space, or
544 ; [ ! .. : ] [ < .. ~ ] any visible chars other than ";"
546 ; productions imported from [ID.ietf-httpbis-p1-messaging]:
548 token
550 OWS ; Optional White Space
552 Note: [I-D.ietf-httpbis-p1-messaging] is used as the ABNF basis in
553 order to ensure that the new header has equivalent parsing
554 rules to the header fields defined in that same specification.
555 Also:
557 1. Quoted-string literals in the above ABNF stanza are
558 case-insensitive.
560 2. In order to correctly match the grammar above, the
561 Strict-Transport-Security HTTP Response Header MUST
562 include at least a max-age directive with at least a
563 single-digit value for delta-seconds.
565 max-age specifies the number of seconds, after the recption of the
566 Strict-Transport-Security HTTP Response Header, during which
567 the UA regards the host the message was received from as a
568 Known HSTS Host (see also Section 7.1.1 "Noting a HSTS
569 Host", below). The delta-seconds production is specified in
570 [RFC2616].
572 [[TODO1: The above para wrt max-age may need further refinement.
573 --JeffH]]
575 includeSubDomains is a flag which, if present, signals to the UA that
576 the HSTS Policy applies to this HSTS Host as well
577 as any subdomains of the host's FQDN.
579 5.2. Examples
581 The below HSTS header field stipulates that the HSTS policy is to
582 remain in effect for one year (there are approximately 31 536 000
583 seconds in a year), and the policy applies only to the domain of the
584 HSTS Host issuing it:
586 Strict-Transport-Security: max-age=31536000
588 The below HSTS header field is stipulates that the HSTS policy is to
589 remain in effect for approximately six months and the policy applies
590 only to the domain of the issuing HSTS Host and all of its
591 subdomains:
593 Strict-Transport-Security: max-age=15768000 ; includeSubDomains
595 6. Server Processing Model
597 This section describes the processing model that HSTS Hosts
598 implement. The model is comprised of two facets: the first being the
599 processing rules for HTTP request messages received over a secure
600 transport (e.g. TLS [RFC4346], SSL [I-D.ietf-tls-ssl-version3], or
601 perhaps others, the second being the processing rules for HTTP
602 request messages received over non-secure transports, i.e. over
603 TCP/IP [RFC0793].
605 6.1. HTTP-over-Secure-Transport Request Type
607 When replying to an HTTP request that was conveyed over a secure
608 transport, a HSTS Host SHOULD include in its response message a
609 Strict-Transport-Security HTTP Response Header that MUST satisfy the
610 grammar specified above in Section 5.1 "Strict-Transport-Security
611 HTTP Response Header Field". If a Strict-Transport-Security HTTP
612 Response Header is included, the HSTS Host MUST include only one such
613 header.
615 Note: Including the Strict-Transport-Security HTTP Response Header
616 is stipulated as a "SHOULD" in order to accomodate various
617 server- and network-side caches and load-balancing
618 configurations where it may be difficult to uniformly emit
619 Strict-Transport-Security HTTP Response Headers on behalf of a
620 given HSTS Host.
622 Establishing a given host as a Known HSTS Host, in the context
623 of a given UA, MAY be accomplished over the HTTP protocol by
624 correctly returning, per this specification, at least one
625 valid Strict-Transport-Security HTTP Response Header to the
626 UA. Other mechanisms, such as a client-side pre-loaded Known
627 HSTS Host list MAY also be used. E.g. see Section 10 "UA
628 Implementation Advice".
630 6.2. HTTP Request Type
632 If a HSTS Host receives a HTTP request message over a non-secure
633 transport, it SHOULD send a HTTP response message containing a
634 Status-Code of 301 and a Location header field value containing
635 either the HTTP request's original Effective Request URI (see
636 Section 11 "Constructing an Effective Request URI", below) altered as
637 necessary to have a URI scheme of "https", or a URI generated
638 according to local policy (which SHOULD employ a URI scheme of
639 "https").
641 Note: The above behavior is a "SHOULD" rather than a "MUST" 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 Host (by whatever means, e.g.
654 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 Host MUST NOT include the Strict-Transport-Security HTTP
660 Response Header in HTTP responses conveyed over non-secure transport.
662 7. User Agent Processing Model
664 This section describes the HTTP Strict Transport Security processing
665 model for UAs. There are several facets to the model, enumerated by
666 the following subsections.
668 Also, this processing model assumes that all Domain Names manipulated
669 in this specification's context are already in ASCII Compatible
670 Encoding (ACE) format as specified in [RFC3490]. If this is not the
671 case in some situation, use the operation given in Section 8 "Domain
672 Name ToASCII Conversion Operation" to convert any encountered
673 internationalized Domain Names to ACE format before processing them.
675 7.1. Strict-Transport-Security Response Header Field Processing
677 If an HTTP response, received over a secure transport, includes a
678 Strict-Transport-Security HTTP Response Header field, conforming to
679 the grammar specified in Section 5.1 "Strict-Transport-Security HTTP
680 Response Header Field" (above), and there are no underlying secure
681 transport errors or warnings, the UA MUST either:
683 o Note the host as a Known HSTS Host if it is not already so noted
684 (see Section 7.1.1 "Noting a HSTS Host", below),
686 or,
688 o Update its cached information for the Known HSTS Host if the max-
689 age and/or includeSubDomains header field value tokens are
690 conveying information different than that already maintained by
691 the UA.
693 Note: The max-age value is essentially a "time to live" value
694 relative to the reception time of the Strict-Transport-
695 Security HTTP Response Header.
697 [[TODO2: Decide UA behavior in face of encountering multiple HSTS
698 headers in a message. Use first header? Last? --JeffH]]
699 Otherwise:
701 o If an HTTP response is received over insecure transport, the UA
702 MUST ignore any present Strict-Transport-Security HTTP Response
703 Header(s).
705 o The UA MUST ignore any Strict-Transport-Security HTTP Response
706 Headers not conforming to the grammar specified in Section 5.1
707 "Strict-Transport-Security HTTP Response Header Field" (above).
709 7.1.1. Noting a HSTS Host
711 If the substring matching the host production from the Request-URI,
712 that the host responded to, syntactically matches the IP-literal or
713 IPv4address productions from section 3.2.2 of [RFC3986], then the UA
714 MUST NOT note this host as a Known HSTS Host.
716 Otherwise, if the substring does not congruently match a presently
717 known HSTS Host, per the matching procedure specified in
718 Section 7.1.2 "Known HSTS Host Domain Name Matching" below, then the
719 UA MUST note this host as a Known HSTS Host, caching the HSTS Host's
720 Domain Name and noting along with it the expiry time of this
721 information, as effectively stipulated per the given max-age value,
722 as well as whether the includeSubDomains flag is asserted or not.
724 7.1.2. Known HSTS Host Domain Name Matching
726 A UA determines whether a Domain Name represents a Known HSTS Host by
727 looking for a match between the query Domain Name and the UA's set of
728 Known HSTS Hosts.
730 1. Compare the query Domain Name string with the Domain Names of the
731 UA's set of Known HSTS Hosts. For each Known HSTS Host's Domain
732 Name, the comparison is done with the query Domain Name label-by-
733 label using an ASCII case-insensitive comparison beginning with
734 the rightmost label, and continuing right-to-left, and ignoring
735 separator characters (see clause 3.1(4) of [RFC3986].
737 * If a label-for-label match between an entire Known HSTS Host's
738 Domain Name and a right-hand portion of the query Domain Name
739 is found, then the Known HSTS Host's Domain Name is a
740 superdomain match for the query Domain Name.
742 For example:
744 Query Domain Name: bar.foo.example.com
746 Superdomain matched
747 Known HSTS Host DN: foo.example.com
749 At this point, the query Domain Name is ascertained to
750 effectively represent a Known HSTS Host. There may also be
751 additional matches further down the Domain Name Label tree, up
752 to and including a congruent match.
754 * If a label-for-label match between a Known HSTS Host's Domain
755 Name and the query domain name is found, i.e. there are no
756 further labels to compare, then the query Domain Name
757 congruently matches this Known HSTS Host.
759 For example:
761 Query Domain Name: foo.example.com
763 Congruently matched
764 Known HSTS Host DN: foo.example.com
766 The query Domain Name is ascertained to represent a Known HSTS
767 Host. However, if there are also superdomain matches, the one
768 highest in the tree asserts the HSTS Policy for this Known
769 HSTS Host.
771 * Otherwise, if no matches are found, the query Domain Name does
772 not represent a Known HSTS Host.
774 7.2. URI Loading and Port Mapping
776 Whenever the UA prepares to "load", also known as "dereference", any
777 URI where the host component of the authority component of the URI
778 [RFC3986] matches that of a Known HSTS Host -- either as a congruent
779 match or as a superdomain match where the superdomain Known HSTS Host
780 has includeSubDomains asserted -- and the URI's scheme is "http",
781 then the UA MUST replace the URI scheme with "https" before
782 proceeding with the load.
784 Additionally, if the URI contains a port component [RFC3986] equal to
785 "80", the UA MUST covert the port component to be "443". Otherwise,
786 a present port component MUST be preserved.
788 7.3. Errors in Secure Transport Establishment
790 When connecting to a Known HSTS Host, the UA MUST terminate the
791 connection with no user recourse if there are any errors (e.g.
792 certificate errors), whether "warning" or "fatal" or any other error
793 level, with the underlying secure transport.
795 7.4. HTTP-Equiv Element Attribute
797 UAs MUST NOT heed http-equiv="Strict-Transport-Security" attribute
798 settings on elements in received content.
800 8. Domain Name ToASCII Conversion Operation
802 This operation converts a string-serialized Domain Name possibly
803 containing arbitrary Unicode characters [Unicode5] into a string-
804 serialized Domain Name in ASCII Compatible Encoding (ACE) format as
805 specified in [RFC3490].
807 The operation is:
809 o Apply the IDNA conversion operation (section 4 of [RFC3490]) to
810 the string, selecting the ToASCII operation and setting both the
811 AllowUnassigned and UseSTD3ASCIIRules flags.
813 9. Server Implementation Advice
815 HSTS Policy expiration time considerations:
817 o Server implementations and deploying web sites need to consider
818 whether they are setting an expiry time that is a constant value
819 into the future, e.g. by constantly sending the same max-age value
820 to UAs. For exmple:
822 Strict-Transport-Security: max-age=778000
824 A max-age value of 778000 is 90 days. Note that each receipt of
825 this header by a UA will require the UA to update its notion of
826 when it must delete its knowledge of this Known HSTS Host. The
827 specifics of how this is accomplished is out of the scope of this
828 specification.
830 o Or, whether they are setting an expiry time that is a fixed point
831 in time, e.g. by sending max-age values that represent the
832 remaining time until the expiry time.
834 o A consideration here is whether a deployer wishes to have signaled
835 HSTS Policy expiry time match that for the web site's domain
836 certificate.
838 Considerations for using HTTP Strict Transport Security in
839 conjunction with self-signed public-key certificates:
841 o If a web site/organization/enterprise is generating their own
842 secure transport public-key certificates for web sites, and that
843 organization's root certificate authority (CA) certificate is not
844 typically embedded by default in browser CA certificate stores,
845 and if HSTS Policy is enabled on a site identifying itself using a
846 self-signed certificate, then secure connections to that site will
847 fail without user recourse, per the HSTS design. This is to
848 protect against various active attacks, as discussed above.
850 o However, if said organization strongly wishes to employ self-
851 signed certificates, and their own CA in concert with HSTS, they
852 can do so by deploying their root CA certificate to their users'
853 browsers. There are various ways in which this can be
854 accomplished (details are out of scope for this specification).
855 Once their root CA cert is installed in the browsers, they may
856 employ HSTS Policy on their site(s).
858 Note: Interactively distributing root CA certs to users, e.g. via
859 email, and having the users install them, is arguably
860 training the users to be susceptible to a possible form of
861 phishing attack, see Section 12.4 "Bogus Root CA
862 Certificate Phish plus DNS Cache Poisoning Attack".
864 10. UA Implementation Advice
866 In order to provide users and web sites more effective protection, UA
867 implementors should consider including features such as:
869 o Disallowing "mixed security context" (also known as "mixed-
870 content") loads (see section 5.3 "Mixed Content" in
871 [W3C.WD-wsc-ui-20100309]).
873 Note: In order to provide behavioral uniformity across UA
874 implementations, the notion of mixed security context aka
875 mixed-content will require (further) standardization work,
876 e.g. to more clearly define the term(s) and to define
877 specific behaviors with respect to it.
879 In order to provide users effective controls for managing their UA's
880 caching of HSTS Policy, UA implementors should consider including
881 features such as:
883 o Ability to delete UA's cached HSTS Policy on a per HSTS Host
884 basis.
886 Note: Adding such a feature should be done very carefully in both
887 the user interface and security senses. Deleting a cache
888 entry for a Known HSTS Host should be a very deliberate and
889 well-considered act -- it shouldn't be something users get
890 used to just "clicking through" in order to get work done.
891 Also, it shouldn't be possible for an attacker to inject
892 script into the UA that silently and programmatically
893 removes entries from the UA's cache of Known HSTS Hosts.
895 In order to provide users and web sites more complete protection, UAs
896 could offer advanced features such as these:
898 o Ability for users to explicitly declare a given Domain Name as
899 representing a HSTS Host, thus seeding it as a Known HSTS Host
900 before any actual interaction with it. This would help protect
901 against the Section 12.2 "Bootstrap MITM Vulnerability".
903 Note: Such a feature is difficult to get right on a per-site
904 basis -- see the discussion of "rewrite rules" in section
905 5.5 of [ForceHTTPS]. For example, arbitrary web sites may
906 not materialize all their URIs using the "https" scheme,
907 and thus could "break" if a UA were to attempt to access
908 the site exclusively using such URIs. Also note that this
909 feature would complement, but is independent of the
910 following described facility.
912 o Facility whereby web site administrators can have UAs pre-
913 configured with HSTS Policy for their site(s) by the UA vendor(s)
914 -- in a manner similar to how root CA certificates are embedded in
915 browsers "at the factory". This would help protect against the
916 Section 12.2 "Bootstrap MITM Vulnerability".
918 Note: Such a facility complements the preceding described
919 feature.
921 [[XXX2: These latter items beg the question of having some means of
922 secure web site metadata and policy discovery and acquisition. There
923 is extant work that may be of interest, e.g. the W3C POWDER work,
924 OASIS XRI/XRD work (as well as XRDS-Simple), and "Link-based Resource
925 Descriptor Discovery" (draft-hammer-discovery). --JeffH]]
927 11. Constructing an Effective Request URI
929 This section specifies how an HSTS Host must construct the Effective
930 Request URI for a received HTTP request.
932 The first line of an HTTP request message is specified by the
933 following ABNF ([I-D.ietf-httpbis-p1-messaging] section 4.1):
935 Request-Line = Method SP request-target SP HTTP-Version CRLF
937 The request-target is following ABNF ([I-D.ietf-httpbis-p1-messaging]
938 section 4.1.2):
940 request-target = "*"
941 / absolute-URI
942 / ( path-absolute [ "?" query ] )
943 / authority
945 Additionally, many HTTP requests contain an additional Host request
946 header field. It is specified by the following ABNF
947 ([I-D.ietf-httpbis-p1-messaging] section 4.1.2):
949 Host = "Host:" OWS Host-v
950 Host-v = uri-host [ ":" port ]
952 Thus an example HTTP message containing the above header fields is:
954 GET /hello.txt HTTP/1.1
955 Host: www.example.com
957 Another example is:
959 GET HTTP://www.example.com/hello.txt HTTP/1.1
961 An HSTS Host constructs the Effective Request URI using the following
962 ABNF grammar (which imports some productions from the above ABNF for
963 Request-Line, request-target, and Host:
965 Effective-Request-URI = absolute-URI-present / path-absolute-form
967 absolute-URI-present = absolute-URI
969 path-absolute-form = scheme "://" Host-v path-absolute [ "?" query ]
971 where:
973 scheme is "http" if the request was received over
974 insecure transport, or scheme is "https" if the
975 request was received over secure transport.
977 For example, if the request message contains a request-target
978 component that matches the grammar of absolute-URI, then the
979 Effective-Request-URI is simply the value of the absolute-URI
980 component. Otherwise, the Effective-Request-URI is a combination,
981 per the path-absolute-form production, of the Host-v, path-absolute,
982 and query components from the request-target and Host components of
983 the request message.
985 [[TODO3: This is a first SWAG at this section. Fix/add prose as
986 appropriate, fix ABNF as needed per review. --JeffH]]
988 12. Security Considerations
990 12.1. Denial of Service (DoS)
992 HSTS could be used to mount certain forms of DoS attacks, where
993 attackers set fake HSTS headers on legitimate sites available only
994 insecurely (e.g. social network service sites, wikis, etc.).
996 12.2. Bootstrap MITM Vulnerability
998 The bootstrap MITM (Man-In-The-Middle) vulnerability is a
999 vulnerability users and HSTS Hosts encounter in the situation where
1000 the user manually enters, or follows a link, to a HSTS Host using a
1001 "http" URI rather than a "https" URI. Because the UA uses an
1002 insecure channel in the initial attempt to interact with the
1003 specified serve, such an initial interaction is vulnerable to various
1004 attacks [ForceHTTPS] .
1006 Note: There are various features/facilities that UA implementations
1007 may employ in order to mitigate this vulnerability. Please
1008 see Section 10 UA Implementation Advice.
1010 12.3. Network Time Attacks
1012 Active network attacks can subvert network time protocols (like NTP)
1013 - making this header less effective against clients that trust NTP
1014 and/or lack a real time clock. Network time attacks are therefore
1015 beyond the scope of the defense. Note that modern operating systems
1016 use NTP by default.
1018 12.4. Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack
1020 If an attacker can convince users of, say, https://bank.example.com
1021 (which is protected by HSTS Policy), to install their own version of
1022 a root CA certificate purporting to be bank.example.com's CA, e.g.
1023 via a phishing email message with a link to such a certificate --
1024 then, if they can perform an attack on the users' DNS, e.g. via cache
1025 poisoning, and turn on HSTS Policy for their fake bank.example.com
1026 site, then they have themselves some new users.
1028 13. IANA Considerations
1030 Below is the Internet Assigned Numbers Authority (IANA) Provisional
1031 Message Header Field registration information per [RFC3864].
1033 Header field name: Strict-Transport-Security
1034 Applicable protocol: HTTP
1035 Status: provisional
1036 Author/Change controller: TBD
1037 Specification document(s): this one
1039 14. Design Decision Notes
1041 This appendix documents various design decisions.
1043 1. Cookies aren't appropriate for HSTS Policy expression as they are
1044 potentially mutable (while stored in the UA), therefore an HTTP
1045 header field is employed.
1047 2. We chose to not attempt to specify how "mixed security context
1048 loads" (aka "mixed-content loads") are handled due to UA
1049 implementation considerations as well as classification
1050 difficulties.
1052 3. A HSTS Host may update UA notions of HSTS Policy via new HSTS
1053 header field values. We chose to have UAs honor the "freshest"
1054 information received from a server because there is the chance of
1055 a web site sending out an errornous HSTS Policy, such as a multi-
1056 year max-age value, and/or an incorrect includeSubDomains flag.
1057 If the HSTS Host couldn't correct such errors over protocol, it
1058 would require some form of annunciation to users and manual
1059 intervention on their part, which could be a non-trivial problem.
1061 4. HSTS Hosts are identified only via Domain Names -- explicit IP
1062 address identification of all forms is excluded. This is for
1063 simplification and also is in recognition of various issues with
1064 using direct IP address identification in concert with PKI-based
1065 security.
1067 15. References
1068 15.1. Normative References
1070 [I-D.ietf-httpbis-p1-messaging]
1071 Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
1072 Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke,
1073 "HTTP/1.1, part 1: URIs, Connections, and Message
1074 Parsing", draft-ietf-httpbis-p1-messaging-09 (work in
1075 progress), March 2010.
1077 [RFC1035] Mockapetris, P., "Domain names - implementation and
1078 specification", STD 13, RFC 1035, November 1987.
1080 [RFC1594] Marine, A., Reynolds, J., and G. Malkin, "FYI on Questions
1081 and Answers - Answers to Commonly asked "New Internet
1082 User" Questions", RFC 1594, March 1994.
1084 [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983,
1085 August 1996.
1087 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
1088 Mechanism", RFC 2109, February 1997.
1090 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1091 Requirement Levels", BCP 14, RFC 2119, March 1997.
1093 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1094 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1095 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1097 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
1099 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
1100 Mechanism", RFC 2965, October 2000.
1102 [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
1103 Internationalized Strings ("stringprep")", RFC 3454,
1104 December 2002.
1106 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
1107 "Internationalizing Domain Names in Applications (IDNA)",
1108 RFC 3490, March 2003.
1110 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
1111 for Internationalized Domain Names in Applications
1112 (IDNA)", RFC 3492, March 2003.
1114 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
1115 Procedures for Message Header Fields", BCP 90, RFC 3864,
1116 September 2004.
1118 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1119 Resource Identifier (URI): Generic Syntax", STD 66,
1120 RFC 3986, January 2005.
1122 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1123 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
1125 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
1126 RFC 4949, August 2007.
1128 [Unicode5]
1129 The Unicode Consortium, "The Unicode Standard, Version
1130 5.0", Boston, MA, Addison-Wesley ISBN 0-321-48091-0, 2007.
1132 [W3C.WD-html5-20100304]
1133 Hyatt, D. and I. Hickson, "HTML5", World Wide Web
1134 Consortium WD WD-html5-20100304, March 2010,
1135 .
1137 15.2. Informative References
1139 [Aircrack-ng]
1140 d'Otreppe, T., "Aircrack-ng", Accessed: 11-Jul-2010,
1141 .
1143 [BeckTews09]
1144 Beck, M. and E. Tews, "Practical Attacks Against WEP and
1145 WPA", Second ACM Conference on Wireless Network
1146 Security Zurich, Switzerland, 2009, .
1150 [ForceHTTPS]
1151 Jackson, C. and A. Barth, "ForceHTTPS: Protecting High-
1152 Security Web Sites from Network Attacks", In Proceedings
1153 of the 17th International World Wide Web Conference
1154 (WWW2008) , 2008,
1155 .
1157 [GoodDhamijaEtAl05]
1158 Good, N., Dhamija, R., Grossklags, J., Thaw, D.,
1159 Aronowitz, S., Mulligan, D., and J. Konstan, "Stopping
1160 Spyware at the Gate: A User Study of Privacy, Notice and
1161 Spyware", In Proceedings of Symposium On Usable Privacy
1162 and Security (SOUPS) Pittsburgh, PA, USA, July 2005, .
1166 [I-D.ietf-tls-ssl-version3]
1167 Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
1168 Version 3.0", draft-ietf-tls-ssl-version3 (work in
1169 progress), November 1996, .
1172 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
1173 RFC 793, September 1981.
1175 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1176 Resource Identifiers (URI): Generic Syntax", RFC 2396,
1177 August 1998.
1179 [SunshineEgelmanEtAl09]
1180 Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and
1181 L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning
1182 Effectiveness", In Proceedings of 18th USENIX Security
1183 Symposium Montreal, Canada, Augus 2009, .
1187 [W3C.WD-wsc-ui-20100309]
1188 Saldhana, A. and T. Roessler, "Web Security Context: User
1189 Interface Guidelines", World Wide Web Consortium
1190 LastCall WD-wsc-ui-20100309, March 2010,
1191 .
1193 [WEBSEC] "WebSec -- HTTP Application Security Minus Authentication
1194 and Transport",
1195 .
1197 [owaspTLSGuide]
1198 Coates, M., Wichers, d., Boberski, M., and T. Reguly,
1199 "Transport Layer Protection Cheat Sheet", Accessed: 11-
1200 Jul-2010, .
1203 Appendix A. Acknowledgments
1205 The authors thank Michael Barrett, Sid Stamm, Maciej Stachowiak, Andy
1206 Steingrubl, Brandon Sterne, Daniel Veditz for their review and
1207 contributions.
1209 Appendix B. Change Log
1211 Changes are grouped by spec revision and listed in reverse
1212 chronological order.
1214 B.1. For draft-ietf-websec-strict-transport-sec
1216 Changes from -00 to -01:
1218 1. Changed the "URI Loading" section to be "URI Loading and Port
1219 Mapping".
1221 2. [HASMAT] reference changed to [WEBSEC].
1223 3. Changed "server" -> "host" where applicable, notably when
1224 discussing "HSTS Hosts". Left as "server" when discussing
1225 e.g. "http server"s.
1227 4. Fixed minor editorial nits.
1229 Changes from draft-hodges-strict-transport-sec-02 to
1230 draft-ietf-websec-strict-transport-sec-00:
1232 1. Altered spec metadata (e.g. filename, date) in order to submit
1233 as a WebSec working group Internet-Draft.
1235 B.2. For draft-hodges-strict-transport-sec
1237 Changes from -01 to -02:
1239 1. updated abstract such that means for expressing HSTS Policy
1240 other than via HSTS header field is noted.
1242 2. Changed spec title to "HTTP Strict Transport Security (HSTS)"
1243 from "Strict Transport Security". Updated use of "STS"
1244 acronym throughout spec to HSTS (except for when specifically
1245 discussing syntax of Strict-Transport-Security HTTP Response
1246 Header field), updated "Terminology" appropriately.
1248 3. Updated the discussion of "Passive Network Attackers" to be
1249 more precise and offered references.
1251 4. Removed para on nomative/non-normative from "Conformance
1252 Criteria" pending polishing said section to IETF RFC norms.
1254 5. Added examples subsection to "Syntax" section.
1256 6. Added OWS to maxAge production in Strict-Transport-Security
1257 ABNF.
1259 7. Cleaned up explanation in the "Note:" in the "HTTP-over-
1260 Secure-Transport Request Type" section, folded 3d para into
1261 "Note:", added conformance clauses to the latter.
1263 8. Added exaplanatory "Note:" and reference to "HTTP Request
1264 Type" section. Added "XXX1" issue.
1266 9. Added conformance clause to "URI Loading".
1268 10. Moved "Notes for STS Server implementors:" from "UA
1269 Implementation dvice " to "HSTS Policy expiration time
1270 considerations:" in "Server Implementation Advice", and also
1271 noted another option.
1273 11. Added cautionary "Note:" to "Ability to delete UA's cached
1274 HSTS Policy on a per HSTS Server basis".
1276 12. Added some informative references.
1278 13. Various minor editorial fixes.
1280 Changes from -00 to -01:
1282 1. Added reference to HASMAT mailing list and request that this
1283 spec be discussed there.
1285 Authors' Addresses
1287 Jeff Hodges
1288 PayPal
1289 2211 North First Street
1290 San Jose, California 95131
1291 US
1293 Email: Jeff.Hodges@PayPal.com
1295 Collin Jackson
1296 Carnegie Mellon University
1298 Email: collin.jackson@sv.cmu.edu
1299 Adam Barth
1300 Google, Inc.
1302 Email: ietf@adambarth.com
1303 URI: http://www.adambarth.com/