6 Internet-Draft Unaffiliated
7 Intended status: Standards Track W. Hardaker
8 Expires: February 18, 2015 Parsons
12 Updates to and Operational Guidance for the DANE Protocol
13 draft-ietf-dane-ops-06
17 This memo clarifies and updates the DANE TLSA protocol based on
18 implementation experience since the publication of the original DANE
19 specification in [RFC6698]. It also contains guidance for DANE
20 implementers and operators.
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at http://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on February 18, 2015.
41 Copyright (c) 2014 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
56 Dukhovni & Hardaker Expires February 18, 2015 [Page 1]
58 Internet-Draft DANE operations August 2014
63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
65 2. DANE TLSA Record Overview . . . . . . . . . . . . . . . . . . 4
66 2.1. Example TLSA record . . . . . . . . . . . . . . . . . . . 6
67 3. DANE TLS Requirements . . . . . . . . . . . . . . . . . . . . 6
68 4. Certificate-Usage-Specific DANE Updates and Guidelines . . . 7
69 4.1. Certificate Usage DANE-EE(3) . . . . . . . . . . . . . . 7
70 4.2. Certificate Usage DANE-TA(2) . . . . . . . . . . . . . . 8
71 4.3. Certificate Usage PKIX-EE(1) . . . . . . . . . . . . . . 11
72 4.4. Certificate Usage PKIX-TA(0) . . . . . . . . . . . . . . 12
73 4.5. Opportunistic Security and PKIX usages . . . . . . . . . 12
74 5. Service Provider and TLSA Publisher Synchronization . . . . . 13
75 6. TLSA Base Domain and CNAMEs . . . . . . . . . . . . . . . . . 15
76 7. TLSA Publisher Requirements . . . . . . . . . . . . . . . . . 16
77 7.1. Key rollover with fixed TLSA Parameters . . . . . . . . . 17
78 7.2. Switching to DANE-TA from DANE-EE . . . . . . . . . . . . 18
79 7.3. Switching to New TLSA Parameters . . . . . . . . . . . . 18
80 7.4. TLSA Publisher Requirements Summary . . . . . . . . . . . 19
81 8. Digest Algorithm Agility . . . . . . . . . . . . . . . . . . 19
82 9. General DANE Guidelines . . . . . . . . . . . . . . . . . . . 20
83 9.1. DANE DNS Record Size Guidelines . . . . . . . . . . . . . 21
84 9.2. Certificate Name Check Conventions . . . . . . . . . . . 21
85 9.3. Design Considerations for Protocols Using DANE . . . . . 23
86 10. Interaction with Certificate Transparency . . . . . . . . . . 23
87 11. Note on DNSSEC Security . . . . . . . . . . . . . . . . . . . 24
88 12. Summary of Updates to RFC6698 . . . . . . . . . . . . . . . . 25
89 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26
90 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
91 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
92 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
93 16.1. Normative References . . . . . . . . . . . . . . . . . . 27
94 16.2. Informative References . . . . . . . . . . . . . . . . . 28
95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
99 [RFC6698] specifies a new DNS resource record "TLSA" that associates
100 a public certificate or public key of a trusted leaf or issuing
101 authority with the corresponding TLS transport endpoint. These DANE
102 TLSA records, when validated by DNSSEC, can be used to augment or
103 replace the trust model of the existing public Certification
104 Authority (CA) Public Key Infrastructure (PKI).
106 [RFC6698] defines three TLSA record fields with respectively 4, 2 and
107 3 currently specified values. These yield 24 distinct combinations
108 of TLSA record types. This many options have lead to implementation
112 Dukhovni & Hardaker Expires February 18, 2015 [Page 2]
114 Internet-Draft DANE operations August 2014
117 and operational complexity. This memo will recommend best-practice
118 choices to help simplify implementation and deployment given these
121 Implementation complexity also arises from the fact that the TLS
122 transport endpoint is often specified indirectly via Service Records
123 (SRV), Mail Exchange (MX) records, CNAME records or other mechanisms
124 that map an abstract service domain to a concrete server domain.
125 With service indirection there are multiple potential places for
126 clients to find the relevant TLSA records. Service indirection is
127 often used to implement "virtual hosting", where a single Service
128 Provider transport endpoint simultaneously supports multiple hosted
129 domain names. With services that employ TLS, such hosting
130 arrangements may require the Service Provider to deploy multiple
131 pairs of private keys and certificates with TLS clients signaling the
132 desired domain via the Server Name Indication (SNI) extension
133 ([RFC6066], section 3). This memo provides operational guidelines
134 intended to maximize interoperability between DANE TLS clients and
137 In the context of this memo, channel security is assumed to be
138 provided by TLS or DTLS. The Transport Layer Security (TLS)
139 [RFC5246] and Datagram Transport Layer Security (DTLS) [RFC6347]
140 protocols provide secured TCP and UDP communication over IP. By
141 convention, "TLS" will be used throughout this document and, unless
142 otherwise specified, the text applies equally well to the DTLS
143 protocol. Used without authentication, TLS provides protection only
144 against eavesdropping through its use of encryption. With
145 authentication, TLS also provides integrity protection and
146 authentication, which protect the transport against man-in-the-middle
149 Other related documents that build on [RFC6698] are
150 [I-D.ietf-dane-srv] and [I-D.ietf-dane-smtp-with-dane]. In
151 Section 12 we summarize the updates this document makes to [RFC6698].
155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
157 "OPTIONAL" in this document are to be interpreted as described in
160 The following terms are used throughout this document:
162 Service Provider: A company or organization that offers to host a
163 service on behalf of a Customer Domain. The original domain name
164 associated with the service often remains under the control of the
168 Dukhovni & Hardaker Expires February 18, 2015 [Page 3]
170 Internet-Draft DANE operations August 2014
173 customer. Connecting applications may be directed to the Service
174 Provider via a redirection resource record. Example redirection
175 records include MX, SRV, and CNAME. The Service Provider
176 frequently provides services for many customers and must carefully
177 manage any TLS credentials offered to connecting applications to
178 ensure name matching is handled easily by the applications.
180 Customer Domain: As described above, a client may be interacting
181 with a service that is hosted by a third party. We will refer to
182 the domain name used to locate the service prior to any
183 redirection, as the "Customer Domain".
185 TLSA Publisher: The entity responsible for publishing a TLSA record
186 within a DNS zone. This zone will be assumed DNSSEC-signed and
187 validatable to a trust anchor, unless otherwise specified. If the
188 Customer Domain is not outsourcing their DNS service, the TLSA
189 Publisher will be the customer themselves. Otherwise, the TLSA
190 Publisher is sometimes the operator of the outsourced DNS service.
192 public key: The term "public key" is short-hand for the
193 subjectPublicKeyInfo component of a PKIX [RFC5280] certificate.
195 SNI: The "Server Name Indication" (SNI) TLS protocol extension
196 allows a TLS client to request a connection to a particular
197 service name of a TLS server ([RFC6066], section 3). Without this
198 TLS extension, a TLS server has no choice but to offer a PKIX
199 certificate with a default list of server names, making it
200 difficult to host multiple Customer Domains at the same IP-
201 addressed based TLS service endpoint (i.e., "secure virtual
204 TLSA parameters: In [RFC6698] the TLSA record is defined to consist
205 of four fields. The first three of these are numeric parameters
206 that specify the meaning of the data in fourth and final field.
207 To avoid language contortions when we need to distinguish between
208 the first three fields that together define a TLSA record "type"
209 and the fourth that provides a data value of that type, we will
210 call the first three fields "TLSA parameters", or sometimes just
211 "parameters" when obvious from context.
213 2. DANE TLSA Record Overview
224 Dukhovni & Hardaker Expires February 18, 2015 [Page 4]
226 Internet-Draft DANE operations August 2014
229 DANE TLSA [RFC6698] specifies a protocol for publishing TLS server
230 certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035].
231 The DANE TLSA specification defines multiple TLSA RR types via
232 combinations of numeric values of the first three fields of the TLSA
233 record (i.e. the "TLSA parameters"). The numeric values of these
234 parameters were later given symbolic names in [RFC7218]. These
237 The Certificate Usage field: Section 2.1.1 of [RFC6698] specifies 4
238 values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3). There
239 is an additional private-use value: PrivCert(255). All other
240 values are reserved for use by future specifications.
242 The selector field: Section 2.1.2 of [RFC6698] specifies 2 values:
243 Cert(0), SPKI(1). There is an additional private-use value:
244 PrivSel(255). All other values are reserved for use by future
247 The matching type field: Section 2.1.3 of [RFC6698] specifies 3
248 values: Full(0), SHA2-256(1), SHA2-512(2). There is an additional
249 private-use value: PrivMatch(255). All other values are reserved
250 for use by future specifications.
252 We may think of TLSA Certificate Usage values 0 through 3 as a
253 combination of two one-bit flags. The low-bit chooses between trust
254 anchor (TA) and end entity (EE) certificates. The high bit chooses
255 between PKIX, or public PKI issued, and DANE, or domain-issued trust
258 o When the low bit is set (PKIX-EE(1) and DANE-EE(3)) the TLSA
259 record matches an EE certificate (also commonly referred to as a
260 leaf or server certificate.)
262 o When the low bit is not set (PKIX-TA(0) and DANE-TA(2)) the TLSA
263 record matches a trust anchor (a Certification Authority) that
264 issued one of the certificates in the server certificate chain.
266 o When the high bit is set (DANE-TA(2) and DANE-EE(3)), the server
267 certificate chain is domain-issued and may be verified without
268 reference to any pre-existing public certification authority PKI.
269 Trust is entirely placed on the content of the TLSA records
280 Dukhovni & Hardaker Expires February 18, 2015 [Page 5]
282 Internet-Draft DANE operations August 2014
285 o When the high bit is not set (PKIX-TA(0) and PKIX-EE(1)), the TLSA
286 record publishes a server policy stating that its certificate
287 chain must pass PKIX validation [RFC5280] and the DANE TLSA record
288 is used to signal an additional requirement that the PKIX
289 validated server certificate chain also contains the referenced CA
292 The selector field specifies whether the TLSA RR matches the whole
293 certificate (Cert(0)) or just its subjectPublicKeyInfo (SPKI(1)).
294 The subjectPublicKeyInfo is an ASN.1 DER encoding of the
295 certificate's algorithm id, any parameters and the public key data.
297 The matching type field specifies how the TLSA RR Certificate
298 Association Data field is to be compared with the certificate or
299 public key. A value of Full(0) means an exact match: the full DER
300 encoding of the certificate or public key is given in the TLSA RR. A
301 value of SHA2-256(1) means that the association data matches the
302 SHA2-256 digest of the certificate or public key, and likewise
303 SHA2-512(2) means a SHA2-512 digest is used. Of the two digest
304 algorithms, for now only SHA2-256(1) is mandatory to implement.
305 Clients SHOULD implement SHA2-512(2), but servers SHOULD NOT
306 exclusively publish SHA2-512(2) digests. The digest algorithm
307 agility protocol defined in Section 8 SHOULD be used by clients to
308 decide how to process TLSA RRsets that employ multiple digest
309 algorithms. Server operators MUST publish TLSA RRsets that are
310 compatible with digest algorithm agility.
312 2.1. Example TLSA record
314 In the example TLSA record below:
316 _25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 (
317 E8B54E0B4BAA815B06D3462D65FBC7C0
318 CF556ECCF9F5303EBFBB77D022F834C0 )
320 The TLSA Certificate Usage is DANE-TA(2), the selector is Cert(0) and
321 the matching type is SHA2-256(1). The last field is the Certificate
322 Association Data Field, which in this case contains the SHA2-256
323 digest of the server certificate.
325 3. DANE TLS Requirements
327 [RFC6698] does not discuss what versions of TLS are required when
328 using DANE records. This document specifies that TLS clients that
329 support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support
330 TLS 1.2. TLS clients and servers using DANE SHOULD support the
331 "Server Name Indication" (SNI) extension of TLS.
336 Dukhovni & Hardaker Expires February 18, 2015 [Page 6]
338 Internet-Draft DANE operations August 2014
341 4. Certificate-Usage-Specific DANE Updates and Guidelines
343 The four Certificate Usage values from the TLSA record, DANE-EE(3),
344 DANE-TA(2), PKIX-EE(1) and PKIX-TA(0), are discussed below.
346 4.1. Certificate Usage DANE-EE(3)
348 In this section the meaning of DANE-EE(3) is updated from [RFC6698]
349 to specify that peer identity matching and that validity interval
350 compliance is based solely on the TLSA RRset properties. We also
351 extend [RFC6698] to cover the use of DANE authentication of raw
352 public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with
353 Certificate Usage DANE-EE(3) and selector SPKI(1).
355 Authentication via certificate usage DANE-EE(3) TLSA records involves
356 simply checking that the server's leaf certificate matches the TLSA
357 record. In particular, the binding of the server public key to its
358 name is based entirely on the TLSA record association. The server
359 MUST be considered authenticated even if none of the names in the
360 certificate match the client's reference identity for the server.
362 Similarly, with DANE-EE(3), the expiration date of the server
363 certificate MUST be ignored. The validity period of the TLSA record
364 key binding is determined by the validity interval of the TLSA record
367 With DANE-EE(3) servers that know all the connecting clients are
368 making use of DANE, they need not employ SNI (i.e., the may ignore
369 the client's SNI message) even when the server is known under
370 multiple domain names that would otherwise require separate
371 certificates. It is instead sufficient for the TLSA RRsets for all
372 the domain names in question to match the server's primary
373 certificate. For application protocols where the server name is
374 obtained indirectly via SRV, MX or similar records, it is simplest to
375 publish a single hostname as the target server name for all the
378 In organizations where it is practical to make coordinated changes in
379 DNS TLSA records before server key rotation, it is generally best to
380 publish end-entity DANE-EE(3) certificate associations in preference
381 to other choices of certificate usage. DANE-EE(3) TLSA records
382 support multiple server names without SNI, don't suddenly stop
383 working when leaf or intermediate certificates expire, and don't fail
384 when a server operator neglects to include all the required issuer
385 certificates in the server certificate chain.
387 TLSA records published for DANE servers SHOULD, as a best practice,
388 be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE
392 Dukhovni & Hardaker Expires February 18, 2015 [Page 7]
394 Internet-Draft DANE operations August 2014
397 implementations are required to support SHA2-256, this record type
398 works for all clients and need not change across certificate renewals
399 with the same key. This TLSA record type easily supports hosting
400 arrangements with a single certificate matching all hosted domains.
401 It is also the easiest to implement correctly in the client.
403 Another advantage of "DANE-EE(3) SPKI(1)" (with any suitable matching
404 type) TLSA records is that they are compatible with the raw public
405 key TLS extension specified in [I-D.ietf-tls-oob-pubkey]. DANE
406 clients that support this extension can use the TLSA record to
407 authenticate servers that negotiate the use of raw public keys in
408 place of X.509 certificate chains. Provided the server adheres to
409 the requirements of Section 7, the fact that raw public keys are not
410 compatible with any other TLSA record types will not get in the way
411 of successful authentication. Clients that employ DANE to
412 authenticate the peer server SHOULD NOT negotiate the use of raw
413 public keys unless the server's TLSA RRset includes compatible TLSA
416 While it is, in principle, also possible to authenticate raw public
417 keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the
418 public key from the certificate in DNS, this is in conflict with the
419 indicated selector and requires extra logic on clients that not all
420 implementations are expected to provide. Servers SHOULD NOT rely on
421 "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication
422 data for raw public keys.
424 4.2. Certificate Usage DANE-TA(2)
426 This section updates [RFC6698] by specifying a new operational
427 requirement for servers publishing TLSA records with a usage of DANE-
428 TA(2): such servers MUST include the trust-anchor certificate in
429 their TLS server certificate message.
431 Some domains may prefer to avoid the operational complexity of
432 publishing unique TLSA RRs for each TLS service. If the domain
433 employs a common issuing Certification Authority to create
434 certificates for multiple TLS services, it may be simpler to publish
435 the issuing authority as a trust anchor (TA) for the certificate
436 chains of all relevant services. The TLSA query domain (TLSA base
437 domain with port and protocol prefix labels) for each service issued
438 by the same TA may then be set to a CNAME alias that points to a
439 common TLSA RRset that matches the TA. For example:
448 Dukhovni & Hardaker Expires February 18, 2015 [Page 8]
450 Internet-Draft DANE operations August 2014
453 www1.example.com. IN A 192.0.2.1
454 www2.example.com. IN A 192.0.2.2
455 _443._tcp.www1.example.com. IN CNAME tlsa201._dane.example.com.
456 _443._tcp.www2.example.com. IN CNAME tlsa201._dane.example.com.
457 tlsa201._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14...
459 With usage DANE-TA(2) the server certificates will need to have names
460 that match one of the client's reference identifiers (see [RFC6125]).
461 The server SHOULD employ SNI to select the appropriate certificate to
462 present to the client.
464 4.2.1. Recommended record combinations
466 TLSA records with selector Full(0) are NOT RECOMMENDED. While these
467 potentially obviate the need to transmit the TA certificate in the
468 TLS server certificate message, client implementations may not be
469 able to augment the server certificate chain with the data obtained
470 from DNS, especially when the TLSA record supplies a bare key
471 (selector SPKI(1)). Since the server will need to transmit the TA
472 certificate in any case, server operators SHOULD publish TLSA records
473 with a selector other than Full(0) and avoid potential DNS
474 interoperability issues with large TLSA records containing full
475 certificates or keys (see Section 9.1.1).
477 TLSA Publishers employing DANE-TA(2) records SHOULD publish records
478 with a selector of Cert(0). Such TLSA records are associated with
479 the whole trust anchor certificate, not just with the trust anchor
480 public key. In particular, the client SHOULD then apply any relevant
481 constraints from the trust anchor certificate, such as, for example,
482 path length constraints.
484 While a selector of SPKI(1) may also be employed, the resulting TLSA
485 record will not specify the full trust anchor certificate content,
486 and elements of the trust anchor certificate other than the public
487 key become mutable. This may, for example, enable a subsidiary CA to
488 issue a chain that violates the trust anchor's path length or name
491 4.2.2. Trust anchor digests and server certificate chain
493 With DANE-TA(2) (these TLSA records are expected to match the digest
494 of a TA certificate or public key), a complication arises when the TA
495 certificate is omitted from the server's certificate chain, perhaps
496 on the basis of Section 7.4.2 of [RFC5246]:
504 Dukhovni & Hardaker Expires February 18, 2015 [Page 9]
506 Internet-Draft DANE operations August 2014
509 The sender's certificate MUST come first in the list. Each
510 following certificate MUST directly certify the one preceding
511 it. Because certificate validation requires that root keys be
512 distributed independently, the self-signed certificate that
513 specifies the root certification authority MAY be omitted from
514 the chain, under the assumption that the remote end must
515 already possess it in order to validate it in any case.
517 With TLSA Certificate Usage DANE-TA(2), there is no expectation that
518 the client is pre-configured with the trust anchor certificate. In
519 fact, client implementations are free to ignore all locally
520 configured trust anchors when processing usage DANE-TA(2) TLSA
521 records and may rely exclusively on the certificates provided in the
522 server's certificate chain. But, with a digest in the TLSA record,
523 the TLSA record contains neither the full trust anchor certificate
524 nor the full public key. If the TLS server's certificate chain does
525 not contain the trust anchor certificate, DANE clients will be unable
526 to authenticate the server.
528 TLSA Publishers that publish TLSA Certificate Usage DANE-TA(2)
529 associations with a selector of SPKI(1) or using a digest-based
530 matching type (not Full(0)) MUST ensure that the corresponding server
531 is configured to also include the trust anchor certificate in its TLS
532 handshake certificate chain, even if that certificate is a self-
533 signed root CA and would have been optional in the context of the
534 existing public CA PKI.
536 4.2.3. Trust anchor public keys
538 TLSA records with TLSA Certificate Usage DANE-TA(2), selector SPKI(1)
539 and a matching type of Full(0) will publish the full public key of a
540 trust anchor via DNS. In section 6.1.1 of [RFC5280] the definition
541 of a trust anchor consists of the following four parts:
543 1. the trusted issuer name,
545 2. the trusted public key algorithm,
547 3. the trusted public key, and
549 4. optionally, the trusted public key parameters associated with the
552 Items 2-4 are precisely the contents of the subjectPublicKeyInfo
553 published in the TLSA record. The issuer name is not included in the
554 subjectPublicKeyInfo.
560 Dukhovni & Hardaker Expires February 18, 2015 [Page 10]
562 Internet-Draft DANE operations August 2014
565 With TLSA Certificate Usage DANE-TA(2), the client may not have the
566 associated trust anchor certificate, and cannot generally verify
567 whether a particular certificate chain is "issued by" the trust
568 anchor described in the TLSA record.
570 When the server certificate chain includes a CA certificate whose
571 public key matches the TLSA record, the client can match that CA as
572 the intended issuer. Otherwise, the client can only check that the
573 topmost certificate in the server's chain is "signed by" the trust
574 anchor's public key in the TLSA record. Such a check may be
575 difficult to implement, and cannot be expected to be supported by all
578 Thus, servers should not rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA
579 records to be sufficient to authenticate chains issued by the
580 associated public key in the absence of a corresponding certificate
581 in the server's TLS certificate message. Servers SHOULD include the
582 TA certificate in their certificate chain.
584 If none of the server's certificate chain elements match a public key
585 specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1)
586 Full(0)" TLSA record is available, clients are encouraged to check
587 whether the topmost certificate in the chain is signed by the
588 provided public key and has not expired, and in that case consider
589 the server authenticated, provided the rest of the chain passes
590 validation including leaf certificate name checks.
592 4.3. Certificate Usage PKIX-EE(1)
594 This Certificate Usage is similar to DANE-EE(3), but in addition PKIX
595 verification is required. Therefore, name checks, certificate
596 expiration, etc., apply as they would without DANE. When, for a
597 given application protocol, DANE clients support both DANE-EE(3) and
598 PKIX-EE(1) usages, it should be noted that an attacker who can
599 compromise DNSSEC can replace these with usage DANE-EE(3) or DANE-
600 TA(2) TLSA records of their choosing, and thus bypass any PKIX
601 verification requirements.
603 Therefore, except when applications support only the PKIX Certificate
604 Usages (0 and 1), this Certificate Usage offers only illusory
605 incremental security over usage DANE-EE(3). It provides lower
606 operational reliability than DANE-EE(3) since some clients may not be
607 configured with the required root CA, the server's chain may be
608 incomplete or name checks may fail. PKIX-EE(1) also requires more
609 complex coordination between the Customer Domain and the Service
610 Provider in hosting arrangements. This certificate usage is NOT
616 Dukhovni & Hardaker Expires February 18, 2015 [Page 11]
618 Internet-Draft DANE operations August 2014
621 4.4. Certificate Usage PKIX-TA(0)
623 This section updates [RFC6698] by specifying new client
624 implementation requirements. Clients that trust intermediate
625 certificates MUST be prepared to construct longer PKIX chains than
626 would be required for PKIX alone.
628 TLSA Certificate Usage PKIX-TA(0) allows a domain to publish
629 constraints on the set of PKIX certification authorities trusted to
630 issue certificates for its TLS servers. This TLSA record matches
631 PKIX-verified trust chains which contain an issuer certificate (root
632 or intermediate) that matches its association data field (typically a
633 certificate or digest).
635 As with PKIX-EE(1) case, an attacker who can compromise DNSSEC can
636 replace these with usage DANE-EE(3) or DANE-TA(2) TLSA records of his
637 choosing and thus bypass the PKIX verification requirements.
638 Therefore, except when applications support only the PKIX Certificate
639 Usages (0 and 1), this Certificate Usage offers only illusory
640 incremental security over usage DANE-TA(2). It provides lower
641 operational reliability than DANE-TA(2) since some clients may not be
642 configured with the required root CA. PKIX-TA(0) also requires more
643 complex coordination between the Customer Domain and the Service
644 Provider in hosting arrangements. This certificate usage is NOT
647 TLSA Publishers who publish TLSA records for a particular public root
648 CA, will expect that clients will then only accept chains anchored at
649 that root. It is possible, however, that the client's trusted
650 certificate store includes some intermediate CAs, either with or
651 without the corresponding root CA. When a client constructs a trust
652 chain leading from a trusted intermediate CA to the server leaf
653 certificate, such a "truncated" chain might not contain the trusted
654 root published in the server's TLSA record.
656 If the omitted root is also trusted, the client may erroneously
657 reject the server chain if it fails to determine that the shorter
658 chain it constructed extends to a longer trusted chain that matches
659 the TLSA record. Thus, when matching a usage PKIX-TA(0) TLSA record,
660 a client SHOULD NOT always stop extending the chain when the first
661 locally trusted certificate is found. If no TLSA records have
662 matched any of the elements of the chain, and the trusted certificate
663 found is not self-issued, the client MUST attempt to build a longer
664 chain in the hope that a certificate closer to the root may in fact
665 match the server's TLSA record.
667 4.5. Opportunistic Security and PKIX usages
672 Dukhovni & Hardaker Expires February 18, 2015 [Page 12]
674 Internet-Draft DANE operations August 2014
677 When the client's protocol design is based on Opportunistic Security
678 (OS, [I-D.dukhovni-opportunistic-security]), and authentication is
679 opportunistically employed based on the presence of server TLSA
680 records, it is especially important to avoid the PKIX-EE(1) and PKIX-
681 TA(0) certificate usages. This is because the client has no way to
682 know in advance that it and the server both trust the requisite root
683 CA. Use of authentication in OS needs to be employed only when the
684 client can be confident of success, absent an attack, or an
685 operational error on the server side.
687 5. Service Provider and TLSA Publisher Synchronization
689 Complications arise when the TLSA Publisher is not the same entity as
690 the Service Provider. In this situation, the TLSA Publisher and the
691 Service Provider must cooperate to ensure that TLSA records published
692 by the TLSA Publisher don't fall out of sync with the server
693 certificate used by the Service Provider.
695 Whenever possible, the TLSA Publisher and the Service Provider should
696 be the same entity. Otherwise, changes in the service certificate
697 chain must be carefully coordinated between the parties involved.
698 Such coordination is difficult and service outages will result when
701 Having the master TLSA record in the Service Provider's zone avoids
702 the complexity of bilateral coordination of server certificate
703 configuration and TLSA record management. Even when the TLSA RRset
704 must be published in the Customer Domain's DNS zone (perhaps the
705 client application does not "chase" CNAMEs to the TLSA base domain),
706 it is possible to employ CNAME records to delegate the content of the
707 TLSA RRset to a domain operated by the Service Provider. Certificate
708 name checks generally constrain the applicability of TLSA CNAMEs
709 across organizational boundaries to Certificate Usages DANE-EE(3) and
712 Certificate Usage DANE-EE(3): In this case the Service Provider can
713 publish a single TLSA RRset that matches the server certificate or
714 public key digest. The same RRset works for all Customer Domains
715 because name checks do not apply with DANE-EE(3) TLSA records (see
716 Section 4.1). A Customer Domain can create a CNAME record
717 pointing to the TLSA RRset published by the Service Provider.
719 Certificate Usage DANE-TA(2): When the Service Provider operates a
720 private certification authority, the Service Provider is free to
721 issue a certificate bearing any customer's domain name. Without
722 DANE, such a certificate would not pass trust verification, but
723 with DANE, the customer's TLSA RRset that is aliased to the
724 provider's TLSA RRset can delegate authority to the provider's CA
728 Dukhovni & Hardaker Expires February 18, 2015 [Page 13]
730 Internet-Draft DANE operations August 2014
733 for the corresponding service. The Service Provider can generate
734 appropriate certificates for each customer and use the SNI
735 information provided by clients to select the right certificate
736 chain to present to each client.
738 Below are example DNS records (assumed "secure" and shown without the
739 associated DNSSEC information, such as record signatures) that
740 illustrate both of of the above models in the case of an HTTPS
741 service whose clients all support DANE TLS. These examples work even
742 with clients that don't "chase" CNAMEs when constructing the TLSA
743 base domain (see Section 6 below).
745 ; The hosted web service is redirected via a CNAME alias.
746 ; The associated TLSA RRset is also redirected via a CNAME alias.
748 ; A single certificate at the provider works for all Customer
749 ; Domains due to the use of the DANE-EE(3) Certificate Usage.
751 www1.example.com. IN CNAME w1.example.net.
752 _443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net.
753 _443._tcp.w1.example.net. IN TLSA DANE-EE SPKI SHA2-256 (
754 8A9A70596E869BED72C69D97A8895DFA
755 D86F300A343FECEFF19E89C27C896BC9 )
758 ; A CA at the provider can also issue certificates for each Customer
759 ; Domain, and use the DANE-TA(2) Certificate Usage type to
760 ; indicate a trust anchor.
762 www2.example.com. IN CNAME w2.example.net.
763 _443._tcp.www2.example.com. IN CNAME _443._tcp.w2.example.net.
764 _443._tcp.w2.example.net. IN TLSA DANE-TA Cert SHA2-256 (
765 C164B2C3F36D068D42A6138E446152F5
766 68615F28C69BD96A73E354CAC88ED00C )
768 With protocols that support explicit transport redirection via DNS MX
769 records, SRV records, or other similar records, the TLSA base domain
770 is based on the redirected transport end-point, rather than the
771 origin domain. With SMTP, for example, when an email service is
772 hosted by a Service Provider, the Customer Domain's MX hostnames will
773 point at the Service Provider's SMTP hosts. When the Customer
774 Domain's DNS zone is signed, the MX hostnames can be securely used as
775 the base domains for TLSA records that are published and managed by
776 the Service Provider. For example (without the required DNSSEC
777 information, such as record signatures):
784 Dukhovni & Hardaker Expires February 18, 2015 [Page 14]
786 Internet-Draft DANE operations August 2014
789 ; Hosted SMTP service
791 example.com. IN MX 0 mx1.example.net.
792 example.com. IN MX 0 mx2.example.net.
793 _25._tcp.mx1.example.net. IN TLSA DANE-EE SPKI SHA2-256 (
794 8A9A70596E869BED72C69D97A8895DFA
795 D86F300A343FECEFF19E89C27C896BC9 )
796 _25._tcp.mx2.example.net. IN TLSA DANE-EE SPKI SHA2-256 (
797 C164B2C3F36D068D42A6138E446152F5
798 68615F28C69BD96A73E354CAC88ED00C )
800 If redirection to the Service Provider's domain (via MX or SRV
801 records or any similar mechanism) is not possible, and aliasing of
802 the TLSA record is not an option, then more complex coordination
803 between the Customer Domain and Service Provider will be required.
804 Either the Customer Domain periodically provides private keys and a
805 corresponding certificate chain to the Provider (after making
806 appropriate changes in its TLSA records), or the Service Provider
807 periodically generates the keys and certificates and must wait for
808 matching TLSA records to be published by its Customer Domains before
809 deploying newly generated keys and certificate chains. In Section 6
810 below, we describe an approach that employs CNAME "chasing" to avoid
811 the difficulties of coordinating key management across organization
814 For further information about combining DANE and SRV, please see
817 6. TLSA Base Domain and CNAMEs
819 When the application protocol does not support service location
820 indirection via MX, SRV or similar DNS records, the service may be
821 redirected via a CNAME. A CNAME is a more blunt instrument for this
822 purpose, since unlike an MX or SRV record, it remaps the entire
823 origin domain to the target domain for all protocols.
825 The complexity of coordinating key management is largely eliminated
826 when DANE TLSA records are found in the Service Provider's domain, as
827 discussed in Section 5. Therefore, DANE TLS clients connecting to a
828 server whose domain name is a CNAME alias SHOULD follow the CNAME
829 hop-by-hop to its ultimate target host (noting at each step whether
830 the CNAME is DNSSEC-validated). If at each stage of CNAME expansion
831 the DNSSEC validation status is "secure", the final target name
832 SHOULD be the preferred base domain for TLSA lookups.
834 Implementations failing to find a TLSA record using a base name of
835 the final target of a CNAME expansion SHOULD issue a TLSA query using
836 the original destination name. That is, the preferred TLSA base
840 Dukhovni & Hardaker Expires February 18, 2015 [Page 15]
842 Internet-Draft DANE operations August 2014
845 domain should be derived from the fully expanded name, and failing
846 that should be the initial domain name.
848 When the TLSA base domain is the result of "secure" CNAME expansion,
849 the resulting domain name MUST be used as the HostName in SNI, and
850 MUST be the primary reference identifier for peer certificate
851 matching with certificate usages other than DANE-EE(3).
853 Protocol-specific TLSA specifications may provide additional guidance
854 or restrictions when following CNAME expansions.
856 Though CNAMEs are illegal on the right hand side of most indirection
857 records, such as MX and SRV records, they are supported by some
858 implementations. For example, if the MX or SRV host is a CNAME
859 alias, some implementations may "chase" the CNAME. If they do, they
860 SHOULD use the target hostname as the preferred TLSA base domain as
861 described above (and if the TLSA records are found there, use the
862 CNAME expanded domain also in SNI and certificate name checks).
864 7. TLSA Publisher Requirements
866 This section updates [RFC6698] by specifying a requirement on the
867 TLSA Publisher to ensure that each combination of Certificate Usage,
868 selector and matching type in the server's TLSA RRset MUST include at
869 least one record that matches the server's current certificate chain.
870 TLSA records that match recently retired or yet to be deployed
871 certificate chains will be present during key rollover. Such past or
872 future records must never be the only records published for any given
873 combination of usage, selector and matching type. We describe a TLSA
874 record update algorithm that ensures this requirement is met.
876 While a server is to be considered authenticated when its certificate
877 chain is matched by any of the published TLSA records, not all
878 clients support all combinations of TLSA record parameters. Some
879 clients may not support some digest algorithms, others may either not
880 support, or may exclusively support, the PKIX Certificate Usages.
881 Some clients may prefer to negotiate [I-D.ietf-tls-oob-pubkey] raw
882 public keys, which are only compatible with TLSA records whose
883 Certificate Usage is DANE-EE(3) with selector SPKI(1).
896 Dukhovni & Hardaker Expires February 18, 2015 [Page 16]
898 Internet-Draft DANE operations August 2014
901 A consequence of the above uncertainty as to which TLSA parameters
902 are supported by any given client is that servers need to ensure that
903 each and every parameter combination that appears in the TLSA RRset
904 is, on its own, sufficient to match the server's current certificate
905 chain. In particular, when deploying new keys or new parameter
906 combinations some care is required to not generate parameter
907 combinations that only match past or future certificate chains (or
908 raw public keys). The rest of this section explains how to update
909 the TLSA RRset in a manner that ensures the above requirement is met.
911 7.1. Key rollover with fixed TLSA Parameters
913 The simplest case is key rollover while retaining the same set of
914 published parameter combinations. In this case, TLSA records
915 matching the existing server certificate chain (or raw public keys)
916 are first augmented with corresponding records matching the future
917 keys, at least two TTLs or longer before the the new chain is
918 deployed. This allows the obsolete RRset to age out of client caches
919 before the new chain is used in TLS handshakes. Once sufficient time
920 has elapsed and all clients performing DNS lookups are retrieving the
921 updated TLSA records, the server administrator may deploy the new
922 certificate chain, verify that it works, and then remove any obsolete
923 records matching the no longer active chain:
925 ; The initial TLSA RRset
927 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
929 ; The transitional TLSA RRset published at least 2*TTL seconds
930 ; before the actual key change
932 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
933 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
935 ; The final TLSA RRset after the key change
937 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
939 The next case to consider is adding or switching to a new combination
940 of TLSA parameters. In this case publish the new parameter
941 combinations for the server's existing certificate chain first, and
942 only then deploy new keys if desired:
952 Dukhovni & Hardaker Expires February 18, 2015 [Page 17]
954 Internet-Draft DANE operations August 2014
959 _443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46...
961 ; New TLSA RRset, same key re-published as DANE-EE(3)
963 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
965 7.2. Switching to DANE-TA from DANE-EE
967 A more complex involves switching to a trust-anchor or PKIX usage
968 from a chain that is either self-signed, or issued by a private CA
969 and thus not compatible with PKIX. Here the process is to first add
970 TLSA records matching the future chain that is issued by the desired
971 future CA (private or PKIX), but initially with the same parameters
972 as the legacy chain. Then, after deploying the new keys, switch to
973 the new TLSA parameter combination.
975 ; The initial TLSA RRset
977 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
979 ; A transitional TLSA RRset, published at least 2*TTL before the
980 ; actual key change. The new keys are issued by a DANE-TA(2) CA,
981 ; but for now specified via a DANE-EE(3) association.
983 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
984 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
986 ; The final TLSA RRset after the key change. Now that the old
987 ; self-signed EE keys are not an impediment, specify the issuing
988 ; TA of the new keys.
990 _443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d...
992 7.3. Switching to New TLSA Parameters
994 When employing a new digest algorithm in the TLSA RRset, for
995 compatibility with digest agility specified in Section 8 below,
996 administrators should publish the new digest algorithm with each
997 combinations of Certificate Usage and selector for each associated
998 key or chain used with any other digest algorithm. When removing an
999 algorithm, remove it entirely. Each digest algorithm employed should
1000 match the same set of chains (or raw public keys).
1008 Dukhovni & Hardaker Expires February 18, 2015 [Page 18]
1010 Internet-Draft DANE operations August 2014
1013 ; The initial TLSA RRset with EE SHA2-256 associations for two keys.
1015 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1016 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
1018 ; The new TLSA RRset also with SHA2-512 associations for each key
1020 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1021 _443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc...
1022 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
1023 _443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714...
1025 7.4. TLSA Publisher Requirements Summary
1027 In summary, server operators updating TLSA records should make one
1028 change at a time. The individual safe changes are:
1030 o Pre-publish new certificate associations that employ the same TLSA
1031 parameters (usage, selector and matching type) as existing TLSA
1032 records, but match certificate chains that will be deployed in the
1033 near future. Wait for stale TLSA RRsets to expire from DNS caches
1034 before configuring servers to use the new certificate chain.
1036 o Remove TLSA records matching no longer deployed certificate
1039 o Extend the TLSA RRset with a new combination of parameters (usage,
1040 selector and matching type) that is used to generate matching
1041 associations for all certificate chains that are published with
1042 some other parameter combination.
1044 The above steps are intended to ensure that at all times and for each
1045 combination of usage, selector and matching type at least one TLSA
1046 record corresponds to the server's current certificate chain. No
1047 combination of Certificate Usage, selector and matching type in a
1048 server's TLSA RRset should ever match only some combination of future
1049 or past certificate chains. As a result, no matter what combinations
1050 of usage, selector and matching type may be supported by a given
1051 client, they will be sufficient to authenticate the server.
1053 8. Digest Algorithm Agility
1064 Dukhovni & Hardaker Expires February 18, 2015 [Page 19]
1066 Internet-Draft DANE operations August 2014
1069 While [RFC6698] specifies multiple digest algorithms, it does not
1070 specify a protocol by which the TLS client and TLSA record publisher
1071 can agree on the strongest shared algorithm. Such a protocol would
1072 allow the client and server to avoid exposure to any deprecated
1073 weaker algorithms that are published for compatibility with less
1074 capable clients, but should be ignored when possible. We specify
1075 such a protocol below.
1077 Suppose that a DANE TLS client authenticating a TLS server considers
1078 digest algorithm "BetterAlg" stronger than digest algorithm
1079 "WorseAlg". Suppose further that a server's TLSA RRset contains some
1080 records with "BetterAlg" as the digest algorithm. Suppose also that
1081 the server adheres to the requirements of Section 7 and ensures that
1082 each combination of TLSA parameters contains at least one record that
1083 matches the server's current certificate chain (or raw public keys).
1084 Under the above assumptions the client can safely ignore TLSA records
1085 with the weaker algorithm "WorseAlg", because it suffices to only
1086 check the records with the stronger algorithm "BetterAlg".
1088 To make digest algorithm agility possible, all published TLSA RRsets
1089 for use with DANE TLS MUST conform to the requirements of Section 7.
1090 With servers publishing compliant TLSA RRsets, TLS clients can, for
1091 each combination of usage and selector, ignore all digest records
1092 except those that employ their notion of the strongest digest
1093 algorithm. (The server should only publish algorithms it deems
1094 acceptable at all.) The ordering of digest algorithms by strength is
1095 not specified in advance; it is entirely up to the TLS client. TLS
1096 client implementations SHOULD make the digest algorithm preference
1097 ordering a configurable option.
1099 Note, TLSA records with a matching type of Full(0) that publish an
1100 entire certificate or public key object play no role in digest
1101 algorithm agility. They neither trump the processing of records that
1102 employ digests, nor are they ignored in the presence of any records
1103 with a digest (i.e. non-zero) matching type.
1105 TLS clients SHOULD use digest algorithm agility when processing the
1106 DANE TLSA records of an TLS server. Algorithm agility is to be
1107 applied after first discarding any unusable or malformed records
1108 (unsupported digest algorithm, or incorrect digest length). Thus,
1109 for each usage and selector, the client SHOULD process only any
1110 usable records with a matching type of Full(0) and the usable records
1111 whose digest algorithm is considered by the client to be the
1112 strongest among usable records with the given usage and selector.
1114 9. General DANE Guidelines
1120 Dukhovni & Hardaker Expires February 18, 2015 [Page 20]
1122 Internet-Draft DANE operations August 2014
1125 These guidelines provide guidance for using or designing protocols
1128 9.1. DANE DNS Record Size Guidelines
1130 Selecting a combination of TLSA parameters to use requires careful
1131 thought. One important consideration to take into account is the
1132 size of the resulting TLSA record after its parameters are selected.
1134 9.1.1. UDP and TCP Considerations
1136 Deployments SHOULD avoid TLSA record sizes that cause UDP
1139 Although DNS over TCP would provide the ability to more easily
1140 transfer larger DNS records between clients and servers, it is not
1141 universally deployed and is still prohibited by some firewalls.
1142 Clients that request DNS records via UDP typically only use TCP upon
1143 receipt of a truncated response in the DNS response message sent over
1144 UDP. Setting the TC bit alone will be insufficient if the response
1145 containing the TC bit is itself fragmented.
1147 9.1.2. Packet Size Considerations for TLSA Parameters
1149 Server operators SHOULD NOT publish TLSA records using both a TLSA
1150 Selector of Cert(0) and a TLSA Matching Type of Full(0), as even a
1151 single certificate is generally too large to be reliably delivered
1152 via DNS over UDP. Furthermore, two TLSA records containing full
1153 certificates will need to be published simultaneously during a
1154 certificate rollover, as discussed in Section 7.1.
1156 While TLSA records using a TLSA Selector of SPKI(1) and a TLSA
1157 Matching Type of Full(0) (which publish the bare public keys without
1158 the overhead of a containing X.509 certificate) are generally more
1159 compact, these too should be used with caution as they are still
1160 larger than necessary. Rather, servers SHOULD publish digest-based
1161 TLSA Matching Types in their TLSA records. The complete
1162 corresponding certificate should, instead, be transmitted to the
1163 client in-band during the TLS handshake, which can be easily verified
1164 using the digest value.
1166 In summary, the use of a TLSA Matching Type of Full(0) is NOT
1167 RECOMMENDED and the use of a digest-based matching type, such as
1168 SHA2-256(1) SHOULD be used.
1170 9.2. Certificate Name Check Conventions
1176 Dukhovni & Hardaker Expires February 18, 2015 [Page 21]
1178 Internet-Draft DANE operations August 2014
1181 Certificates presented by a TLS server will generally contain a
1182 subjectAltName (SAN) extension or a Common Name (CN) element within
1183 the subject distinguished name (DN). The TLS server's DNS domain
1184 name is normally published within these elements, ideally within the
1185 subjectAltName extension. (The use of the CN field for this purpose
1188 When a server hosts multiple domains at the same transport endpoint,
1189 the server's ability to respond with the right certificate chain is
1190 predicated on correct SNI information from the client. DANE clients
1191 MUST send the SNI extension with a HostName value of the base domain
1194 Except with TLSA Certificate Usage DANE-EE(3), where name checks are
1195 not applicable (see Section 4.1), DANE clients MUST verify that the
1196 client has reached the correct server by checking that the server
1197 name is listed in the server certificate's SAN or CN. The server
1198 name used for this comparison SHOULD be the base domain of the TLSA
1199 RRset. Additional acceptable names may be specified by protocol-
1200 specific DANE standards. For example, with SMTP both the destination
1201 domain name and the MX host name are acceptable names to be found in
1202 the server certificate (see [I-D.ietf-dane-smtp-with-dane]).
1204 It is the responsibility of the service operator, in coordination
1205 with the TLSA Publisher, to ensure that at least one of the TLSA
1206 records published for the service will match the server's certificate
1207 chain (either the default chain or the certificate that was selected
1208 based on the SNI information provided by the client).
1210 Given the DNSSEC validated DNS records below:
1212 example.com. IN MX 0 mail.example.com.
1213 mail.example.com. IN A 192.0.2.1
1214 _25._tcp.mail.example.com. IN TLSA DANE-TA Cert SHA2-256 (
1215 E8B54E0B4BAA815B06D3462D65FBC7C0
1216 CF556ECCF9F5303EBFBB77D022F834C0 )
1218 The TLSA base domain is "mail.example.com" and is required to be the
1219 HostName in the client's SNI extension. The server certificate chain
1220 is required to be be signed by a trust anchor with the above
1221 certificate SHA2-256 digest. Finally, one of the DNS names in the
1222 server certificate is required to be be either "mail.example.com" or
1223 "example.com" (this additional name is a concession to compatibility
1224 with prior practice, see [I-D.ietf-dane-smtp-with-dane] for details).
1226 The semantics of wildcards in server certificates are left to
1227 individual application protocol specifications.
1232 Dukhovni & Hardaker Expires February 18, 2015 [Page 22]
1234 Internet-Draft DANE operations August 2014
1237 9.3. Design Considerations for Protocols Using DANE
1239 When a TLS client goes to the trouble of authenticating a certificate
1240 chain presented by a TLS server, it will typically not continue to
1241 use that server in the event of authentication failure, or else
1242 authentication serves no purpose. Some clients may, at times,
1243 operate in an "audit" mode, where authentication failure is reported
1244 to the user or in logs as a potential problem, but the connection
1245 proceeds despite the failure. Nevertheless servers publishing TLSA
1246 records MUST be configured to allow correctly configured clients to
1247 successfully authenticate their TLS certificate chains.
1249 A service with DNSSEC-validated TLSA records implicitly promises TLS
1250 support. When all the TLSA records for a service are found
1251 "unusable", due to unsupported parameter combinations or malformed
1252 associated data, DANE clients cannot authenticate the service
1253 certificate chain. When authenticated TLS is dictated by the
1254 application, the client SHOULD NOT connect to the associated server.
1255 If, on the other hand, the use of TLS is "opportunistic", then the
1256 client SHOULD generally use the server via an unauthenticated TLS
1257 connection, but if TLS encryption cannot be established, the client
1258 MUST NOT use the server. Standards for DANE specific to the
1259 particular application protocol may modify the above requirements, as
1260 appropriate, to specify whether the connection should be established
1261 anyway without relying on TLS security, with only encryption but not
1262 authentication, or whether to refuse to connect entirely.
1263 Application protocols need to specify when to prioritize security
1264 over the ability to connect under adverse conditions.
1266 9.3.1. Design Considerations for non-PKIX Protocols
1268 For some application protocols (such as SMTP to MX with opportunistic
1269 TLS), the existing public CA PKI is not a viable alternative to DANE.
1270 For these (non-PKIX) protocols, new DANE standards SHOULD NOT suggest
1271 publishing TLSA records with TLSA Certificate Usage PKIX-TA(0) or
1272 PKIX-EE(1), as TLS clients cannot be expected to perform [RFC5280]
1273 PKIX validation or [RFC6125] identity verification.
1275 Protocols designed for non-PKIX use SHOULD choose to treat any TLSA
1276 records with TLSA Certificate Usage PKIX-TA(0) or PKIX-EE(1) as
1277 unusable. After verifying that the only available TLSA Certificate
1278 Usage types are PKIX-TA(0) or PKIX-EE(1), protocol specifications MAY
1279 instruct clients to either refuse to initiate a connection or to
1280 connect via unauthenticated TLS if no alternative authentication
1281 mechanisms are available.
1283 10. Interaction with Certificate Transparency
1288 Dukhovni & Hardaker Expires February 18, 2015 [Page 23]
1290 Internet-Draft DANE operations August 2014
1293 Certificate Transparency (CT) [RFC6962] defines an experimental
1294 approach to mitigate the risk of rogue or compromised public CAs
1295 issuing unauthorized certificates. This section clarifies the
1296 interaction of CT and DANE. CT is an experimental protocol and
1297 auditing system that applies only to public CAs, and only when they
1298 are free to issue unauthorized certificates for a domain. If the CA
1299 is not a public CA, or a DANE-EE(3) TLSA RR directly specifies the
1300 end entity certificate, there is no role for CT, and clients need not
1303 When a server is authenticated via a DANE TLSA RR with TLSA
1304 Certificate Usage DANE-EE(3), the domain owner has directly specified
1305 the certificate associated with the given service without reference
1306 to any PKIX certification authority. Therefore, when a TLS client
1307 authenticates the TLS server via a TLSA certificate association with
1308 usage DANE-EE(3), CT checks SHOULD NOT be performed. Publication of
1309 the server certificate or public key (digest) in a TLSA record in a
1310 DNSSEC signed zone by the domain owner assures the TLS client that
1311 the certificate is not an unauthorized certificate issued by a rogue
1312 CA without the domain owner's consent.
1314 When a server is authenticated via a DANE TLSA RR with TLSA usage
1315 DANE-TA(2) and the server certificate does not chain to a known
1316 public root CA, CT cannot apply (CT logs only accept chains that
1317 start with a known, public root). Since TLSA Certificate Usage DANE-
1318 TA(2) is generally intended to support non-PKIX trust anchors, TLS
1319 clients SHOULD NOT perform CT checks with usage DANE-TA(2) using
1322 A server operator who wants clients to perform CT checks should
1323 publish TLSA RRs with usage PKIX-TA(0) or PKIX-EE(1).
1325 11. Note on DNSSEC Security
1327 Clearly the security of the DANE TLSA PKI rests on the security of
1328 the underlying DNSSEC infrastructure. While this memo is not a guide
1329 to DNSSEC security, a few comments may be helpful to TLSA
1332 With the existing public CA PKI, name constraints are rarely used,
1333 and a public root CA can issue certificates for any domain of its
1334 choice. With DNSSEC, under the Registry/Registrar/Registrant model,
1335 the situation is different: only the registrar of record can update a
1336 domain's DS record in the registry parent zone (in some cases,
1337 however, the registry is the sole registrar). With many gTLDs, for
1338 which multiple registrars compete to provide domains in a single
1339 registry, it is important to make sure that rogue registrars cannot
1340 easily initiate an unauthorized domain transfer, and thus take over
1344 Dukhovni & Hardaker Expires February 18, 2015 [Page 24]
1346 Internet-Draft DANE operations August 2014
1349 DNSSEC for the domain. DNS Operators SHOULD use a registrar lock of
1350 their domains to offer some protection against this possibility.
1352 When the registrar is also the DNS operator for the domain, one needs
1353 to consider whether the registrar will allow orderly migration of the
1354 domain to another registrar or DNS operator in a way that will
1355 maintain DNSSEC integrity. TLSA Publishers SHOULD ensure their
1356 registrar publishes a suitable domain transfer policy.
1358 DNSSEC signed RRsets cannot be securely revoked before they expire.
1359 Operators should plan accordingly and not generate signatures with
1360 excessively long duration periods. For domains publishing high-value
1361 keys, a signature lifetime of a few days is reasonable, and the zone
1362 should be resigned daily. For domains with less critical data, a
1363 reasonable signature lifetime is a couple of weeks to a month, and
1364 the zone should be resigned weekly. Monitoring of the signature
1365 lifetime is important. If the zone is not resigned in a timely
1366 manner, one risks a major outage and the entire domain will become
1369 12. Summary of Updates to RFC6698
1371 Authors note: is this section needed? Or is it sufficiently clear
1372 above that we don't need to restate things here?
1374 o In Section 3 we update [RFC6698] to specify a requirement for
1375 clients to support at least TLS 1.0, and to support SNI.
1377 o In Section 4.1 we update [RFC6698] to specify peer identity
1378 matching and certificate validity interval based solely on the
1379 basis of the TLSA RRset. We also specify DANE authentication of
1380 raw public keys [I-D.ietf-tls-oob-pubkey] via TLSA records with
1381 Certificate Usage DANE-EE(3) and selector SPKI(1).
1383 o In Section 4.2 we update [RFC6698] to require that servers
1384 publishing digest TLSA records with a usage of DANE-TA(2) MUST
1385 include the trust-anchor certificate in their TLS server
1386 certificate message. This extends to the case of "2 1 0" TLSA
1387 records which publish a full public key.
1389 o In Section 4.3 and Section 4.4, we explain that PKIX-EE(1) and
1390 PKIX-TA(0) are generally NOT RECOMMENDED. With usage PKIX-TA(0)
1391 we note that clients may need to processes extended trust chains
1392 beyond the first trusted issuer, when that issuer is not self-
1400 Dukhovni & Hardaker Expires February 18, 2015 [Page 25]
1402 Internet-Draft DANE operations August 2014
1405 o In Section 6, we recommend that DANE application protocols specify
1406 that when possible securely CNAME expanded names be used to derive
1407 the TLSA base domain.
1409 o In Section 7, we specify a strategy for managing TLSA records that
1410 interoperates with DANE clients regardless of what subset of the
1411 possible TLSA record types (combinations of TLSA parameters) is
1412 supported by the client.
1414 o In Section 8, we propose a digest algorithm agility protocol.
1415 [Note: This section does not yet represent the rough consensus of
1416 the DANE working group and requires further discussion. Perhaps
1417 this belongs in a separate document.]
1419 o In Section 9.1 we recommend against the use of Full(0) TLSA
1420 records, as digest records are generally much more compact.
1422 13. Security Considerations
1424 Application protocols that cannot make use of the existing public CA
1425 PKI (so called non-PKIX protocols), may choose not to implement
1426 certain PKIX-dependent TLSA record types defined in [RFC6698]. If
1427 such records are published despite not being supported by the
1428 application protocol, they are treated as "unusable". When TLS is
1429 opportunistic, the client may proceed to use the server with
1430 mandatory unauthenticated TLS. This is stronger than opportunistic
1431 TLS without DANE, since in that case the client may also proceed with
1432 a plaintext connection. When TLS is not opportunistic, the client
1433 MUST NOT connect to the server.
1435 Therefore, when TLSA records are used with protocols where PKIX does
1436 not apply, the recommended policy is for servers to not publish PKIX-
1437 dependent TLSA records, and for opportunistic TLS clients to use them
1438 to enforce the use of (albeit unauthenticated) TLS, but otherwise
1439 treat them as unusable. Of course, when PKIX validation is supported
1440 by the application protocol, clients SHOULD perform PKIX validation
1443 14. IANA Considerations
1445 This specification requires no support from IANA.
1447 15. Acknowledgements
1449 The authors would like to thank Phil Pennock for his comments and
1450 advice on this document.
1456 Dukhovni & Hardaker Expires February 18, 2015 [Page 26]
1458 Internet-Draft DANE operations August 2014
1461 Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded
1462 me into participating in DANE working group discussions. Thanks to
1463 Paul Hoffman who motivated me to produce this memo and provided
1464 feedback on early drafts. Thanks also to Samuel Dukhovni for
1465 editorial assistance.
1469 16.1. Normative References
1471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1472 Requirement Levels", BCP 14, RFC 2119, March 1997.
1474 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1475 Rose, "DNS Security Introduction and Requirements", RFC
1478 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1479 Rose, "Resource Records for the DNS Security Extensions",
1480 RFC 4034, March 2005.
1482 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1483 Rose, "Protocol Modifications for the DNS Security
1484 Extensions", RFC 4035, March 2005.
1486 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1487 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
1489 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1490 Housley, R., and W. Polk, "Internet X.509 Public Key
1491 Infrastructure Certificate and Certificate Revocation List
1492 (CRL) Profile", RFC 5280, May 2008.
1494 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
1495 Extension Definitions", RFC 6066, January 2011.
1497 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
1498 Verification of Domain-Based Application Service Identity
1499 within Internet Public Key Infrastructure Using X.509
1500 (PKIX) Certificates in the Context of Transport Layer
1501 Security (TLS)", RFC 6125, March 2011.
1503 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
1504 Security Version 1.2", RFC 6347, January 2012.
1506 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
1507 of Named Entities (DANE) Transport Layer Security (TLS)
1508 Protocol: TLSA", RFC 6698, August 2012.
1512 Dukhovni & Hardaker Expires February 18, 2015 [Page 27]
1514 Internet-Draft DANE operations August 2014
1517 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
1518 Conversations about DNS-Based Authentication of Named
1519 Entities (DANE)", RFC 7218, April 2014.
1521 16.2. Informative References
1523 [I-D.dukhovni-opportunistic-security]
1524 Dukhovni, V., "Opportunistic Security: Some Protection
1525 Most of the Time", draft-dukhovni-opportunistic-
1526 security-03 (work in progress), August 2014.
1528 [I-D.ietf-dane-smtp-with-dane]
1529 Dukhovni, V. and W. Hardaker, "SMTP security via
1530 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-11
1531 (work in progress), August 2014.
1534 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
1535 Based Authentication of Named Entities (DANE) TLSA Records
1536 with SRV Records", draft-ietf-dane-srv-07 (work in
1537 progress), July 2014.
1539 [I-D.ietf-tls-oob-pubkey]
1540 Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
1541 T. Kivinen, "Using Raw Public Keys in Transport Layer
1542 Security (TLS) and Datagram Transport Layer Security
1543 (DTLS)", draft-ietf-tls-oob-pubkey-11 (work in progress),
1546 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
1547 Transparency", RFC 6962, June 2013.
1554 Email: ietf-dane@dukhovni.org
1563 Email: ietf@hardakers.net
1568 Dukhovni & Hardaker Expires February 18, 2015 [Page 28]
git://git.exim.org / users / jgh / exim.git / blob