1 Internet Engineering Task Force (IETF) V. Dukhovni
2 Request for Comments: 7671 Two Sigma
3 Updates: 6698 W. Hardaker
4 Category: Standards Track Parsons
5 ISSN: 2070-1721 October 2015
6
7
8 The DNS-Based Authentication of Named Entities (DANE) Protocol:
9 Updates and Operational Guidance
10
11 Abstract
12
13 This document clarifies and updates the DNS-Based Authentication of
14 Named Entities (DANE) TLSA specification (RFC 6698), based on
15 subsequent implementation experience. It also contains guidance for
16 implementers, operators, and protocol developers who want to use DANE
17 records.
18
19 Status of This Memo
20
21 This is an Internet Standards Track document.
22
23 This document is a product of the Internet Engineering Task Force
24 (IETF). It represents the consensus of the IETF community. It has
25 received public review and has been approved for publication by the
26 Internet Engineering Steering Group (IESG). Further information on
27 Internet Standards is available in Section 2 of RFC 5741.
28
29 Information about the current status of this document, any errata,
30 and how to provide feedback on it may be obtained at
31 http://www.rfc-editor.org/info/rfc7671.
32
33 Copyright Notice
34
35 Copyright (c) 2015 IETF Trust and the persons identified as the
36 document authors. All rights reserved.
37
38 This document is subject to BCP 78 and the IETF Trust's Legal
39 Provisions Relating to IETF Documents
40 (http://trustee.ietf.org/license-info) in effect on the date of
41 publication of this document. Please review these documents
42 carefully, as they describe your rights and restrictions with respect
43 to this document. Code Components extracted from this document must
44 include Simplified BSD License text as described in Section 4.e of
45 the Trust Legal Provisions and are provided without warranty as
46 described in the Simplified BSD License.
47
48
49
50
51
52 Dukhovni & Hardaker Standards Track [Page 1]
53 RFC 7671 DANE Operations October 2015
54
55
56 Table of Contents
57
58 1. Introduction ....................................................3
59 1.1. Terminology ................................................4
60 2. DANE TLSA Record Overview .......................................5
61 2.1. Example TLSA Record ........................................6
62 3. DANE TLS Requirements ...........................................6
63 4. DANE Certificate Usage Selection Guidelines .....................7
64 4.1. Opportunistic Security and PKIX Usages .....................7
65 4.2. Interaction with Certificate Transparency ..................8
66 4.3. Switching from/to PKIX-TA/EE to/from DANE-TA/EE ............9
67 5. Certificate-Usage-Specific DANE Updates and Guidelines ..........9
68 5.1. Certificate Usage DANE-EE(3) ...............................9
69 5.2. Certificate Usage DANE-TA(2) ..............................11
70 5.3. Certificate Usage PKIX-EE(1) ..............................15
71 5.4. Certificate Usage PKIX-TA(0) ..............................15
72 6. Service Provider and TLSA Publisher Synchronization ............16
73 7. TLSA Base Domain and CNAMEs ....................................18
74 8. TLSA Publisher Requirements ....................................19
75 8.1. Key Rollover with Fixed TLSA Parameters ...................20
76 8.2. Switching to DANE-TA(2) from DANE-EE(3) ...................21
77 8.3. Switching to New TLSA Parameters ..........................22
78 8.4. TLSA Publisher Requirements: Summary ......................23
79 9. Digest Algorithm Agility .......................................23
80 10. General DANE Guidelines .......................................25
81 10.1. DANE DNS Record Size Guidelines ..........................25
82 10.2. Certificate Name Check Conventions .......................26
83 10.3. Design Considerations for Protocols Using DANE ...........27
84 11. Note on DNSSEC Security .......................................28
85 12. Summary of Updates to RFC 6698 ................................29
86 13. Operational Considerations ....................................29
87 14. Security Considerations .......................................30
88 15. References ....................................................30
89 15.1. Normative References .....................................30
90 15.2. Informative References ...................................32
91 Acknowledgements ..................................................33
92 Authors' Addresses ................................................33
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Dukhovni & Hardaker Standards Track [Page 2]
108 RFC 7671 DANE Operations October 2015
109
110
111 1. Introduction
112
113 The DNS-Based Authentication of Named Entities (DANE) specification
114 [RFC6698] introduces the DNS "TLSA" resource record (RR) type ("TLSA"
115 is not an acronym). TLSA records associate a certificate or a public
116 key of an end-entity or a trusted issuing authority with the
117 corresponding Transport Layer Security (TLS) [RFC5246] or Datagram
118 Transport Layer Security (DTLS) [RFC6347] transport endpoint. DANE
119 relies on the DNS Security Extensions (DNSSEC) [RFC4033]. DANE TLSA
120 records validated by DNSSEC can be used to augment or replace the use
121 of trusted public Certification Authorities (CAs).
122
123 The TLS and DTLS protocols provide secured TCP and UDP communication,
124 respectively, over IP. In the context of this document, channel
125 security is assumed to be provided by TLS or DTLS. By convention,
126 "TLS" will be used throughout this document; unless otherwise
127 specified, the text applies equally well to DTLS over UDP. Used
128 without authentication, TLS provides protection only against
129 eavesdropping through its use of encryption. With authentication,
130 TLS also protects the transport against man-in-the-middle (MITM)
131 attacks.
132
133 [RFC6698] defines three TLSA record fields: the first with four
134 possible values, the second with two, and the third with three.
135 These yield 24 distinct combinations of TLSA record types. This
136 document recommends a smaller set of best-practice combinations of
137 these fields to simplify protocol design, implementation, and
138 deployment.
139
140 This document explains and recommends DANE-specific strategies to
141 simplify "virtual hosting", where a single Service Provider transport
142 endpoint simultaneously supports multiple hosted Customer Domains.
143
144 Other related documents that build on [RFC6698] are [RFC7673] and
145 [RFC7672].
146
147 Section 12 summarizes the normative updates this document makes to
148 [RFC6698].
149
150
151
152
153
154
155
156
157
158
159
160
161
162 Dukhovni & Hardaker Standards Track [Page 3]
163 RFC 7671 DANE Operations October 2015
164
165
166 1.1. Terminology
167
168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
170 "OPTIONAL" in this document are to be interpreted as described in
171 [RFC2119].
172
173 The following terms are used throughout this document:
174
175 Web PKI: The Public Key Infrastructure (PKI) model employed by
176 browsers to authenticate web servers. This employs a set of
177 trusted public CAs to vouch for the authenticity of public keys
178 associated with a particular party (the subject).
179
180 Service Provider: A company or organization that offers to host a
181 service on behalf of the owner of a Customer Domain. The original
182 domain name associated with the service often remains under the
183 control of the customer. Connecting applications may be directed
184 to the Service Provider via a redirection RR. Example redirection
185 records include MX, SRV, and CNAME. The Service Provider
186 frequently provides services for many customers and needs to
187 ensure that the TLS credentials presented to connecting
188 applications authenticate it as a valid server for the requested
189 domain.
190
191 Customer Domain: As described above, a TLS client may be interacting
192 with a service that is hosted by a third party. This document
193 refers to the domain name used to locate the service (prior to any
194 redirection) as the "Customer Domain".
195
196 TLSA Publisher: The entity responsible for publishing a TLSA record
197 within a DNS zone. This zone will be assumed DNSSEC-signed and
198 validatable to a trust anchor (TA), unless otherwise specified.
199 If the Customer Domain is not outsourcing its DNS service, the
200 TLSA Publisher will be the customer itself. Otherwise, the TLSA
201 Publisher may be the operator of the outsourced DNS service.
202
203 Public key: The term "public key" is shorthand for the
204 subjectPublicKeyInfo component of a PKIX [RFC5280] certificate.
205
206 SNI: The Server Name Indication (SNI) TLS protocol extension allows
207 a TLS client to request a connection to a particular service name
208 of a TLS server ([RFC6066], Section 3). Without this TLS
209 extension, a TLS server has no choice but to offer a certificate
210 with a default list of server names, making it difficult to host
211 multiple Customer Domains at the same IP-address-based TLS service
212 endpoint (i.e., provide "secure virtual hosting").
213
214
215
216
217 Dukhovni & Hardaker Standards Track [Page 4]
218 RFC 7671 DANE Operations October 2015
219
220
221 TLSA parameters: In [RFC6698], the TLSA record is defined to consist
222 of four fields. The first three of these are numeric parameters
223 that specify the meaning of the data in the fourth and final
224 field. This document refers to the first three fields as "TLSA
225 parameters", or sometimes just "parameters" when obvious from
226 context.
227
228 TLSA base domain: Per Section 3 of [RFC6698], TLSA records are
229 stored at a DNS domain name that is a combination of a port and
230 protocol prefix and a "base domain". In [RFC6698], the "base
231 domain" is the fully qualified domain name of the TLS server.
232 This document modifies the TLSA record lookup strategy to prefer
233 the fully CNAME-expanded name of the TLS server, provided that
234 expansion is "secure" (DNSSEC validated) at each stage of the
235 expansion, and TLSA records are published for this fully expanded
236 name. Thus, the "TLSA base domain" is either the fully
237 CNAME-expanded TLS server name or otherwise the initial fully
238 qualified TLS server name, whichever is used in combination with a
239 port and protocol prefix to obtain the TLSA RRset.
240
241 2. DANE TLSA Record Overview
242
243 DANE TLSA [RFC6698] specifies a protocol for publishing TLS server
244 certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035].
245 DANE TLSA records consist of four fields. The record type is
246 determined by the values of the first three fields, which this
247 document refers to as the "TLSA parameters" to distinguish them from
248 the fourth and last field. The numeric values of these parameters
249 were given symbolic names in [RFC7218]. The four fields are as
250 follows:
251
252 The Certificate Usage field: Section 2.1.1 of [RFC6698] specifies
253 four values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3).
254 There is an additional private-use value: PrivCert(255), which,
255 given its private scope, shall not be considered further in this
256 document. All other values are reserved for use by future
257 specifications.
258
259 The Selector field: Section 2.1.2 of [RFC6698] specifies two values:
260 Cert(0) and SPKI(1). There is an additional private-use value:
261 PrivSel(255). All other values are reserved for use by future
262 specifications.
263
264 The Matching Type field: Section 2.1.3 of [RFC6698] specifies three
265 values: Full(0), SHA2-256(1), and SHA2-512(2). There is an
266 additional private-use value: PrivMatch(255). All other values
267 are reserved for use by future specifications.
268
269
270
271
272 Dukhovni & Hardaker Standards Track [Page 5]
273 RFC 7671 DANE Operations October 2015
274
275
276 The Certificate Association Data field: See Section 2.1.4 of
277 [RFC6698]. This field stores the full value or digest of the
278 certificate or subject public key as determined by the matching
279 type and selector, respectively.
280
281 In the Matching Type field, of the two digest algorithms --
282 SHA2-256(1) and SHA2-512(2) -- as of the time of this writing, only
283 SHA2-256(1) is mandatory to implement. Clients SHOULD implement
284 SHA2-512(2), but servers SHOULD NOT exclusively publish SHA2-512(2)
285 digests. The digest algorithm agility protocol defined in Section 9
286 SHOULD be used by clients to decide how to process TLSA RRsets that
287 employ multiple digest algorithms. Server operators MUST publish
288 TLSA RRsets that are compatible (see Section 8) with digest algorithm
289 agility (Section 9).
290
291 2.1. Example TLSA Record
292
293 In the example TLSA record below, the TLSA certificate usage is
294 DANE-TA(2), the selector is Cert(0), and the matching type is
295 SHA2-256(1). The last field is the Certificate Association Data
296 field, which in this case contains the SHA2-256 digest of the server
297 certificate.
298
299 _25._tcp.mail.example.com. IN TLSA 2 0 1 (
300 E8B54E0B4BAA815B06D3462D65FBC7C0
301 CF556ECCF9F5303EBFBB77D022F834C0 )
302
303 3. DANE TLS Requirements
304
305 [RFC6698] does not discuss what versions of TLS are required when
306 using DANE records. This document specifies that TLS clients that
307 support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support
308 TLS 1.2 or later.
309
310 TLS clients using DANE MUST support the SNI extension of TLS
311 [RFC6066]. Servers MAY support SNI and respond with a matching
312 certificate chain but MAY also ignore SNI and respond with a default
313 certificate chain. When a server supports SNI but is not configured
314 with a certificate chain that exactly matches the client's SNI
315 extension, the server SHOULD respond with another certificate chain
316 (a default or closest match). This is because clients might support
317 more than one server name but can only put a single name in the SNI
318 extension.
319
320
321
322
323
324
325
326
327 Dukhovni & Hardaker Standards Track [Page 6]
328 RFC 7671 DANE Operations October 2015
329
330
331 4. DANE Certificate Usage Selection Guidelines
332
333 As mentioned in Section 2, the TLSA Certificate Usage field takes one
334 of four possible values. With PKIX-TA(0) and PKIX-EE(1), the
335 validation of peer certificate chains requires additional
336 preconfigured CA TAs that are mutually trusted by the operators of
337 the TLS server and client. With DANE-TA(2) and DANE-EE(3), no
338 preconfigured CA TAs are required and the published DANE TLSA records
339 are sufficient to verify the peer's certificate chain.
340
341 Standards for application protocols that employ DANE TLSA can specify
342 more specific guidance than [RFC6698] or this document. Such
343 application-specific standards need to carefully consider which set
344 of DANE certificate usages to support. Simultaneous support for all
345 four usages is NOT RECOMMENDED for DANE clients. When all four
346 usages are supported, an attacker capable of compromising the
347 integrity of DNSSEC needs only to replace the server's TLSA RRset
348 with one that lists suitable DANE-EE(3) or DANE-TA(2) records,
349 effectively bypassing any added verification via public CAs. In
350 other words, when all four usages are supported, PKIX-TA(0) and
351 PKIX-EE(1) offer only illusory incremental security over DANE-TA(2)
352 and DANE-EE(3).
353
354 Designs in which clients support just the DANE-TA(2) and DANE-EE(3)
355 certificate usages are RECOMMENDED. With DANE-TA(2) and DANE-EE(3),
356 clients don't need to track a large changing list of X.509 TAs in
357 order to successfully authenticate servers whose certificates are
358 issued by a CA that is brand new or not widely trusted.
359
360 The DNSSEC TLSA records for servers MAY include both sets of usages
361 if the server needs to support a mixture of clients, some supporting
362 one pair of usages and some the other.
363
364 4.1. Opportunistic Security and PKIX Usages
365
366 When the client's protocol design is based on "Opportunistic
367 Security" (OS) [RFC7435] and the use of authentication is based on
368 the presence of server TLSA records, it is especially important to
369 avoid the PKIX-EE(1) and PKIX-TA(0) certificate usages.
370
371 When authenticated TLS is used opportunistically based on the
372 presence of DANE TLSA records and no secure TLSA records are present,
373 unauthenticated TLS is used if possible, and if TLS is not possible,
374 perhaps even cleartext. However, if usable secure TLSA records are
375 published, then authentication MUST succeed. Also, outside the
376 browser space, there is no preordained canon of trusted CAs, and in
377 any case there is no security advantage in using PKIX-TA(0) or
378
379
380
381
382 Dukhovni & Hardaker Standards Track [Page 7]
383 RFC 7671 DANE Operations October 2015
384
385
386 PKIX-EE(1) when the DANE-TA(2) and DANE-EE(3) usages are also
387 supported (as an attacker who can compromise DNS can replace the
388 former with the latter).
389
390 Authentication via the PKIX-TA(0) and PKIX-EE(1) certificate usages
391 is more brittle; the client and server need to happen to agree on a
392 mutually trusted CA, but with OS the client is just trying to protect
393 the communication channel at the request of the server and would
394 otherwise be willing to use cleartext or unauthenticated TLS. The
395 use of fragile mechanisms (like public CA authentication for some
396 unspecified set of trusted CAs) is not sufficiently reliable for an
397 OS client to honor the server's request for authentication. OS needs
398 to be non-intrusive and to require few, if any, workarounds for valid
399 but mismatched peers.
400
401 Because the PKIX-TA(0) and PKIX-EE(1) usages offer no more security
402 and are more prone to failure, they are a poor fit for OS and
403 SHOULD NOT be used in that context.
404
405 4.2. Interaction with Certificate Transparency
406
407 Certificate Transparency (CT) [RFC6962] defines an experimental
408 approach that could be used to mitigate the risk of rogue or
409 compromised public CAs issuing unauthorized certificates. This
410 section clarifies the interaction of the experimental CT and DANE.
411 This section may need to be revised in light of any future Standards
412 Track version of CT.
413
414 When a server is authenticated via a DANE TLSA RR with TLSA
415 certificate usage DANE-EE(3), the domain owner has directly specified
416 the certificate associated with the given service without reference
417 to any public CA. Therefore, when a TLS client authenticates the TLS
418 server via a TLSA record with usage DANE-EE(3), CT checks SHOULD NOT
419 be performed. Publication of the server certificate or public key
420 (digest) in a TLSA record in a DNSSEC-signed zone by the domain owner
421 assures the TLS client that the certificate is not an unauthorized
422 certificate issued by a rogue CA without the domain owner's consent.
423
424 When a server is authenticated via a DANE TLSA record with TLSA usage
425 DANE-TA(2) and the server certificate does not chain to a known
426 public root CA, CT cannot apply (CT logs only accept chains that
427 start with a known public root). Since TLSA certificate usage
428 DANE-TA(2) is generally intended to support non-public TAs, TLS
429 clients SHOULD NOT perform CT checks with usage DANE-TA(2).
430
431
432
433
434
435
436
437 Dukhovni & Hardaker Standards Track [Page 8]
438 RFC 7671 DANE Operations October 2015
439
440
441 With certificate usages PKIX-TA(0) and PKIX-EE(1), CT applies just as
442 it would without DANE. TLSA records of this type only constrain
443 which CAs are acceptable in PKIX validation. All checks used in the
444 absence of DANE still apply when validating certificate chains with
445 DANE PKIX-TA(0) and PKIX-EE(1) constraints.
446
447 4.3. Switching from/to PKIX-TA/EE to/from DANE-TA/EE
448
449 The choice of preferred certificate usages may need to change as an
450 application protocol evolves. When transitioning between PKIX-TA/
451 PKIX-EE and DANE-TA/DANE-EE, clients begin to enable support for the
452 new certificate usage values. If the new preferred certificate
453 usages are PKIX-TA/EE, this requires installing and managing the
454 appropriate set of CA TAs. During this time, servers will publish
455 both types of TLSA records. At some later time, when the vast
456 majority of servers have published the new preferred TLSA records,
457 clients can stop supporting the legacy certificate usages.
458 Similarly, servers can stop publishing legacy TLSA records once the
459 vast majority of clients support the new certificate usages.
460
461 5. Certificate-Usage-Specific DANE Updates and Guidelines
462
463 The four certificate usage values from the TLSA record -- DANE-EE(3),
464 DANE-TA(2), PKIX-EE(1), and PKIX-TA(0) -- are discussed below.
465
466 5.1. Certificate Usage DANE-EE(3)
467
468 In this section, the meaning of DANE-EE(3) is updated from [RFC6698]
469 to specify that peer identity matching and validity period
470 enforcement are based solely on the TLSA RRset properties. This
471 document also extends [RFC6698] to cover the use of DANE
472 authentication of raw public keys [RFC7250] via TLSA records with
473 certificate usage DANE-EE(3) and selector SPKI(1).
474
475 Authentication via certificate usage DANE-EE(3) TLSA records involves
476 simply checking that the server's leaf certificate matches the TLSA
477 record. In particular, the binding of the server public key to its
478 name is based entirely on the TLSA record association. The server
479 MUST be considered authenticated even if none of the names in the
480 certificate match the client's reference identity for the server.
481 This simplifies the operation of servers that host multiple Customer
482 Domains, as a single certificate can be associated with multiple
483 domains without having to match each of the corresponding reference
484 identifiers.
485
486
487
488
489
490
491
492 Dukhovni & Hardaker Standards Track [Page 9]
493 RFC 7671 DANE Operations October 2015
494
495
496 ; Multiple Customer Domains hosted by an example.net
497 ; Service Provider:
498 ;
499 www.example.com. IN CNAME ex-com.example.net.
500 www.example.org. IN CNAME ex-org.example.net.
501 ;
502 ; In the provider's DNS zone, a single certificate and TLSA
503 ; record support multiple Customer Domains, greatly simplifying
504 ; "virtual hosting".
505 ;
506 ex-com.example.net. IN A 192.0.2.1
507 ex-org.example.net. IN A 192.0.2.1
508 _443._tcp.ex-com.example.net. IN CNAME tlsa._dane.example.net.
509 _443._tcp.ex-org.example.net. IN CNAME tlsa._dane.example.net.
510 tlsa._dane.example.net. IN TLSA 3 1 1 e3b0c44298fc1c14...
511
512 Also, with DANE-EE(3), the expiration date of the server certificate
513 MUST be ignored. The validity period of the TLSA record key binding
514 is determined by the validity period of the TLSA record DNSSEC
515 signatures. Validity is reaffirmed on an ongoing basis by continuing
516 to publish the TLSA record and signing the zone in which the record
517 is contained, rather than via dates "set in stone" in the
518 certificate. The expiration becomes a reminder to the administrator
519 that it is likely time to rotate the key, but missing the date no
520 longer causes an outage. When keys are rotated (for whatever
521 reason), it is important to follow the procedures outlined in
522 Section 8.
523
524 If a server uses just DANE-EE(3) TLSA records and all its clients are
525 DANE clients, the server need not employ SNI (i.e., it may ignore the
526 client's SNI message) even when the server is known via multiple
527 domain names that would otherwise require separate certificates. It
528 is instead sufficient for the TLSA RRsets for all the domain names in
529 question to match the server's default certificate. For application
530 protocols where the server name is obtained indirectly via SRV
531 records, MX records, or similar records, it is simplest to publish a
532 single hostname as the target server name for all the hosted domains.
533
534 In organizations where it is practical to make coordinated changes in
535 DNS TLSA records before server key rotation, it is generally best to
536 publish end-entity DANE-EE(3) certificate associations in preference
537 to other choices of certificate usage. DANE-EE(3) TLSA records
538 support multiple server names without SNI, don't suddenly stop
539 working when leaf or intermediate certificates expire, and don't fail
540 when a server operator neglects to include all the required issuer
541 certificates in the server certificate chain.
542
543
544
545
546
547 Dukhovni & Hardaker Standards Track [Page 10]
548 RFC 7671 DANE Operations October 2015
549
550
551 More specifically, it is RECOMMENDED that at most sites TLSA records
552 published for DANE servers be "DANE-EE(3) SPKI(1) SHA2-256(1)"
553 records. Selector SPKI(1) is chosen because it is compatible with
554 raw public keys [RFC7250] and the resulting TLSA record need not
555 change across certificate renewals with the same key. Matching type
556 SHA2-256(1) is chosen because all DANE implementations are required
557 to support SHA2-256. This TLSA record type easily supports hosting
558 arrangements with a single certificate matching all hosted domains.
559 It is also the easiest to implement correctly in the client.
560
561 Clients that support raw public keys can use DANE TLSA records with
562 certificate usage DANE-EE(3) and selector SPKI(1) to authenticate
563 servers that negotiate the use of raw public keys. Provided the
564 server adheres to the requirements of Section 8, the fact that raw
565 public keys are not compatible with any other TLSA record types will
566 not get in the way of successful authentication. Clients that employ
567 DANE to authenticate the peer server SHOULD NOT negotiate the use of
568 raw public keys unless the server's TLSA RRset includes "DANE-EE(3)
569 SPKI(1)" TLSA records.
570
571 While it is, in principle, also possible to authenticate raw public
572 keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the
573 public key from the certificate in DNS, extracting just the public
574 key from a "3 0 0" TLSA record requires extra logic on clients that
575 not all implementations are expected to provide. Servers that wish
576 to support [RFC7250] raw public keys need to publish TLSA records
577 with a certificate usage of DANE-EE(3) and a selector of SPKI(1).
578
579 While DANE-EE(3) TLSA records are expected to be by far the most
580 prevalent, as explained in Section 5.2, DANE-TA(2) records are a
581 valid alternative for sites with many DANE services. Note, however,
582 that virtual hosting is more complex with DANE-TA(2). Also, with
583 DANE-TA(2), server operators MUST ensure that the server is
584 configured with a sufficiently complete certificate chain and need to
585 remember to replace certificates prior to their expiration dates.
586
587 5.2. Certificate Usage DANE-TA(2)
588
589 This section updates [RFC6698] by specifying a new operational
590 requirement for servers publishing TLSA records with a usage of
591 DANE-TA(2): such servers MUST include the TA certificate in their TLS
592 server certificate message unless all such TLSA records are "2 0 0"
593 records that publish the server certificate in full.
594
595 Some domains may prefer to avoid the operational complexity of
596 publishing unique TLSA RRs for each TLS service. If the domain
597 employs a common issuing CA to create certificates for multiple TLS
598 services, it may be simpler to publish the issuing authority as a TA
599
600
601
602 Dukhovni & Hardaker Standards Track [Page 11]
603 RFC 7671 DANE Operations October 2015
604
605
606 for the certificate chains of all relevant services. The TLSA query
607 domain (TLSA base domain with port and protocol prefix labels) for
608 each service issued by the same TA may then be set to a CNAME alias
609 that points to a common TLSA RRset that matches the TA. For example:
610
611 ; Two servers, each with its own certificate, that share
612 ; a common issuer (TA).
613 ;
614 www1.example.com. IN A 192.0.2.1
615 www2.example.com. IN A 192.0.2.2
616 _443._tcp.www1.example.com. IN CNAME tlsa._dane.example.com.
617 _443._tcp.www2.example.com. IN CNAME tlsa._dane.example.com.
618 tlsa._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14...
619
620 The above configuration simplifies server key rotation, because while
621 the servers continue to receive new certificates from a CA matched by
622 the shared (target of the CNAMEs) TLSA record, server certificates
623 can be updated without making any DNS changes. As the list of active
624 issuing CAs changes, the shared TLSA record will be updated (much
625 less frequently) by the administrators who manage the CAs. Those
626 administrators still need to perform TLSA record updates with care,
627 as described in Section 8.
628
629 With usage DANE-TA(2), the server certificates will need to have
630 names that match one of the client's reference identifiers (see
631 [RFC6125]). When hosting multiple unrelated Customer Domains (that
632 can't all appear in a single certificate), such a server SHOULD
633 employ SNI to select the appropriate certificate to present to the
634 client.
635
636 5.2.1. Recommended Record Combinations
637
638 TLSA records with a matching type of Full(0) are NOT RECOMMENDED.
639 While these potentially obviate the need to transmit the TA
640 certificate in the TLS server certificate message, client
641 implementations may not be able to augment the server certificate
642 chain with the data obtained from DNS, especially when the TLSA
643 record supplies a bare key (selector SPKI(1)). Since the server will
644 need to transmit the TA certificate in any case, server operators
645 SHOULD publish TLSA records with a matching type other than Full(0)
646 and avoid potential DNS interoperability issues with large TLSA
647 records containing full certificates or keys (see Section 10.1.1).
648
649
650
651
652
653
654
655
656
657 Dukhovni & Hardaker Standards Track [Page 12]
658 RFC 7671 DANE Operations October 2015
659
660
661 TLSA Publishers employing DANE-TA(2) records SHOULD publish records
662 with a selector of Cert(0). Such TLSA records are associated with
663 the whole TA certificate, not just with the TA public key. In
664 particular, when authenticating the peer certificate chain via such a
665 TLSA record, the client SHOULD apply any relevant constraints from
666 the TA certificate, such as, for example, path length constraints.
667
668 While a selector of SPKI(1) may also be employed, the resulting TLSA
669 record will not specify the full TA certificate content, and elements
670 of the TA certificate other than the public key become mutable. This
671 may, for example, enable a subsidiary CA to issue a chain that
672 violates the TA's path length or name constraints.
673
674 5.2.2. Trust Anchor Digests and Server Certificate Chain
675
676 With DANE-TA(2), a complication arises when the TA certificate is
677 omitted from the server's certificate chain, perhaps on the basis of
678 Section 7.4.2 of [RFC5246]:
679
680 The sender's certificate MUST come first in the list. Each
681 following certificate MUST directly certify the one preceding it.
682 Because certificate validation requires that root keys be
683 distributed independently, the self-signed certificate that
684 specifies the root certificate authority MAY be omitted from the
685 chain, under the assumption that the remote end must already
686 possess it in order to validate it in any case.
687
688 With TLSA certificate usage DANE-TA(2), there is no expectation that
689 the client is preconfigured with the TA certificate. In fact, client
690 implementations are free to ignore all locally configured TAs when
691 processing usage DANE-TA(2) TLSA records and may rely exclusively on
692 the certificates provided in the server's certificate chain. But,
693 with a digest in the TLSA record, the TLSA record contains neither
694 the full TA certificate nor the full public key. If the TLS server's
695 certificate chain does not contain the TA certificate, DANE clients
696 will be unable to authenticate the server.
697
698 TLSA Publishers that publish TLSA certificate usage DANE-TA(2)
699 associations with a selector of SPKI(1) or with a digest-based
700 matching type (not Full(0)) MUST ensure that the corresponding server
701 is configured to also include the TA certificate in its TLS handshake
702 certificate chain, even if that certificate is a self-signed root CA
703 and would have been optional in the context of the existing public
704 CA PKI.
705
706
707
708
709
710
711
712 Dukhovni & Hardaker Standards Track [Page 13]
713 RFC 7671 DANE Operations October 2015
714
715
716 Only when the server TLSA record includes a "DANE-TA(2) Cert(0)
717 Full(0)" TLSA record containing a full TA certificate is the TA
718 certificate optional in the server's TLS certificate message. This
719 is also the only type of DANE-TA(2) record for which the client MUST
720 be able to verify the server's certificate chain even if the TA
721 certificate appears only in DNS and is absent from the TLS handshake
722 server certificate message.
723
724 5.2.3. Trust Anchor Public Keys
725
726 TLSA records with TLSA certificate usage DANE-TA(2), selector
727 SPKI(1), and a matching type of Full(0) publish the full public key
728 of a TA via DNS. In Section 6.1.1 of [RFC5280], the definition of a
729 TA consists of the following four parts:
730
731 1. the trusted issuer name,
732
733 2. the trusted public key algorithm,
734
735 3. the trusted public key, and
736
737 4. optionally, the trusted public key parameters associated with the
738 public key.
739
740 Items 2-4 are precisely the contents of the subjectPublicKeyInfo
741 published in the TLSA record. The issuer name is not included in the
742 subjectPublicKeyInfo.
743
744 With TLSA certificate usage DANE-TA(2), the client may not have the
745 associated TA certificate and cannot generally verify whether or not
746 a particular certificate chain is "issued by" the TA described in the
747 TLSA record.
748
749 When the server certificate chain includes a CA certificate whose
750 public key matches the TLSA record, the client can match that CA as
751 the intended issuer. Otherwise, the client can only check that the
752 topmost certificate in the server's chain is "signed by" the TA's
753 public key in the TLSA record. Such a check may be difficult to
754 implement and cannot be expected to be supported by all clients.
755
756 Thus, servers cannot rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA
757 records to be sufficient to authenticate chains issued by the
758 associated public key in the absence of a corresponding certificate
759 in the server's TLS certificate message. Servers employing "2 1 0"
760 TLSA records MUST include the corresponding TA certificate in their
761 certificate chain.
762
763
764
765
766
767 Dukhovni & Hardaker Standards Track [Page 14]
768 RFC 7671 DANE Operations October 2015
769
770
771 If none of the server's certificate chain elements match a public key
772 specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1)
773 Full(0)" TLSA record is available, it is RECOMMENDED that clients
774 check to see whether or not the topmost certificate in the chain is
775 signed by the provided public key and has not expired, and in that
776 case consider the server authenticated, provided the rest of the
777 chain passes validation, including leaf certificate name checks.
778
779 5.3. Certificate Usage PKIX-EE(1)
780
781 This certificate usage is similar to DANE-EE(3); but, in addition,
782 PKIX verification is required. Therefore, name checks, certificate
783 expiration, CT, etc. apply as they would without DANE.
784
785 5.4. Certificate Usage PKIX-TA(0)
786
787 This section updates [RFC6698] by specifying new client
788 implementation requirements. Clients that trust intermediate
789 certificates MUST be prepared to construct longer PKIX chains than
790 would be required for PKIX alone.
791
792 TLSA certificate usage PKIX-TA(0) allows a domain to publish
793 constraints on the set of PKIX CAs trusted to issue certificates for
794 its TLS servers. A PKIX-TA(0) TLSA record matches PKIX-verified
795 trust chains that contain an issuer certificate (root or
796 intermediate) that matches its Certificate Association Data field
797 (typically a certificate or digest).
798
799 PKIX-TA(0) requires more complex coordination (than with DANE-TA(2)
800 or DANE-EE(3)) between the Customer Domain and the Service Provider
801 in hosting arrangements. Thus, this certificate usage is
802 NOT RECOMMENDED when the Service Provider is not also the TLSA
803 Publisher (at the TLSA base domain obtained via CNAMEs, SRV records,
804 or MX records).
805
806 TLSA Publishers who publish TLSA records for a particular public root
807 CA will expect that clients will only accept chains anchored at that
808 root. It is possible, however, that the client's trusted certificate
809 store includes some intermediate CAs, either with or without the
810 corresponding root CA. When a client constructs a trust chain
811 leading from a trusted intermediate CA to the server leaf
812 certificate, such a "truncated" chain might not contain the trusted
813 root published in the server's TLSA record.
814
815 If the omitted root is also trusted, the client may erroneously
816 reject the server chain if it fails to determine that the shorter
817 chain it constructed extends to a longer trusted chain that matches
818 the TLSA record. Thus, when matching a usage PKIX-TA(0) TLSA record,
819
820
821
822 Dukhovni & Hardaker Standards Track [Page 15]
823 RFC 7671 DANE Operations October 2015
824
825
826 so long as no matching certificate has yet been found, a client MUST
827 continue extending the chain even after any locally trusted
828 certificate is found. If no TLSA records have matched any of the
829 elements of the chain and the trusted certificate found is not
830 self-issued, the client MUST attempt to build a longer chain in case
831 a certificate closer to the root matches the server's TLSA record.
832
833 6. Service Provider and TLSA Publisher Synchronization
834
835 Whenever possible, the TLSA Publisher and the Service Provider should
836 be the same entity. Otherwise, they need to coordinate changes to
837 ensure that TLSA records published by the TLSA Publisher don't fall
838 out of sync with the server certificate used by the Service Provider.
839 Such coordination is difficult, and service outages will result when
840 coordination fails.
841
842 Publishing the TLSA record in the Service Provider's zone avoids the
843 complexity of bilateral coordination of server certificate
844 configuration and TLSA record management. Even when the TLSA RRset
845 has to be published in the Customer Domain's DNS zone (perhaps the
846 client application does not "chase" CNAMEs to the TLSA base domain),
847 it is possible to employ CNAME records to delegate the content of the
848 TLSA RRset to a domain operated by the Service Provider.
849
850 Only certificate usages DANE-EE(3) and DANE-TA(2) work well with TLSA
851 CNAMEs across organizational boundaries. With PKIX-TA(0) or
852 PKIX-EE(1), the Service Provider would need to obtain certificates in
853 the name of the Customer Domain from a suitable public CA (securely
854 impersonate the customer), or the customer would need to provision
855 the relevant private keys and certificates at the Service Provider's
856 systems.
857
858 Certificate Usage DANE-EE(3): In this case, the Service Provider can
859 publish a single TLSA RRset that matches the server certificate or
860 public key digest. The same RRset works for all Customer Domains
861 because name checks do not apply with DANE-EE(3) TLSA records (see
862 Section 5.1). A Customer Domain can create a CNAME record
863 pointing to the TLSA RRset published by the Service Provider.
864
865 Certificate Usage DANE-TA(2): When the Service Provider operates a
866 private CA, the Service Provider is free to issue a certificate
867 bearing any customer's domain name. Without DANE, such a
868 certificate would not pass trust verification, but with DANE, the
869 customer's TLSA RRset that is aliased to the provider's TLSA RRset
870 can delegate authority to the provider's CA for the corresponding
871 service. The Service Provider can generate appropriate
872
873
874
875
876
877 Dukhovni & Hardaker Standards Track [Page 16]
878 RFC 7671 DANE Operations October 2015
879
880
881 certificates for each customer and use the SNI information
882 provided by clients to select the right certificate chain to
883 present to each client.
884
885 Below are example DNS records (assumed "secure" and shown without the
886 associated DNSSEC information, such as record signatures) that
887 illustrate both of the above models in the case of an HTTPS service
888 whose clients all support DANE TLS. These examples work even with
889 clients that don't "chase" CNAMEs when constructing the TLSA base
890 domain (see Section 7 below).
891
892 ; The hosted web service is redirected via a CNAME alias.
893 ; The associated TLSA RRset is also redirected via a CNAME alias.
894 ;
895 ; Certificate usage DANE-EE(3) makes it possible to deploy
896 ; a single provider certificate for all Customer Domains.
897 ;
898 www1.example.com. IN CNAME w1.example.net.
899 _443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net.
900 _443._tcp.w1.example.net. IN TLSA 3 1 1 (
901 8A9A70596E869BED72C69D97A8895DFA
902 D86F300A343FECEFF19E89C27C896BC9 )
903
904 ;
905 ; A CA at the provider can also issue certificates for each Customer
906 ; Domain and employ the DANE-TA(2) certificate usage to
907 ; designate the provider's CA as a TA.
908 ;
909 www2.example.com. IN CNAME w2.example.net.
910 _443._tcp.www2.example.com. IN CNAME _443._tcp.w2.example.net.
911 _443._tcp.w2.example.net. IN TLSA 2 0 1 (
912 C164B2C3F36D068D42A6138E446152F5
913 68615F28C69BD96A73E354CAC88ED00C )
914
915 With protocols that support explicit transport redirection via DNS MX
916 records, SRV records, or other similar records, the TLSA base domain
917 is based on the redirected transport endpoint rather than the origin
918 domain. With SMTP, for example, when an email service is hosted by a
919 Service Provider, the Customer Domain's MX hostnames will point at
920 the Service Provider's SMTP hosts. When the Customer Domain's DNS
921 zone is signed, the MX hostnames can be securely used as the base
922
923
924
925
926
927
928
929
930
931
932 Dukhovni & Hardaker Standards Track [Page 17]
933 RFC 7671 DANE Operations October 2015
934
935
936 domains for TLSA records that are published and managed by the
937 Service Provider. For example (without the required DNSSEC
938 information, such as record signatures):
939
940 ; Hosted SMTP service.
941 ;
942 example.com. IN MX 0 mx1.example.net.
943 example.com. IN MX 0 mx2.example.net.
944 _25._tcp.mx1.example.net. IN TLSA 3 1 1 (
945 8A9A70596E869BED72C69D97A8895DFA
946 D86F300A343FECEFF19E89C27C896BC9 )
947 _25._tcp.mx2.example.net. IN TLSA 3 1 1 (
948 C164B2C3F36D068D42A6138E446152F5
949 68615F28C69BD96A73E354CAC88ED00C )
950
951 If redirection to the Service Provider's domain (via MX records, SRV
952 records, or any similar mechanism) is not possible and aliasing of
953 the TLSA record is not an option, then more complex coordination
954 between the Customer Domain and Service Provider will be required.
955 Either the Customer Domain periodically provides private keys and a
956 corresponding certificate chain to the provider (after making
957 appropriate changes in its TLSA records), or the Service Provider
958 periodically generates the keys and certificates and needs to wait
959 for matching TLSA records to be published by its Customer Domains
960 before deploying newly generated keys and certificate chains.
961 Section 7 below describes an approach that employs CNAME "chasing" to
962 avoid the difficulties of coordinating key management across
963 organizational boundaries.
964
965 For further information about combining DANE and SRV, please see
966 [RFC7673].
967
968 7. TLSA Base Domain and CNAMEs
969
970 When the application protocol does not support service location
971 indirection via MX, SRV, or similar DNS records, the service may be
972 redirected via a CNAME. A CNAME is a more blunt instrument for this
973 purpose because, unlike an MX or SRV record, it remaps the entire
974 origin domain to the target domain for all protocols.
975
976 The complexity of coordinating key management is largely eliminated
977 when DANE TLSA records are found in the Service Provider's domain, as
978 discussed in Section 6. Therefore, DANE TLS clients connecting to a
979 server whose domain name is a CNAME alias SHOULD follow the CNAME
980 "hop by hop" to its ultimate target host (noting at each step whether
981 or not the CNAME is DNSSEC validated). If at each stage of CNAME
982 expansion the DNSSEC validation status is "secure", the final target
983 name SHOULD be the preferred base domain for TLSA lookups.
984
985
986
987 Dukhovni & Hardaker Standards Track [Page 18]
988 RFC 7671 DANE Operations October 2015
989
990
991 Implementations failing to find a TLSA record using a base name of
992 the final target of a CNAME expansion SHOULD issue a TLSA query using
993 the original destination name. That is, the preferred TLSA base
994 domain SHOULD be derived from the fully expanded name and, failing
995 that, SHOULD be the initial domain name.
996
997 When the TLSA base domain is the result of "secure" CNAME expansion,
998 the resulting domain name MUST be used as the HostName in the
999 client's SNI extension and MUST be the primary reference identifier
1000 for peer certificate matching with certificate usages other than
1001 DANE-EE(3).
1002
1003 Protocol-specific TLSA specifications may provide additional guidance
1004 or restrictions when following CNAME expansions.
1005
1006 Though CNAMEs are illegal on the right-hand side of most indirection
1007 records, such as MX and SRV records, they are supported by some
1008 implementations. For example, if the MX or SRV host is a CNAME
1009 alias, some implementations may "chase" the CNAME. If they do, they
1010 SHOULD use the target hostname as the preferred TLSA base domain as
1011 described above (and, if the TLSA records are found there, also use
1012 the CNAME-expanded domain in SNI and certificate name checks).
1013
1014 8. TLSA Publisher Requirements
1015
1016 This section updates [RFC6698] by specifying that the TLSA Publisher
1017 MUST ensure that each combination of certificate usage, selector, and
1018 matching type in the server's TLSA RRset includes at least one record
1019 that matches the server's current certificate chain. TLSA records
1020 that match recently retired or yet-to-be-deployed certificate chains
1021 will be present during key rollover. Such past or future records
1022 MUST NOT at any time be the only records published for any given
1023 combination of usage, selector, and matching type. The TLSA record
1024 update process described below ensures that this requirement is met.
1025
1026 While a server is to be considered authenticated when its certificate
1027 chain is matched by any of the published TLSA records, not all
1028 clients support all combinations of TLSA record parameters. Some
1029 clients may not support some digest algorithms; others may either not
1030 support or exclusively support the PKIX certificate usages. Some
1031 clients may prefer to negotiate [RFC7250] raw public keys, which are
1032 only compatible with TLSA records whose certificate usage is
1033 DANE-EE(3) with selector SPKI(1). The only other TLSA record type
1034 that is potentially compatible with raw public keys is "DANE-EE(3)
1035 Cert(0) Full(0)", but support for raw public keys with that TLSA
1036 record type is not expected to be broadly implemented.
1037
1038
1039
1040
1041
1042 Dukhovni & Hardaker Standards Track [Page 19]
1043 RFC 7671 DANE Operations October 2015
1044
1045
1046 A consequence of the above uncertainty as to which TLSA parameters
1047 are supported by any given client is that servers need to ensure that
1048 each and every parameter combination that appears in the TLSA RRset
1049 is, on its own, sufficient to match the server's current certificate
1050 chain. In particular, when deploying new keys or new parameter
1051 combinations, some care is required to not generate parameter
1052 combinations that only match past or future certificate chains (or
1053 raw public keys). The rest of this section explains how to update
1054 the TLSA RRset in a manner that ensures that the above requirement
1055 is met.
1056
1057 8.1. Key Rollover with Fixed TLSA Parameters
1058
1059 The simplest case is key rollover while retaining the same set of
1060 published parameter combinations. In this case, TLSA records
1061 matching the existing server certificate chain (or raw public keys)
1062 are first augmented with corresponding records matching the future
1063 keys, at least two Times to Live (TTLs) or longer before the new
1064 chain is deployed. This allows the obsolete RRset to age out of
1065 client caches before the new chain is used in TLS handshakes. Once
1066 sufficient time has elapsed and all clients performing DNS lookups
1067 are retrieving the updated TLSA records, the server administrator may
1068 deploy the new certificate chain, verify that it works, and then
1069 remove any obsolete records matching the chain that is no longer
1070 active:
1071
1072 ; Initial TLSA RRset.
1073 ;
1074 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1075
1076 ; Transitional TLSA RRset published at least two TTLs before
1077 ; the actual key change.
1078 ;
1079 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1080 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
1081
1082 ; Final TLSA RRset after the key change.
1083 ;
1084 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097 Dukhovni & Hardaker Standards Track [Page 20]
1098 RFC 7671 DANE Operations October 2015
1099
1100
1101 The next case to consider is adding or switching to a new combination
1102 of TLSA parameters. In this case, publish the new parameter
1103 combinations for the server's existing certificate chain first, and
1104 only then deploy new keys if desired:
1105
1106 ; Initial TLSA RRset.
1107 ;
1108 _443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46...
1109
1110 ; New TLSA RRset, same key re-published as DANE-EE(3).
1111 ;
1112 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1113
1114 8.2. Switching to DANE-TA(2) from DANE-EE(3)
1115
1116 This section explains how to migrate to a new certificate chain and
1117 TLSA record with usage DANE-TA(2) from a self-signed server
1118 certificate and a "DANE-EE(3) SPKI(1) SHA2-256(1)" TLSA record. This
1119 example assumes that a new private key is generated in conjunction
1120 with transitioning to a new certificate issued by the desired TA.
1121
1122 The original "3 1 1" TLSA record supports [RFC7250] raw public keys,
1123 and clients may choose to negotiate their use. The use of raw public
1124 keys rules out the possibility of certificate chain verification.
1125 Therefore, the transitional TLSA record for the planned DANE-TA(2)
1126 certificate chain is a "3 1 1" record that works even when raw public
1127 keys are used. The TLSA RRset is updated to use DANE-TA(2) only
1128 after the new chain is deployed and the "3 1 1" record matching the
1129 original key is dropped.
1130
1131 This process follows the requirement that each combination of
1132 parameters present in the RRset is always sufficient to validate the
1133 server. It avoids publishing a transitional TLSA RRset in which
1134 "3 1 1" matches only the current key and "2 0 1" matches only the
1135 future certificate chain, because these might not work reliably
1136 during the initial deployment of the new keys.
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152 Dukhovni & Hardaker Standards Track [Page 21]
1153 RFC 7671 DANE Operations October 2015
1154
1155
1156 ; Initial TLSA RRset.
1157 ;
1158 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1159
1160 ; Transitional TLSA RRset, published at least two TTLs before the
1161 ; actual key change. The new keys are issued by a DANE-TA(2) CA
1162 ; but are initially specified via a DANE-EE(3) association.
1163 ;
1164 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1165 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
1166
1167 ; The final TLSA RRset after the key change. Now that the old
1168 ; self-signed EE key is out of the picture, publish the issuing
1169 ; TA of the new chain.
1170 ;
1171 _443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d...
1172
1173 8.3. Switching to New TLSA Parameters
1174
1175 When employing a new digest algorithm in the TLSA RRset, for
1176 compatibility with digest algorithm agility as specified in Section 9
1177 below, administrators SHOULD publish the new digest algorithm with
1178 each combination of certificate usage and selector for each
1179 associated key or chain used with any other digest algorithm. When
1180 removing an algorithm, remove it entirely. Each digest algorithm
1181 employed SHOULD match the same set of chains (or raw public keys).
1182
1183 ; Initial TLSA RRset with "DANE-EE(3) SHA2-256(1)" associations
1184 ; for two keys.
1185 ;
1186 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1187 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
1188
1189 ; New TLSA RRset, also with SHA2-512(2) associations
1190 ; for each key.
1191 ;
1192 _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
1193 _443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc...
1194 _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
1195 _443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714...
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207 Dukhovni & Hardaker Standards Track [Page 22]
1208 RFC 7671 DANE Operations October 2015
1209
1210
1211 8.4. TLSA Publisher Requirements: Summary
1212
1213 In summary, server operators updating TLSA records should make one
1214 change at a time. The individual safe changes are as follows:
1215
1216 o Pre-publish new certificate associations that employ the same TLSA
1217 parameters (usage, selector, and matching type) as existing TLSA
1218 records, but match certificate chains that will be deployed in the
1219 near future.
1220
1221 o Wait for stale TLSA RRsets to expire from DNS caches before
1222 configuring servers to use the new certificate chain.
1223
1224 o Remove TLSA records matching any certificate chains that are no
1225 longer deployed.
1226
1227 o Publish TLSA RRsets in which all parameter combinations
1228 (certificate usage, selector, and matching type) present in the
1229 RRset match the same set of current and planned certificate
1230 chains.
1231
1232 The above steps are intended to ensure that at all times, and for
1233 each combination of usage, selector, and matching type, at least one
1234 TLSA record corresponds to the server's current certificate chain.
1235 Each combination of certificate usage, selector, and matching type in
1236 a server's TLSA RRset SHOULD NOT at any time (including unexpired
1237 RRsets in client caches) match only some combination of future or
1238 past certificate chains. As a result, no matter what combinations of
1239 usage, selector, and matching type may be supported by a given
1240 client, they will be sufficient to authenticate the server.
1241
1242 9. Digest Algorithm Agility
1243
1244 While [RFC6698] specifies multiple digest algorithms, it does not
1245 specify a protocol by which the client and TLSA record publisher can
1246 agree on the strongest shared algorithm. Such a protocol would allow
1247 the client and server to avoid exposure to deprecated weaker
1248 algorithms that are published for compatibility with less capable
1249 clients but that SHOULD be avoided when possible. Such a protocol is
1250 specified below.
1251
1252 This section defines a protocol for avoiding deprecated digest
1253 algorithms when these are published in a peer's TLSA RRset alongside
1254 stronger digest algorithms. Note that this protocol never avoids RRs
1255 with a DANE matching type of Full(0), as these do not employ a digest
1256 algorithm that might someday be weakened by cryptanalysis.
1257
1258
1259
1260
1261
1262 Dukhovni & Hardaker Standards Track [Page 23]
1263 RFC 7671 DANE Operations October 2015
1264
1265
1266 Client implementations SHOULD implement a default order of digest
1267 algorithms by strength. This order SHOULD be configurable by the
1268 administrator or user of the client software. If possible, a
1269 configurable mapping from numeric DANE TLSA matching types to
1270 underlying digest algorithms provided by the cryptographic library
1271 SHOULD be implemented to allow new matching types to be used with
1272 software that predates their introduction. Configurable ordering of
1273 digest algorithms SHOULD be extensible to any new digest algorithms.
1274
1275 To make digest algorithm agility possible, all published DANE TLSA
1276 RRsets MUST conform to the requirements of Section 8. Clients SHOULD
1277 use digest algorithm agility when processing the peer's DANE TLSA
1278 records. Algorithm agility is to be applied after first discarding
1279 any unusable or malformed records (unsupported digest algorithm, or
1280 incorrect digest length). For each usage and selector, the client
1281 SHOULD process only any usable records with a matching type of
1282 Full(0) and the usable records whose digest algorithm is considered
1283 by the client to be the strongest among usable records with the given
1284 usage and selector.
1285
1286 Example: a client implements digest algorithm agility and prefers
1287 SHA2-512(2) over SHA2-256(1), while the server publishes an RRset
1288 that employs both digest algorithms as well as a Full(0) record.
1289
1290 _25._tcp.mail.example.com. IN TLSA 3 1 1 (
1291 3FE246A848798236DD2AB78D39F0651D
1292 6B6E7CA8E2984012EB0A2E1AC8A87B72 )
1293 _25._tcp.mail.example.com. IN TLSA 3 1 2 (
1294 D4F5AF015B46C5057B841C7E7BAB759C
1295 BF029526D29520C5BE6A32C67475439E
1296 54AB3A945D80C743347C9BD4DADC9D8D
1297 57FAB78EAA835362F3CA07CCC19A3214 )
1298 _25._tcp.mail.example.com. IN TLSA 3 1 0 (
1299 3059301306072A8648CE3D020106082A
1300 8648CE3D0301070342000471CB1F504F
1301 9E4B33971376C005445DACD33CD79A28
1302 81C3DED1981F18E7AAA76609DD0E4EF2
1303 8265C82703030AD60C5DBA6FB8A9397A
1304 C0FCF06D424C885D484887 )
1305
1306 In this case, the client SHOULD accept a server public key that
1307 matches either the "3 1 0" record or the "3 1 2" record, but it
1308 SHOULD NOT accept keys that match only the weaker "3 1 1" record.
1309
1310
1311
1312
1313
1314
1315
1316
1317 Dukhovni & Hardaker Standards Track [Page 24]
1318 RFC 7671 DANE Operations October 2015
1319
1320
1321 10. General DANE Guidelines
1322
1323 These guidelines provide guidance for using or designing protocols
1324 for DANE.
1325
1326 10.1. DANE DNS Record Size Guidelines
1327
1328 Selecting a combination of TLSA parameters to use requires careful
1329 thought. One important consideration to take into account is the
1330 size of the resulting TLSA record after its parameters are selected.
1331
1332 10.1.1. UDP and TCP Considerations
1333
1334 Deployments SHOULD avoid TLSA record sizes that cause UDP
1335 fragmentation.
1336
1337 Although DNS over TCP would provide the ability to more easily
1338 transfer larger DNS records between clients and servers, it is not
1339 universally deployed and is still prohibited by some firewalls.
1340 Clients that request DNS records via UDP typically only use TCP upon
1341 receipt of a truncated response in the DNS response message sent over
1342 UDP. Setting the Truncation (TC) bit (Section 4.1.1 of [RFC1035])
1343 alone will be insufficient if the response containing the TC bit is
1344 itself fragmented.
1345
1346 10.1.2. Packet Size Considerations for TLSA Parameters
1347
1348 Server operators SHOULD NOT publish TLSA records using both a TLSA
1349 selector of Cert(0) and a TLSA matching type of Full(0), as even a
1350 single certificate is generally too large to be reliably delivered
1351 via DNS over UDP. Furthermore, two TLSA records containing full
1352 certificates will need to be published simultaneously during a
1353 certificate rollover, as discussed in Section 8.1.
1354
1355 While TLSA records using a TLSA selector of SPKI(1) and a TLSA
1356 matching type of Full(0) (which publish the bare public keys, i.e.,
1357 without the overhead of encapsulating the keys in an X.509
1358 certificate) are generally more compact, these are also best avoided
1359 when significantly larger than their digests. Rather, servers SHOULD
1360 publish digest-based TLSA matching types in their TLSA records, in
1361 which case the complete corresponding certificate MUST be transmitted
1362 to the client in-band during the TLS handshake. The certificate (or
1363 raw public key) can be easily verified using the digest value.
1364
1365 In summary, the use of a TLSA matching type of Full(0) is
1366 NOT RECOMMENDED, and a digest-based matching type, such as
1367 SHA2-256(1), SHOULD be used instead.
1368
1369
1370
1371
1372 Dukhovni & Hardaker Standards Track [Page 25]
1373 RFC 7671 DANE Operations October 2015
1374
1375
1376 10.2. Certificate Name Check Conventions
1377
1378 Certificates presented by a TLS server will generally contain a
1379 subjectAltName (SAN) extension or a Common Name (CN) element within
1380 the subject Distinguished Name (DN). The TLS server's DNS domain
1381 name is normally published within these elements, ideally within the
1382 SAN extension. (The use of the CN field for this purpose is
1383 deprecated.)
1384
1385 When a server hosts multiple domains at the same transport endpoint,
1386 the server's ability to respond with the right certificate chain is
1387 predicated on correct SNI information from the client. DANE clients
1388 MUST send the SNI extension with a HostName value of the base domain
1389 of the TLSA RRset.
1390
1391 With the exception of TLSA certificate usage DANE-EE(3), where name
1392 checks are not applicable (see Section 5.1), DANE clients MUST verify
1393 that the client has reached the correct server by checking that the
1394 server name is listed in the server certificate's SAN or CN (when
1395 still supported). The primary server name used for this comparison
1396 MUST be the TLSA base domain; however, additional acceptable names
1397 may be specified by protocol-specific DANE standards. For example,
1398 with SMTP, both the destination domain name and the MX hostname are
1399 acceptable names to be found in the server certificate (see
1400 [RFC7672]).
1401
1402 It is the responsibility of the service operator, in coordination
1403 with the TLSA Publisher, to ensure that at least one of the TLSA
1404 records published for the service will match the server's certificate
1405 chain (either the default chain or the certificate that was selected
1406 based on the SNI information provided by the client).
1407
1408 Given the DNSSEC-validated DNS records below:
1409
1410 example.com. IN MX 0 mail.example.com.
1411 mail.example.com. IN A 192.0.2.1
1412 _25._tcp.mail.example.com. IN TLSA 2 0 1 (
1413 E8B54E0B4BAA815B06D3462D65FBC7C0
1414 CF556ECCF9F5303EBFBB77D022F834C0 )
1415
1416 The TLSA base domain is "mail.example.com" and is required to be the
1417 HostName in the client's SNI extension. The server certificate chain
1418 is required to be signed by a TA with the above certificate SHA2-256
1419 digest. Finally, one of the DNS names in the server certificate is
1420 required to be either "mail.example.com" or "example.com" (this
1421 additional name is a concession to compatibility with prior practice;
1422 see [RFC7672] for details).
1423
1424
1425
1426
1427 Dukhovni & Hardaker Standards Track [Page 26]
1428 RFC 7671 DANE Operations October 2015
1429
1430
1431 [RFC6125] specifies the semantics of wildcards in server certificates
1432 for various application protocols. DANE does not change how
1433 wildcards are treated by any given application.
1434
1435 10.3. Design Considerations for Protocols Using DANE
1436
1437 When a TLS client goes to the trouble of authenticating a certificate
1438 chain presented by a TLS server, it will typically not continue to
1439 use that server in the event of authentication failure, or else
1440 authentication serves no purpose. Some clients may, at times,
1441 operate in an "audit" mode, where authentication failure is reported
1442 to the user or in logs as a potential problem, but the connection
1443 proceeds despite the failure. Nevertheless, servers publishing TLSA
1444 records MUST be configured to allow correctly configured clients to
1445 successfully authenticate their TLS certificate chains.
1446
1447 A service with DNSSEC-validated TLSA records implicitly promises TLS
1448 support. When all the TLSA records for a service are found
1449 "unusable" due to unsupported parameter combinations or malformed
1450 certificate association data, DANE clients cannot authenticate the
1451 service certificate chain. When authenticated TLS is mandatory, the
1452 client MUST NOT connect to the associated server.
1453
1454 If, on the other hand, the use of TLS and DANE is "opportunistic"
1455 [RFC7435], then when all TLSA records are unusable, the client SHOULD
1456 connect to the server via an unauthenticated TLS connection, and if
1457 TLS encryption cannot be established, the client MUST NOT connect to
1458 the server.
1459
1460 Standards for opportunistic DANE TLS specific to a particular
1461 application protocol may modify the above requirements. The key
1462 consideration is whether or not mandating the use of
1463 (unauthenticated) TLS even with unusable TLSA records is asking for
1464 more security than one can realistically expect. If expecting TLS
1465 support when unusable TLSA records are published is realistic for the
1466 application in question, then the application MUST avoid cleartext.
1467 If not realistic, then mandating TLS would cause clients (even in the
1468 absence of active attacks) to run into problems with various peers
1469 that do not interoperate "securely enough". That would create strong
1470 incentives to just disable Opportunistic Security and stick with
1471 cleartext.
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482 Dukhovni & Hardaker Standards Track [Page 27]
1483 RFC 7671 DANE Operations October 2015
1484
1485
1486 11. Note on DNSSEC Security
1487
1488 Clearly, the security of the DANE TLSA PKI rests on the security of
1489 the underlying DNSSEC infrastructure. While this document is not a
1490 guide to DNSSEC security, a few comments may be helpful to TLSA
1491 implementers.
1492
1493 With the existing public CA Web PKI, name constraints are rarely
1494 used, and a public root CA can issue certificates for any domain of
1495 its choice. With DNSSEC, under the Registry/Registrar/Registrant
1496 model, the situation is different: only the registrar of record can
1497 update a domain's DS record [RFC4034] in the registry parent zone (in
1498 some cases, however, the registry is the sole registrar). With many
1499 Generic Top-Level Domains (gTLDs) for which multiple registrars
1500 compete to provide domains in a single registry, it is important to
1501 make sure that rogue registrars cannot easily initiate an
1502 unauthorized domain transfer and thus take over DNSSEC for the
1503 domain. DNS operators are advised to set a registrar lock on their
1504 domains to offer some protection against this possibility.
1505
1506 When the registrar is also the DNS operator for the domain, one needs
1507 to consider whether or not the registrar will allow orderly migration
1508 of the domain to another registrar or DNS operator in a way that will
1509 maintain DNSSEC integrity. TLSA Publishers are advised to seek out a
1510 DNS hosting registrar that makes it possible to transfer domains to
1511 another hosting provider without disabling DNSSEC.
1512
1513 DNSSEC-signed RRsets cannot be securely revoked before they expire.
1514 Operators need to plan accordingly and not generate signatures of
1515 excessively long duration. For domains publishing high-value keys, a
1516 signature lifetime (length of the "signature validity period" as
1517 described in Section 8.1 of [RFC4033]) of a few days is reasonable,
1518 and the zone can be re-signed daily. For domains with less critical
1519 data, a reasonable signature lifetime is a couple of weeks to a
1520 month, and the zone can be re-signed weekly.
1521
1522 Short signature lifetimes require tighter synchronization of primary
1523 and secondary nameservers, to make sure that secondary servers never
1524 serve records with expired signatures. They also limit the maximum
1525 time for which a primary server that signs the zone can be down.
1526 Therefore, short signature lifetimes are more appropriate for sites
1527 with dedicated operations staff, who can restore service quickly in
1528 case of a problem.
1529
1530 Monitoring is important. If a DNS zone is not re-signed in a timely
1531 manner, a major outage is likely, as the entire domain and all its
1532 sub-domains become "bogus".
1533
1534
1535
1536
1537 Dukhovni & Hardaker Standards Track [Page 28]
1538 RFC 7671 DANE Operations October 2015
1539
1540
1541 12. Summary of Updates to RFC 6698
1542
1543 o Section 3 updates [RFC6698] to specify a requirement for clients
1544 to support at least TLS 1.0 and to support SNI.
1545
1546 o Section 4 explains that application support for all four
1547 certificate usages is NOT RECOMMENDED. The recommended design is
1548 to support just DANE-EE(3) and DANE-TA(2).
1549
1550 o Section 5.1 updates [RFC6698] to specify that peer identity
1551 matching and validity period enforcement are based solely on the
1552 TLSA RRset properties. It also specifies DANE authentication of
1553 raw public keys [RFC7250] via TLSA records with certificate usage
1554 DANE-EE(3) and selector SPKI(1).
1555
1556 o Section 5.2 updates [RFC6698] to require that servers publishing
1557 digest TLSA records with a usage of DANE-TA(2) MUST include the
1558 TA certificate in their TLS server certificate message. This
1559 extends to the case of "2 1 0" TLSA records that publish a full
1560 public key.
1561
1562 o Section 5.4 observes that with usage PKIX-TA(0), clients may need
1563 to process extended trust chains beyond the first trusted issuer
1564 when that issuer is not self-signed.
1565
1566 o Section 7 recommends that DANE application protocols specify that,
1567 when possible, securely CNAME-expanded names be used to derive the
1568 TLSA base domain.
1569
1570 o Section 8 specifies a strategy for managing TLSA records that
1571 interoperates with DANE clients regardless of what subset of the
1572 possible TLSA record types (combinations of TLSA parameters) is
1573 supported by the client.
1574
1575 o Section 9 specifies a digest algorithm agility protocol.
1576
1577 o Section 10.1 recommends against the use of Full(0) TLSA records,
1578 as digest records are generally much more compact.
1579
1580 13. Operational Considerations
1581
1582 The DNS TTL of TLSA records needs to be chosen with care. When an
1583 unplanned change in the server's certificate chain and TLSA RRset is
1584 required, such as when keys are compromised or lost, clients that
1585 cache stale TLSA records will fail to validate the certificate chain
1586 of the updated server. Publish TLSA RRsets with TTLs that are short
1587 enough to limit unplanned service disruption to an acceptable
1588 duration.
1589
1590
1591
1592 Dukhovni & Hardaker Standards Track [Page 29]
1593 RFC 7671 DANE Operations October 2015
1594
1595
1596 The signature lifetime (length of the signature validity period) for
1597 TLSA records SHOULD NOT be too long. Signed DNSSEC records can be
1598 replayed by an MITM attacker, provided the signatures have not yet
1599 expired. Shorter signature validity periods allow for faster
1600 invalidation of compromised keys. Zone refresh and expiration times
1601 for secondary nameservers often imply a lower bound on the signature
1602 validity period (Section 11). See Section 4.4.1 of [RFC6781].
1603
1604 14. Security Considerations
1605
1606 Application protocols that cannot use the existing public CA Web PKI
1607 may choose to not implement certain TLSA record types defined in
1608 [RFC6698]. If such records are published despite not being supported
1609 by the application protocol, they are treated as "unusable". When
1610 TLS is opportunistic, the client MAY proceed to use the server with
1611 mandatory unauthenticated TLS. This is stronger than opportunistic
1612 TLS without DANE, since in that case the client may also proceed with
1613 a cleartext connection. When TLS is not opportunistic, the client
1614 MUST NOT connect to the server.
1615
1616 Thus, when TLSA records are used with opportunistic protocols where
1617 PKIX-TA(0) and PKIX-EE(1) do not apply, the recommended protocol
1618 design is for servers to not publish such TLSA records, and for
1619 opportunistic TLS clients to use them to only enforce the use of
1620 (albeit unauthenticated) TLS but otherwise treat them as unusable.
1621 Of course, when PKIX-TA(0) and PKIX-EE(1) are supported by the
1622 application protocol, clients MUST implement these certificate usages
1623 as described in [RFC6698] and this document.
1624
1625 15. References
1626
1627 15.1. Normative References
1628
1629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1630 Requirement Levels", BCP 14, RFC 2119,
1631 DOI 10.17487/RFC2119, March 1997,
1632 <http://www.rfc-editor.org/info/rfc2119>.
1633
1634 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1635 Rose, "DNS Security Introduction and Requirements",
1636 RFC 4033, DOI 10.17487/RFC4033, March 2005,
1637 <http://www.rfc-editor.org/info/rfc4033>.
1638
1639 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1640 Rose, "Resource Records for the DNS Security Extensions",
1641 RFC 4034, DOI 10.17487/RFC4034, March 2005,
1642 <http://www.rfc-editor.org/info/rfc4034>.
1643
1644
1645
1646
1647 Dukhovni & Hardaker Standards Track [Page 30]
1648 RFC 7671 DANE Operations October 2015
1649
1650
1651 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1652 Rose, "Protocol Modifications for the DNS Security
1653 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
1654 <http://www.rfc-editor.org/info/rfc4035>.
1655
1656 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1657 (TLS) Protocol Version 1.2", RFC 5246,
1658 DOI 10.17487/RFC5246, August 2008,
1659 <http://www.rfc-editor.org/info/rfc5246>.
1660
1661 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1662 Housley, R., and W. Polk, "Internet X.509 Public Key
1663 Infrastructure Certificate and Certificate Revocation List
1664 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
1665 <http://www.rfc-editor.org/info/rfc5280>.
1666
1667 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
1668 Extensions: Extension Definitions", RFC 6066,
1669 DOI 10.17487/RFC6066, January 2011,
1670 <http://www.rfc-editor.org/info/rfc6066>.
1671
1672 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
1673 Verification of Domain-Based Application Service Identity
1674 within Internet Public Key Infrastructure Using X.509
1675 (PKIX) Certificates in the Context of Transport Layer
1676 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125,
1677 March 2011, <http://www.rfc-editor.org/info/rfc6125>.
1678
1679 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
1680 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
1681 January 2012, <http://www.rfc-editor.org/info/rfc6347>.
1682
1683 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
1684 of Named Entities (DANE) Transport Layer Security (TLS)
1685 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698,
1686 August 2012, <http://www.rfc-editor.org/info/rfc6698>.
1687
1688 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
1689 Conversations about DNS-Based Authentication of Named
1690 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218,
1691 April 2014, <http://www.rfc-editor.org/info/rfc7218>.
1692
1693 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
1694 Weiler, S., and T. Kivinen, "Using Raw Public Keys in
1695 Transport Layer Security (TLS) and Datagram Transport
1696 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
1697 June 2014, <http://www.rfc-editor.org/info/rfc7250>.
1698
1699
1700
1701
1702 Dukhovni & Hardaker Standards Track [Page 31]
1703 RFC 7671 DANE Operations October 2015
1704
1705
1706 15.2. Informative References
1707
1708 [RFC1035] Mockapetris, P., "Domain names - implementation and
1709 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
1710 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
1711
1712 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
1713 Operational Practices, Version 2", RFC 6781,
1714 DOI 10.17487/RFC6781, December 2012,
1715 <http://www.rfc-editor.org/info/rfc6781>.
1716
1717 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
1718 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
1719 <http://www.rfc-editor.org/info/rfc6962>.
1720
1721 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
1722 Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
1723 December 2014, <http://www.rfc-editor.org/info/rfc7435>.
1724
1725 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
1726 Opportunistic DNS-Based Authentication of Named Entities
1727 (DANE) Transport Layer Security (TLS)", RFC 7672,
1728 DOI 10.17487/RFC7672, October 2015,
1729 <http://www.rfc-editor.org/info/rfc7672>.
1730
1731 [RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using
1732 DNS-Based Authentication of Named Entities (DANE) TLSA
1733 Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673,
1734 October 2015, <http://www.rfc-editor.org/info/rfc7673>.
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757 Dukhovni & Hardaker Standards Track [Page 32]
1758 RFC 7671 DANE Operations October 2015
1759
1760
1761 Acknowledgements
1762
1763 The authors would like to thank Phil Pennock for his comments and
1764 advice on this document.
1765
1766 Acknowledgements from Viktor: Thanks to Tony Finch, who finally
1767 prodded me into participating in DANE working group discussions.
1768 Thanks to Paul Hoffman, who motivated me to produce this document and
1769 provided feedback on early draft versions of it. Thanks also to
1770 Samuel Dukhovni for editorial assistance.
1771
1772 Authors' Addresses
1773
1774 Viktor Dukhovni
1775 Two Sigma
1776
1777 Email: ietf-dane@dukhovni.org
1778
1779
1780 Wes Hardaker
1781 Parsons
1782 P.O. Box 382
1783 Davis, CA 95617
1784 United States
1785
1786 Email: ietf@hardakers.net
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812 Dukhovni & Hardaker Standards Track [Page 33]
1813
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.