idnits 2.17.1 draft-ietf-dane-srv-03.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 (December 13, 2013) is 3784 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) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-11) exists of draft-ietf-xmpp-dna-04 Summary: 1 error (**), 0 flaws (~~), 3 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: June 16, 2014 P. Saint-Andre 6 Cisco Systems, Inc. 7 December 13, 2013 9 Using DNS-Based Authentication of Named Entities (DANE) TLSA records 10 with SRV and MX records. 11 draft-ietf-dane-srv-03 13 Abstract 15 The DANE specification (RFC 6698) describes how to use TLSA resource 16 records in the DNS to associate a server's host name with its TLS 17 certificate. The association is secured with DNSSEC. Some 18 application protocols use SRV records (RFC 2782) to indirectly name 19 the server hosts for a service domain (SMTP uses MX records for the 20 same purpose). This specification gives generic instructions for how 21 these application protocols locate and use TLSA records when 22 technologies such as SRV records are used. Separate documents give 23 the details that are specific to particular application protocols. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 16, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Relation between SRV and MX records . . . . . . . . . . . . . 3 62 4. DNS Checks for TLSA and SRV Records . . . . . . . . . . . . . 4 63 4.1. SRV Query . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. TLSA Queries . . . . . . . . . . . . . . . . . . . . . . 5 65 5. TLS Checks for TLSA and SRV Records . . . . . . . . . . . . . 5 66 6. Guidance for Application Protocols . . . . . . . . . . . . . 6 67 7. Guidance for Server Operators . . . . . . . . . . . . . . . . 6 68 8. Internationalization Considerations . . . . . . . . . . . . . 7 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 10.1. Mixed Security Status . . . . . . . . . . . . . . . . . 7 72 10.2. A Service Domain Trusts its Servers . . . . . . . . . . 7 73 10.3. Certificate Subject Name Matching . . . . . . . . . . . 8 74 10.4. Deliberate Omissions . . . . . . . . . . . . . . . . . . 8 75 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 12.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10 80 Appendix B. Rationale . . . . . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 The base DANE specification [RFC6698] describes how to use TLSA 86 resource records in the DNS to associate a server's host name with 87 its TLS certificate. The association is secured using DNSSEC. That 88 document "only relates to securely associating certificates for TLS 89 and DTLS with host names" (see the last paragraph of section 1.2 of 90 [RFC6698]). 92 Some application protocols do not use host names directly; instead, 93 they use a service domain and the relevant host names are located 94 indirectly via SRV records [RFC2782], or MX records in the case of 95 SMTP [RFC5321]. (Note: in the "CertID" specification [RFC6125], the 96 source domain and host name are referred to as the "source domain" 97 and the "derived domain".) Because of this intermediate resolution 98 step, the normal DANE rules specified in [RFC6698] do not directly 99 apply to protocols that use SRV or MX records. 101 This document describes how to use DANE TLSA records with SRV and MX 102 records. To summarize: 104 o We rely on DNSSEC to secure the association between the service 105 domain and the target server host names (i.e., the host names that 106 are discovered by the SRV or MX query). 108 o The TLSA records are located using the port, protocol, and target 109 host name fields (not the service domain). 111 o Clients always use TLS when connecting to servers with TLSA 112 records. 114 o Assuming that the association is secure, the server's certificate 115 is expected to authenticate the target server host name, rather 116 than the service domain. 118 Separate documents give the details that are specific to particular 119 application protocols, such as SMTP [I-D.ietf-dane-smtp-with-dane] 120 and XMPP [I-D.ietf-xmpp-dna]. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this memo are to be interpreted as described in 127 [RFC2119]. 129 3. Relation between SRV and MX records 131 For the purpose of this specification (to avoid cluttering the 132 description with special cases) we treat each MX record ([RFC5321] 133 section 5) as being equivalent to an SRV record [RFC2782] with 134 corresponding fields copied from the MX record and the remaining 135 fields having fixed values as follows: 137 Service - smtp 139 Proto - tcp 141 Name - MX owner name (mail domain) 143 TTL - MX TTL 144 Class - MX Class 146 Priority - MX Priority 148 Weight - 0 150 Port - 25 152 Target - MX Target 154 Thus we can treat the following MX record as if it were the SRV 155 record shown below: 157 example.com. 86400 IN MX 10 mx.example.net. 159 _smtp._tcp.example.com. 86400 IN SRV 10 0 25 mx.example.net. 161 Other details that are specific to SMTP are described in 162 [I-D.ietf-dane-smtp-with-dane]. 164 4. DNS Checks for TLSA and SRV Records 166 4.1. SRV Query 168 When the client makes an SRV query, a successful result will be a 169 list of one or more SRV records (or possibly a chain of CNAME / DNAME 170 aliases referring to such a list). 172 For this specification to apply, all of these DNS RRsets MUST be 173 "secure" according to DNSSSEC validation ([RFC4033] section 5). In 174 the case of aliases, the whole chain MUST be secure as well as the 175 ultimate target. (This corresponds to the AD bit being set in the 176 response(s) - see [RFC4035] section 3.2.3.) 178 If they are not all secure, this protocol has not been fully 179 deployed. The client SHOULD fall back to its non-DNSSEC non-DANE 180 behavior. (This corresponds to the AD bit being unset.) 182 If any of the responses is "bogus" according to DNSSEC validation, 183 the client MUST abort. (This usually corresponds to a "server 184 failure" response.) 186 In the successful case, the client now has an authentic list of 187 server host names with weight and priority values. It performs 188 server ordering and selection using the weight and priority values 189 without regard to the presence or absence of DNSSEC or TLSA records. 190 It takes note of the DNSSEC validation status of the SRV response for 191 use when checking certificate names (see Section 5). 193 4.2. TLSA Queries 195 This sub-section applies to each server host name individually, 196 provided the SRV response was secure according to DNSSEC validation. 198 The client SHALL construct the TLSA query name as described in 199 [RFC6698] section 3, based on fields from the SRV record: the port 200 from the SRV RDATA, the protocol from the SRV query name, and the 201 TLSA base domain set to the SRV target host name. 203 For example, the following SRV record leads to the TLSA query shown 204 below: 206 _imap._tcp.example.com. 86400 IN SRV 10 0 143 imap.example.net. 208 _143._tcp.imap.example.net. IN TLSA ? 210 The client SHALL determine if the TLSA record(s) are usable according 211 to section 4.1 of [RFC6698]. This affects SRV handling as follows: 213 If the TLSA response is "secure", the client MUST use TLS when 214 connecting to the server. The TLSA records are used when validating 215 the server's certificate as described under Section 5. 217 If the TLSA response is "insecure" or "indeterminate", the client 218 SHALL proceed as if this server has no TLSA records. It MAY connect 219 to the server with or without TLS. 221 If the TLSA response is "bogus", then the client MUST NOT connect to 222 the corresponding server. (The client can still use other SRV 223 targets.) 225 5. TLS Checks for TLSA and SRV Records 227 When connecting to a server, the client MUST use TLS if the responses 228 to the SRV and TLSA queries were "secure" as described above. If the 229 client received zero usable TLSA certificate associations, it SHALL 230 validate the server's TLS certificate using the normal PKIX rules 231 [RFC5280] or protocol-specific rules (e.g., following [RFC6125]) 232 without further input from the TLSA records. If the client received 233 one or more usable TLSA certificate associations, it SHALL process 234 them as described in [RFC6698] section 2.1. 236 The client uses the DNSSEC validation status of the SRV query in its 237 server certificate identity checks. (The TLSA validation status does 238 not affect the server certificate identity checks.) It SHALL use the 239 Server Name Indication extension (TLS SNI) [RFC6066] or its 240 functional equivalent in the relevant application protocol (e.g., in 241 XMPP [RFC6120] this is the the 'to' address of the initial stream 242 header). The preferred name SHALL be chosen as follows, and the 243 client SHALL verify the identity asserted by the server's certificate 244 according to [RFC6125] section 6, using a list of reference 245 identifiers constructed as follows. (Note again that in RFC 6125 the 246 terms "source domain" and "derived domain" refer to the same things 247 as "service domain" and "target host name" in this document.) 249 SRV is insecure or indeterminate: The reference identifiers SHALL 250 include the service domain and MUST NOT include the SRV target 251 host name. The service domain is the preferred name for TLS SNI 252 or its equivalent. 254 SRV is secure: The reference identifiers SHALL include both the 255 service domain and the SRV target host name. The target host name 256 is the preferred name for TLS SNI or its equivalent. 258 (In the latter case, the client will accept either identity so that 259 it is compatible with servers that do and do not support this 260 specification.) 262 6. Guidance for Application Protocols 264 Separate documents describe how to apply this specification to 265 particular application protocols. If you are writing such as 266 document the following points ought to be covered: 268 o Fallback logic in the event of bogus replies and the like. 270 o Compatibility with clients that do not support SRV lookups. 272 7. Guidance for Server Operators 274 In order to support this specification, server software MUST 275 implement the TLS Server Name Indication extension (TLS SNI) 276 [RFC6066] (or its functional equivalent in the relevant application 277 protocol) for selecting the appropriate certificate. 279 A server that supports TLS and is the target of an SRV record MUST 280 have a TLS certificate that authenticates the SRV query domain (i.e. 281 the service domain, or "source domain" in [RFC6125] terms). This is 282 necessary for clients that cannot perform DNSSEC validation. This 283 certificate MUST be the default that is presented if the client does 284 not use TLS SNI or its functional equivalent. 286 In order to support this specification, the server SHOULD also have a 287 certificate that authenticates the SRV target domain (e.g., the mail 288 server hostname). This can be done using a multi-name certificate or 289 by using the client's TLS SNI or its functional equivalent to select 290 the appropriate certificate. The server's TLSA record SHOULD 291 correspond to this certificate. 293 Note: In some application protocols, there are old non-SRV clients 294 that expect a server's TLS certificate to authenticate its host name; 295 they are also unlikely to support SNI. This means that servers for 296 old clients need a different default certificate from servers that 297 are the targets of SRV records. If the server does not have a 298 certificate that authenticates all relevant names, it is necessary to 299 segregate old and new clients. This can be done by using different 300 target hosts or non-standard ports in the SRV targets. (The latter 301 avoids the need for additional certificates.) 303 8. Internationalization Considerations 305 If any of the DNS queries are for an internationalized domain name, 306 then they need to use the A-label form [RFC5890]. 308 9. IANA Considerations 310 No IANA action is required. 312 10. Security Considerations 314 10.1. Mixed Security Status 316 We do not specify that clients checking all of a service domain's 317 server host names are consistent in whether they have or do not have 318 TLSA records. This is so that partial or incremental deployment does 319 not break the service. Different levels of deployment are likely if 320 a service domain has a third-party fallback server, for example. 322 The SRV and MX sorting rules are unchanged; in particular they have 323 not been altered in order to prioritize secure servers over insecure 324 servers. If a site wants to be secure it needs to deploy this 325 protocol completely; a partial deployment is not secure and we make 326 no special effort to support it. 328 10.2. A Service Domain Trusts its Servers 329 By signing their zone with DNSSEC, service domain operators 330 implicitly instruct their clients to check their server TLSA records. 331 This implies another point in the trust relationship between service 332 domain holders and their server operators. Most of the setup 333 requirements for this protocol fall on the server operator: 334 installing a TLS certificate with the correct name, and publishing a 335 TLSA record under that name. If these are not correct then 336 connections from TLSA-aware clients might fail. 338 10.3. Certificate Subject Name Matching 340 Section 4 of the TLSA specification [RFC6698] leaves the details of 341 checking names in certificates to higher level application protocols, 342 though it suggests the use of [RFC6125]. 344 Name checking might appear to be unnecessary, since DNSSEC provides a 345 secure binding between the server name and the TLSA record, which in 346 turn authenticates the certificate. However this latter step can be 347 indirect, via a chain of certificates. A usage=0 TLSA record only 348 authenticates the CA that issued the certificate, and third parties 349 can obtain certificates from the same CA. 351 Therefore this specification says that a client needs to check 352 whether the server's certificate matches the server host name, to 353 ensure that the certificate was issued by the CA to the server that 354 the client is connecting to. The client always performs this check 355 regardless of the TLSA usage, to simplify implementation and so that 356 this specification is less likely to need updating when new TLSA 357 usages are added. 359 10.4. Deliberate Omissions 361 We do not specify that clients check the DNSSEC state of the server 362 address records. This is not necessary since the certificate checks 363 ensure that the client has connected to the correct server. (The 364 address records will normally have the same security state as the 365 TLSA records, but they can differ if there are CNAME or DNAME 366 indirections.) 368 11. Acknowledgements 370 Thanks to Mark Andrews for arguing that authenticating the server 371 host name is the right thing, and that we ought to rely on DNSSEC to 372 secure the SRV / MX lookup. Thanks to James Cloos, Ned Freed, Olafur 373 Gudmundsson, Paul Hoffman, Phil Pennock, Hector Santos, Jonas 374 Schneider, and Alessandro Vesely for helpful suggestions. 376 12. References 378 12.1. Normative References 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, March 1997. 383 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 384 specifying the location of services (DNS SRV)", RFC 2782, 385 February 2000. 387 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 388 Rose, "DNS Security Introduction and Requirements", RFC 389 4033, March 2005. 391 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 392 Rose, "Protocol Modifications for the DNS Security 393 Extensions", RFC 4035, March 2005. 395 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 396 Housley, R., and W. Polk, "Internet X.509 Public Key 397 Infrastructure Certificate and Certificate Revocation List 398 (CRL) Profile", RFC 5280, May 2008. 400 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 401 October 2008. 403 [RFC5890] Klensin, J., "Internationalized Domain Names for 404 Applications (IDNA): Definitions and Document Framework", 405 RFC 5890, August 2010. 407 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 408 Extension Definitions", RFC 6066, January 2011. 410 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 411 Protocol (XMPP): Core", RFC 6120, March 2011. 413 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 414 Verification of Domain-Based Application Service Identity 415 within Internet Public Key Infrastructure Using X.509 416 (PKIX) Certificates in the Context of Transport Layer 417 Security (TLS)", RFC 6125, March 2011. 419 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 420 of Named Entities (DANE) Transport Layer Security (TLS) 421 Protocol: TLSA", RFC 6698, August 2012. 423 12.2. Informative References 425 [I-D.ietf-dane-smtp-with-dane] 426 Dukhovni, V. and W. Hardaker, "(DANE) TLSA records.", 427 draft-ietf-dane-smtp-with-dane (work in progress), 428 November 2013. 430 [I-D.ietf-xmpp-dna] 431 Saint-Andre, P. and M. Miller, "Domain Name Associations 432 (DNA) in the Extensible Messaging and Presence Protocol 433 (XMPP)", draft-ietf-xmpp-dna-04 (work in progress), 434 October 2013. 436 Appendix A. Example 438 In the following, most of the DNS resource data is elided for 439 simplicity. 441 ; mail domain 442 example.com. MX 1 mx.example.net. 443 example.com. RRSIG MX ... 445 ; SMTP server host name 446 mx.example.net. A 192.0.2.1 447 mx.example.net. AAAA 2001:db8:212:8::e:1 449 ; TLSA resource record 450 _25._tcp.mx.example.net. TLSA ... 451 _25._tcp.mx.example.net. RRSIG TLSA ... 453 Mail for addresses at example.com is delivered by SMTP to 454 mx.example.net. Connections to mx.example.net port 25 that use 455 STARTTLS will get a server certificate that authenticates the name 456 mx.example.net. 458 Appendix B. Rationale 460 The long-term goal of this specification is to settle on TLS 461 certificates that verify the server host name rather than the service 462 domain, since this is more convenient for servers hosting multiple 463 domains (so-called "multi-tenanted environments") and scales up more 464 easily to larger numbers of service domains. 466 There are a number of other reasons for doing it this way: 468 o The certificate is part of the server configuration, so it makes 469 sense to associate it with the server host name rather than the 470 service domain. 472 o In the absence of TLS SNI, if the certificate identifies the host 473 name then it does not need to list all the possible service 474 domains. 476 o When the server certificate is replaced it is much easier if there 477 is one part of the DNS that needs updating to match, instead of an 478 unbounded number of hosted service domains. 480 o The same TLSA records work with this specification, and with 481 direct connections to the host name in the style of [RFC6698]. 483 o Some application protocols, such as SMTP, allow a client to 484 perform transactions with multiple service domains in the same 485 connection. It is not in general feasible for the client to 486 specify the service domain using TLS SNI when the connection is 487 established, and the server might not be able to present a 488 certificate that authenticates all possible service domains. 490 o It is common for SMTP servers to act in multiple roles, for 491 example as outgoing relays or as incoming MX servers, depending on 492 the client identity. It is simpler if the server can present the 493 same certificate regardless of the role in which it is to act. 494 Sometimes the server does not know its role until the client has 495 authenticated, which usually occurs after TLS has been 496 established. 498 This specification does not provide an option to put TLSA records 499 under the service domain because that would add complexity without 500 providing any benefit, and security protocols are best kept simple. 501 As described above, there are real-world cases where authenticating 502 the service domain cannot be made to work, so there would be 503 complicated criteria for when service domain TLSA records might be 504 used and when they cannot. This is all avoided by putting the TLSA 505 records under the server host name. 507 The disadvantage is that clients which do not do DNSSEC validation 508 must, according to [RFC6125] rules, check the server certificate 509 against the service domain, since they have no other way to 510 authenticate the server. This means that SNI support or its 511 functional equivalent is necessary for backward compatibility. 513 Authors' Addresses 514 Tony Finch 515 University of Cambridge Computing Service 516 New Museums Site 517 Pembroke Street 518 Cambridge CB2 3QH 519 ENGLAND 521 Phone: +44 797 040 1426 522 Email: dot@dotat.at 523 URI: http://dotat.at/ 525 Matthew Miller 526 Cisco Systems, Inc. 527 1899 Wynkoop Street, Suite 600 528 Denver, CO 80202 529 USA 531 Email: mamille2@cisco.com 533 Peter Saint-Andre 534 Cisco Systems, Inc. 535 1899 Wynkoop Street, Suite 600 536 Denver, CO 80202 537 USA 539 Email: psaintan@cisco.com