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