7Internet Engineering Task Force (IETF) V. Dukhovni
8Request for Comments: 7671 Two Sigma
9Updates: 6698 W. Hardaker
10Category: Standards Track Parsons
11ISSN: 2070-1721 October 2015
14 The DNS-Based Authentication of Named Entities (DANE) Protocol:
15 Updates and Operational Guidance
19 This document clarifies and updates the DNS-Based Authentication of
20 Named Entities (DANE) TLSA specification (RFC 6698), based on
21 subsequent implementation experience. It also contains guidance for
22 implementers, operators, and protocol developers who want to use DANE
27 This is an Internet Standards Track document.
29 This document is a product of the Internet Engineering Task Force
30 (IETF). It represents the consensus of the IETF community. It has
31 received public review and has been approved for publication by the
32 Internet Engineering Steering Group (IESG). Further information on
33 Internet Standards is available in Section 2 of RFC 5741.
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 http://www.rfc-editor.org/info/rfc7671.
41 Copyright (c) 2015 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.
58Dukhovni & Hardaker Standards Track [Page 1]
60RFC 7671 DANE Operations October 2015
65 1. Introduction ....................................................3
66 1.1. Terminology ................................................4
67 2. DANE TLSA Record Overview .......................................5
68 2.1. Example TLSA Record ........................................6
69 3. DANE TLS Requirements ...........................................6
70 4. DANE Certificate Usage Selection Guidelines .....................7
71 4.1. Opportunistic Security and PKIX Usages .....................7
72 4.2. Interaction with Certificate Transparency ..................8
73 4.3. Switching from/to PKIX-TA/EE to/from DANE-TA/EE ............9
74 5. Certificate-Usage-Specific DANE Updates and Guidelines ..........9
75 5.1. Certificate Usage DANE-EE(3) ...............................9
76 5.2. Certificate Usage DANE-TA(2) ..............................11
77 5.3. Certificate Usage PKIX-EE(1) ..............................15
78 5.4. Certificate Usage PKIX-TA(0) ..............................15
79 6. Service Provider and TLSA Publisher Synchronization ............16
80 7. TLSA Base Domain and CNAMEs ....................................18
81 8. TLSA Publisher Requirements ....................................19
82 8.1. Key Rollover with Fixed TLSA Parameters ...................20
83 8.2. Switching to DANE-TA(2) from DANE-EE(3) ...................21
84 8.3. Switching to New TLSA Parameters ..........................22
85 8.4. TLSA Publisher Requirements: Summary ......................23
86 9. Digest Algorithm Agility .......................................23
87 10. General DANE Guidelines .......................................25
88 10.1. DANE DNS Record Size Guidelines ..........................25
89 10.2. Certificate Name Check Conventions .......................26
90 10.3. Design Considerations for Protocols Using DANE ...........27
91 11. Note on DNSSEC Security .......................................28
92 12. Summary of Updates to RFC 6698 ................................29
93 13. Operational Considerations ....................................29
94 14. Security Considerations .......................................30
95 15. References ....................................................30
96 15.1. Normative References .....................................30
97 15.2. Informative References ...................................32
98 Acknowledgements ..................................................33
99 Authors' Addresses ................................................33
114Dukhovni & Hardaker Standards Track [Page 2]
116RFC 7671 DANE Operations October 2015
121 The DNS-Based Authentication of Named Entities (DANE) specification
122 [RFC6698] introduces the DNS "TLSA" resource record (RR) type ("TLSA"
123 is not an acronym). TLSA records associate a certificate or a public
124 key of an end-entity or a trusted issuing authority with the
125 corresponding Transport Layer Security (TLS) [RFC5246] or Datagram
126 Transport Layer Security (DTLS) [RFC6347] transport endpoint. DANE
127 relies on the DNS Security Extensions (DNSSEC) [RFC4033]. DANE TLSA
128 records validated by DNSSEC can be used to augment or replace the use
129 of trusted public Certification Authorities (CAs).
131 The TLS and DTLS protocols provide secured TCP and UDP communication,
132 respectively, over IP. In the context of this document, channel
133 security is assumed to be provided by TLS or DTLS. By convention,
134 "TLS" will be used throughout this document; unless otherwise
135 specified, the text applies equally well to DTLS over UDP. Used
136 without authentication, TLS provides protection only against
137 eavesdropping through its use of encryption. With authentication,
138 TLS also protects the transport against man-in-the-middle (MITM)
141 [RFC6698] defines three TLSA record fields: the first with four
142 possible values, the second with two, and the third with three.
143 These yield 24 distinct combinations of TLSA record types. This
144 document recommends a smaller set of best-practice combinations of
145 these fields to simplify protocol design, implementation, and
148 This document explains and recommends DANE-specific strategies to
149 simplify "virtual hosting", where a single Service Provider transport
150 endpoint simultaneously supports multiple hosted Customer Domains.
152 Other related documents that build on [RFC6698] are [RFC7673] and
155 Section 12 summarizes the normative updates this document makes to
170Dukhovni & Hardaker Standards Track [Page 3]
172RFC 7671 DANE Operations October 2015
177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
179 "OPTIONAL" in this document are to be interpreted as described in
182 The following terms are used throughout this document:
184 Web PKI: The Public Key Infrastructure (PKI) model employed by
185 browsers to authenticate web servers. This employs a set of
186 trusted public CAs to vouch for the authenticity of public keys
187 associated with a particular party (the subject).
189 Service Provider: A company or organization that offers to host a
190 service on behalf of the owner of a Customer Domain. The original
191 domain name associated with the service often remains under the
192 control of the customer. Connecting applications may be directed
193 to the Service Provider via a redirection RR. Example redirection
194 records include MX, SRV, and CNAME. The Service Provider
195 frequently provides services for many customers and needs to
196 ensure that the TLS credentials presented to connecting
197 applications authenticate it as a valid server for the requested
200 Customer Domain: As described above, a TLS client may be interacting
201 with a service that is hosted by a third party. This document
202 refers to the domain name used to locate the service (prior to any
203 redirection) as the "Customer Domain".
205 TLSA Publisher: The entity responsible for publishing a TLSA record
206 within a DNS zone. This zone will be assumed DNSSEC-signed and
207 validatable to a trust anchor (TA), unless otherwise specified.
208 If the Customer Domain is not outsourcing its DNS service, the
209 TLSA Publisher will be the customer itself. Otherwise, the TLSA
210 Publisher may be the operator of the outsourced DNS service.
212 Public key: The term "public key" is shorthand for the
213 subjectPublicKeyInfo component of a PKIX [RFC5280] certificate.
215 SNI: The Server Name Indication (SNI) TLS protocol extension allows
216 a TLS client to request a connection to a particular service name
217 of a TLS server ([RFC6066], Section 3). Without this TLS
218 extension, a TLS server has no choice but to offer a certificate
219 with a default list of server names, making it difficult to host
220 multiple Customer Domains at the same IP-address-based TLS service
221 endpoint (i.e., provide "secure virtual hosting").
226Dukhovni & Hardaker Standards Track [Page 4]
228RFC 7671 DANE Operations October 2015
231 TLSA parameters: In [RFC6698], the TLSA record is defined to consist
232 of four fields. The first three of these are numeric parameters
233 that specify the meaning of the data in the fourth and final
234 field. This document refers to the first three fields as "TLSA
235 parameters", or sometimes just "parameters" when obvious from
238 TLSA base domain: Per Section 3 of [RFC6698], TLSA records are
239 stored at a DNS domain name that is a combination of a port and
240 protocol prefix and a "base domain". In [RFC6698], the "base
241 domain" is the fully qualified domain name of the TLS server.
242 This document modifies the TLSA record lookup strategy to prefer
243 the fully CNAME-expanded name of the TLS server, provided that
244 expansion is "secure" (DNSSEC validated) at each stage of the
245 expansion, and TLSA records are published for this fully expanded
247 CNAME-expanded TLS server name or otherwise the initial fully
248 qualified TLS server name, whichever is used in combination with a
249 port and protocol prefix to obtain the TLSA RRset.
2512. DANE TLSA Record Overview
253 DANE TLSA [RFC6698] specifies a protocol for publishing TLS server
254 certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035].
255 DANE TLSA records consist of four fields. The record type is
256 determined by the values of the first three fields, which this
257 document refers to as the "TLSA parameters" to distinguish them from
258 the fourth and last field. The numeric values of these parameters
259 were given symbolic names in [RFC7218]. The four fields are as
262 The Certificate Usage field: Section 2.1.1 of [RFC6698] specifies
263 four values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3).
264 There is an additional private-use value: PrivCert(255), which,
265 given its private scope, shall not be considered further in this
266 document. All other values are reserved for use by future
269 The Selector field: Section 2.1.2 of [RFC6698] specifies two values:
270 Cert(0) and SPKI(1). There is an additional private-use value:
271 PrivSel(255). All other values are reserved for use by future
274 The Matching Type field: Section 2.1.3 of [RFC6698] specifies three
275 values: Full(0), SHA2-256(1), and SHA2-512(2). There is an
276 additional private-use value: PrivMatch(255). All other values
277 are reserved for use by future specifications.
282Dukhovni & Hardaker Standards Track [Page 5]
284RFC 7671 DANE Operations October 2015
287 The Certificate Association Data field: See Section 2.1.4 of
288 [RFC6698]. This field stores the full value or digest of the
289 certificate or subject public key as determined by the matching
290 type and selector, respectively.
292 In the Matching Type field, of the two digest algorithms --
293 SHA2-256(1) and SHA2-512(2) -- as of the time of this writing, only
294 SHA2-256(1) is mandatory to implement. Clients SHOULD implement
295 SHA2-512(2), but servers SHOULD NOT exclusively publish SHA2-512(2)
296 digests. The digest algorithm agility protocol defined in Section 9
297 SHOULD be used by clients to decide how to process TLSA RRsets that
298 employ multiple digest algorithms. Server operators MUST publish
299 TLSA RRsets that are compatible (see Section 8) with digest algorithm
3022.1. Example TLSA Record
304 In the example TLSA record below, the TLSA certificate usage is
305 DANE-TA(2), the selector is Cert(0), and the matching type is
306 SHA2-256(1). The last field is the Certificate Association Data
307 field, which in this case contains the SHA2-256 digest of the server
310 _25._tcp.mail.example.com. IN TLSA 2 0 1 (
311 E8B54E0B4BAA815B06D3462D65FBC7C0
312 CF556ECCF9F5303EBFBB77D022F834C0 )
3143. DANE TLS Requirements
316 [RFC6698] does not discuss what versions of TLS are required when
317 using DANE records. This document specifies that TLS clients that
318 support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support
321 TLS clients using DANE MUST support the SNI extension of TLS
322 [RFC6066]. Servers MAY support SNI and respond with a matching
323 certificate chain but MAY also ignore SNI and respond with a default
324 certificate chain. When a server supports SNI but is not configured
325 with a certificate chain that exactly matches the client's SNI
326 extension, the server SHOULD respond with another certificate chain
327 (a default or closest match). This is because clients might support
328 more than one server name but can only put a single name in the SNI
338Dukhovni & Hardaker Standards Track [Page 6]
340RFC 7671 DANE Operations October 2015
3434. DANE Certificate Usage Selection Guidelines
345 As mentioned in Section 2, the TLSA Certificate Usage field takes one
346 of four possible values. With PKIX-TA(0) and PKIX-EE(1), the
347 validation of peer certificate chains requires additional
348 preconfigured CA TAs that are mutually trusted by the operators of
349 the TLS server and client. With DANE-TA(2) and DANE-EE(3), no
350 preconfigured CA TAs are required and the published DANE TLSA records
351 are sufficient to verify the peer's certificate chain.
353 Standards for application protocols that employ DANE TLSA can specify
354 more specific guidance than [RFC6698] or this document. Such
355 application-specific standards need to carefully consider which set
356 of DANE certificate usages to support. Simultaneous support for all
357 four usages is NOT RECOMMENDED for DANE clients. When all four
358 usages are supported, an attacker capable of compromising the
359 integrity of DNSSEC needs only to replace the server's TLSA RRset
360 with one that lists suitable DANE-EE(3) or DANE-TA(2) records,
361 effectively bypassing any added verification via public CAs. In
362 other words, when all four usages are supported, PKIX-TA(0) and
363 PKIX-EE(1) offer only illusory incremental security over DANE-TA(2)
366 Designs in which clients support just the DANE-TA(2) and DANE-EE(3)
367 certificate usages are RECOMMENDED. With DANE-TA(2) and DANE-EE(3),
368 clients don't need to track a large changing list of X.509 TAs in
369 order to successfully authenticate servers whose certificates are
370 issued by a CA that is brand new or not widely trusted.
372 The DNSSEC TLSA records for servers MAY include both sets of usages
373 if the server needs to support a mixture of clients, some supporting
374 one pair of usages and some the other.
3764.1. Opportunistic Security and PKIX Usages
378 When the client's protocol design is based on "Opportunistic
379 Security" (OS) [RFC7435] and the use of authentication is based on
380 the presence of server TLSA records, it is especially important to
381 avoid the PKIX-EE(1) and PKIX-TA(0) certificate usages.
383 When authenticated TLS is used opportunistically based on the
384 presence of DANE TLSA records and no secure TLSA records are present,
385 unauthenticated TLS is used if possible, and if TLS is not possible,
386 perhaps even cleartext. However, if usable secure TLSA records are
387 published, then authentication MUST succeed. Also, outside the
388 browser space, there is no preordained canon of trusted CAs, and in
389 any case there is no security advantage in using PKIX-TA(0) or
394Dukhovni & Hardaker Standards Track [Page 7]
396RFC 7671 DANE Operations October 2015
399 PKIX-EE(1) when the DANE-TA(2) and DANE-EE(3) usages are also
400 supported (as an attacker who can compromise DNS can replace the
401 former with the latter).
403 Authentication via the PKIX-TA(0) and PKIX-EE(1) certificate usages
404 is more brittle; the client and server need to happen to agree on a
405 mutually trusted CA, but with OS the client is just trying to protect
406 the communication channel at the request of the server and would
407 otherwise be willing to use cleartext or unauthenticated TLS. The
408 use of fragile mechanisms (like public CA authentication for some
409 unspecified set of trusted CAs) is not sufficiently reliable for an
410 OS client to honor the server's request for authentication. OS needs
411 to be non-intrusive and to require few, if any, workarounds for valid
412 but mismatched peers.
414 Because the PKIX-TA(0) and PKIX-EE(1) usages offer no more security
415 and are more prone to failure, they are a poor fit for OS and
416 SHOULD NOT be used in that context.
4184.2. Interaction with Certificate Transparency
420 Certificate Transparency (CT) [RFC6962] defines an experimental
421 approach that could be used to mitigate the risk of rogue or
422 compromised public CAs issuing unauthorized certificates. This
423 section clarifies the interaction of the experimental CT and DANE.
424 This section may need to be revised in light of any future Standards
427 When a server is authenticated via a DANE TLSA RR with TLSA
428 certificate usage DANE-EE(3), the domain owner has directly specified
429 the certificate associated with the given service without reference
430 to any public CA. Therefore, when a TLS client authenticates the TLS
431 server via a TLSA record with usage DANE-EE(3), CT checks SHOULD NOT
432 be performed. Publication of the server certificate or public key
433 (digest) in a TLSA record in a DNSSEC-signed zone by the domain owner
434 assures the TLS client that the certificate is not an unauthorized
435 certificate issued by a rogue CA without the domain owner's consent.
437 When a server is authenticated via a DANE TLSA record with TLSA usage
438 DANE-TA(2) and the server certificate does not chain to a known
439 public root CA, CT cannot apply (CT logs only accept chains that
440 start with a known public root). Since TLSA certificate usage
441 DANE-TA(2) is generally intended to support non-public TAs, TLS
442 clients SHOULD NOT perform CT checks with usage DANE-TA(2).
450Dukhovni & Hardaker Standards Track [Page 8]
452RFC 7671 DANE Operations October 2015
455 With certificate usages PKIX-TA(0) and PKIX-EE(1), CT applies just as
456 it would without DANE. TLSA records of this type only constrain
457 which CAs are acceptable in PKIX validation. All checks used in the
458 absence of DANE still apply when validating certificate chains with
459 DANE PKIX-TA(0) and PKIX-EE(1) constraints.
4614.3. Switching from/to PKIX-TA/EE to/from DANE-TA/EE
463 The choice of preferred certificate usages may need to change as an
464 application protocol evolves. When transitioning between PKIX-TA/
465 PKIX-EE and DANE-TA/DANE-EE, clients begin to enable support for the
466 new certificate usage values. If the new preferred certificate
467 usages are PKIX-TA/EE, this requires installing and managing the
468 appropriate set of CA TAs. During this time, servers will publish
469 both types of TLSA records. At some later time, when the vast
470 majority of servers have published the new preferred TLSA records,
471 clients can stop supporting the legacy certificate usages.
472 Similarly, servers can stop publishing legacy TLSA records once the
473 vast majority of clients support the new certificate usages.
4755. Certificate-Usage-Specific DANE Updates and Guidelines
477 The four certificate usage values from the TLSA record -- DANE-EE(3),
478 DANE-TA(2), PKIX-EE(1), and PKIX-TA(0) -- are discussed below.
4805.1. Certificate Usage DANE-EE(3)
482 In this section, the meaning of DANE-EE(3) is updated from [RFC6698]
483 to specify that peer identity matching and validity period
484 enforcement are based solely on the TLSA RRset properties. This
485 document also extends [RFC6698] to cover the use of DANE
486 authentication of raw public keys [RFC7250] via TLSA records with
487 certificate usage DANE-EE(3) and selector SPKI(1).
490 simply checking that the server's leaf certificate matches the TLSA
491 record. In particular, the binding of the server public key to its
492 name is based entirely on the TLSA record association. The server
493 MUST be considered authenticated even if none of the names in the
494 certificate match the client's reference identity for the server.
495 This simplifies the operation of servers that host multiple Customer
496 Domains, as a single certificate can be associated with multiple
497 domains without having to match each of the corresponding reference
506Dukhovni & Hardaker Standards Track [Page 9]
508RFC 7671 DANE Operations October 2015
511 ; Multiple Customer Domains hosted by an example.net
514 www.example.com. IN CNAME ex-com.example.net.
515 www.example.org. IN CNAME ex-org.example.net.
517 ; In the provider's DNS zone, a single certificate and TLSA
518 ; record support multiple Customer Domains, greatly simplifying
521 ex-com.example.net. IN A 192.0.2.1
522 ex-org.example.net. IN A 192.0.2.1
523 _443._tcp.ex-com.example.net. IN CNAME tlsa._dane.example.net.
524 _443._tcp.ex-org.example.net. IN CNAME tlsa._dane.example.net.
525 tlsa._dane.example.net. IN TLSA 3 1 1 e3b0c44298fc1c14...
528 MUST be ignored. The validity period of the TLSA record key binding
529 is determined by the validity period of the TLSA record DNSSEC
530 signatures. Validity is reaffirmed on an ongoing basis by continuing
531 to publish the TLSA record and signing the zone in which the record
532 is contained, rather than via dates "set in stone" in the
533 certificate. The expiration becomes a reminder to the administrator
534 that it is likely time to rotate the key, but missing the date no
535 longer causes an outage. When keys are rotated (for whatever
536 reason), it is important to follow the procedures outlined in
539 If a server uses just DANE-EE(3) TLSA records and all its clients are
540 DANE clients, the server need not employ SNI (i.e., it may ignore the
541 client's SNI message) even when the server is known via multiple
542 domain names that would otherwise require separate certificates. It
543 is instead sufficient for the TLSA RRsets for all the domain names in
544 question to match the server's default certificate. For application
545 protocols where the server name is obtained indirectly via SRV
546 records, MX records, or similar records, it is simplest to publish a
547 single hostname as the target server name for all the hosted domains.
549 In organizations where it is practical to make coordinated changes in
550 DNS TLSA records before server key rotation, it is generally best to
551 publish end-entity DANE-EE(3) certificate associations in preference
552 to other choices of certificate usage. DANE-EE(3) TLSA records
553 support multiple server names without SNI, don't suddenly stop
554 working when leaf or intermediate certificates expire, and don't fail
555 when a server operator neglects to include all the required issuer
556 certificates in the server certificate chain.
562Dukhovni & Hardaker Standards Track [Page 10]
564RFC 7671 DANE Operations October 2015
567 More specifically, it is RECOMMENDED that at most sites TLSA records
568 published for DANE servers be "DANE-EE(3) SPKI(1) SHA2-256(1)"
569 records. Selector SPKI(1) is chosen because it is compatible with
570 raw public keys [RFC7250] and the resulting TLSA record need not
571 change across certificate renewals with the same key. Matching type
572 SHA2-256(1) is chosen because all DANE implementations are required
573 to support SHA2-256. This TLSA record type easily supports hosting
574 arrangements with a single certificate matching all hosted domains.
575 It is also the easiest to implement correctly in the client.
577 Clients that support raw public keys can use DANE TLSA records with
578 certificate usage DANE-EE(3) and selector SPKI(1) to authenticate
579 servers that negotiate the use of raw public keys. Provided the
580 server adheres to the requirements of Section 8, the fact that raw
581 public keys are not compatible with any other TLSA record types will
582 not get in the way of successful authentication. Clients that employ
583 DANE to authenticate the peer server SHOULD NOT negotiate the use of
584 raw public keys unless the server's TLSA RRset includes "DANE-EE(3)
585 SPKI(1)" TLSA records.
587 While it is, in principle, also possible to authenticate raw public
588 keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the
589 public key from the certificate in DNS, extracting just the public
590 key from a "3 0 0" TLSA record requires extra logic on clients that
591 not all implementations are expected to provide. Servers that wish
592 to support [RFC7250] raw public keys need to publish TLSA records
593 with a certificate usage of DANE-EE(3) and a selector of SPKI(1).
595 While DANE-EE(3) TLSA records are expected to be by far the most
596 prevalent, as explained in Section 5.2, DANE-TA(2) records are a
597 valid alternative for sites with many DANE services. Note, however,
598 that virtual hosting is more complex with DANE-TA(2). Also, with
599 DANE-TA(2), server operators MUST ensure that the server is
600 configured with a sufficiently complete certificate chain and need to
601 remember to replace certificates prior to their expiration dates.
6035.2. Certificate Usage DANE-TA(2)
605 This section updates [RFC6698] by specifying a new operational
606 requirement for servers publishing TLSA records with a usage of
607 DANE-TA(2): such servers MUST include the TA certificate in their TLS
608 server certificate message unless all such TLSA records are "2 0 0"
609 records that publish the server certificate in full.
611 Some domains may prefer to avoid the operational complexity of
612 publishing unique TLSA RRs for each TLS service. If the domain
613 employs a common issuing CA to create certificates for multiple TLS
614 services, it may be simpler to publish the issuing authority as a TA
618Dukhovni & Hardaker Standards Track [Page 11]
620RFC 7671 DANE Operations October 2015
623 for the certificate chains of all relevant services. The TLSA query
624 domain (TLSA base domain with port and protocol prefix labels) for
625 each service issued by the same TA may then be set to a CNAME alias
626 that points to a common TLSA RRset that matches the TA. For example:
628 ; Two servers, each with its own certificate, that share
629 ; a common issuer (TA).
631 www1.example.com. IN A 192.0.2.1
632 www2.example.com. IN A 192.0.2.2
633 _443._tcp.www1.example.com. IN CNAME tlsa._dane.example.com.
634 _443._tcp.www2.example.com. IN CNAME tlsa._dane.example.com.
635 tlsa._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14...
637 The above configuration simplifies server key rotation, because while
638 the servers continue to receive new certificates from a CA matched by
639 the shared (target of the CNAMEs) TLSA record, server certificates
640 can be updated without making any DNS changes. As the list of active
641 issuing CAs changes, the shared TLSA record will be updated (much
642 less frequently) by the administrators who manage the CAs. Those
643 administrators still need to perform TLSA record updates with care,
644 as described in Section 8.
646 With usage DANE-TA(2), the server certificates will need to have
647 names that match one of the client's reference identifiers (see
648 [RFC6125]). When hosting multiple unrelated Customer Domains (that
649 can't all appear in a single certificate), such a server SHOULD
650 employ SNI to select the appropriate certificate to present to the
6535.2.1. Recommended Record Combinations
655 TLSA records with a matching type of Full(0) are NOT RECOMMENDED.
656 While these potentially obviate the need to transmit the TA
657 certificate in the TLS server certificate message, client
658 implementations may not be able to augment the server certificate
659 chain with the data obtained from DNS, especially when the TLSA
660 record supplies a bare key (selector SPKI(1)). Since the server will
661 need to transmit the TA certificate in any case, server operators
662 SHOULD publish TLSA records with a matching type other than Full(0)
663 and avoid potential DNS interoperability issues with large TLSA
664 records containing full certificates or keys (see Section 10.1.1).
674Dukhovni & Hardaker Standards Track [Page 12]
676RFC 7671 DANE Operations October 2015
679 TLSA Publishers employing DANE-TA(2) records SHOULD publish records
680 with a selector of Cert(0). Such TLSA records are associated with
681 the whole TA certificate, not just with the TA public key. In
682 particular, when authenticating the peer certificate chain via such a
683 TLSA record, the client SHOULD apply any relevant constraints from
684 the TA certificate, such as, for example, path length constraints.
686 While a selector of SPKI(1) may also be employed, the resulting TLSA
687 record will not specify the full TA certificate content, and elements
688 of the TA certificate other than the public key become mutable. This
689 may, for example, enable a subsidiary CA to issue a chain that
690 violates the TA's path length or name constraints.
694 With DANE-TA(2), a complication arises when the TA certificate is
695 omitted from the server's certificate chain, perhaps on the basis of
696 Section 7.4.2 of [RFC5246]:
698 The sender's certificate MUST come first in the list. Each
699 following certificate MUST directly certify the one preceding it.
700 Because certificate validation requires that root keys be
701 distributed independently, the self-signed certificate that
702 specifies the root certificate authority MAY be omitted from the
703 chain, under the assumption that the remote end must already
704 possess it in order to validate it in any case.
706 With TLSA certificate usage DANE-TA(2), there is no expectation that
707 the client is preconfigured with the TA certificate. In fact, client
708 implementations are free to ignore all locally configured TAs when
709 processing usage DANE-TA(2) TLSA records and may rely exclusively on
710 the certificates provided in the server's certificate chain. But,
711 with a digest in the TLSA record, the TLSA record contains neither
712 the full TA certificate nor the full public key. If the TLS server's
713 certificate chain does not contain the TA certificate, DANE clients
714 will be unable to authenticate the server.
716 TLSA Publishers that publish TLSA certificate usage DANE-TA(2)
717 associations with a selector of SPKI(1) or with a digest-based
718 matching type (not Full(0)) MUST ensure that the corresponding server
719 is configured to also include the TA certificate in its TLS handshake
720 certificate chain, even if that certificate is a self-signed root CA
721 and would have been optional in the context of the existing public
730Dukhovni & Hardaker Standards Track [Page 13]
732RFC 7671 DANE Operations October 2015
735 Only when the server TLSA record includes a "DANE-TA(2) Cert(0)
736 Full(0)" TLSA record containing a full TA certificate is the TA
737 certificate optional in the server's TLS certificate message. This
738 is also the only type of DANE-TA(2) record for which the client MUST
739 be able to verify the server's certificate chain even if the TA
740 certificate appears only in DNS and is absent from the TLS handshake
741 server certificate message.
7435.2.3. Trust Anchor Public Keys
745 TLSA records with TLSA certificate usage DANE-TA(2), selector
746 SPKI(1), and a matching type of Full(0) publish the full public key
747 of a TA via DNS. In Section 6.1.1 of [RFC5280], the definition of a
748 TA consists of the following four parts:
750 1. the trusted issuer name,
752 2. the trusted public key algorithm,
754 3. the trusted public key, and
756 4. optionally, the trusted public key parameters associated with the
759 Items 2-4 are precisely the contents of the subjectPublicKeyInfo
760 published in the TLSA record. The issuer name is not included in the
761 subjectPublicKeyInfo.
763 With TLSA certificate usage DANE-TA(2), the client may not have the
764 associated TA certificate and cannot generally verify whether or not
765 a particular certificate chain is "issued by" the TA described in the
768 When the server certificate chain includes a CA certificate whose
769 public key matches the TLSA record, the client can match that CA as
770 the intended issuer. Otherwise, the client can only check that the
771 topmost certificate in the server's chain is "signed by" the TA's
772 public key in the TLSA record. Such a check may be difficult to
773 implement and cannot be expected to be supported by all clients.
775 Thus, servers cannot rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA
776 records to be sufficient to authenticate chains issued by the
777 associated public key in the absence of a corresponding certificate
778 in the server's TLS certificate message. Servers employing "2 1 0"
779 TLSA records MUST include the corresponding TA certificate in their
786Dukhovni & Hardaker Standards Track [Page 14]
788RFC 7671 DANE Operations October 2015
791 If none of the server's certificate chain elements match a public key
792 specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1)
793 Full(0)" TLSA record is available, it is RECOMMENDED that clients
794 check to see whether or not the topmost certificate in the chain is
795 signed by the provided public key and has not expired, and in that
796 case consider the server authenticated, provided the rest of the
797 chain passes validation, including leaf certificate name checks.
801 This certificate usage is similar to DANE-EE(3); but, in addition,
802 PKIX verification is required. Therefore, name checks, certificate
803 expiration, CT, etc. apply as they would without DANE.
8055.4. Certificate Usage PKIX-TA(0)
807 This section updates [RFC6698] by specifying new client
808 implementation requirements. Clients that trust intermediate
809 certificates MUST be prepared to construct longer PKIX chains than
810 would be required for PKIX alone.
812 TLSA certificate usage PKIX-TA(0) allows a domain to publish
813 constraints on the set of PKIX CAs trusted to issue certificates for
814 its TLS servers. A PKIX-TA(0) TLSA record matches PKIX-verified
815 trust chains that contain an issuer certificate (root or
816 intermediate) that matches its Certificate Association Data field
817 (typically a certificate or digest).
819 PKIX-TA(0) requires more complex coordination (than with DANE-TA(2)
820 or DANE-EE(3)) between the Customer Domain and the Service Provider
821 in hosting arrangements. Thus, this certificate usage is
822 NOT RECOMMENDED when the Service Provider is not also the TLSA
823 Publisher (at the TLSA base domain obtained via CNAMEs, SRV records,
826 TLSA Publishers who publish TLSA records for a particular public root
827 CA will expect that clients will only accept chains anchored at that
828 root. It is possible, however, that the client's trusted certificate
829 store includes some intermediate CAs, either with or without the
830 corresponding root CA. When a client constructs a trust chain
831 leading from a trusted intermediate CA to the server leaf
832 certificate, such a "truncated" chain might not contain the trusted
833 root published in the server's TLSA record.
836 reject the server chain if it fails to determine that the shorter
837 chain it constructed extends to a longer trusted chain that matches
838 the TLSA record. Thus, when matching a usage PKIX-TA(0) TLSA record,
842Dukhovni & Hardaker Standards Track [Page 15]
844RFC 7671 DANE Operations October 2015
847 so long as no matching certificate has yet been found, a client MUST
848 continue extending the chain even after any locally trusted
849 certificate is found. If no TLSA records have matched any of the
850 elements of the chain and the trusted certificate found is not
851 self-issued, the client MUST attempt to build a longer chain in case
852 a certificate closer to the root matches the server's TLSA record.
8546. Service Provider and TLSA Publisher Synchronization
856 Whenever possible, the TLSA Publisher and the Service Provider should
857 be the same entity. Otherwise, they need to coordinate changes to
858 ensure that TLSA records published by the TLSA Publisher don't fall
859 out of sync with the server certificate used by the Service Provider.
860 Such coordination is difficult, and service outages will result when
863 Publishing the TLSA record in the Service Provider's zone avoids the
864 complexity of bilateral coordination of server certificate
865 configuration and TLSA record management. Even when the TLSA RRset
866 has to be published in the Customer Domain's DNS zone (perhaps the
867 client application does not "chase" CNAMEs to the TLSA base domain),
868 it is possible to employ CNAME records to delegate the content of the
869 TLSA RRset to a domain operated by the Service Provider.
871 Only certificate usages DANE-EE(3) and DANE-TA(2) work well with TLSA
872 CNAMEs across organizational boundaries. With PKIX-TA(0) or
873 PKIX-EE(1), the Service Provider would need to obtain certificates in
874 the name of the Customer Domain from a suitable public CA (securely
875 impersonate the customer), or the customer would need to provision
876 the relevant private keys and certificates at the Service Provider's
879 Certificate Usage DANE-EE(3): In this case, the Service Provider can
880 publish a single TLSA RRset that matches the server certificate or
881 public key digest. The same RRset works for all Customer Domains
882 because name checks do not apply with DANE-EE(3) TLSA records (see
883 Section 5.1). A Customer Domain can create a CNAME record
884 pointing to the TLSA RRset published by the Service Provider.
886 Certificate Usage DANE-TA(2): When the Service Provider operates a
887 private CA, the Service Provider is free to issue a certificate
888 bearing any customer's domain name. Without DANE, such a
889 certificate would not pass trust verification, but with DANE, the
890 customer's TLSA RRset that is aliased to the provider's TLSA RRset
891 can delegate authority to the provider's CA for the corresponding
892 service. The Service Provider can generate appropriate
898Dukhovni & Hardaker Standards Track [Page 16]
900RFC 7671 DANE Operations October 2015
903 certificates for each customer and use the SNI information
904 provided by clients to select the right certificate chain to
905 present to each client.
907 Below are example DNS records (assumed "secure" and shown without the
908 associated DNSSEC information, such as record signatures) that
909 illustrate both of the above models in the case of an HTTPS service
910 whose clients all support DANE TLS. These examples work even with
911 clients that don't "chase" CNAMEs when constructing the TLSA base
912 domain (see Section 7 below).
914 ; The hosted web service is redirected via a CNAME alias.
915 ; The associated TLSA RRset is also redirected via a CNAME alias.
917 ; Certificate usage DANE-EE(3) makes it possible to deploy
918 ; a single provider certificate for all Customer Domains.
920 www1.example.com. IN CNAME w1.example.net.
921 _443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net.
922 _443._tcp.w1.example.net. IN TLSA 3 1 1 (
923 8A9A70596E869BED72C69D97A8895DFA
924 D86F300A343FECEFF19E89C27C896BC9 )
927 ; A CA at the provider can also issue certificates for each Customer
928 ; Domain and employ the DANE-TA(2) certificate usage to
929 ; designate the provider's CA as a TA.
931 www2.example.com. IN CNAME w2.example.net.
932 _443._tcp.www2.example.com. IN CNAME _443._tcp.w2.example.net.
933 _443._tcp.w2.example.net. IN TLSA 2 0 1 (
934 C164B2C3F36D068D42A6138E446152F5
935 68615F28C69BD96A73E354CAC88ED00C )
937 With protocols that support explicit transport redirection via DNS MX
938 records, SRV records, or other similar records, the TLSA base domain
939 is based on the redirected transport endpoint rather than the origin
940 domain. With SMTP, for example, when an email service is hosted by a
941 Service Provider, the Customer Domain's MX hostnames will point at
942 the Service Provider's SMTP hosts. When the Customer Domain's DNS
943 zone is signed, the MX hostnames can be securely used as the base
954Dukhovni & Hardaker Standards Track [Page 17]
956RFC 7671 DANE Operations October 2015
959 domains for TLSA records that are published and managed by the
960 Service Provider. For example (without the required DNSSEC
961 information, such as record signatures):
963 ; Hosted SMTP service.
965 example.com. IN MX 0 mx1.example.net.
966 example.com. IN MX 0 mx2.example.net.
967 _25._tcp.mx1.example.net. IN TLSA 3 1 1 (
968 8A9A70596E869BED72C69D97A8895DFA
969 D86F300A343FECEFF19E89C27C896BC9 )
970 _25._tcp.mx2.example.net. IN TLSA 3 1 1 (
971 C164B2C3F36D068D42A6138E446152F5
972 68615F28C69BD96A73E354CAC88ED00C )
974 If redirection to the Service Provider's domain (via MX records, SRV
975 records, or any similar mechanism) is not possible and aliasing of
976 the TLSA record is not an option, then more complex coordination
977 between the Customer Domain and Service Provider will be required.
978 Either the Customer Domain periodically provides private keys and a
979 corresponding certificate chain to the provider (after making
980 appropriate changes in its TLSA records), or the Service Provider
981 periodically generates the keys and certificates and needs to wait
982 for matching TLSA records to be published by its Customer Domains
983 before deploying newly generated keys and certificate chains.
984 Section 7 below describes an approach that employs CNAME "chasing" to
985 avoid the difficulties of coordinating key management across
986 organizational boundaries.
988 For further information about combining DANE and SRV, please see
9917. TLSA Base Domain and CNAMEs
993 When the application protocol does not support service location
994 indirection via MX, SRV, or similar DNS records, the service may be
995 redirected via a CNAME. A CNAME is a more blunt instrument for this
996 purpose because, unlike an MX or SRV record, it remaps the entire
997 origin domain to the target domain for all protocols.
999 The complexity of coordinating key management is largely eliminated
1000 when DANE TLSA records are found in the Service Provider's domain, as
1001 discussed in Section 6. Therefore, DANE TLS clients connecting to a
1002 server whose domain name is a CNAME alias SHOULD follow the CNAME
1003 "hop by hop" to its ultimate target host (noting at each step whether
1004 or not the CNAME is DNSSEC validated). If at each stage of CNAME
1005 expansion the DNSSEC validation status is "secure", the final target
1006 name SHOULD be the preferred base domain for TLSA lookups.
1010Dukhovni & Hardaker Standards Track [Page 18]
1012RFC 7671 DANE Operations October 2015
1016 the final target of a CNAME expansion SHOULD issue a TLSA query using
1017 the original destination name. That is, the preferred TLSA base
1018 domain SHOULD be derived from the fully expanded name and, failing
1019 that, SHOULD be the initial domain name.
1022 the resulting domain name MUST be used as the HostName in the
1023 client's SNI extension and MUST be the primary reference identifier
1024 for peer certificate matching with certificate usages other than
1027 Protocol-specific TLSA specifications may provide additional guidance
1028 or restrictions when following CNAME expansions.
1031 records, such as MX and SRV records, they are supported by some
1032 implementations. For example, if the MX or SRV host is a CNAME
1033 alias, some implementations may "chase" the CNAME. If they do, they
1034 SHOULD use the target hostname as the preferred TLSA base domain as
1035 described above (and, if the TLSA records are found there, also use
1036 the CNAME-expanded domain in SNI and certificate name checks).
10388. TLSA Publisher Requirements
1040 This section updates [RFC6698] by specifying that the TLSA Publisher
1041 MUST ensure that each combination of certificate usage, selector, and
1042 matching type in the server's TLSA RRset includes at least one record
1043 that matches the server's current certificate chain. TLSA records
1044 that match recently retired or yet-to-be-deployed certificate chains
1045 will be present during key rollover. Such past or future records
1046 MUST NOT at any time be the only records published for any given
1047 combination of usage, selector, and matching type. The TLSA record
1048 update process described below ensures that this requirement is met.
1050 While a server is to be considered authenticated when its certificate
1051 chain is matched by any of the published TLSA records, not all
1052 clients support all combinations of TLSA record parameters. Some
1053 clients may not support some digest algorithms; others may either not
1054 support or exclusively support the PKIX certificate usages. Some
1055 clients may prefer to negotiate [RFC7250] raw public keys, which are
1056 only compatible with TLSA records whose certificate usage is
1057 DANE-EE(3) with selector SPKI(1). The only other TLSA record type
1058 that is potentially compatible with raw public keys is "DANE-EE(3)
1059 Cert(0) Full(0)", but support for raw public keys with that TLSA
1060 record type is not expected to be broadly implemented.
1066Dukhovni & Hardaker Standards Track [Page 19]
1068RFC 7671 DANE Operations October 2015
1071 A consequence of the above uncertainty as to which TLSA parameters
1072 are supported by any given client is that servers need to ensure that
1073 each and every parameter combination that appears in the TLSA RRset
1074 is, on its own, sufficient to match the server's current certificate
1075 chain. In particular, when deploying new keys or new parameter
1076 combinations, some care is required to not generate parameter
1077 combinations that only match past or future certificate chains (or
1078 raw public keys). The rest of this section explains how to update
1079 the TLSA RRset in a manner that ensures that the above requirement
10828.1. Key Rollover with Fixed TLSA Parameters
1084 The simplest case is key rollover while retaining the same set of
1085 published parameter combinations. In this case, TLSA records
1086 matching the existing server certificate chain (or raw public keys)
1087 are first augmented with corresponding records matching the future
1088 keys, at least two Times to Live (TTLs) or longer before the new
1089 chain is deployed. This allows the obsolete RRset to age out of
1090 client caches before the new chain is used in TLS handshakes. Once
1091 sufficient time has elapsed and all clients performing DNS lookups
1092 are retrieving the updated TLSA records, the server administrator may
1093 deploy the new certificate chain, verify that it works, and then
1094 remove any obsolete records matching the chain that is no longer
1097 ; Initial TLSA RRset.
1099 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1101 ; Transitional TLSA RRset published at least two TTLs before
1102 ; the actual key change.
1104 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1105 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
1107 ; Final TLSA RRset after the key change.
1109 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
1122Dukhovni & Hardaker Standards Track [Page 20]
1124RFC 7671 DANE Operations October 2015
1127 The next case to consider is adding or switching to a new combination
1128 of TLSA parameters. In this case, publish the new parameter
1129 combinations for the server's existing certificate chain first, and
1130 only then deploy new keys if desired:
1132 ; Initial TLSA RRset.
1134 _443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46...
1136 ; New TLSA RRset, same key re-published as DANE-EE(3).
1138 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
11408.2. Switching to DANE-TA(2) from DANE-EE(3)
1142 This section explains how to migrate to a new certificate chain and
1143 TLSA record with usage DANE-TA(2) from a self-signed server
1144 certificate and a "DANE-EE(3) SPKI(1) SHA2-256(1)" TLSA record. This
1145 example assumes that a new private key is generated in conjunction
1146 with transitioning to a new certificate issued by the desired TA.
1149 and clients may choose to negotiate their use. The use of raw public
1150 keys rules out the possibility of certificate chain verification.
1151 Therefore, the transitional TLSA record for the planned DANE-TA(2)
1152 certificate chain is a "3 1 1" record that works even when raw public
1153 keys are used. The TLSA RRset is updated to use DANE-TA(2) only
1154 after the new chain is deployed and the "3 1 1" record matching the
1155 original key is dropped.
1157 This process follows the requirement that each combination of
1158 parameters present in the RRset is always sufficient to validate the
1159 server. It avoids publishing a transitional TLSA RRset in which
1160 "3 1 1" matches only the current key and "2 0 1" matches only the
1161 future certificate chain, because these might not work reliably
1162 during the initial deployment of the new keys.
1178Dukhovni & Hardaker Standards Track [Page 21]
1180RFC 7671 DANE Operations October 2015
1183 ; Initial TLSA RRset.
1185 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1187 ; Transitional TLSA RRset, published at least two TTLs before the
1188 ; actual key change. The new keys are issued by a DANE-TA(2) CA
1189 ; but are initially specified via a DANE-EE(3) association.
1191 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1192 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
1194 ; The final TLSA RRset after the key change. Now that the old
1195 ; self-signed EE key is out of the picture, publish the issuing
1196 ; TA of the new chain.
1198 _443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d...
12008.3. Switching to New TLSA Parameters
1202 When employing a new digest algorithm in the TLSA RRset, for
1203 compatibility with digest algorithm agility as specified in Section 9
1204 below, administrators SHOULD publish the new digest algorithm with
1205 each combination of certificate usage and selector for each
1206 associated key or chain used with any other digest algorithm. When
1207 removing an algorithm, remove it entirely. Each digest algorithm
1208 employed SHOULD match the same set of chains (or raw public keys).
1210 ; Initial TLSA RRset with "DANE-EE(3) SHA2-256(1)" associations
1213 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1214 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
1216 ; New TLSA RRset, also with SHA2-512(2) associations
1219 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1220 _443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc...
1221 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
1222 _443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714...
1234Dukhovni & Hardaker Standards Track [Page 22]
1236RFC 7671 DANE Operations October 2015
12398.4. TLSA Publisher Requirements: Summary
1241 In summary, server operators updating TLSA records should make one
1242 change at a time. The individual safe changes are as follows:
1244 o Pre-publish new certificate associations that employ the same TLSA
1245 parameters (usage, selector, and matching type) as existing TLSA
1246 records, but match certificate chains that will be deployed in the
1249 o Wait for stale TLSA RRsets to expire from DNS caches before
1250 configuring servers to use the new certificate chain.
1252 o Remove TLSA records matching any certificate chains that are no
1255 o Publish TLSA RRsets in which all parameter combinations
1256 (certificate usage, selector, and matching type) present in the
1257 RRset match the same set of current and planned certificate
1260 The above steps are intended to ensure that at all times, and for
1261 each combination of usage, selector, and matching type, at least one
1262 TLSA record corresponds to the server's current certificate chain.
1263 Each combination of certificate usage, selector, and matching type in
1264 a server's TLSA RRset SHOULD NOT at any time (including unexpired
1265 RRsets in client caches) match only some combination of future or
1266 past certificate chains. As a result, no matter what combinations of
1267 usage, selector, and matching type may be supported by a given
1268 client, they will be sufficient to authenticate the server.
12709. Digest Algorithm Agility
1272 While [RFC6698] specifies multiple digest algorithms, it does not
1273 specify a protocol by which the client and TLSA record publisher can
1274 agree on the strongest shared algorithm. Such a protocol would allow
1275 the client and server to avoid exposure to deprecated weaker
1276 algorithms that are published for compatibility with less capable
1277 clients but that SHOULD be avoided when possible. Such a protocol is
1280 This section defines a protocol for avoiding deprecated digest
1281 algorithms when these are published in a peer's TLSA RRset alongside
1282 stronger digest algorithms. Note that this protocol never avoids RRs
1283 with a DANE matching type of Full(0), as these do not employ a digest
1284 algorithm that might someday be weakened by cryptanalysis.
1290Dukhovni & Hardaker Standards Track [Page 23]
1292RFC 7671 DANE Operations October 2015
1295 Client implementations SHOULD implement a default order of digest
1296 algorithms by strength. This order SHOULD be configurable by the
1297 administrator or user of the client software. If possible, a
1298 configurable mapping from numeric DANE TLSA matching types to
1299 underlying digest algorithms provided by the cryptographic library
1300 SHOULD be implemented to allow new matching types to be used with
1301 software that predates their introduction. Configurable ordering of
1302 digest algorithms SHOULD be extensible to any new digest algorithms.
1304 To make digest algorithm agility possible, all published DANE TLSA
1305 RRsets MUST conform to the requirements of Section 8. Clients SHOULD
1306 use digest algorithm agility when processing the peer's DANE TLSA
1307 records. Algorithm agility is to be applied after first discarding
1308 any unusable or malformed records (unsupported digest algorithm, or
1309 incorrect digest length). For each usage and selector, the client
1310 SHOULD process only any usable records with a matching type of
1311 Full(0) and the usable records whose digest algorithm is considered
1312 by the client to be the strongest among usable records with the given
1315 Example: a client implements digest algorithm agility and prefers
1316 SHA2-512(2) over SHA2-256(1), while the server publishes an RRset
1317 that employs both digest algorithms as well as a Full(0) record.
1319 _25._tcp.mail.example.com. IN TLSA 3 1 1 (
1320 3FE246A848798236DD2AB78D39F0651D
1321 6B6E7CA8E2984012EB0A2E1AC8A87B72 )
1322 _25._tcp.mail.example.com. IN TLSA 3 1 2 (
1323 D4F5AF015B46C5057B841C7E7BAB759C
1324 BF029526D29520C5BE6A32C67475439E
1325 54AB3A945D80C743347C9BD4DADC9D8D
1326 57FAB78EAA835362F3CA07CCC19A3214 )
1327 _25._tcp.mail.example.com. IN TLSA 3 1 0 (
1328 3059301306072A8648CE3D020106082A
1329 8648CE3D0301070342000471CB1F504F
1330 9E4B33971376C005445DACD33CD79A28
1331 81C3DED1981F18E7AAA76609DD0E4EF2
1332 8265C82703030AD60C5DBA6FB8A9397A
1333 C0FCF06D424C885D484887 )
1335 In this case, the client SHOULD accept a server public key that
1336 matches either the "3 1 0" record or the "3 1 2" record, but it
1337 SHOULD NOT accept keys that match only the weaker "3 1 1" record.
1346Dukhovni & Hardaker Standards Track [Page 24]
1348RFC 7671 DANE Operations October 2015
135110. General DANE Guidelines
1353 These guidelines provide guidance for using or designing protocols
135610.1. DANE DNS Record Size Guidelines
1358 Selecting a combination of TLSA parameters to use requires careful
1359 thought. One important consideration to take into account is the
1360 size of the resulting TLSA record after its parameters are selected.
136210.1.1. UDP and TCP Considerations
1364 Deployments SHOULD avoid TLSA record sizes that cause UDP
1367 Although DNS over TCP would provide the ability to more easily
1368 transfer larger DNS records between clients and servers, it is not
1369 universally deployed and is still prohibited by some firewalls.
1370 Clients that request DNS records via UDP typically only use TCP upon
1371 receipt of a truncated response in the DNS response message sent over
1372 UDP. Setting the Truncation (TC) bit (Section 4.1.1 of [RFC1035])
1373 alone will be insufficient if the response containing the TC bit is
137610.1.2. Packet Size Considerations for TLSA Parameters
1378 Server operators SHOULD NOT publish TLSA records using both a TLSA
1379 selector of Cert(0) and a TLSA matching type of Full(0), as even a
1380 single certificate is generally too large to be reliably delivered
1381 via DNS over UDP. Furthermore, two TLSA records containing full
1382 certificates will need to be published simultaneously during a
1383 certificate rollover, as discussed in Section 8.1.
1385 While TLSA records using a TLSA selector of SPKI(1) and a TLSA
1386 matching type of Full(0) (which publish the bare public keys, i.e.,
1387 without the overhead of encapsulating the keys in an X.509
1388 certificate) are generally more compact, these are also best avoided
1389 when significantly larger than their digests. Rather, servers SHOULD
1390 publish digest-based TLSA matching types in their TLSA records, in
1391 which case the complete corresponding certificate MUST be transmitted
1392 to the client in-band during the TLS handshake. The certificate (or
1393 raw public key) can be easily verified using the digest value.
1395 In summary, the use of a TLSA matching type of Full(0) is
1396 NOT RECOMMENDED, and a digest-based matching type, such as
1397 SHA2-256(1), SHOULD be used instead.
1402Dukhovni & Hardaker Standards Track [Page 25]
1404RFC 7671 DANE Operations October 2015
140710.2. Certificate Name Check Conventions
1409 Certificates presented by a TLS server will generally contain a
1410 subjectAltName (SAN) extension or a Common Name (CN) element within
1411 the subject Distinguished Name (DN). The TLS server's DNS domain
1412 name is normally published within these elements, ideally within the
1413 SAN extension. (The use of the CN field for this purpose is
1416 When a server hosts multiple domains at the same transport endpoint,
1417 the server's ability to respond with the right certificate chain is
1418 predicated on correct SNI information from the client. DANE clients
1419 MUST send the SNI extension with a HostName value of the base domain
1422 With the exception of TLSA certificate usage DANE-EE(3), where name
1423 checks are not applicable (see Section 5.1), DANE clients MUST verify
1424 that the client has reached the correct server by checking that the
1425 server name is listed in the server certificate's SAN or CN (when
1426 still supported). The primary server name used for this comparison
1427 MUST be the TLSA base domain; however, additional acceptable names
1428 may be specified by protocol-specific DANE standards. For example,
1429 with SMTP, both the destination domain name and the MX hostname are
1430 acceptable names to be found in the server certificate (see
1433 It is the responsibility of the service operator, in coordination
1434 with the TLSA Publisher, to ensure that at least one of the TLSA
1435 records published for the service will match the server's certificate
1436 chain (either the default chain or the certificate that was selected
1437 based on the SNI information provided by the client).
1439 Given the DNSSEC-validated DNS records below:
1441 example.com. IN MX 0 mail.example.com.
1442 mail.example.com. IN A 192.0.2.1
1443 _25._tcp.mail.example.com. IN TLSA 2 0 1 (
1444 E8B54E0B4BAA815B06D3462D65FBC7C0
1445 CF556ECCF9F5303EBFBB77D022F834C0 )
1447 The TLSA base domain is "mail.example.com" and is required to be the
1448 HostName in the client's SNI extension. The server certificate chain
1449 is required to be signed by a TA with the above certificate SHA2-256
1450 digest. Finally, one of the DNS names in the server certificate is
1451 required to be either "mail.example.com" or "example.com" (this
1452 additional name is a concession to compatibility with prior practice;
1453 see [RFC7672] for details).
1458Dukhovni & Hardaker Standards Track [Page 26]
1460RFC 7671 DANE Operations October 2015
1463 [RFC6125] specifies the semantics of wildcards in server certificates
1464 for various application protocols. DANE does not change how
1465 wildcards are treated by any given application.
146710.3. Design Considerations for Protocols Using DANE
1469 When a TLS client goes to the trouble of authenticating a certificate
1470 chain presented by a TLS server, it will typically not continue to
1471 use that server in the event of authentication failure, or else
1472 authentication serves no purpose. Some clients may, at times,
1473 operate in an "audit" mode, where authentication failure is reported
1474 to the user or in logs as a potential problem, but the connection
1475 proceeds despite the failure. Nevertheless, servers publishing TLSA
1476 records MUST be configured to allow correctly configured clients to
1477 successfully authenticate their TLS certificate chains.
1479 A service with DNSSEC-validated TLSA records implicitly promises TLS
1480 support. When all the TLSA records for a service are found
1481 "unusable" due to unsupported parameter combinations or malformed
1482 certificate association data, DANE clients cannot authenticate the
1483 service certificate chain. When authenticated TLS is mandatory, the
1484 client MUST NOT connect to the associated server.
1486 If, on the other hand, the use of TLS and DANE is "opportunistic"
1487 [RFC7435], then when all TLSA records are unusable, the client SHOULD
1488 connect to the server via an unauthenticated TLS connection, and if
1489 TLS encryption cannot be established, the client MUST NOT connect to
1492 Standards for opportunistic DANE TLS specific to a particular
1493 application protocol may modify the above requirements. The key
1494 consideration is whether or not mandating the use of
1495 (unauthenticated) TLS even with unusable TLSA records is asking for
1496 more security than one can realistically expect. If expecting TLS
1497 support when unusable TLSA records are published is realistic for the
1498 application in question, then the application MUST avoid cleartext.
1499 If not realistic, then mandating TLS would cause clients (even in the
1500 absence of active attacks) to run into problems with various peers
1501 that do not interoperate "securely enough". That would create strong
1502 incentives to just disable Opportunistic Security and stick with
1514Dukhovni & Hardaker Standards Track [Page 27]
1516RFC 7671 DANE Operations October 2015
151911. Note on DNSSEC Security
1521 Clearly, the security of the DANE TLSA PKI rests on the security of
1522 the underlying DNSSEC infrastructure. While this document is not a
1523 guide to DNSSEC security, a few comments may be helpful to TLSA
1526 With the existing public CA Web PKI, name constraints are rarely
1527 used, and a public root CA can issue certificates for any domain of
1528 its choice. With DNSSEC, under the Registry/Registrar/Registrant
1529 model, the situation is different: only the registrar of record can
1530 update a domain's DS record [RFC4034] in the registry parent zone (in
1531 some cases, however, the registry is the sole registrar). With many
1532 Generic Top-Level Domains (gTLDs) for which multiple registrars
1533 compete to provide domains in a single registry, it is important to
1534 make sure that rogue registrars cannot easily initiate an
1535 unauthorized domain transfer and thus take over DNSSEC for the
1536 domain. DNS operators are advised to set a registrar lock on their
1537 domains to offer some protection against this possibility.
1539 When the registrar is also the DNS operator for the domain, one needs
1540 to consider whether or not the registrar will allow orderly migration
1541 of the domain to another registrar or DNS operator in a way that will
1542 maintain DNSSEC integrity. TLSA Publishers are advised to seek out a
1543 DNS hosting registrar that makes it possible to transfer domains to
1544 another hosting provider without disabling DNSSEC.
1546 DNSSEC-signed RRsets cannot be securely revoked before they expire.
1547 Operators need to plan accordingly and not generate signatures of
1548 excessively long duration. For domains publishing high-value keys, a
1549 signature lifetime (length of the "signature validity period" as
1550 described in Section 8.1 of [RFC4033]) of a few days is reasonable,
1551 and the zone can be re-signed daily. For domains with less critical
1552 data, a reasonable signature lifetime is a couple of weeks to a
1553 month, and the zone can be re-signed weekly.
1555 Short signature lifetimes require tighter synchronization of primary
1556 and secondary nameservers, to make sure that secondary servers never
1557 serve records with expired signatures. They also limit the maximum
1558 time for which a primary server that signs the zone can be down.
1559 Therefore, short signature lifetimes are more appropriate for sites
1560 with dedicated operations staff, who can restore service quickly in
1563 Monitoring is important. If a DNS zone is not re-signed in a timely
1564 manner, a major outage is likely, as the entire domain and all its
1565 sub-domains become "bogus".
1570Dukhovni & Hardaker Standards Track [Page 28]
1572RFC 7671 DANE Operations October 2015
157512. Summary of Updates to RFC 6698
1577 o Section 3 updates [RFC6698] to specify a requirement for clients
1578 to support at least TLS 1.0 and to support SNI.
1580 o Section 4 explains that application support for all four
1581 certificate usages is NOT RECOMMENDED. The recommended design is
1582 to support just DANE-EE(3) and DANE-TA(2).
1584 o Section 5.1 updates [RFC6698] to specify that peer identity
1585 matching and validity period enforcement are based solely on the
1586 TLSA RRset properties. It also specifies DANE authentication of
1587 raw public keys [RFC7250] via TLSA records with certificate usage
1588 DANE-EE(3) and selector SPKI(1).
1590 o Section 5.2 updates [RFC6698] to require that servers publishing
1591 digest TLSA records with a usage of DANE-TA(2) MUST include the
1592 TA certificate in their TLS server certificate message. This
1593 extends to the case of "2 1 0" TLSA records that publish a full
1596 o Section 5.4 observes that with usage PKIX-TA(0), clients may need
1597 to process extended trust chains beyond the first trusted issuer
1598 when that issuer is not self-signed.
1600 o Section 7 recommends that DANE application protocols specify that,
1601 when possible, securely CNAME-expanded names be used to derive the
1604 o Section 8 specifies a strategy for managing TLSA records that
1605 interoperates with DANE clients regardless of what subset of the
1606 possible TLSA record types (combinations of TLSA parameters) is
1607 supported by the client.
1609 o Section 9 specifies a digest algorithm agility protocol.
1611 o Section 10.1 recommends against the use of Full(0) TLSA records,
1612 as digest records are generally much more compact.
161413. Operational Considerations
1616 The DNS TTL of TLSA records needs to be chosen with care. When an
1617 unplanned change in the server's certificate chain and TLSA RRset is
1618 required, such as when keys are compromised or lost, clients that
1619 cache stale TLSA records will fail to validate the certificate chain
1620 of the updated server. Publish TLSA RRsets with TTLs that are short
1621 enough to limit unplanned service disruption to an acceptable
1626Dukhovni & Hardaker Standards Track [Page 29]
1628RFC 7671 DANE Operations October 2015
1631 The signature lifetime (length of the signature validity period) for
1632 TLSA records SHOULD NOT be too long. Signed DNSSEC records can be
1633 replayed by an MITM attacker, provided the signatures have not yet
1634 expired. Shorter signature validity periods allow for faster
1635 invalidation of compromised keys. Zone refresh and expiration times
1636 for secondary nameservers often imply a lower bound on the signature
1637 validity period (Section 11). See Section 4.4.1 of [RFC6781].
163914. Security Considerations
1641 Application protocols that cannot use the existing public CA Web PKI
1642 may choose to not implement certain TLSA record types defined in
1643 [RFC6698]. If such records are published despite not being supported
1644 by the application protocol, they are treated as "unusable". When
1645 TLS is opportunistic, the client MAY proceed to use the server with
1646 mandatory unauthenticated TLS. This is stronger than opportunistic
1647 TLS without DANE, since in that case the client may also proceed with
1648 a cleartext connection. When TLS is not opportunistic, the client
1649 MUST NOT connect to the server.
1651 Thus, when TLSA records are used with opportunistic protocols where
1652 PKIX-TA(0) and PKIX-EE(1) do not apply, the recommended protocol
1653 design is for servers to not publish such TLSA records, and for
1654 opportunistic TLS clients to use them to only enforce the use of
1655 (albeit unauthenticated) TLS but otherwise treat them as unusable.
1656 Of course, when PKIX-TA(0) and PKIX-EE(1) are supported by the
1657 application protocol, clients MUST implement these certificate usages
1658 as described in [RFC6698] and this document.
166215.1. Normative References
1664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1665 Requirement Levels", BCP 14, RFC 2119,
1666 DOI 10.17487/RFC2119, March 1997,
1667 <http://www.rfc-editor.org/info/rfc2119>.
1669 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1670 Rose, "DNS Security Introduction and Requirements",
1671 RFC 4033, DOI 10.17487/RFC4033, March 2005,
1672 <http://www.rfc-editor.org/info/rfc4033>.
1674 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1675 Rose, "Resource Records for the DNS Security Extensions",
1676 RFC 4034, DOI 10.17487/RFC4034, March 2005,
1677 <http://www.rfc-editor.org/info/rfc4034>.
1682Dukhovni & Hardaker Standards Track [Page 30]
1684RFC 7671 DANE Operations October 2015
1687 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1688 Rose, "Protocol Modifications for the DNS Security
1689 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
1690 <http://www.rfc-editor.org/info/rfc4035>.
1692 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1693 (TLS) Protocol Version 1.2", RFC 5246,
1694 DOI 10.17487/RFC5246, August 2008,
1695 <http://www.rfc-editor.org/info/rfc5246>.
1697 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1698 Housley, R., and W. Polk, "Internet X.509 Public Key
1699 Infrastructure Certificate and Certificate Revocation List
1700 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1701 <http://www.rfc-editor.org/info/rfc5280>.
1703 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
1704 Extensions: Extension Definitions", RFC 6066,
1705 DOI 10.17487/RFC6066, January 2011,
1706 <http://www.rfc-editor.org/info/rfc6066>.
1708 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
1709 Verification of Domain-Based Application Service Identity
1710 within Internet Public Key Infrastructure Using X.509
1711 (PKIX) Certificates in the Context of Transport Layer
1712 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125,
1713 March 2011, <http://www.rfc-editor.org/info/rfc6125>.
1715 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
1716 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
1717 January 2012, <http://www.rfc-editor.org/info/rfc6347>.
1719 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
1720 of Named Entities (DANE) Transport Layer Security (TLS)
1721 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698,
1722 August 2012, <http://www.rfc-editor.org/info/rfc6698>.
1724 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
1725 Conversations about DNS-Based Authentication of Named
1726 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218,
1727 April 2014, <http://www.rfc-editor.org/info/rfc7218>.
1729 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
1730 Weiler, S., and T. Kivinen, "Using Raw Public Keys in
1731 Transport Layer Security (TLS) and Datagram Transport
1732 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
1733 June 2014, <http://www.rfc-editor.org/info/rfc7250>.
1738Dukhovni & Hardaker Standards Track [Page 31]
1740RFC 7671 DANE Operations October 2015
174315.2. Informative References
1745 [RFC1035] Mockapetris, P., "Domain names - implementation and
1746 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
1747 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
1749 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
1750 Operational Practices, Version 2", RFC 6781,
1751 DOI 10.17487/RFC6781, December 2012,
1752 <http://www.rfc-editor.org/info/rfc6781>.
1754 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
1755 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
1756 <http://www.rfc-editor.org/info/rfc6962>.
1758 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
1759 Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
1760 December 2014, <http://www.rfc-editor.org/info/rfc7435>.
1762 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
1763 Opportunistic DNS-Based Authentication of Named Entities
1764 (DANE) Transport Layer Security (TLS)", RFC 7672,
1765 DOI 10.17487/RFC7672, October 2015,
1766 <http://www.rfc-editor.org/info/rfc7672>.
1768 [RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using
1769 DNS-Based Authentication of Named Entities (DANE) TLSA
1770 Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673,
1771 October 2015, <http://www.rfc-editor.org/info/rfc7673>.
1794Dukhovni & Hardaker Standards Track [Page 32]
1796RFC 7671 DANE Operations October 2015
1801 The authors would like to thank Phil Pennock for his comments and
1802 advice on this document.
1804 Acknowledgements from Viktor: Thanks to Tony Finch, who finally
1805 prodded me into participating in DANE working group discussions.
1806 Thanks to Paul Hoffman, who motivated me to produce this document and
1807 provided feedback on early draft versions of it. Thanks also to
1808 Samuel Dukhovni for editorial assistance.
1815 Email: ietf-dane@dukhovni.org
1824 Email: ietf@hardakers.net
1850Dukhovni & Hardaker Standards Track [Page 33]