idnits 2.17.1
draft-cem-dane-assertion-00.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
-- The document date (November 20, 2014) is 3445 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)
** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112)
** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111)
Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Independent Submission C. Mehner
3 Internet-Draft USAA
4 Intended status: Standards Track November 20, 2014
5 Expires: May 24, 2015
7 HTTP DANE Validation Assertion
8 draft-cem-dane-assertion-00
10 Abstract
12 This document defines a new HTTP header that allows web host
13 operators to instruct user agents to remember the hosts' request for
14 DANE (DNS-Based Authentication of Named Entities) validation over a
15 period of time. During that time, UAs will require that the host
16 presents a certificate chain that will authenticate the Transport
17 Layer Security connection using DANE. By having hosts explicitly
18 state that they have adopted DANE, UAs will only expend resources
19 attempting DANE validation on hosts that request it. Comments are
20 solicited and should be addressed to the author
22 Status of This Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at http://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on May 24, 2015.
39 Copyright Notice
41 Copyright (c) 2014 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
54 Table of Contents
56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
58 2. Server and Client Behavior . . . . . . . . . . . . . . . . . 3
59 2.1. Response Header Field Syntax . . . . . . . . . . . . . . 3
60 2.1.1. The max-age Directive . . . . . . . . . . . . . . . . 4
61 2.1.2. The includeSubDomains Directive . . . . . . . . . . . 5
62 2.1.3. The required Directive . . . . . . . . . . . . . . . 5
63 2.1.4. Examples . . . . . . . . . . . . . . . . . . . . . . 5
64 2.2. Server Processing Model . . . . . . . . . . . . . . . . . 6
65 2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 6
66 2.2.2. HTTP Request Type . . . . . . . . . . . . . . . . . . 6
67 2.3. User Agent Processing Model . . . . . . . . . . . . . . . 6
68 2.3.1. DANE-Validation Response Header Field Processing . . 7
69 2.3.2. Noting a DANE Host - Storage Model . . . . . . . . . 7
70 2.3.3. HTTP-Equiv Element Attribute . . . . . . . . . 9
71 2.4. Noting DANE Hosts . . . . . . . . . . . . . . . . . . . . 9
72 2.5. Validating DANE Connections . . . . . . . . . . . . . . . 9
73 2.6. Interactions With Preloaded DANE Host Lists . . . . . . . 10
74 2.7. TLSA Certificate Usages in DANE . . . . . . . . . . . . . 10
75 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10
76 3.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 11
77 3.2. Using includeSubDomains Safely . . . . . . . . . . . . . 11
78 3.3. Interactions With Cookie Scoping . . . . . . . . . . . . 12
79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
80 5. Usability Considerations . . . . . . . . . . . . . . . . . . 13
81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
82 7. Normative References . . . . . . . . . . . . . . . . . . . . 13
83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
85 1. Introduction
87 This document defines a new HTTP header that enables user agents
88 (UAs) a web host to know which hosts upon which they should perform a
89 DANE [RFC6698] validation. This is called an "HTTP DANE Validation
90 Assertion" (HDVA). The goal of this proposal is to raise the
91 adoption of DANE in web hosts by addressing the cost of attempting
92 DANE Validation on every host via a mechanism that allows web hosts
93 to declare that they use DANE. Using this header also can give hosts
94 the functionality of HTTP-based public key pinning
95 [I-D.ietf-websec-key-pinning] while gaining the greater flexibility
96 of DANE.
98 UAs performing DANE validation on every HTTPS connection will not
99 benefit from this header, however conformant UAs will use DANE on
100 connections subsequent to the initial time the host is noted. Those
101 hosts will not be able to detect and thwart a MITM attacking the UA's
102 first connection to the host. However, the requirement that the MITM
103 provide an X.509 certificate chain that can pass the UA's validation
104 requirements without error (UAs are assumed to use either [RFC5280]
105 or [RFC6698] to verify cryptographic identity) or control over a DNS-
106 SEC zone mitigates this risk somewhat.
108 1.1. Requirements Language
110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
112 document are to be interpreted as described in RFC 2119 [RFC2119].
114 2. Server and Client Behavior
116 2.1. Response Header Field Syntax
118 The DANE-Validation HTTP response header field (DVA header field)
119 indicates to a UA that it should perform DANE Validation ([RFC6698])
120 in regards to the host emitting the response message containing this
121 header field.
123 Figure 1 describes the syntax (Augmented Backus-Naur Form) of the
124 header fields, using the grammar defined in [RFC5234] and the rules
125 defined in Section 3.2 of [RFC7230].
127 DANE-Validation-Directives = directive *( OWS ";" OWS directive )
129 directive = directive-name [ "=" directive-value ]
130 directive-name = token
131 directive-value = token
132 / quoted-string
134 Figure 1: HDVA Header Syntax
136 Optional white space (OWS) is used as defined in Section 3.2.3 of
137 [RFC7230]. Token and quoted-string are used as defined in
138 Section 3.2.6 of [RFC7230].
140 The directives defined in this specification are described below.
141 The overall requirements for directives are:
143 1. The order of appearance of directives is not significant.
145 2. A given directive MUST NOT appear more than once in a given
146 header field. Directives are either optional or required, as
147 stipulated in their definitions.
149 3. Directive names are case-insensitive.
151 4. UAs MUST ignore any header fields containing directives, or other
152 header field value data, that do not conform to the syntax
153 defined in this specification. In particular, UAs must not
154 attempt to fix malformed header fields.
156 5. If a header field contains any directive(s) the UA does not
157 recognize, the UA MUST ignore those directives.
159 6. If the DVA header field otherwise satisfies the above
160 requirements (1 through 5), the UA MUST process the directives it
161 recognizes.
163 Additional directives extending the semantic functionality of the
164 header fields can be defined in other specifications. The first such
165 specification will need to define a registry for such directives.
166 Such future directives will be ignored by UAs implementing only this
167 specification, as well as by generally non-conforming UAs.
169 When a connection passes DANE Validation after noting the DVA header,
170 the host becomes a Known DANE Host.
172 2.1.1. The max-age Directive
174 The REQUIRED "max-age" directive specifies the number of seconds,
175 after the reception of the DVA header field, during which the UA
176 SHOULD regard the host (from whom the message was received) as a
177 Known DANE Host.
179 The syntax of the max-age directive's REQUIRED value (after quoted-
180 string unescaping, if necessary) is defined as:
182 max-age-value = delta-seconds
183 delta-seconds = 1*DIGIT
185 Figure 2: max-age Value Syntax
187 delta-seconds is used as defined in [RFC7234], Section 1.2.1.
189 See Section 2.3.2 for limitations on the range of values for max-age.
191 2.1.2. The includeSubDomains Directive
193 The OPTIONAL includeSubDomains directive is a valueless directive
194 that, if present (i.e., it is "asserted"), signals to the UA that the
195 DANE Policy applies to this DANE Host as well as any subdomains of
196 the host's domain name.
198 2.1.3. The required Directive
200 The OPTIONAL required directive is a valueless directive that, if
201 present (i.e., it is "asserted"), signals to the UA that it MUST
202 perform a DANE validation and if no DANE information is received (via
203 network lookup or cache) the UA MUST NOT start a TLS connection or it
204 MUST abort the TLS handshake. Because Section 4.1 of [RFC6698]
205 allows fallback from DANE to PKIX, this directive is in place for
206 Host operators to force both PKIX and DANE validation to take place
207 to provide the additional protection on the connection.
209 2.1.4. Examples
211 The HDVA header field below stipulates that the HDVA Policy is to
212 remain in effect for one year (there are approximately 31536000
213 seconds in a year), and the policy applies only to the domain of the
214 HDVA Host issuing it:
216 DANE-Validation: max-age=31536000
218 The HDVA header field below stipulates that the HDVA Policy is to
219 remain in effect for approximately six months and that the policy
220 applies to the domain of the issuing HDVA Host and all of its
221 subdomains:
223 DANE-Validation: max-age=15768000 ; includeSubDomains
225 The max-age directive value can optionally be quoted:
227 DANE-Validation: max-age="31536000"
229 The HDVA header field below indicates that the UA must delete the
230 entire HDVA Policy associated with the HDVA Host that sent the header
231 field:
233 DANE-Validation: max-age=0
235 The HDVA header field below has exactly the same effect as the one
236 immediately above because the includeSubDomains directive's presence
237 in the HDVA header field is ignored when max-age is zero:
239 DANE-Validation: max-age=0; includeSubDomains
241 The HDVA header field below states that if the UA MUST receive and
242 validate DANE information, and if it does not it MUST close the
243 connection:
245 DANE-Validation: max-age=15768000; required
247 2.2. Server Processing Model
249 This section describes the processing model that DANE Hosts
250 implement. The model has 2 parts: (1) the processing rules for HTTP
251 request messages received over a secure transport (e.g.
252 authenticated, non-anonymous TLS); and (2) the processing rules for
253 HTTP request messages received over non-secure transports, such as
254 TCP.
256 2.2.1. HTTP-over-Secure-Transport Request Type
258 When replying to an HTTP request that was conveyed over a secure
259 transport, a DANE Host SHOULD include in its response exactly one DVA
260 header field and MUST satisfy the grammar specified in Section 2.1.
262 Establishing a given host as a Known DANE Host, in the context of a
263 given UA, is accomplished as follows:
265 1. Over the HTTP protocol running over secure transport, by
266 correctly returning (per this specification) at least one valid
267 DVA header field to the UA.
269 2. Through other mechanisms, such as a client-side pre-loaded Known
270 DANE Host List.
272 2.2.2. HTTP Request Type
274 DANE Hosts MAY include the DVA header field in HTTP redirects
275 conveyed over non-secure transport. Hosts may choose to do this if
276 they wish to operate using the TLSA usages of DANE-EE or DANE-TA (as
277 defined in [RFC7218].
279 2.3. User Agent Processing Model
281 The UA processing model relies on parsing domain names. Note that
282 internationalized domain names SHALL be canonicalized according to
283 the scheme in Section 10 of [RFC6797].
285 2.3.1. DANE-Validation Response Header Field Processing
287 If the UA receives, over a secure transport, an HTTP response that
288 includes a DVA header field conforming to the grammar specified in
289 Section 2.1, and there are no underlying secure transport errors or
290 warnings (see Section 2.4), the UA MUST either:
292 o Note the host as a Known DANE Host if it is not already so noted
293 (see Section 2.3.2)
295 or
297 o Update the UA's cached information for the Known DANE Host if any
298 of the max-age, includeSubDomains, or required header field value
299 directives convey information different from that already
300 maintained by the UA.
302 The max-age value is essentially a "time to live" value relative to
303 the time of the most recent observation of the DVA header field. If
304 the max-age header field value token has a value of 0, the UA MUST
305 remove its cached DANE Policy information (including the
306 includeSubDomains directive, if asserted) if the DANE Host is Known,
307 or, MUST NOT note this DANE Host if it is not yet Known.
309 If a UA receives more than one DVA header field in an HTTP response
310 message over secure transport, then the UA MUST process only the
311 first DVA header field.
313 If the UA receives the HTTP response over non-secure transport it
314 MUST NOT note the host as a DVA host. To allow the validation of
315 DANE-EE and DANE-TA TLSA usages, a UA MAY accept DVA headers as a
316 'hint' to perform DANE Validation on the connection.
318 If the DVA header is not a Valid DANE Header (see Section 2.4), the
319 UA MUST ignore any present DVA header field(s). The UA MUST ignore
320 any DVA header fields not conforming to the grammar specified in
321 Section 2.1.
323 2.3.2. Noting a DANE Host - Storage Model
325 The Effective Date of a Known DANE Host is the time that the UA
326 observed a Valid DANE Header for the host. The Effective Expiration
327 Date of a Known DANE Host is the Effective Date plus the max-age. A
328 Known DANE Host is "expired" if the Effective Expiration Date refers
329 to a date in the past. The UA MUST ignore any expired Known DANE
330 Hosts in its cache.
332 For example, if a UA is beginning to perform DANE Validation for a
333 Known DANE Host and finds that the cached information for the host
334 indicates an Effective Expiration Date in the past, the UA MUST NOT
335 continue with DANE Validation for the host, and must consider the
336 host to no longer be a Known DANE Host.
338 Known DANE Hosts are identified only by domain names, and never IP
339 addresses. If the substring matching the host production from the
340 Request-URI (of the message to which the host responded)
341 syntactically matches the IP-literal or IPv4address productions from
342 Section 3.2.2 of [RFC3986], then the UA MUST NOT note this host as a
343 Known DANE Host.
345 Otherwise, if the substring does not congruently match an existing
346 Known DANE Host's domain name, per the matching procedure specified
347 in Section 8.2 of [RFC6797], then the UA MUST add this host to the
348 Known DANE Host cache. The UA caches the following information:
350 o the DANE Host's domain name
352 o the Effective Expiration Date, or enough information to calculate
353 it (the Effective Date and the value of the max-age directive)
355 o whether or not the includeSubDomains directive is asserted
357 o whether or not the required directive is asserted
359 If any other metadata from optional or future DVA header directives
360 are present in the Valid DANE Header, and the UA understands them,
361 the UA MAY note them as well.
363 UAs MAY set an upper limit on the value of max-age, so that UAs that
364 have noted erroneous DANE Validation Assertions (whether by accident
365 or due to attack) have some chance of aging out over time. If the
366 server sets a max-age greater than the UA's upper limit, the UA MAY
367 behave as if the server set the max-age to the UA's upper limit. For
368 example, if the UA caps max-age at 5184000 seconds (60 days), and a
369 DANE Host sets a max-age directive of 90 days in its Valid DANE
370 Header, the UA MAY behave as if the max-age were effectively 60 days.
371 (One way to achieve this behavior is for the UA to simply store a
372 value of 60 days instead of the 90 day value provided by the DANE
373 Host.) For UA implementation guidance on how to select a maximum
374 max-age, see Section 3.1.
376 The UA MUST NOT modify any metadata of any superdomain matched Known
377 DANE Host.
379 2.3.3. HTTP-Equiv Element Attribute
381 UAs MUST NOT heed http-equiv="DANE-Validation" attribute settings on
382 elements [W3C.REC-html401-19991224] in received content.
384 2.4. Noting DANE Hosts
386 Upon receipt of the DVA response header field, the UA notes the host
387 as a Known DANE Host, storing the Host and associated directives in
388 non-volatile storage (for example, along with the HSTS or HPKP
389 metadata). The associated directives are collectively known as DANE
390 Metadata.
392 The UA MUST note the Host as a DANE Host if and only if it received
393 the DVA response header field over an error-free TLS connection. If
394 the host is a DANE Host, this includes the validation added in
395 Section 2.5.
397 If the DVA response header field does not meet the above criteria,
398 the UA MUST NOT note the host as a DANE Host. A DVA response header
399 field that meets all these criteria is known as a Valid DANE Header.
401 Whenever a UA receives a Valid DANE Header, it MUST set its DANE
402 Metadata to the exact Effective Expiration Date (computed from max-
403 age), and note any associated directives if present.
405 For forward compatibility, the UA MUST ignore any unrecognized DVA
406 header directives, while still processing those directives it does
407 recognize. Section 2.1 specifies the directives max-age,
408 includeSubDomains, and required but future specifications and
409 implementations might use additional directives.
411 2.5. Validating DANE Connections
413 When a UA connects to a Known DANE Host using a TLS connection, the
414 UA SHOULD perform a DANE Validation on the Host, as soon as possible
415 (e.g. immediately after receiving the Server Certificate message). A
416 DANE Validation follows the procedure for comparing a certificate
417 association from a TLSA record and a certificate from the TLS
418 handshake as defined in [RFC6698].)
420 If no TLSA records were received for evaluation and the host's DANE
421 Metadata includes an asserted required directive, the UA MUST
422 terminate the connection.
424 If the connection has no errors in the DANE Validation, the UA will
425 determine whether to apply any additional correctness checks such as
426 Pin Validation [I-D.ietf-websec-key-pinning], or applying an HTTP
427 Strict Transport Security Policy [RFC6797].
429 2.6. Interactions With Preloaded DANE Host Lists
431 UAs MAY choose to implement additional sources of DANE Host
432 information, such as through built-in lists of host information.
433 Such UAs should allow users to override such additional sources,
434 including disabling them from consideration.
436 The effective policy for a Known DANE Host that has both built-in
437 hosts and hosts from previously observed DVA header response fields
438 is implementation-defined.
440 2.7. TLSA Certificate Usages in DANE
442 HDVA is able to interoperate with UAs that support DANE and those
443 that do not. For Hosts that use PKIX-TA or PKIX-EE certificate
444 validation will occur both with and without DANE. Hosts that expect
445 to use DANE-TA or DANE-EE should not expect to interoperate with UAs
446 that do not support DANE. Conversely, hosts that choose PKIX-TA or
447 PKIX-EE should not expect full interoperation with UAs that do not
448 include a full list of trust authorities.
450 UAs that choose to accept and validate DVA headers over non-secure
451 transport as a 'hint' to perform a DANE Validation MUST do so in
452 according with Section 2.3.1 and MUST allow DANE-TA and DANE-EE
453 usages for the initial connection and given a successful DANE
454 Validation note the TLS connection as error-free.
456 3. Security Considerations
458 HTTP DANE-Validation Assertions allow hosts to strongly assert their
459 intention for additional validation of their cryptographic identity.
460 This document concerns the expression, conveyance, and enforcement of
461 the DANE Validation policy.
463 See [RFC6698] for security considerations relating to a DANE
464 Validation.
466 This document adds the concept of a required directive that requires
467 the UA to receive TLSA records when communicating with a DANE Host
468 over secure transport. When the host asserts the required directive
469 there is additional risk of an active network attacker blocking DANE
470 information from reaching the UA. This scenario would effectively
471 create a denial of service for the victim of the attack. This is
472 also a concern in some networks, which are configured in such a
473 manner as to effectively block DANE information. If a host chooses
474 to assert the required directive, they should consider clients that
475 may not be able to get DANE information and consider the associated
476 risks when asserting that directive. Without the required directive,
477 an active network attacker could potentially block DANE information
478 from reaching the victim and force validation of the connection to
479 precede without any DANE information this would circumvent the
480 additional out-of-band checks and rely on the UA's normal
481 cryptographic identity validation, which could allow an attacker to
482 man-in-the-middle the connection with a certificate that would
483 otherwise fail DANE Validation.
485 To help mitigate this risk UAs SHOULD cache TLSA records as mentioned
486 in Section 8.2 of [RFC6698]. In addition, if a UA does a pre-fetch
487 for IP address, they should also prefetch TLSA records for DANE
488 Hosts. Furthermore, UAs can receive TLSA records through another
489 medium such as TLS extensions, HTTP, or other methods, which may not
490 be blocked or be faster than DNS itself.
492 To discover attacks on a host that does not assert the required
493 directive, over a network where an attacker is blocking the TLSA
494 records from reaching a UA, the host may also employ the Report-Only
495 directive from [I-D.ietf-websec-key-pinning].
497 3.1. Maximum max-age
499 As mentioned in Section 2.3.2, UAs MAY cap the max-age value at some
500 upper limit. There is a security trade-off in that low maximum
501 values provide a narrow window of protection for users who visit the
502 Known DANE Host only infrequently, while high maximum values may
503 potentially result in a UA's inability to successfully perform DANE
504 Validation on hosts that assert the required directive should they
505 choose to remove the TLSA record from the domain. Also, if a host
506 has removed the TLSA records, a long max-age would create longer
507 initial connection times while the UA attempts to retrieve a non-
508 existent TLSA record.
510 There is likely no ideal upper limit to the max-age directive that
511 would satisfy all use cases. However, a value on the order of 60
512 days (5,184,000 seconds) may be considered a balance between the two
513 competing security concerns.
515 3.2. Using includeSubDomains Safely
517 It may happen that DANE Hosts whose hostnames share a parent domain
518 use different Valid DVA Headers. If a host whose hostname is a
519 parent domain for another host sets the includeSubDomains directive,
520 the two hosts' DANE policies may conflict with each other. For
521 example, consider two Known DANE Hosts, example.com and
522 subdomain.example.com. Assume example.com sets a Valid DVA Header
523 such as this:
525 DANE-Validation: max-age=12000; required; includeSubDomains
527 Figure 3: example.com Valid DVA Header
529 Assume subdomain.example.com sets a Valid DVA Header such as this:
531 DANE-Validation: max-age=12000;
533 Figure 4: subdomain.example.com Valid DVA Header
535 Assume a UA that has not previously noted either of these hosts as
536 DANE Hosts. If the UA first contacts subdomain.example.com, it will
537 note the host as a DANE Host, and attempt DANE Validation as normal
538 on subsequent connections. If the UA does not receive a TLSA record
539 for subdomain.example.com it will fall back to the UA's normal
540 certificate path validation. If the UA then contacts example.com, it
541 will note the DANE Host and require DANE Validation on future
542 connections.
544 However, if the UA happened to visit example.com before
545 subdomain.example.com, the UA would, due to example.com's use of the
546 includeSubDomains and required directives, require a valid TLSA
547 record to perform DANE Validation for subdomain.example.com. If such
548 a record was not present or available, the UA will cancel the
549 connection. Thus, depending on the order in which the UA observes
550 the Valid DVA Headers for hosts example.com and
551 subdomain.example.com, DANE Validation might or might not fail for
552 subdomain.example.com, if it cannot receive any TLSA records. This
553 can occur even if the certificate chain the UA receives for
554 subdomain.example.com is perfectly valid.
556 Thus, DANE Host operators must use the includeSubDomains directive
557 with care. For example, they may choose to use the required
558 directive only on Hosts that do not assert the includeSubDomains
559 directive, those that do not have any child domains, or to only use
560 the required directive on HOSTs whose child domains are all assured
561 to receive TLSA records via TLS extensions or some other pre-arranged
562 means.
564 3.3. Interactions With Cookie Scoping
566 HTTP cookies [RFC6265] set by a Known DANE Host can be stolen by a
567 network attacker who can forge web and DNS responses so as to cause a
568 client to send the cookies to a phony subdomain of the host. To
569 prevent this, hosts SHOULD set the "secure" attribute and precisely
570 scope the "domain" attribute on all security-sensitive cookies, such
571 as session cookies. These settings tell the browser that the cookie
572 should only be sent back to the specific host(s) (not any arbitrary
573 subdomain of a given domain), and should only be sent over HTTPS (not
574 HTTP).
576 4. IANA Considerations
578 IANA is requested to register the response headers described in this
579 document in the "Message Headers" registry ([permanent-headers]),
580 with the following parameters:
582 o Header Field Names should be "DANE-Validation"
584 o Protocol should be "http"
586 o Status should be "standard"
588 o Reference should be this document
590 5. Usability Considerations
592 To keep backwards compatibility with non-conforming UAs a host may
593 choose to provide PKIX-TA or PKIX-EE TLSA records combined with the
594 required directive in the DVA Header in order to provide a protection
595 against imposter certificates. When the UA encounters a situation
596 like that where it would prevent the connection from continuing,
597 users will experience a denial of service. It is advisable for UAs
598 to explain the reason why, i.e. that it was impossible to verify the
599 confirmed cryptographic identity of the host.
601 It is advisable that UAs have a way for users to clear the current
602 list of DANE Hosts, and to allow users to query the current state of
603 DANE Hosts.
605 6. Acknowledgements
607 Thanks to the websec working group for the Public-Key-Pinning draft,
608 from which this document draws heavily.
610 7. Normative References
612 [I-D.ietf-websec-key-pinning]
613 Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
614 Extension for HTTP", draft-ietf-websec-key-pinning-21
615 (work in progress), October 2014.
617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
618 Requirement Levels", BCP 14, RFC 2119, March 1997.
620 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
621 Resource Identifier (URI): Generic Syntax", STD 66, RFC
622 3986, January 2005.
624 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
625 Specifications: ABNF", STD 68, RFC 5234, January 2008.
627 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
628 Housley, R., and W. Polk, "Internet X.509 Public Key
629 Infrastructure Certificate and Certificate Revocation List
630 (CRL) Profile", RFC 5280, May 2008.
632 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
633 April 2011.
635 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
636 of Named Entities (DANE) Transport Layer Security (TLS)
637 Protocol: TLSA", RFC 6698, August 2012.
639 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
640 Transport Security (HSTS)", RFC 6797, November 2012.
642 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
643 Conversations about DNS-Based Authentication of Named
644 Entities (DANE)", RFC 7218, April 2014.
646 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
647 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
648 2014.
650 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext
651 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June
652 2014.
654 [W3C.REC-html401-19991224]
655 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01
656 Specification", World Wide Web Consortium Recommendation
657 REC-html401-19991224, December 1999,
658 .
660 [permanent-headers]
661 Klyne, G., "Permanent Message Header Field Names", July
662 2014, .
665 Author's Address
667 Carl Mehner
668 USAA
669 9800 Fredericksburg
670 San Antonio, TX 78288
671 US
673 Email: carl.mehner@usaa.com