idnits 2.17.1 draft-ietf-dane-srv-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 15, 2015) is 3297 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-16) exists of draft-ietf-dane-ops-07 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-19) exists of draft-ietf-dane-smtp-with-dane-15 == Outdated reference: A later version (-11) exists of draft-ietf-xmpp-dna-10 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS-Based Authentication of Named Entities (DANE) T. Finch 3 Internet-Draft University of Cambridge 4 Intended status: Standards Track M. Miller 5 Expires: October 17, 2015 Cisco Systems, Inc. 6 P. Saint-Andre 7 &yet 8 April 15, 2015 10 Using DNS-Based Authentication of Named Entities (DANE) TLSA Records 11 with SRV Records 12 draft-ietf-dane-srv-13 14 Abstract 16 The DANE specification (RFC 6698) describes how to use TLSA resource 17 records secured by DNSSEC (RFC 4033) to associate a server's 18 connection endpoint with its TLS certificate. However, application 19 protocols that use SRV records (RFC 2782) to indirectly name the 20 target server connection endpoints for a service domain cannot apply 21 the rules from RFC 6698. Therefore this document provides guidelines 22 that enable such protocols to locate and use TLSA records. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 17, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. DNS Checks . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. SRV Query . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. Address Queries . . . . . . . . . . . . . . . . . . . . . 5 63 3.3. TLSA Queries . . . . . . . . . . . . . . . . . . . . . . 5 64 3.4. Impact on TLS Usage . . . . . . . . . . . . . . . . . . . 5 65 4. TLS Checks . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1. SRV Records Only . . . . . . . . . . . . . . . . . . . . 6 67 4.2. TLSA Records . . . . . . . . . . . . . . . . . . . . . . 7 68 5. Guidance for Protocol Authors . . . . . . . . . . . . . . . . 7 69 6. Guidance for Server Operators . . . . . . . . . . . . . . . . 8 70 7. Guidance for Application Developers . . . . . . . . . . . . . 8 71 8. Internationalization Considerations . . . . . . . . . . . . . 9 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 10.1. Mixed Security Status . . . . . . . . . . . . . . . . . 9 75 10.2. Certificate Subject Name Matching . . . . . . . . . . . 9 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 11.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 80 A.1. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 A.2. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 Appendix B. Rationale . . . . . . . . . . . . . . . . . . . . . 13 83 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 The base DANE specification [RFC6698] describes how to use TLSA 89 resource records secured by DNSSEC [RFC4033] to associate a target 90 server's connection endpoint with its TLS certificate. Some 91 application protocols locate connection endpoints indirectly via SRV 92 records [RFC2782]. As a result of this indirection, the rules 93 specified in [RFC6698] cannot be directly applied to such application 94 protocols. (Rules for SMTP [RFC5321], which uses MX resource records 95 instead of SRV records, are described in 96 [I-D.ietf-dane-smtp-with-dane].) 97 This document describes how to use DANE TLSA records with SRV 98 records. To summarize: 100 o We rely on DNSSEC to secure SRV records that map the desired 101 service, transport protocol, and service domain to the 102 corresponding target server connection endpoints (i.e., the target 103 server host names and port numbers returned in the SRV records for 104 that service type). 106 o Although in accordance with [RFC2782] a service domain can 107 advertise a number of SRV records (some of which might map to 108 connection endpoints that do not support TLS), the intent of this 109 specification is for a client to securely discover connection 110 endpoints that support TLS. 112 o The TLSA records for each connection endpoint are located using 113 the transport protocol, port number, and host name for the target 114 server (not the service domain). 116 o When DNSSEC-validated TLSA records are published for a given 117 connection endpoint, clients always use TLS when connecting (even 118 if the connection endpoint supports cleartext communication). 120 o If there is at least one usable TLSA record for a given connection 121 endpoint, the connection endpoint's TLS certificate or public key 122 needs to match at least one of those usable TLSA records. 124 o If there are no usable TLSA records for a given connection 125 endpoint, the target server host name is used as one of the 126 acceptable reference identifiers, as described in [RFC6125]. 127 Other reference identifiers might arise through CNAME expansion of 128 either the service domain or target server host name, as detailed 129 in [I-D.ietf-dane-ops]. 131 o If there are no usable TLSA records for any connection endpoint 132 (and thus the client cannot securely discover a connection 133 endpoint that supports TLS), the client's behavior is a matter for 134 the application protocol or client implementation; this might 135 involve a fallback to non-DANE behavior using the public key 136 infrastructure [RFC5280]. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this memo are to be interpreted as described in 143 [RFC2119]. 145 This draft uses the definitions for "secure", "insecure", "bogus", 146 and "indeterminate" from Section 4.3 of [RFC4035]. This draft uses 147 the acronyms from [RFC7218] for the values of TLSA fields where 148 appropriate. 150 Additionally, this document uses the following terms: 152 connection endpoint: A tuple of a fully qualified DNS host name, 153 transport protocol, and port number that a client uses to 154 establish a connection to the target server. 156 service domain: The fully qualified DNS domain name that identifies 157 an application service; corresponds to the term "source domain" 158 from [RFC6125]. 160 This document uses the term "target server host name" in place of the 161 term "derived domain" from the CertID specification [RFC6125]. 163 3. DNS Checks 165 3.1. SRV Query 167 When the client makes an SRV query, a successful result will 168 typically be a list of one or more SRV records (or possibly a chain 169 of CNAME / DNAME aliases leading to such a list). 171 NOTE: Implementers need to be aware that unsuccessful results can 172 occur because of various DNS-related errors; guidance on avoiding 173 downgrade attacks can be found in Section 4 of 174 [I-D.ietf-dane-smtp-with-dane]. 176 For this specification to apply, the entire chain of DNS RRset(s) 177 returned MUST be "secure" according to DNSSEC validation (Section 5 178 of [RFC4035]). In the case where the answer is obtained via a chain 179 of CNAME and/or DNAME aliases, the whole chain of CNAME and DNAME 180 RRsets MUST also be secure. 182 If the SRV lookup fails because the RRset is "bogus" (or the lookup 183 fails for reasons other than no records), the client MUST abort its 184 attempt to connect to the desired service. If the lookup result is 185 "insecure" (or no SRV records exist), this protocol does not apply 186 and the client SHOULD fall back to its non-DNSSEC, non-DANE (and 187 possibly non-SRV) behavior. 189 When the lookup returns a "secure" RRset (possibly via a chain of 190 "secure" CNAME/DNAME records), the client now has an authentic list 191 of target server connection endpoints with weight and priority 192 values. It performs server ordering and selection using the weight 193 and priority values without regard to the presence or absence of 194 DNSSEC or TLSA records. It also takes note of the DNSSEC validation 195 status of the SRV response for use when checking certificate names 196 (see Section 4). The client can then proceed to making address 197 queries on the target server host names as described in the following 198 section. 200 3.2. Address Queries 202 For each SRV target server connnection endpoint, the client makes A 203 and/or AAAA queries, performs DNSSEC validation on the address (A or 204 AAAA) response, and continues as follows based on the results: 206 o If either the A or AAAA RRSets are "secure", the client MUST 207 perform a TLSA query for that target server connection endpoint as 208 described in the next section. 210 o If both RRsets are "insecure", the client MUST NOT perform a TLSA 211 query for that target server connection endpoint; the TLSA query 212 will most likely fail or produce spurious results. 214 o If the address record lookup fails (this a validation status of 215 either "bogus" or "indeterminate"), the client MUST NOT connect to 216 this connection endpoint; instead it uses the next most 217 appropriate SRV target. This mitigates against downgrade attacks. 219 3.3. TLSA Queries 221 The client SHALL construct the TLSA query name as described in 222 Section 3 of [RFC6698], based on the fields from the SRV record: the 223 port number from the SRV RDATA, the transport protocol from the SRV 224 query name, and the TLSA base domain from the SRV target server host 225 name. 227 For example, the following SRV record for IMAP (see [RFC6186]): 229 _imap._tcp.example.com. 86400 IN SRV 10 0 9143 imap.example.net. 231 leads to the TLSA query shown below: 233 _9143._tcp.imap.example.net. IN TLSA ? 235 3.4. Impact on TLS Usage 237 The client SHALL determine if the TLSA records returned in the 238 previous step are usable according to Section 4.1 of [RFC6698]. This 239 affects the use of TLS as follows: 241 o If the TLSA response is "secure" and usable, then the client MUST 242 use TLS when connecting to the target server. The TLSA records 243 are used when validating the server's certificate as described in 244 Section 4. 246 o If the TLSA response is "bogus" or "indeterminate" (or the lookup 247 fails for reasons other than no records), then the client MUST NOT 248 connect to the target server (the client can still use other SRV 249 targets). 251 o If the TLSA response is "insecure" (or no TLSA records exist), 252 then the client SHALL proceed as if the target server had no TLSA 253 records. It MAY connect to the target server with or without TLS, 254 subject to the policies of the application protocol or client 255 implementation. 257 4. TLS Checks 259 When connecting to a server, the client MUST use TLS if the responses 260 to the SRV and TLSA queries were "secure" as described above. The 261 rules described in the next two sections apply to such secure 262 responses; Section 4.2 where there is at least one usable TLSA 263 record, and Section 4.1 otherwise. 265 4.1. SRV Records Only 267 If the client received zero usable TLSA certificate associations, it 268 SHALL validate the server's TLS certificate using the normal PKIX 269 rules [RFC5280] or protocol-specific rules (e.g., following 270 [RFC6125]) without further input from the TLSA records. In this 271 case, the client uses the information in the server certificate and 272 the DNSSEC validation status of the SRV query in its authentication 273 checks. It SHOULD use the Server Name Indication extension (TLS SNI) 274 [RFC6066] or its functional equivalent in the relevant application 275 protocol (e.g., in XMPP [RFC6120] this is the 'to' address of the 276 initial stream header). The preferred name SHALL be chosen as 277 follows, and the client SHALL verify the identity asserted by the 278 server's certificate according to Section 6 of [RFC6125], using a 279 list of reference identifiers constructed as follows (note again that 280 in RFC 6125 the terms "source domain" and "derived domain" to refer 281 to the same things as "service domain" and "target server host name" 282 in this document). The examples below assume a service domain of 283 "im.example.com" and a target server host name of 284 "xmpp23.hosting.example.net". 286 SRV is insecure: The reference identifiers SHALL include the service 287 domain and MUST NOT include the SRV target server host name (e.g., 288 include "im.example.com" but not "xmpp23.hosting.example.net"). 290 The service domain is the preferred name for TLS SNI or its 291 equivalent. 293 SRV is secure: The reference identifiers SHALL include both the 294 service domain and the SRV target server host name (e.g., include 295 both "im.example.com" and "xmpp23.hosting.example.net"). The 296 target server host name is the preferred name for TLS SNI or its 297 equivalent. 299 In the latter case, the client will accept either identity to ensure 300 compatibility with servers that support this specification as well as 301 servers that do not support this specification. 303 4.2. TLSA Records 305 If the client received one or more usable TLSA certificate 306 associations, it SHALL process them as described in Section 2.1 of 307 [RFC6698]. 309 If the TLS server's certificate -- or the public key of the server's 310 certificate -- matches a usable TLSA record with Certificate Usage 311 "DANE-EE", the client MUST ignore validation checks from [RFC5280] 312 and reference identifier checks from [RFC6125]. The information in 313 such a TLSA record supersedes the non-key information in the 314 certificate. 316 5. Guidance for Protocol Authors 318 This document describes how to use DANE with application protocols in 319 which target servers are discovered via SRV records. Although this 320 document attempts to provide generic guidance applying to all such 321 protocols, additional documents for particular application protocols 322 could cover related topics, such as: 324 o Fallback logic in the event that a client is unable to connect 325 securely to a target server by following the procedures defined in 326 this document. 328 o How clients ought to behave if they do not support SRV lookups, or 329 if clients that support SRV lookups encounter service domains that 330 do not offer SRV records. 332 o Whether the application protocol has a functional equivalent for 333 TLS SNI that is preferred within that protocol. 335 o Use of SRV records with additional discovery technologies, such as 336 the use of both SRV records and NAPTR records [RFC3403] for 337 transport selection in the Session Initiation Protocol (SIP). 339 For example, [I-D.ietf-xmpp-dna] covers such topics for the 340 Extensible Messaging and Presence Protocol (XMPP). 342 6. Guidance for Server Operators 344 To conform to this specification, the published SRV records and 345 subsequent address (A and AAAA) records MUST be secured with DNSSEC. 346 There SHOULD also be at least one TLSA record published that 347 authenticates the server's certificate. 349 When using TLSA records with Certificate Usage "DANE-EE", it is not 350 necessary for the deployed certificate to contain an identifier for 351 either the source domain or target server host name. However, 352 operators need to be aware that servers relying solely on validation 353 using Certificate Usage "DANE-EE" TLSA records might prevent clients 354 that do not support this specification from successfully connecting 355 with TLS. 357 For TLSA records with Certificate Usage types other than "DANE-EE", 358 the certificate(s) MUST contain an identifier that matches: 360 o the service domain name (the "source domain" in [RFC6125] terms, 361 which is the SRV query domain); and/or 363 o the target server host name (the "derived domain" in [RFC6125] 364 terms, which is the SRV target host name). 366 Servers that support multiple service domains (i.e., so-called 367 "multi-tenanted environments") can implement the Transport Layer 368 Security Server Name Indication (TLS SNI) [RFC6066] or its functional 369 equivalent to determine which certificate to offer. Clients that do 370 not support this specification will indicate a preference for the 371 service domain name, while clients that support this specification 372 will indicate the target server host name. However, the server 373 determines what certificate to present in the TLS handshake; e.g., 374 the presented certificate might only authenticate the target server 375 host name. 377 7. Guidance for Application Developers 379 Developers of application clients that depend on DANE-SRV often would 380 like to prepare as quickly as possible for making a connection to the 381 intended service, thus reducing the wait time for end users. To make 382 this optimization possible, a DNS library might perform the SRV 383 queries, address queries, and TLSA queries in parallel. (Because a 384 TLSA record can be ignored if it turns out that the address record on 385 which it depends is not secure, performing the TLSA queries in 386 parallel with the SRV queries and address queries is not harmful from 387 a security perspective and can yield some operational benefits.) 389 8. Internationalization Considerations 391 If any of the DNS queries are for an internationalized domain name, 392 then they need to use the A-label form [RFC5890]. 394 9. IANA Considerations 396 No IANA action is required. 398 10. Security Considerations 400 10.1. Mixed Security Status 402 We do not specify that all of the target server connection endpoints 403 for a service domain need to be consistent in whether they have or do 404 not have TLSA records. This is so that partial or incremental 405 deployment does not break the service. Different levels of 406 deployment are likely if a service domain has a third-party fallback 407 server, for example. 409 The SRV sorting rules are unchanged; in particular they have not been 410 altered in order to prioritize secure connection endpoints over 411 insecure connection endpoints. If a site wants to be secure it needs 412 to deploy this protocol completely; a partial deployment is not 413 secure and we make no special effort to support it. 415 10.2. Certificate Subject Name Matching 417 Section 4 of the TLSA specification [RFC6698] leaves the details of 418 checking names in certificates to higher level application protocols, 419 though it suggests the use of [RFC6125]. 421 Name checks are not necessary if the matching TLSA record is of 422 Certificate Usage "DANE-EE". Because such a record identifies the 423 specific certificate (or public key of the certificate), additional 424 checks are superfluous and potentially conflicting. 426 Otherwise, while DNSSEC provides a secure binding between the server 427 name and the TLSA record, and the TLSA record provides a binding to a 428 certificate, this latter step can be indirect via a chain of 429 certificates. For example, a Certificate Usage "PKIX-TA" TLSA record 430 only authenticates the CA that issued the certificate, and third 431 parties can obtain certificates from the same CA. Therefore, clients 432 need to check whether the server's certificate matches one of the 433 expected reference identifiers to ensure that the certificate was 434 issued by the CA to the server the client expects (naturally, this is 435 in addition to standard certificate-related checks as specified in 436 [RFC5280], including but not limited to certificate syntax, 437 certificate extensions such as name constraints and extended key 438 usage, and handling of certification paths). 440 11. References 442 11.1. Normative References 444 [I-D.ietf-dane-ops] 445 Dukhovni, V. and W. Hardaker, "Updates to and Operational 446 Guidance for the DANE Protocol", draft-ietf-dane-ops-07 447 (work in progress), October 2014. 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, March 1997. 452 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 453 specifying the location of services (DNS SRV)", RFC 2782, 454 February 2000. 456 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 457 Rose, "DNS Security Introduction and Requirements", RFC 458 4033, March 2005. 460 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 461 Rose, "Protocol Modifications for the DNS Security 462 Extensions", RFC 4035, March 2005. 464 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 465 Housley, R., and W. Polk, "Internet X.509 Public Key 466 Infrastructure Certificate and Certificate Revocation List 467 (CRL) Profile", RFC 5280, May 2008. 469 [RFC5890] Klensin, J., "Internationalized Domain Names for 470 Applications (IDNA): Definitions and Document Framework", 471 RFC 5890, August 2010. 473 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 474 Extension Definitions", RFC 6066, January 2011. 476 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 477 Verification of Domain-Based Application Service Identity 478 within Internet Public Key Infrastructure Using X.509 479 (PKIX) Certificates in the Context of Transport Layer 480 Security (TLS)", RFC 6125, March 2011. 482 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 483 of Named Entities (DANE) Transport Layer Security (TLS) 484 Protocol: TLSA", RFC 6698, August 2012. 486 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 487 Conversations about DNS-Based Authentication of Named 488 Entities (DANE)", RFC 7218, April 2014. 490 11.2. Informative References 492 [I-D.ietf-dane-smtp-with-dane] 493 Dukhovni, V. and W. Hardaker, "SMTP security via 494 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-15 495 (work in progress), March 2015. 497 [I-D.ietf-xmpp-dna] 498 Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name 499 Associations (DNA) in the Extensible Messaging and 500 Presence Protocol (XMPP)", draft-ietf-xmpp-dna-10 (work in 501 progress), March 2015. 503 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 504 Part Three: The Domain Name System (DNS) Database", RFC 505 3403, October 2002. 507 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 508 October 2008. 510 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 511 Protocol (XMPP): Core", RFC 6120, March 2011. 513 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 514 Submission/Access Services", RFC 6186, March 2011. 516 Appendix A. Examples 518 In the following, most of the DNS resource data is elided for 519 simplicity. 521 A.1. IMAP 522 ; mail domain 523 _imap._tcp.example.com. SRV 10 0 9143 imap.example.net. 524 example.com. RRSIG SRV ... 526 ; target server host name 527 imap.example.net. A 192.0.2.1 528 imap.example.net. RRSIG A ... 530 imap.example.net. AAAA 2001:db8:212:8::e:1 531 imap.example.net. RRSIG ... 533 ; TLSA resource record 534 _9143._tcp.imap.example.net. TLSA ... 535 _9143._tcp.imap.example.net. RRSIG TLSA ... 537 Mail messages received for addresses at example.com are retrieved via 538 IMAP at imap.example.net. Connections to imap.example.net port 9143 539 that use STARTTLS will get a server certificate that authenticates 540 the name imap.example.net. 542 A.2. XMPP 544 ; XMPP domain 545 _xmpp-client._tcp.example.com. SRV 1 0 5222 im.example.net. 546 _xmpp-client._tcp.example.com. RRSIG SRV ... 548 ; target server host name 549 im.example.net. A 192.0.2.3 550 im.example.net. RRSIG A ... 552 im.example.net. AAAA 2001:db8:212:8::e:4 553 im.example.net. RRSIG AAAA ... 555 ; TLSA resource record 556 _5222._tcp.im.example.net. TLSA ... 557 _5222._tcp.im.example.net. RRSIG TLSA ... 559 XMPP sessions for addresses at example.com are established at 560 im.example.net. Connections to im.example.net port 5222 that use 561 STARTTLS will get a server certificate that authenticates the name 562 im.example.net. 564 Appendix B. Rationale 566 The long-term goal of this specification is to settle on TLS 567 certificates that verify the target server host name rather than the 568 service domain, since this is more convenient for servers hosting 569 multiple domains (so-called "multi-tenanted environments") and scales 570 up more easily to larger numbers of service domains. 572 There are a number of other reasons for doing it this way: 574 o The certificate is part of the server configuration, so it makes 575 sense to associate it with the server host name rather than the 576 service domain. 578 o In the absence of TLS SNI, if the certificate identifies the 579 target server host name then it does not need to list all the 580 possible service domains. 582 o When the server certificate is replaced it is much easier if there 583 is one part of the DNS that needs updating to match, instead of an 584 unbounded number of hosted service domains. 586 o The same TLSA records work with this specification, and with 587 direct connections to the connection endpoint in the style of 588 [RFC6698]. 590 o Some application protocols, such as SMTP, allow a client to 591 perform transactions with multiple service domains in the same 592 connection. It is not in general feasible for the client to 593 specify the service domain using TLS SNI when the connection is 594 established, and the server might not be able to present a 595 certificate that authenticates all possible service domains. See 596 [I-D.ietf-dane-smtp-with-dane] for details. 598 o It is common for SMTP servers to act in multiple roles, for 599 example as outgoing relays or as incoming MX servers, depending on 600 the client identity. It is simpler if the server can present the 601 same certificate regardless of the role in which it is to act. 602 Sometimes the server does not know its role until the client has 603 authenticated, which usually occurs after TLS has been 604 established. See [I-D.ietf-dane-smtp-with-dane] for details. 606 This specification does not provide an option to put TLSA records 607 under the service domain because that would add complexity without 608 providing any benefit, and security protocols are best kept simple. 609 As described above, there are real-world cases where authenticating 610 the service domain cannot be made to work, so there would be 611 complicated criteria for when service domain TLSA records might be 612 used and when they cannot. This is all avoided by putting the TLSA 613 records under the target server host name. 615 The disadvantage is that clients which do not complete DNSSEC 616 validation must, according to [RFC6125] rules, check the server 617 certificate against the service domain, since they have no other way 618 to authenticate the server. This means that SNI support or its 619 functional equivalent is necessary for backward compatibility. 621 Appendix C. Acknowledgements 623 Thanks to Mark Andrews for arguing that authenticating the target 624 server host name is the right thing, and that we ought to rely on 625 DNSSEC to secure the SRV lookup. Thanks to Stephane Bortzmeyer, 626 James Cloos, Viktor Dukhovni, Ned Freed, Olafur Gudmundsson, Paul 627 Hoffman, Phil Pennock, Hector Santos, Jonas Schneider, and Alessandro 628 Vesely for helpful suggestions. 630 Carl Wallace provided an insightful review on behalf of the Security 631 Directorate. 633 The authors gratefully acknowledge the assistance of Olafur 634 Gudmundsson and Warren Kumari as the working group chairs and Stephen 635 Farrell as the sponsoring Area Director. 637 Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for 638 employing him during his work on earlier versions of this document. 640 Authors' Addresses 642 Tony Finch 643 University of Cambridge Computing Service 644 New Museums Site 645 Pembroke Street 646 Cambridge CB2 3QH 647 ENGLAND 649 Phone: +44 797 040 1426 650 Email: dot@dotat.at 651 URI: http://dotat.at/ 652 Matthew Miller 653 Cisco Systems, Inc. 654 1899 Wynkoop Street, Suite 600 655 Denver, CO 80202 656 USA 658 Email: mamille2@cisco.com 660 Peter Saint-Andre 661 &yet 663 Email: peter@andyet.com 664 URI: https://andyet.com/