idnits 2.17.1 draft-ietf-dane-srv-09.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 (February 13, 2015) is 3357 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-10 == Outdated reference: A later version (-11) exists of draft-ietf-xmpp-dna-05 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: August 17, 2015 Cisco Systems, Inc. 6 P. Saint-Andre 7 &yet 8 February 13, 2015 10 Using DNS-Based Authentication of Named Entities (DANE) TLSA Records 11 with SRV Records 12 draft-ietf-dane-srv-09 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 August 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 . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . 7 70 7. Guidance for Application Developers . . . . . . . . . . . . . 8 71 8. Internationalization Considerations . . . . . . . . . . . . . 8 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 10.1. Mixed Security Status . . . . . . . . . . . . . . . . . 9 75 10.2. Certificate Subject Name Matching . . . . . . . . . . . 9 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 11.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11 80 A.1. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 A.2. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 Appendix B. Rationale . . . . . . . . . . . . . . . . . . . . . 12 83 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 13 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 The TLSA records for each connection endpoint are located using 107 the transport protocol, port number, and host name for the target 108 server (not the service domain). 110 o When DNSSEC-validated TLSA records are published for a particular 111 connection endpoint, clients always use TLS when connecting (even 112 if the connection endpoint supports cleartext communication). 114 o If there is at least one usable TLSA record, the connection 115 endpoint's TLS certificate or public key needs to match at least 116 one of those usable TLSA records. 118 o If there are no usable TLSA records, the target server host name 119 is used as one of the acceptable reference identifiers, as 120 described in [RFC6125]. Other reference identifiers might arise 121 through CNAME expansion of either the service domain or target 122 server host name, as detailed in [I-D.ietf-dane-ops]. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this memo are to be interpreted as described in 129 [RFC2119]. 131 This draft uses the definitions for "secure", "insecure", "bogus", 132 and "indeterminate" from [RFC4035]. This draft uses the acronyms 133 from [RFC7218] for the values of TLSA fields where appropriate. 135 Additionally, this document uses the following terms: 137 connection endpoint: A tuple of a fully qualified DNS host name, 138 transport protocol, and port number that a client uses to 139 establish a connection to the target server. 141 service domain: The fully qualified DNS domain name that identifies 142 an application service; corresponds to the term "source domain" 143 from [RFC6125]. 145 This document uses the term "target server host name" in place of the 146 term "derived domain" from the CertID specification [RFC6125]. 148 3. DNS Checks 150 3.1. SRV Query 152 When the client makes an SRV query, a successful result will 153 typically be a list of one or more SRV records (or possibly a chain 154 of CNAME / DNAME aliases leading to such a list). 156 NOTE: Implementers need to be aware that unsuccessful results can 157 occur because of various DNS-related errors; guidance on avoiding 158 downgrade attacks can be found in Section 2.1 of 159 [I-D.ietf-dane-smtp-with-dane]. 161 For this specification to apply, the entire DNS RRset that is 162 returned MUST be "secure" according to DNSSEC validation (Section 5 163 of [RFC4035]). In the case where the answer is obtained via a chain 164 of CNAME and/or DNAME aliases, the whole chain of CNAME and DNAME 165 RRsets MUST also be secure. 167 If the lookup result is "insecure" (or no SRV records are located), 168 this protocol does not apply and the client SHOULD fall back to its 169 non-DNSSEC, non-DANE (and possibly non-SRV) behavior. If the SRV 170 lookup fails because the RRset is "bogus", the client MUST abort its 171 attempt to connect to the desired service. 173 When the lookup returns a "secure" RRset (possibly via a chain of 174 "secure" CNAME/DNAME records), the client now has an authentic list 175 of target server connection endpoints with weight and priority 176 values. It performs server ordering and selection using the weight 177 and priority values without regard to the presence or absence of 178 DNSSEC or TLSA records. It also takes note of the DNSSEC validation 179 status of the SRV response for use when checking certificate names 180 (see Section 4). The client can then proceed to making address 181 queries on the target server host names as described in the following 182 section. 184 3.2. Address Queries 186 For each SRV target server connnection endpoint, the client makes A 187 and/or AAAA queries, performs DNSSEC validation on the address (A or 188 AAAA) response, and continues as follows based on the results: 190 o If either the A or AAAA RRSets are "secure", the client MUST 191 perform a TLSA query for that target server connection endpoint as 192 described in the next section. 194 o If both RRsets are "insecure", the client MUST NOT perform a TLSA 195 query for that target server connection endpoint; the TLSA query 196 will most likely fail or produce spurious results. 198 o If the address record lookup fails (this a validation status of 199 either "bogus" or "indeterminate"), the client MUST NOT connect to 200 this connection endpoint; instead it uses the next most 201 appropriate SRV target. This mitigates against downgrade attacks. 203 3.3. TLSA Queries 205 The client SHALL construct the TLSA query name as described in 206 Section 3 of [RFC6698], based on the fields from the SRV record: the 207 port number from the SRV RDATA, the transport protocol from the SRV 208 query name, and the TLSA base domain from the SRV target server host 209 name. 211 For example, the following SRV record for IMAP (see [RFC6186]): 213 _imap._tcp.example.com. 86400 IN SRV 10 0 9143 imap.example.net. 215 leads to the TLSA query shown below: 217 _9143._tcp.imap.example.net. IN TLSA ? 219 3.4. Impact on TLS Usage 221 The client SHALL determine if the TLSA records returned in the 222 previous step are usable according to Section 4.1 of [RFC6698]. This 223 affects the use TLS as follows: 225 o If the TLSA response is "secure" and usable, then the client MUST 226 use TLS when connecting to the target server. The TLSA records 227 are used when validating the server's certificate as described in 228 Section 4. 230 o If the TLSA lookup fails, then the client SHALL proceed as if the 231 target server had no TLSA records. It MAY connect to the target 232 server with or without TLS, subject to the policies of the 233 application protocol or client implementation. 235 o If the TLSA response is "bogus" or "indeterminate", then the 236 client MUST NOT connect to the target server (the client can still 237 use other SRV targets). 239 4. TLS Checks 241 When connecting to a server, the client MUST use TLS if the responses 242 to the SRV and TLSA queries were "secure" as described above. The 243 rules described in the next two sections apply to such secure 244 responses; Section 4.2 where there is at least one usable TLSA 245 record, and Section 4.1 otherwise. 247 4.1. SRV Records Only 249 If the client received zero usable TLSA certificate associations, it 250 SHALL validate the server's TLS certificate using the normal PKIX 251 rules [RFC5280] or protocol-specific rules (e.g., following 252 [RFC6125]) without further input from the TLSA records. In this 253 case, the client uses the information in the server certificate and 254 the DNSSEC validation status of the SRV query in its authentication 255 checks. It SHOULD use the Server Name Indication extension (TLS SNI) 256 [RFC6066] or its functional equivalent in the relevant application 257 protocol (e.g., in XMPP [RFC6120] this is the 'to' address of the 258 initial stream header). The preferred name SHALL be chosen as 259 follows, and the client SHALL verify the identity asserted by the 260 server's certificate according to Section 6 of [RFC6125], using a 261 list of reference identifiers constructed as follows (note again that 262 in RFC 6125 the terms "source domain" and "derived domain" to refer 263 to the same things as "service domain" and "target server host name" 264 in this document). The examples below assume a service domain of 265 "im.example.com" and a target server host name of 266 "xmpp23.hosting.example.net". 268 SRV is insecure: The reference identifiers SHALL include the service 269 domain and MUST NOT include the SRV target server host name (e.g., 270 include "im.example.com" but not "xmpp23.hosting.example.net"). 271 The service domain is the preferred name for TLS SNI or its 272 equivalent. 274 SRV is secure: The reference identifiers SHALL include both the 275 service domain and the SRV target server host name (e.g., include 276 both "im.example.com" and "xmpp23.hosting.example.net"). The 277 target server host name is the preferred name for TLS SNI or its 278 equivalent. 280 In the latter case, the client will accept either identity to ensure 281 compatibility with servers that support this specification as well as 282 servers that do not support this specification. 284 4.2. TLSA Records 286 If the client received one or more usable TLSA certificate 287 associations, it SHALL process them as described in Section 2.1 of 288 [RFC6698]. 290 If the TLS server's certificate -- or the public key of the server's 291 certificate -- matches a usable TLSA record with Certificate Usage 292 "DANE-EE", the client MUST ignore expiration checks from [RFC5280] 293 and reference identifier checks from [RFC6125]. The information in 294 such a TLSA record supersedes the non-key information in the 295 certificate. 297 5. Guidance for Protocol Authors 299 This document describes how to use DANE with application protocols in 300 which target servers are discovered via SRV records. Although this 301 document attempts to provide generic guidance applying to all such 302 protocols, additional documents for particular application protocols 303 could cover related topics, such as: 305 o Fallback logic in the event that a client is unable to connect 306 securely to a target server by following the procedures defined in 307 this document. 309 o How clients ought to behave if they do not support SRV lookups, or 310 if clients that support SRV lookups encounter service domains that 311 do not offer SRV records. 313 o Whether the application protocol has a functional equivalent for 314 TLS SNI that is preferred within that protocol. 316 o Use of SRV records with additional discovery technologies, such as 317 the use of both SRV records and NAPTR records [RFC3403] for 318 transport selection in the Session Initiation Protocol (SIP). 320 For example, [I-D.ietf-xmpp-dna] covers such topics for the 321 Extensible Messaging and Presence Protocol (XMPP). 323 6. Guidance for Server Operators 325 To conform to this specification, the published SRV records and 326 subsequent address (A and AAAA) records MUST be secured with DNSSEC. 327 There SHOULD also be at least one TLSA record published that 328 authenticates the server's certificate. 330 When using TLSA records with Certificate Usage "DANE-EE", it is not 331 necessary for the deployed certificate to contain an identifier for 332 either the source domain or target server host name. However, 333 operators need to be aware that servers relying solely on validation 334 using Certificate Usage "DANE-EE" TLSA records might prevent clients 335 that do not support this specification from successfully connecting 336 with TLS. 338 For TLSA records with Certificate Usage types other than "DANE-EE", 339 the certificate(s) MUST contain an identifier that matches: 341 o the service domain name (the "source domain" in [RFC6125] terms, 342 which is the SRV query domain); and/or 344 o the target server host name (the "derived domain" in [RFC6125] 345 terms, which is the SRV target host name). 347 Servers that support multiple service domains (i.e., so-called 348 "multi-tenanted environments") can implement the Transport Layer 349 Security Server Name Indication (TLS SNI) [RFC6066] or its functional 350 equivalent to determine which certificate to offer. Clients that do 351 not support this specification will indicate a preference for the 352 service domain name, while clients that support this specification 353 will indicate the target server host name. However, the server 354 determines what certificate to present in the TLS handshake; e.g., 355 the presented certificate might only authenticate the target server 356 host name. 358 7. Guidance for Application Developers 360 Developers of application clients that depend on DANE-SRV often would 361 like to prepare as quickly as possible for making a connection to the 362 intended service, thus reducing the wait time for end users. To make 363 this optimization possible, a DNS library might perform the SRV 364 queries, address queries, and TLSA queries in parallel. (Because a 365 TLSA record can be ignored if it turns out that the address record on 366 which it depends is not secure, performing the TLSA queries in 367 parallel with the SRV queries and address queries is not harmful from 368 a security perspective and can yield some operational benefits.) 370 8. Internationalization Considerations 372 If any of the DNS queries are for an internationalized domain name, 373 then they need to use the A-label form [RFC5890]. 375 9. IANA Considerations 377 No IANA action is required. 379 10. Security Considerations 381 10.1. Mixed Security Status 383 We do not specify that all of the target server connection endpoints 384 for a service domain need to be consistent in whether they have or do 385 not have TLSA records. This is so that partial or incremental 386 deployment does not break the service. Different levels of 387 deployment are likely if a service domain has a third-party fallback 388 server, for example. 390 The SRV sorting rules are unchanged; in particular they have not been 391 altered in order to prioritize secure connection endpoints over 392 insecure connection endpoints. If a site wants to be secure it needs 393 to deploy this protocol completely; a partial deployment is not 394 secure and we make no special effort to support it. 396 10.2. Certificate Subject Name Matching 398 Section 4 of the TLSA specification [RFC6698] leaves the details of 399 checking names in certificates to higher level application protocols, 400 though it suggests the use of [RFC6125]. 402 Name checks are not necessary if the matching TLSA record is of 403 Certificate Usage "DANE-EE". Because such a record identifies the 404 specific certificate (or public key of the certificate), additional 405 checks are superfluous and potentially conflicting. 407 Otherwise, while DNSSEC provides a secure binding between the server 408 name and the TLSA record, and the TLSA record provides a binding to a 409 certificate, this latter step can be indirect via a chain of 410 certificates. For example, a Certificate Usage "PKIX-TA" TLSA record 411 only authenticates the CA that issued the certificate, and third 412 parties can obtain certificates from the same CA. Therefore, clients 413 need to check whether the server's certificate matches one of the 414 expected reference identifiers to ensure that the certificate was 415 issued by the CA to the server the client expects. 417 11. References 419 11.1. Normative References 421 [I-D.ietf-dane-ops] 422 Dukhovni, V. and W. Hardaker, "Updates to and Operational 423 Guidance for the DANE Protocol", draft-ietf-dane-ops-07 424 (work in progress), October 2014. 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, March 1997. 429 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 430 specifying the location of services (DNS SRV)", RFC 2782, 431 February 2000. 433 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 434 Rose, "DNS Security Introduction and Requirements", RFC 435 4033, March 2005. 437 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 438 Rose, "Protocol Modifications for the DNS Security 439 Extensions", RFC 4035, March 2005. 441 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 442 Housley, R., and W. Polk, "Internet X.509 Public Key 443 Infrastructure Certificate and Certificate Revocation List 444 (CRL) Profile", RFC 5280, May 2008. 446 [RFC5890] Klensin, J., "Internationalized Domain Names for 447 Applications (IDNA): Definitions and Document Framework", 448 RFC 5890, August 2010. 450 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 451 Extension Definitions", RFC 6066, January 2011. 453 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 454 Verification of Domain-Based Application Service Identity 455 within Internet Public Key Infrastructure Using X.509 456 (PKIX) Certificates in the Context of Transport Layer 457 Security (TLS)", RFC 6125, March 2011. 459 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 460 of Named Entities (DANE) Transport Layer Security (TLS) 461 Protocol: TLSA", RFC 6698, August 2012. 463 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 464 Conversations about DNS-Based Authentication of Named 465 Entities (DANE)", RFC 7218, April 2014. 467 11.2. Informative References 469 [I-D.ietf-dane-smtp-with-dane] 470 Dukhovni, V. and W. Hardaker, "SMTP security via 471 opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-10 472 (work in progress), May 2014. 474 [I-D.ietf-xmpp-dna] 475 Saint-Andre, P. and M. Miller, "Domain Name Associations 476 (DNA) in the Extensible Messaging and Presence Protocol 477 (XMPP)", draft-ietf-xmpp-dna-05 (work in progress), 478 February 2014. 480 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 481 Part Three: The Domain Name System (DNS) Database", RFC 482 3403, October 2002. 484 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 485 October 2008. 487 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 488 Protocol (XMPP): Core", RFC 6120, March 2011. 490 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 491 Submission/Access Services", RFC 6186, March 2011. 493 Appendix A. Examples 495 In the following, most of the DNS resource data is elided for 496 simplicity. 498 A.1. IMAP 500 ; mail domain 501 _imap._tcp.example.com. SRV 10 0 9143 imap.example.net. 502 example.com. RRSIG SRV ... 504 ; target server host name 505 imap.example.net. A 192.0.2.1 506 imap.example.net. RRSIG A ... 508 imap.example.net. AAAA 2001:db8:212:8::e:1 509 imap.example.net. RRSIG ... 511 ; TLSA resource record 512 _9143._tcp.imap.example.net. TLSA ... 513 _9143._tcp.imap.example.net. RRSIG TLSA ... 515 Mail messages received for addresses at example.com are retrieved via 516 IMAP at imap.example.net. Connections to imap.example.net port 9143 517 that use STARTTLS will get a server certificate that authenticates 518 the name imap.example.net. 520 A.2. XMPP 522 ; XMPP domain 523 _xmpp-client.example.com. SRV 1 0 5222 im.example.net. 524 _xmpp-client.example.com. RRSIG SRV ... 526 ; target server host name 527 im.example.net. A 192.0.2.3 528 im.example.net. RRSIG A ... 530 im.example.net. AAAA 2001:db8:212:8::e:4 531 im.example.net. RRSIG AAAA ... 533 ; TLSA resource record 534 _5222._tcp.im.example.net. TLSA ... 535 _5222._tcp.im.example.net. RRSIG TLSA ... 537 XMPP sessions for addresses at example.com are established at 538 im.example.net. Connections to im.example.net port 5222 that use 539 STARTTLS will get a server certificate that authenticates the name 540 im.example.net. 542 Appendix B. Rationale 544 The long-term goal of this specification is to settle on TLS 545 certificates that verify the target server host name rather than the 546 service domain, since this is more convenient for servers hosting 547 multiple domains (so-called "multi-tenanted environments") and scales 548 up more easily to larger numbers of service domains. 550 There are a number of other reasons for doing it this way: 552 o The certificate is part of the server configuration, so it makes 553 sense to associate it with the server host name rather than the 554 service domain. 556 o In the absence of TLS SNI, if the certificate identifies the 557 target server host name then it does not need to list all the 558 possible service domains. 560 o When the server certificate is replaced it is much easier if there 561 is one part of the DNS that needs updating to match, instead of an 562 unbounded number of hosted service domains. 564 o The same TLSA records work with this specification, and with 565 direct connections to the connection endpoint in the style of 566 [RFC6698]. 568 o Some application protocols, such as SMTP, allow a client to 569 perform transactions with multiple service domains in the same 570 connection. It is not in general feasible for the client to 571 specify the service domain using TLS SNI when the connection is 572 established, and the server might not be able to present a 573 certificate that authenticates all possible service domains. See 574 [I-D.ietf-dane-smtp-with-dane] for details. 576 o It is common for SMTP servers to act in multiple roles, for 577 example as outgoing relays or as incoming MX servers, depending on 578 the client identity. It is simpler if the server can present the 579 same certificate regardless of the role in which it is to act. 580 Sometimes the server does not know its role until the client has 581 authenticated, which usually occurs after TLS has been 582 established. See [I-D.ietf-dane-smtp-with-dane] for details. 584 This specification does not provide an option to put TLSA records 585 under the service domain because that would add complexity without 586 providing any benefit, and security protocols are best kept simple. 587 As described above, there are real-world cases where authenticating 588 the service domain cannot be made to work, so there would be 589 complicated criteria for when service domain TLSA records might be 590 used and when they cannot. This is all avoided by putting the TLSA 591 records under the target server host name. 593 The disadvantage is that clients which do not complete DNSSEC 594 validation must, according to [RFC6125] rules, check the server 595 certificate against the service domain, since they have no other way 596 to authenticate the server. This means that SNI support or its 597 functional equivalent is necessary for backward compatibility. 599 Appendix C. Acknowledgements 601 Thanks to Mark Andrews for arguing that authenticating the target 602 server host name is the right thing, and that we ought to rely on 603 DNSSEC to secure the SRV lookup. Thanks to Stephane Bortzmeyer, 604 James Cloos, Viktor Dukhovni, Ned Freed, Olafur Gudmundsson, Paul 605 Hoffman, Phil Pennock, Hector Santos, Jonas Schneider, and Alessandro 606 Vesely for helpful suggestions. 608 Authors' Addresses 610 Tony Finch 611 University of Cambridge Computing Service 612 New Museums Site 613 Pembroke Street 614 Cambridge CB2 3QH 615 ENGLAND 617 Phone: +44 797 040 1426 618 Email: dot@dotat.at 619 URI: http://dotat.at/ 621 Matthew Miller 622 Cisco Systems, Inc. 623 1899 Wynkoop Street, Suite 600 624 Denver, CO 80202 625 USA 627 Email: mamille2@cisco.com 629 Peter Saint-Andre 630 &yet 632 Email: peter@andyet.com 633 URI: https://andyet.com/