7Internet Engineering Task Force (IETF) R. Barnes
8Request for Comments: 6394 BBN Technologies
9Category: Informational October 2011
13 Use Cases and Requirements for DNS-Based Authentication
14 of Named Entities (DANE)
18 Many current applications use the certificate-based authentication
19 features in Transport Layer Security (TLS) to allow clients to verify
20 that a connected server properly represents a desired domain name.
21 Typically, this authentication has been based on PKIX certificate
22 chains rooted in well-known certificate authorities (CAs), but
23 additional information can be provided via the DNS itself. This
24 document describes a set of use cases in which the DNS and DNS
25 Security Extensions (DNSSEC) could be used to make assertions that
26 support the TLS authentication process. The main focus of this
27 document is TLS server authentication, but it also covers TLS client
28 authentication for applications where TLS clients are identified by
33 This document is not an Internet Standards Track specification; it is
34 published for informational purposes.
36 This document is a product of the Internet Engineering Task Force
37 (IETF). It represents the consensus of the IETF community. It has
38 received public review and has been approved for publication by the
39 Internet Engineering Steering Group (IESG). Not all documents
40 approved by the IESG are a candidate for any level of Internet
41 Standard; see Section 2 of RFC 5741.
43 Information about the current status of this document, any errata,
44 and how to provide feedback on it may be obtained at
45 http://www.rfc-editor.org/info/rfc6394.
58Barnes Informational [Page 1]
60RFC 6394 DANE Use Cases October 2011
65 Copyright (c) 2011 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
80 1. Introduction ....................................................2
81 2. Definitions .....................................................4
82 3. Use Cases .......................................................4
83 3.1. CA Constraints .............................................5
84 3.2. Service Certificate Constraints ............................6
85 3.3. Trust Anchor Assertion and Domain-Issued Certificates ......7
86 3.4. Delegated Services .........................................9
87 4. Other Requirements .............................................10
88 5. Acknowledgements ...............................................11
89 6. Security Considerations ........................................11
90 7. References .....................................................11
91 7.1. Normative References ......................................11
92 7.2. Informative References ....................................12
96 Transport Layer Security (TLS) is used as the basis for security
97 features in many modern Internet application service protocols to
98 provide secure client-server connections [RFC5246]. It underlies
99 secure HTTP and secure email [RFC2818] [RFC2595] [RFC3207], and
100 provides hop-by-hop security in real-time multimedia and instant-
101 messaging protocols [RFC3261] [RFC6120].
103 Application service clients typically establish TLS connections to
104 application servers identified by DNS domain names. The process of
105 obtaining this "source" domain is application specific [RFC6125].
106 The name could be entered by a user or found through an automated
107 discovery process such as an SRV or NAPTR record. After obtaining
108 the address of the server via an A or AAAA DNS record, the client
109 conducts a TLS handshake with the server, during which the server
110 presents a PKIX certificate [RFC5280]. The TLS layer performs PKIX
114Barnes Informational [Page 2]
116RFC 6394 DANE Use Cases October 2011
119 validation of the certificate, including verification that the
120 certificate chains to one of the client's trust anchors. If this
121 validation is successful, then the application layer determines
122 whether the DNS name for the application service presented in the
123 certificate matches the source domain name [RFC6125]. Typically, if
124 the name matches, then the client proceeds with the TLS connection.
126 The certificate authorities (CAs) that issue PKIX certificates are
127 asserting bindings between domain names and the public keys they
128 certify. Application service clients are verifying these bindings
129 and making authorization decisions -- whether to proceed with
130 connections -- based on them.
132 Clients thus rely on CAs to correctly assert bindings between public
133 keys and domain names, in the sense that the holder of the
134 corresponding private key should be the domain holder. Today, an
135 attacker can successfully authenticate as a given application service
136 domain if he can obtain a "mis-issued" certificate from one of the
137 widely used CAs -- a certificate containing the victim application
138 service's domain name and a public key whose corresponding private
139 key is held by the attacker. If the attacker can additionally insert
140 himself as a "man in the middle" between a client and server (e.g.,
141 through DNS cache poisoning of an A or AAAA record), then the
142 attacker can convince the client that a server of the attacker's
143 choice legitimately represents the victim's application service.
145 With the advent of DNSSEC [RFC4033], it is now possible for DNS name
146 resolution to provide its information securely, in the sense that
147 clients can verify that DNS information was provided by the domain
148 operator and not tampered with in transit. The goal of technologies
149 for DNS-based Authentication of Named Entities (DANE) is to use the
150 DNS and DNSSEC to provide additional information about the
151 cryptographic credentials associated with a domain, so that clients
152 can use this information to increase the level of assurance they
153 receive from the TLS handshake process. This document describes a
154 set of use cases that capture specific goals for using the DNS in
155 this way, and a set of requirements that the ultimate DANE mechanism
158 Finally, it should be noted that although this document will
159 frequently use HTTPS as an example application service, DANE is
160 intended to apply equally to all applications that make use of TLS to
161 connect to application services identified by domain names.
170Barnes Informational [Page 3]
172RFC 6394 DANE Use Cases October 2011
177 This document also makes use of standard PKIX, DNSSEC, and TLS
178 terminology. See RFC 5280 [RFC5280], RFC 4033 [RFC4033], and
179 RFC 5246 [RFC5246], respectively, for these terms. In addition,
180 terms related to TLS-protected application services and DNS names are
181 taken from RFC 6125 [RFC6125].
183 Note in particular that the term "server" in this document refers to
184 the server role in TLS, rather than to a host. Multiple servers of
185 this type may be co-located on a single physical host, often using
186 different ports, and each of these can use different certificates.
188 This document refers several times to the notion of a "domain
189 holder". This term is understood to mean the entity that is
190 authorized to control the contents of a particular zone. For
191 example, the registrants of 2nd- or 3rd-level domains are the holders
192 of those domains. The holder of a particular domain is not
193 necessarily the entity that operates the zone.
195 It should be noted that the presence of a valid DNSSEC signature in a
196 DNS reply does not necessarily imply that the records protected by
197 that signature were authorized by the domain holder. The distinction
198 between the holder of a domain and the operator of the corresponding
199 zone has several security implications, which are discussed in the
200 individual use cases below.
204 In this section, we describe the major use cases that the DANE
205 mechanism should support. This list is not intended to represent all
206 possible ways that the DNS can be used to support TLS authentication.
207 Rather, it represents the specific cases that comprise the initial
210 In the use cases below, we will refer to the following dramatis
213 Alice: The operator of a TLS-protected application service on the
214 host alice.example.com, and administrator of the corresponding
217 Bob: A client connecting to alice.example.com.
219 Charlie: A well-known CA that issues certificates with domain names
226Barnes Informational [Page 4]
228RFC 6394 DANE Use Cases October 2011
231 Oscar: An outsourcing provider that operates TLS-protected
232 application services on behalf of customers.
234 Trent: A CA that issues certificates with domain names as
235 identifiers, but is not generally well-known.
237 These use cases are framed in terms of adding verification steps to
238 TLS server identity checking on the part of application service
239 clients. In application services where the clients are also
240 identified by domain names (e.g., Extensible Messaging and Presence
241 Protocol (XMPP) server-to-server connections), the same
242 considerations and use cases are applicable to the application
243 server's checking of identities in TLS client certificates.
247 Alice runs a website on alice.example.com and has obtained a
248 certificate from the well-known CA Charlie. She is concerned that
249 other well-known CAs might issue certificates for alice.example.com
250 without her authorization, which clients would accept. Alice would
251 like to provide a mechanism for visitors to her site to know that
252 they should expect alice.example.com to use a certificate issued
253 under the CA that she uses (Charlie) and not another CA. That is,
254 Alice is recommending that the client verify that there is a valid
255 certificate chain from the server certificate to Charlie before
256 accepting the server certificate. (For example, in the TLS
257 handshake, the server might include Charlie's certificate in the
258 server Certificate message's certificate_list structure [RFC5246]).
260 When Bob connects to alice.example.com, he uses this mechanism to
261 verify that the certificate presented by the server was issued under
262 the proper CA, Charlie. Bob also performs the normal PKIX validation
263 procedure for this certificate, in particular verifying that the
264 certificate chains to a trust anchor (possibly Charlie's CA, if Bob
265 accepts Charlie's CA as a trust anchor).
267 Alice may wish to provide similar information to an external CA
268 operator, Charlie. Prior to issuing a certificate for
269 alice.example.com to someone claiming to be Alice, Charlie needs to
270 verify that Alice is actually requesting a certificate. Alice could
271 indicate her preferred CA using DANE to CAs as well as relying
272 parties. Charlie could then check to see whether Alice said that her
273 certificates should be issued by Charlie or another CA. Note that
274 this check does not guarantee that the precise entity requesting a
275 certification from Charlie actually represents Alice -- only that
276 Alice has authorized Charlie to issue certificates for her domain to
277 properly authorized individuals.
282Barnes Informational [Page 5]
284RFC 6394 DANE Use Cases October 2011
287 In principle, DANE information expressing CA constraints can be
288 presented with or without DNSSEC protection. Presenting DANE
289 information without DNSSEC protection does not introduce any new
290 vulnerabilities, but neither does it add much assurance. Deletion of
291 records removes the protection provided by this constraint, but the
292 client is still protected by CA practices (as now). Injected or
293 modified false records are not useful unless the attacker can also
294 obtain a certificate for the target domain. Thus, in the worst case,
295 tampering with these constraints increases the risk of false
296 authentication to the level that is now standard.
298 Using DANE information for CA constraints without DNSSEC provides a
299 very small incremental security feature. Many common attacks against
300 TLS connections already require the attacker to inject false A or
301 AAAA records in order to steer the victim client to the attacker's
302 server. An attacker that can already inject false DNS records can
303 also provide fake DANE information (without DNSSEC) by simply
304 spoofing the additional records required to carry the DANE
307 Injected or modified false DANE information of this type can be used
308 for denial of service, even if the attacker does not have a
309 certificate for the target domain. If an attacker can modify DNS
310 responses that a target host receives, however, there are already
311 much simpler ways of denying service, such as providing a false A or
312 AAAA record. In this case, DNSSEC is not helpful, since an attacker
313 could still cause a denial of service by blocking all DNS responses
314 for the target domain.
316 Continuing to require PKIX validation also limits the degree to which
317 DNS operators (as distinct from the holders of domains) can interfere
318 with TLS authentication through this mechanism. As above, even if a
319 DNS operator falsifies DANE records, it cannot masquerade as the
320 target server unless it can also obtain a certificate for the target
3233.2. Service Certificate Constraints
325 Alice runs a website on alice.example.com and has obtained a
326 certificate from the well-known CA Charlie. She is concerned about
327 additional, unauthorized certificates being issued by Charlie as well
328 as by other CAs. She would like to provide a way for visitors to her
329 site to know that they should expect alice.example.com to present a
330 specific certificate. In TLS terms, Alice is letting Bob know that
331 this specific certificate must be the first certificate in the server
332 Certificate message's certificate_list structure [RFC5246].
338Barnes Informational [Page 6]
340RFC 6394 DANE Use Cases October 2011
343 When Bob connects to alice.example.com, he uses this mechanism to
344 verify that the certificate presented by the server is the correct
345 certificate. Bob also performs the normal PKIX validation procedure
346 for this certificate, in particular verifying that the certificate
347 chains to a trust anchor.
349 The security implications for this case are the same as for the "CA
350 Constraints" case above.
3523.3. Trust Anchor Assertion and Domain-Issued Certificates
354 Alice would like to be able to generate and use certificates for her
355 website on alice.example.com without involving an external CA at all.
356 Alice can generate her own certificates today, making self-signed
357 certificates and possibly certificates subordinate to those
358 certificates. When Bob receives such a certificate in a TLS
359 handshake, however, he doesn't automatically have a way to verify
360 that the issuer of the certificate is actually Alice, because he
361 doesn't necessarily possess Alice's corresponding trust anchor. This
362 concerns him because an attacker could present a different
363 certificate and perform a man-in-the-middle attack. Bob would like
364 to protect against this.
366 Alice would thus like to publish information so that visitors to her
367 site can know that the certificates presented by her application
368 services are legitimately hers. When Bob connects to
369 alice.example.com, he uses this information to verify that the
370 certificate presented by the server has been issued by Alice. Since
371 Bob can bind certificates to Alice in this way, he can use Alice's CA
372 as a trust anchor for purposes of validating certificates for
373 alice.example.com. Alice can additionally recommend that clients
374 accept only her certificates using the CA constraints described
377 As in Section 3.1 above, Alice may wish to represent this information
378 to potential third-party CAs (Charlie) as well as to relying parties
379 (Bob). Since publishing a certificate in a DANE record of this form
380 authorizes the holder of the corresponding private key to represent
381 alice.example.com, a CA that has received a request to issue a
382 certificate from alice.example.com could use the DANE information to
383 verify the requestor's authorization to receive a certificate for
384 that domain. For example, a CA might choose to issue a certificate
385 for a given domain name and public key only when the holder of the
386 domain name has provisioned DANE information with a certificate
387 containing the public key.
394Barnes Informational [Page 7]
396RFC 6394 DANE Use Cases October 2011
399 Note that this use case is functionally equivalent to the case where
400 Alice doesn't issue her own certificates, but uses Trent's CA, which
401 is not well-known. In this case, Alice would be advising Bob that he
402 should treat Trent as a trust anchor for purposes of validating
403 Alice's certificates, rather than a CA operated by Alice herself.
404 Bob would thus need a way to securely obtain Trent's trust anchor
405 information, namely through DANE information.
407 Alice's advertising of trust anchor material in this way does not
408 guarantee that Bob will accept the advertised trust anchor. For
409 example, Bob might have out-of-band information (such as a
410 pre-existing local policy) that indicates that the CA advertised by
411 Alice (Trent's CA) is not trustworthy, which would lead him to decide
412 not to accept Trent as a trust anchor, and thus to reject Alice's
413 certificate if it is issued under Trent's CA.
415 Providing trust anchor material in this way clearly requires DNSSEC,
416 since corrupted or injected records could be used by an attacker to
417 cause clients to trust an attacker's certificate (assuming that the
418 attacker's certificate is not rejected by some other local policy).
419 Deleted records will only result in connection failure and denial of
420 service, although this could result in clients re-connecting without
421 TLS (a downgrade attack), depending on the application. Therefore,
422 in order for this use case to be safe, applications must forbid
423 clients from falling back to unsecured channels when records appear
424 to have been deleted (e.g., when a missing record has no NSEC or
427 By the same token, this use case puts the most power in the hands of
428 DNS operators. Since the operator of the appropriate DNS zone has
429 de facto control over the content and signing of the zone, he can
430 create false DANE records that bind a malicious party's certificate
431 to a domain. This risk is especially important to keep in mind in
432 cases where the operator of a DNS zone is a different entity than the
433 holder of the domain, as in DNS hosting/outsourcing arrangements,
434 since in these cases the DNS operator might be able to make changes
435 to a domain that are not authorized by the holder of the domain.
437 It should be noted that DNS operators already have the ability to
438 obtain certificates for domains under their control, under certain CA
439 policies. In the current system, CAs need to verify that an entity
440 requesting a certificate for a domain is actually the legitimate
441 holder of that domain. Typically, this is done using information
442 published about that domain, such as WHOIS email addresses or special
443 records inserted into a domain. By manipulating these values, it is
444 possible for DNS operators to obtain certificates from some well-
445 known certificate authorities today without authorization from the
450Barnes Informational [Page 8]
452RFC 6394 DANE Use Cases October 2011
4553.4. Delegated Services
457 In addition to guarding against CA mis-issue, CA constraints and
458 certificate constraints can also be used to constrain the set of
459 certificates that can be used by an outsourcing provider. Suppose
460 that Oscar operates alice.example.com on behalf of Alice. In
461 particular, Oscar then has de facto control over what certificates to
462 present in TLS handshakes for alice.example.com. In such cases,
463 there are a few ways that DNS-based information about TLS
464 certificates could be configured; for example:
466 1. Alice has the A/AAAA records in her DNS and can sign them along
467 with the DANE record, but Oscar and Alice now need to have tight
468 coordination if the addresses and/or the certificates change.
470 2. Alice refers to Oscar's DNS by delegating a sub-domain name to
471 Oscar, and has no control over the A/AAAA, DANE, or any other
472 pieces under Oscar's control.
474 3. Alice can put DANE records into her DNS server but delegate the
475 address records to Oscar's DNS server. This means that Alice can
476 control the usage of certificates, but Oscar is free to move the
477 servers around as needed. The only coordination needed is when
478 the certificates change, and then it would depend on how the DANE
479 record is set up (i.e., a CA or an end-entity certificate
482 Which of these deployment patterns is used in a given deployment will
483 determine what sort of constraints can be expressed by which actors.
484 In cases where Alice controls DANE records (1 and 3), she can use CA
485 and certificate constraints to control what certificates Oscar
486 presents for Alice's application services. For instance, Alice might
487 require Oscar to use certificates under a given set of CAs. This
488 control, however, requires that Alice update DANE records when Oscar
489 needs to change certificates. Cases where Oscar controls DANE
490 records allow Oscar to maintain more autonomy from Alice, but by the
491 same token, Alice cannot enforce any requirements on the certificates
492 that Oscar presents in TLS handshakes.
506Barnes Informational [Page 9]
508RFC 6394 DANE Use Cases October 2011
513 In addition to supporting the above use cases, the DANE mechanism
514 must satisfy several lower-level operational and protocol
515 requirements and goals.
517 Multiple Ports: DANE should be able to support multiple application
518 services with different credentials on the same named host,
519 distinguished by port number.
521 No Downgrade: An attacker who can tamper with DNS responses must not
522 be able to make a DANE-compliant client treat a site that has
523 deployed DANE and DNSSEC like a site that has deployed neither.
525 Encapsulation: If there is DANE information for the name
526 alice.example.com, it must only affect application services hosted
527 at alice.example.com.
529 Predictability: Client behavior in response to DANE information must
530 be defined in the DANE specification as precisely as possible,
531 especially for cases where DANE information might conflict with
534 Opportunistic Security: The DANE mechanism must allow a client to
535 determine whether DANE information is available for a site, so
536 that a client can provide the highest level of security possible
537 for a given application service. Clients that do not support DANE
538 should continue to work as specified, regardless of whether DANE
539 information is present or not.
541 Combination: The DANE mechanism must allow multiple DANE statements
542 of the above forms to be combined. For example, a domain holder
543 should be able to specify that clients should accept a particular
544 certificate (Section 3.2) as well as any certificate issued by its
545 own CA (Section 3.3). The precise types of combination allowed
546 will be defined by the DANE protocol.
548 Roll-over: The DANE mechanism must allow a site to transition from
549 using one DANE mechanism to another. For example, a domain holder
550 should be able to migrate from using DANE to assert a domain-
551 issued certificate (Section 3.3) to using DANE to require an
552 external CA (Section 3.1), or vice versa. The DANE mechanism must
553 also allow roll-over between records of the same type, e.g., when
556 Simple Key Management: DANE should have a mode in which the domain
557 holder only needs to maintain a single long-lived public/private
562Barnes Informational [Page 10]
564RFC 6394 DANE Use Cases October 2011
567 Minimal Dependencies: It should be possible for a site to deploy
568 DANE without also deploying anything else, except DNSSEC.
570 Minimal Options: Ideally, DANE should have only one operating mode.
571 Practically, DANE should have as few operating modes as possible.
573 Wildcards: The mechanism for distributing DANE information should
574 allow the use of DNS wildcard labels (*) for setting DANE
575 information for all names within a wildcard expansion.
577 Redirection: The mechanism for distributing DANE information should
578 work when the application service name is the result of following
579 a DNS redirection chain (e.g., via CNAME or DNAME).
583 Thanks to Eric Rescorla for the initial formulation of the use cases,
584 Zack Weinberg and Phillip Hallam-Baker for contributing other
585 requirements, and the whole DANE working group for helpful comments
5886. Security Considerations
590 The primary focus of this document is the enhancement of TLS
591 authentication procedures using the DNS. The general effect of such
592 mechanisms is to increase the role of DNS operators in authentication
593 processes, either in place of or in addition to traditional third-
594 party actors such as commercial certificate authorities. The
595 specific security implications of the respective use cases are
596 discussed in their respective sections above.
6007.1. Normative References
602 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
603 Rose, "DNS Security Introduction and Requirements",
604 RFC 4033, March 2005.
606 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
607 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
609 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
610 Housley, R., and W. Polk, "Internet X.509 Public Key
611 Infrastructure Certificate and Certificate Revocation List
612 (CRL) Profile", RFC 5280, May 2008.
618Barnes Informational [Page 11]
620RFC 6394 DANE Use Cases October 2011
623 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
624 Verification of Domain-Based Application Service Identity
625 within Internet Public Key Infrastructure Using X.509
626 (PKIX) Certificates in the Context of Transport Layer
627 Security (TLS)", RFC 6125, March 2011.
6297.2. Informative References
631 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
634 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
636 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
637 Transport Layer Security", RFC 3207, February 2002.
639 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
640 A., Peterson, J., Sparks, R., Handley, M., and E.
641 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
644 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
645 Protocol (XMPP): Core", RFC 6120, March 2011.
651 9861 Broken Land Parkway
655 Phone: +1 410 290 6169
656 EMail: rbarnes@bbn.com
674Barnes Informational [Page 12]