1 Internet Engineering Task Force (IETF) T. Finch
2 Request for Comments: 7673 University of Cambridge
3 Category: Standards Track M. Miller
4 ISSN: 2070-1721 Cisco Systems, Inc.
5 P. Saint-Andre
6 &yet
7 October 2015
8
9
10 Using DNS-Based Authentication of Named Entities (DANE)
11 TLSA Records with SRV Records
12
13 Abstract
14
15 The DNS-Based Authentication of Named Entities (DANE) specification
16 (RFC 6698) describes how to use TLSA resource records secured by
17 DNSSEC (RFC 4033) to associate a server's connection endpoint with
18 its Transport Layer Security (TLS) certificate (thus enabling
19 administrators of domain names to specify the keys used in that
20 domain's TLS servers). However, application protocols that use SRV
21 records (RFC 2782) to indirectly name the target server connection
22 endpoints for a service domain name cannot apply the rules from RFC
23 6698. Therefore, this document provides guidelines that enable such
24 protocols to locate and use TLSA records.
25
26 Status of This Memo
27
28 This is an Internet Standards Track document.
29
30 This document is a product of the Internet Engineering Task Force
31 (IETF). It represents the consensus of the IETF community. It has
32 received public review and has been approved for publication by the
33 Internet Engineering Steering Group (IESG). Further information on
34 Internet Standards is available in Section 2 of RFC 5741.
35
36 Information about the current status of this document, any errata,
37 and how to provide feedback on it may be obtained at
38 http://www.rfc-editor.org/info/rfc7673.
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Finch, et al. Standards Track [Page 1]
53 RFC 7673 TLSA and SRV October 2015
54
55
56 Copyright Notice
57
58 Copyright (c) 2015 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 Table of Contents
72
73 1. Introduction ....................................................3
74 2. Terminology .....................................................4
75 3. DNS Checks ......................................................4
76 3.1. SRV Query ..................................................4
77 3.2. Address Queries ............................................5
78 3.3. TLSA Queries ...............................................6
79 3.4. Impact on TLS Usage ........................................6
80 4. TLS Checks ......................................................7
81 4.1. SRV Records Only ...........................................7
82 4.2. TLSA Records ...............................................8
83 5. Guidance for Protocol Authors ...................................8
84 6. Guidance for Server Operators ...................................8
85 7. Guidance for Application Developers .............................9
86 8. Internationalization Considerations .............................9
87 9. Security Considerations ........................................10
88 9.1. Mixed Security Status .....................................10
89 9.2. Certificate Subject Name Matching .........................10
90 10. References ....................................................11
91 10.1. Normative References .....................................11
92 10.2. Informative References ...................................12
93 Appendix A. Examples ..............................................13
94 A.1. IMAP .......................................................13
95 A.2. XMPP .......................................................13
96 Appendix B. Rationale .............................................14
97 Acknowledgements ..................................................15
98 Authors' Addresses ................................................16
99
100
101
102
103
104
105
106
107 Finch, et al. Standards Track [Page 2]
108 RFC 7673 TLSA and SRV October 2015
109
110
111 1. Introduction
112
113 The base DNS-Based Authentication of Named Entities (DANE)
114 specification [RFC6698] describes how to use TLSA resource records
115 secured by DNSSEC [RFC4033] to associate a target server's connection
116 endpoint with its Transport Layer Security (TLS) certificate (thus
117 enabling administrators of domain names to specify the keys used in
118 that domain's TLS servers). Some application protocols locate
119 connection endpoints indirectly via SRV records [RFC2782]. As a
120 result of this indirection, the rules specified in [RFC6698] cannot
121 be directly applied to such application protocols. (Rules for SMTP
122 [RFC5321], which uses MX resource records instead of SRV records, are
123 described in [RFC7672].)
124
125 This document describes how to use DANE TLSA records with SRV
126 records. To summarize:
127
128 o We rely on DNSSEC to secure SRV records that map the desired
129 service, transport protocol, and service domain name to the
130 corresponding target server connection endpoints (i.e., the target
131 server hostnames and port numbers returned in the SRV records for
132 that service type).
133
134 o Although in accordance with [RFC2782] a service domain name can
135 advertise a number of SRV records (some of which might map to
136 connection endpoints that do not support TLS), the intent of this
137 specification is for a client to securely discover connection
138 endpoints that support TLS.
139
140 o The TLSA records for each connection endpoint are located using
141 the transport protocol, port number, and hostname for the target
142 server (not the service domain name).
143
144 o When DNSSEC-validated TLSA records are published for a given
145 connection endpoint, clients always use TLS when connecting (even
146 if the connection endpoint supports cleartext communication).
147
148 o If there is at least one usable TLSA record for a given connection
149 endpoint, the connection endpoint's TLS certificate or public key
150 needs to match at least one of those usable TLSA records.
151
152 o If there are no usable TLSA records for a given connection
153 endpoint, the target server hostname is used as one of the
154 acceptable reference identifiers, as described in [RFC6125].
155 Other reference identifiers might arise through CNAME expansion of
156 either the service domain name or target server hostname, as
157 detailed in [RFC7671].
158
159
160
161
162 Finch, et al. Standards Track [Page 3]
163 RFC 7673 TLSA and SRV October 2015
164
165
166 o If there are no usable TLSA records for any connection endpoint
167 (and thus the client cannot securely discover a connection
168 endpoint that supports TLS), the client's behavior is a matter for
169 the application protocol or client implementation; this might
170 involve a fallback to non-DANE behavior using the public key
171 infrastructure [RFC5280].
172
173 2. Terminology
174
175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
177 "OPTIONAL" in this memo are to be interpreted as described in
178 [RFC2119].
179
180 This document uses the definitions for "secure", "insecure", "bogus",
181 and "indeterminate" from Section 4.3 of [RFC4035]. This document
182 uses the acronyms from [RFC7218] for the values of TLSA fields where
183 appropriate.
184
185 Additionally, this document uses the following terms:
186
187 connection endpoint: A tuple of a fully qualified DNS hostname,
188 transport protocol, and port number that a client uses to
189 establish a connection to the target server.
190
191 service domain name: The fully qualified DNS domain name that
192 identifies an application service; corresponds to the term "source
193 domain" from [RFC6125].
194
195 This document uses the term "target server hostname" in place of the
196 term "derived domain" from the so-called CertID specification
197 [RFC6125].
198
199 3. DNS Checks
200
201 3.1. SRV Query
202
203 When the client makes an SRV query, a successful result will
204 typically be a list of one or more SRV records (or possibly a chain
205 of CNAME/DNAME aliases leading to such a list).
206
207 NOTE: Implementers need to be aware that unsuccessful results can
208 occur because of various DNS-related errors; guidance on avoiding
209 downgrade attacks can be found in Section 2.1 of [RFC7672].
210
211
212
213
214
215
216
217 Finch, et al. Standards Track [Page 4]
218 RFC 7673 TLSA and SRV October 2015
219
220
221 For this specification to apply, the entire chain of DNS RRset(s)
222 returned MUST be "secure" according to DNSSEC validation (Section 5
223 of [RFC4035]). In the case where the answer is obtained via a chain
224 of CNAME and/or DNAME aliases, the whole chain of CNAME and DNAME
225 RRsets MUST also be secure.
226
227 If the SRV lookup fails because the RRset is "bogus" (or the lookup
228 fails for reasons other than no records), the client MUST abort its
229 attempt to connect to the desired service. If the lookup result is
230 "insecure" (or no SRV records exist), this protocol does not apply
231 and the client SHOULD fall back to its non-DNSSEC, non-DANE (and
232 possibly non-SRV) behavior.
233
234 When the lookup returns a "secure" RRset (possibly via a chain of
235 "secure" CNAME/DNAME records), the client now has an authentic list
236 of target server connection endpoints with weight and priority
237 values. It performs server ordering and selection using the weight
238 and priority values without regard to the presence or absence of
239 DNSSEC or TLSA records. It also takes note of the DNSSEC validation
240 status of the SRV response for use when checking certificate names
241 (see Section 4). The client can then proceed to making address
242 queries on the target server hostnames as described in the following
243 section.
244
245 3.2. Address Queries
246
247 For each SRV target server connection endpoint, the client makes
248 A and/or AAAA queries, performs DNSSEC validation on the address
249 (A or AAAA) response, and continues as follows, based on the results:
250
251 o If a returned RRSet is "secure", the client MUST perform a TLSA
252 query for that target server connection endpoint, as described in
253 the next section.
254
255 o If no returned RRsets are "secure", the client MUST NOT perform a
256 TLSA query for that target server connection endpoint; the TLSA
257 query will most likely fail or produce spurious results.
258
259 o If the address record lookup fails (a validation status of either
260 "bogus" or "indeterminate"), the client MUST NOT connect to this
261 connection endpoint; instead, it uses the next most appropriate
262 SRV target. This helps prevent downgrade attacks.
263
264
265
266
267
268
269
270
271
272 Finch, et al. Standards Track [Page 5]
273 RFC 7673 TLSA and SRV October 2015
274
275
276 3.3. TLSA Queries
277
278 The client SHALL construct the TLSA query name as described in
279 Section 3 of [RFC6698], based on the fields from the SRV record: the
280 port number from the SRV RDATA, the transport protocol from the SRV
281 query name, and the TLSA base domain from the SRV target server
282 hostname.
283
284 For example, the following SRV record for IMAP (see [RFC6186])
285
286 _imap._tcp.example.com. 86400 IN SRV 10 0 9143 imap.example.net.
287
288 leads to the TLSA query shown below:
289
290 _9143._tcp.imap.example.net. IN TLSA ?
291
292 3.4. Impact on TLS Usage
293
294 The client SHALL determine if the TLSA records returned in the
295 previous step are usable according to Section 4.1 of [RFC6698]. This
296 affects the use of TLS as follows:
297
298 o If the TLSA response is "secure" and usable, then the client MUST
299 use TLS when connecting to the target server. The TLSA records
300 are used when validating the server's certificate as described in
301 Section 4.
302
303 o If the TLSA response is "bogus" or "indeterminate" (or the lookup
304 fails for reasons other than no records), then the client MUST NOT
305 connect to the target server (the client can still use other SRV
306 targets).
307
308 o If the TLSA response is "insecure" (or no TLSA records exist),
309 then the client SHALL proceed as if the target server had no TLSA
310 records. It MAY connect to the target server with or without TLS,
311 subject to the policies of the application protocol or client
312 implementation.
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327 Finch, et al. Standards Track [Page 6]
328 RFC 7673 TLSA and SRV October 2015
329
330
331 4. TLS Checks
332
333 When connecting to a server, the client MUST use TLS if the responses
334 to the SRV and TLSA queries were "secure" as described above. The
335 rules described in the next two sections -- Section 4.2 for cases
336 where there is at least one usable TLSA record, and Section 4.1
337 otherwise -- apply to such secure responses.
338
339 4.1. SRV Records Only
340
341 If the client received zero usable TLSA certificate associations, it
342 SHALL validate the server's TLS certificate using the normal PKIX
343 rules [RFC5280] or protocol-specific rules (e.g., following
344 [RFC6125]) without further input from the TLSA records. In this
345 case, the client uses the information in the server certificate and
346 the DNSSEC validation status of the SRV query in its authentication
347 checks. It SHOULD use the Server Name Indication extension (TLS SNI)
348 [RFC6066] or its functional equivalent in the relevant application
349 protocol (e.g., in the Extensible Messaging and Presence Protocol
350 (XMPP) [RFC6120], this is the 'to' address of the initial stream
351 header). The preferred name SHALL be chosen as follows, and the
352 client SHALL verify the identity asserted by the server's certificate
353 according to Section 6 of [RFC6125], using a list of reference
354 identifiers constructed as follows (note again that in RFC 6125 the
355 terms "source domain" and "derived domain" refer to the same things
356 as "service domain name" and "target server hostname" in this
357 document). The examples below assume a service domain name of
358 "im.example.com" and a target server hostname of
359 "xmpp23.hosting.example.net".
360
361 SRV is insecure: The reference identifiers SHALL include the service
362 domain name and MUST NOT include the SRV target server hostname
363 (e.g., include "im.example.com" but not
364 "xmpp23.hosting.example.net"). The service domain name is the
365 preferred name for TLS SNI or its equivalent.
366
367 SRV is secure: The reference identifiers SHALL include both the
368 service domain name and the SRV target server hostname (e.g.,
369 include both "im.example.com" and "xmpp23.hosting.example.net").
370 The service domain name is still the preferred name for TLS SNI or
371 its equivalent (this reduces code complexity and the possibility
372 of interoperability problems).
373
374 In the latter case, the client will accept either identity to ensure
375 compatibility with servers that support this specification as well as
376 servers that do not support this specification.
377
378
379
380
381
382 Finch, et al. Standards Track [Page 7]
383 RFC 7673 TLSA and SRV October 2015
384
385
386 4.2. TLSA Records
387
388 If the client received one or more usable TLSA certificate
389 associations, it SHALL process them as described in Section 2.1 of
390 [RFC6698].
391
392 If the TLS server's certificate -- or the public key of the server's
393 certificate -- matches a usable TLSA record with certificate usage
394 DANE-EE, the client MUST ignore validation checks from [RFC5280] and
395 reference identifier checks from [RFC6125]. The information in such
396 a TLSA record supersedes the non-key information in the certificate.
397
398 5. Guidance for Protocol Authors
399
400 This document describes how to use DANE with application protocols in
401 which target servers are discovered via SRV records. Although this
402 document attempts to provide generic guidance applying to all such
403 protocols, additional documents for particular application protocols
404 could cover related topics, such as:
405
406 o Fallback logic in the event that a client is unable to connect
407 securely to a target server by following the procedures defined in
408 this document.
409
410 o How clients ought to behave if (1) they do not support SRV lookups
411 or (2) they do support SRV lookups and encounter service domain
412 names that do not offer SRV records.
413
414 o Whether or not the application protocol has a functional
415 equivalent for TLS SNI that is preferred within that protocol.
416
417 o The use of SRV records with additional discovery technologies,
418 such as the use of both SRV records and NAPTR records [RFC3403]
419 for transport selection in the Session Initiation Protocol (SIP).
420
421 For example, [XMPP-DNA] covers such topics for XMPP.
422
423 6. Guidance for Server Operators
424
425 To conform to this specification, the published SRV records and
426 subsequent address (A and AAAA) records MUST be secured with DNSSEC.
427 There SHOULD also be at least one TLSA record published that
428 authenticates the server's certificate.
429
430 When using TLSA records with certificate usage DANE-EE, it is not
431 necessary for the deployed certificate to contain an identifier for
432 either the source domain or target server hostname. However,
433 operators need to be aware that servers relying solely on validation
434
435
436
437 Finch, et al. Standards Track [Page 8]
438 RFC 7673 TLSA and SRV October 2015
439
440
441 using certificate usage DANE-EE TLSA records might prevent clients
442 that do not support this specification from successfully connecting
443 with TLS.
444
445 For TLSA records with certificate usage types other than DANE-EE, the
446 certificate(s) MUST contain an identifier that matches:
447
448 o the service domain name (the "source domain" in [RFC6125] terms,
449 which is the SRV query domain), and/or
450
451 o the target server hostname (the "derived domain" in [RFC6125]
452 terms, which is the SRV target hostname).
453
454 Servers that support multiple service domain names (i.e., so-called
455 "multi-tenanted environments") can implement TLS SNI [RFC6066] or its
456 functional equivalent to determine which certificate to offer.
457 Clients that do not support this specification will indicate a
458 preference for the service domain name, while clients that support
459 this specification will indicate the target server hostname.
460 However, the server determines what certificate to present in the TLS
461 handshake; e.g., the presented certificate might only authenticate
462 the target server hostname.
463
464 7. Guidance for Application Developers
465
466 Developers of application clients that depend on DANE-SRV often would
467 like to prepare as quickly as possible for making a connection to the
468 intended service, thus reducing the wait time for end users. To make
469 this optimization possible, a DNS library might perform the address
470 queries and TLSA queries in parallel. (Because a TLSA record can be
471 ignored if it turns out that the address record on which it depends
472 is not secure, performing the TLSA queries in parallel with the
473 address queries is not harmful from a security perspective and can
474 yield some operational benefits.)
475
476 8. Internationalization Considerations
477
478 If any of the DNS queries are for an internationalized domain name,
479 then they need to use the A-label form [RFC5890].
480
481
482
483
484
485
486
487
488
489
490
491
492 Finch, et al. Standards Track [Page 9]
493 RFC 7673 TLSA and SRV October 2015
494
495
496 9. Security Considerations
497
498 9.1. Mixed Security Status
499
500 We do not specify that all of the target server connection endpoints
501 for a service domain name need to be consistent in whether they have
502 or do not have TLSA records. This is so that partial or incremental
503 deployment does not break the service. Different levels of
504 deployment are likely if a service domain name has a third-party
505 fallback server, for example.
506
507 The SRV sorting rules are unchanged; in particular, they have not
508 been altered in order to prioritize secure connection endpoints over
509 insecure connection endpoints. If a site wants to be secure, it
510 needs to deploy this protocol completely; a partial deployment is not
511 secure, and we make no special effort to support it.
512
513 9.2. Certificate Subject Name Matching
514
515 Section 4 of the TLSA specification [RFC6698] leaves the details of
516 checking names in certificates to higher-level application protocols,
517 though it suggests the use of [RFC6125].
518
519 Name checks are not necessary if the matching TLSA record is of
520 certificate usage DANE-EE. Because such a record identifies the
521 specific certificate (or public key of the certificate), additional
522 checks are superfluous and potentially conflicting.
523
524 Otherwise, while DNSSEC provides a secure binding between the server
525 name and the TLSA record, and the TLSA record provides a binding to a
526 certificate, this latter step can be indirect via a chain of
527 certificates. For example, a certificate usage PKIX-TA TLSA record
528 only authenticates the Certification Authority (CA) that issued the
529 certificate, and third parties can obtain certificates from the same
530 CA. Therefore, clients need to check to see whether or not the
531 server's certificate matches one of the expected reference
532 identifiers to ensure that the certificate was issued by the CA to
533 the server the client expects (naturally, this is in addition to
534 standard certificate-related checks as specified in [RFC5280],
535 including but not limited to certificate syntax, certificate
536 extensions such as name constraints and extended key usage, and
537 handling of certification paths).
538
539
540
541
542
543
544
545
546
547 Finch, et al. Standards Track [Page 10]
548 RFC 7673 TLSA and SRV October 2015
549
550
551 10. References
552
553 10.1. Normative References
554
555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
556 Requirement Levels", BCP 14, RFC 2119,
557 DOI 10.17487/RFC2119, March 1997,
558 <http://www.rfc-editor.org/info/rfc2119>.
559
560 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
561 specifying the location of services (DNS SRV)", RFC 2782,
562 DOI 10.17487/RFC2782, February 2000,
563 <http://www.rfc-editor.org/info/rfc2782>.
564
565 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
566 Rose, "DNS Security Introduction and Requirements",
567 RFC 4033, DOI 10.17487/RFC4033, March 2005,
568 <http://www.rfc-editor.org/info/rfc4033>.
569
570 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
571 Rose, "Protocol Modifications for the DNS Security
572 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
573 <http://www.rfc-editor.org/info/rfc4035>.
574
575 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
576 Housley, R., and W. Polk, "Internet X.509 Public Key
577 Infrastructure Certificate and Certificate Revocation List
578 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
579 <http://www.rfc-editor.org/info/rfc5280>.
580
581 [RFC5890] Klensin, J., "Internationalized Domain Names for
582 Applications (IDNA): Definitions and Document Framework",
583 RFC 5890, DOI 10.17487/RFC5890, August 2010,
584 <http://www.rfc-editor.org/info/rfc5890>.
585
586 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
587 Extensions: Extension Definitions", RFC 6066,
588 DOI 10.17487/RFC6066, January 2011,
589 <http://www.rfc-editor.org/info/rfc6066>.
590
591 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
592 Verification of Domain-Based Application Service Identity
593 within Internet Public Key Infrastructure Using X.509
594 (PKIX) Certificates in the Context of Transport Layer
595 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125,
596 March 2011, <http://www.rfc-editor.org/info/rfc6125>.
597
598
599
600
601
602 Finch, et al. Standards Track [Page 11]
603 RFC 7673 TLSA and SRV October 2015
604
605
606 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
607 of Named Entities (DANE) Transport Layer Security (TLS)
608 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698,
609 August 2012, <http://www.rfc-editor.org/info/rfc6698>.
610
611 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify
612 Conversations about DNS-Based Authentication of Named
613 Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218,
614 April 2014, <http://www.rfc-editor.org/info/rfc7218>.
615
616 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based
617 Authentication of Named Entities (DANE) Protocol: Updates
618 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
619 October 2015, <http://www.rfc-editor.org/info/rfc7671>.
620
621 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
622 Opportunistic DNS-Based Authentication of Named Entities
623 (DANE) Transport Layer Security (TLS)", RFC 7672,
624 DOI 10.17487/RFC7672, October 2015,
625 <http://www.rfc-editor.org/info/rfc7672>.
626
627 10.2. Informative References
628
629 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
630 Part Three: The Domain Name System (DNS) Database",
631 RFC 3403, DOI 10.17487/RFC3403, October 2002,
632 <http://www.rfc-editor.org/info/rfc3403>.
633
634 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
635 DOI 10.17487/RFC5321, October 2008,
636 <http://www.rfc-editor.org/info/rfc5321>.
637
638 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
639 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
640 March 2011, <http://www.rfc-editor.org/info/rfc6120>.
641
642 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email
643 Submission/Access Services", RFC 6186,
644 DOI 10.17487/RFC6186, March 2011,
645 <http://www.rfc-editor.org/info/rfc6186>.
646
647 [XMPP-DNA] Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name
648 Associations (DNA) in the Extensible Messaging and
649 Presence Protocol (XMPP)", Work in Progress,
650 draft-ietf-xmpp-dna-11, September 2015.
651
652
653
654
655
656
657 Finch, et al. Standards Track [Page 12]
658 RFC 7673 TLSA and SRV October 2015
659
660
661 Appendix A. Examples
662
663 In the following, most of the DNS resource data is elided for
664 simplicity.
665
666 A.1. IMAP
667
668 ; mail domain
669 _imap._tcp.example.com. SRV 10 0 9143 imap.example.net.
670 example.com. RRSIG SRV ...
671
672 ; target server hostname
673 imap.example.net. A 192.0.2.1
674 imap.example.net. RRSIG A ...
675
676 imap.example.net. AAAA 2001:db8:212:8::e:1
677 imap.example.net. RRSIG ...
678
679 ; TLSA resource record
680 _9143._tcp.imap.example.net. TLSA ...
681 _9143._tcp.imap.example.net. RRSIG TLSA ...
682
683 Mail messages received for addresses at example.com are retrieved via
684 IMAP at imap.example.net. Connections to imap.example.net port 9143
685 that use STARTTLS will get a server certificate that authenticates
686 the name imap.example.net.
687
688 A.2. XMPP
689
690 ; XMPP domain
691 _xmpp-client._tcp.example.com. SRV 1 0 5222 im.example.net.
692 _xmpp-client._tcp.example.com. RRSIG SRV ...
693
694 ; target server hostname
695 im.example.net. A 192.0.2.3
696 im.example.net. RRSIG A ...
697
698 im.example.net. AAAA 2001:db8:212:8::e:4
699 im.example.net. RRSIG AAAA ...
700
701 ; TLSA resource record
702 _5222._tcp.im.example.net. TLSA ...
703 _5222._tcp.im.example.net. RRSIG TLSA ...
704
705 XMPP sessions for addresses at example.com are established at
706 im.example.net. Connections to im.example.net port 5222 that use
707 STARTTLS will get a server certificate that authenticates the name
708 im.example.net.
709
710
711
712 Finch, et al. Standards Track [Page 13]
713 RFC 7673 TLSA and SRV October 2015
714
715
716 Appendix B. Rationale
717
718 The long-term goal of this specification is to settle on TLS
719 certificates that verify the target server hostname rather than the
720 service domain name, since this is more convenient for servers
721 hosting multiple domains (so-called "multi-tenanted environments")
722 and scales up more easily to larger numbers of service domain names.
723
724 There are a number of other reasons for doing it this way:
725
726 o The certificate is part of the server configuration, so it makes
727 sense to associate it with the target server hostname rather than
728 the service domain name.
729
730 o In the absence of TLS SNI, if the certificate identifies the
731 target server hostname, then it does not need to list all the
732 possible service domain names.
733
734 o When the server certificate is replaced, it is much easier if
735 there is one part of the DNS that needs updating to match, instead
736 of an unbounded number of hosted service domain names.
737
738 o The same TLSA records work with this specification, and with
739 direct connections to the connection endpoint in the style of
740 [RFC6698].
741
742 o Some application protocols, such as SMTP, allow a client to
743 perform transactions with multiple service domain names in the
744 same connection. It is not, in general, feasible for the client
745 to specify the service domain name using TLS SNI when the
746 connection is established, and the server might not be able to
747 present a certificate that authenticates all possible service
748 domain names. See [RFC7672] for details.
749
750 o It is common for SMTP servers to act in multiple roles -- for
751 example, as outgoing relays or as incoming MX servers, depending
752 on the client identity. It is simpler if the server can present
753 the same certificate regardless of the role in which it is to act.
754 Sometimes the server does not know its role until the client has
755 authenticated, which usually occurs after TLS has been
756 established. See [RFC7672] for details.
757
758
759
760
761
762
763
764
765
766
767 Finch, et al. Standards Track [Page 14]
768 RFC 7673 TLSA and SRV October 2015
769
770
771 This specification does not provide an option to put TLSA records
772 under the service domain name, because that would add complexity
773 without providing any benefit; security protocols are best kept
774 simple. As described above, there are real-world cases where
775 authenticating the service domain name cannot be made to work, so
776 there would be complicated criteria regarding when service domain
777 name TLSA records might be used and when they cannot. This is all
778 avoided by putting the TLSA records under the target server hostname.
779
780 The disadvantage is that clients that do not complete DNSSEC
781 validation must, according to [RFC6125] rules, check the server
782 certificate against the service domain name, since they have no other
783 way to authenticate the server. This means that SNI support or its
784 functional equivalent is necessary for backward compatibility.
785
786 Acknowledgements
787
788 Thanks to Mark Andrews for arguing that authenticating the target
789 server hostname is the right thing, and that we ought to rely on
790 DNSSEC to secure the SRV lookup. Thanks to Stephane Bortzmeyer,
791 James Cloos, Viktor Dukhovni, Ned Freed, Olafur Gudmundsson, Paul
792 Hoffman, Phil Pennock, Hector Santos, Jonas Schneider, and Alessandro
793 Vesely for helpful suggestions.
794
795 Carl Wallace completed an insightful review on behalf of the Security
796 Directorate.
797
798 Ben Campbell, Brian Haberman, and Alvaro Retana provided helpful
799 feedback during IESG review.
800
801 The authors gratefully acknowledge the assistance of Olafur
802 Gudmundsson and Warren Kumari as the working group chairs and Stephen
803 Farrell as the sponsoring Area Director.
804
805 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
806 employing him during his work on earlier draft versions of this
807 document.
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822 Finch, et al. Standards Track [Page 15]
823 RFC 7673 TLSA and SRV October 2015
824
825
826 Authors' Addresses
827
828 Tony Finch
829 University of Cambridge Information Services
830 Roger Needham Building
831 7 JJ Thomson Avenue
832 Cambridge CB3 0RB
833 United Kingdom
834
835 Phone: +44 797 040 1426
836 Email: dot@dotat.at
837 URI: http://dotat.at/
838
839
840 Matthew Miller
841 Cisco Systems, Inc.
842 1899 Wynkoop Street, Suite 600
843 Denver, CO 80202
844 United States
845
846 Email: mamille2@cisco.com
847
848
849 Peter Saint-Andre
850 &yet
851
852 Email: peter@andyet.com
853 URI: https://andyet.com/
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877 Finch, et al. Standards Track [Page 16]
878
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.