idnits 2.17.1 draft-ietf-dane-smtp-with-dane-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When at least one usable "secure" TLSA record is found, the SMTP client SHOULD use TLSA records to authenticate the next-hop host, mail SHOULD not be delivered via this next-hop host if authentication fails, otherwise the SMTP client is vulnerable to TLS man in the middle attacks. -- The document date (October 21, 2013) is 3812 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3546' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'RFC4346' is defined on line 809, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 815, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-dane-ops-00 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3546 (Obsoleted by RFC 4366) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DANE V. Dukhovni 3 Internet-Draft Unaffiliated 4 Intended status: Experimental W. Hardaker 5 Expires: April 24, 2014 Parsons 6 October 21, 2013 8 SMTP security via opportunistic DANE TLS 9 draft-ietf-dane-smtp-with-dane-02 11 Abstract 13 This memo describes a protocol for opportunistic TLS security based 14 on the DANE TLSA DNS record. The protocol is downgrade resistant 15 when the SMTP client supports DANE TLSA and the server domain 16 publishes TLSA records for its MX hosts. This enables an incremental 17 transition of the Internet email backbone (MTA to MTA SMTP traffic) 18 to TLS encrypted and authenticated delivery. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 24, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.2. SMTP Channel Security . . . . . . . . . . . . . . . . . . 3 57 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Hardening Opportunistic TLS . . . . . . . . . . . . . . . . . 5 59 2.1. TLS discovery . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1.1. Non-MX destinations . . . . . . . . . . . . . . . . . 6 61 2.1.2. MX resolution . . . . . . . . . . . . . . . . . . . . 7 62 2.1.3. TLSA record lookup . . . . . . . . . . . . . . . . . 9 63 2.2. DANE authentication . . . . . . . . . . . . . . . . . . . 10 64 2.2.1. TLSA certificate usages . . . . . . . . . . . . . . . 10 65 2.2.2. Certificate matching . . . . . . . . . . . . . . . . 12 66 3. Opportunistic TLS for Submission . . . . . . . . . . . . . . 14 67 4. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 15 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 70 7. Normative References . . . . . . . . . . . . . . . . . . . . 17 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 73 1. Introduction 75 Lacking verified DNS and "Server Name Indication" (SNI), there has 76 historically been no scalable way for SMTP server operators to deploy 77 certificates with a client-trusted subject name. It's only with the 78 deployment of DNSSEC and DANE that authenticated TLS for SMTP to MX 79 becomes possible between parties that have not already established an 80 identity convention out-of-band. 82 1.1. Background 84 The Domain Name System Security Extensions (DNSSEC) add data origin 85 authentication and data integrity to the Domain Name System. DNSSEC 86 is defined in [RFC4033], [RFC4034] and [RFC4035]. 88 As described in the introduction of [RFC6698], TLS authentication via 89 the existing public Certificate Authority (CA) Public Key 90 Infrastructure (PKI) suffers from an over-abundance of trusted 91 certificate authorities capable of issuing certificates for any 92 domain of their choice. DNS-Based Authentication of Named Entities 93 (DANE) leverages the DNSSEC infrastructure to publish trusted keys 94 and certificates for use with TLS via a new TLSA record type. With 95 DANE, the public CA PKI can be augmented or replaced by DNSSEC 96 validated TLSA records. 98 The Transport Layer Security (TLS [RFC5246]) protocol enables secure 99 TCP communication. In the context of this memo, channel security is 100 assumed to be provided by TLS. Used without authentication, TLS 101 protects only against eavesdropping. With authentication, TLS also 102 protects against man-in-the-middle (MITM) attacks. 104 1.2. SMTP Channel Security 106 The Simple Mail Transport Protocol (SMTP) ([RFC5321]) is multi-hop 107 store & forward, while TLS security is hop-by-hop. The number of 108 hops from the sender's Mail User Agent to the recipient mailbox is 109 rarely less than 2 and is often higher. Some hops may be TLS 110 protected, some may not. The same SMTP TCP endpoint can serve both 111 TLS and non-TLS clients, with TLS negotiated via the SMTP STARTTLS 112 command ([RFC3207]). DNS MX records abstract the next-hop transport 113 end-point. SMTP addresses are not transport addresses and are 114 security agnostic. Unlike HTTP, there is no URI scheme for email 115 addresses to designate whether the SMTP server should be contacted 116 with or without security. 118 A Mail Transport Agent (MTA) may need to forward a message to a 119 particular email recipient . To deliver the 120 message, the MTA needs to retrieve the MX hosts of example.com from 121 DNS, and then deliver the message to one of them. Absent DNSSEC, the 122 MX lookup is vulnerable to man-in-the-middle and cache poisoning 123 attacks. An active attacker can forge DNS replies with fake MX 124 records, and can direct traffic to a server of his choice. 125 Therefore, secure verification of MX host certificates is not 126 possible without DNSSEC. A man in the middle can also suppress the 127 MX host's STARTTLS EHLO response, convincing the client that 128 communication over TLS is unavailable. 130 One might try to harden STARTTLS with SMTP against DNS attacks by 131 requiring each MX host to posess an X.509 certificate for the 132 recipient domain that is obtained from the message envelope and is 133 not subject to DNS reply forgery. Unfortunately, this is 134 impractical, as email for many domains is handled by third parties, 135 which are not in a position to obtain certificates for all the 136 domains they serve. Deployment of SNI (see [RFC6066] Section 3.1) is 137 no panacea, since SNI key management is operationally challenging 138 except when the email service provider is also the domain's registrar 139 and its certificate issuer; this is rarely the case for email. 141 Since the recipient domain name cannot be used as the SMTP server 142 authentication identity, and neither can the MX hostname without 143 DNSSEC, large scale deployment of authenticated TLS for SMTP requires 144 secure DNS. At this time, DNSSEC is not yet widely deployed and MTA 145 to MTA traffic between Internet connected organizations rarely uses 146 TLS at all, or simply uses TLS opportunistically without 147 authentication and protects against only passive eavesdropping 148 attacks. 150 The exceptions are cases in which the sending MTA is statically 151 configured to use TLS for mail sent to specific selected peer domains 152 and is configured with appropriate subject names (or content digests) 153 to expect in the presented MX host certificates of those domains. 154 Such statically configured SMTP secure channels are used rarely, 155 generally between domains that make bilateral arrangements with their 156 business partners. Internet email, on the other hand, requires 157 contacting many new domains for which security configurations can not 158 be established in advance. 160 Note, the above does not apply to mail submission [RFC6409], where a 161 mail user agent is pre-configured to send all email to a fixed Mail 162 Submission Agent (MSA). Submission servers usually offer TLS and the 163 Mail User Agent (MUA) can be statically configured to require TLS 164 with its chosen MSA. The situation changes when submission servers 165 are configured dynamically via SRV records (see [RFC6186] Section 6). 166 Applications to submission via SRV records will be discussed later in 167 this memo. 169 With little opportunity to use TLS authentication, MX hosts that 170 support STARTTLS often use self-signed or private CA issued X.509 171 certificates. Sending systems are rarely configured with a 172 comprehensive list of trusted CAs and do not check CRLs or implement 173 OCSP. In essence, they don't and can't rely on the existing public 174 CA PKI. This is not a result of complacency on the part SMTP server 175 administrators and MTA developers. Nor is it just a consequence of 176 the relative maturity of the SMTP infrastructure at the time that TLS 177 was introduced. Rather, the abstraction of the SMTP transport 178 endpoint via DNS MX records, often across organization boundaries, 179 limits the use of public CA PKI with SMTP to a small set of sender- 180 configured peer domains. 182 This does not mean, however, that the Internet email backbone cannot 183 benefit from TLS. The fact that transport security is not explicitly 184 specified in either the recipient address or the MX record means that 185 new protocols can furnish out-of-band information to SMTP, making it 186 possible to simultaneously discover both which peer domains support 187 secure delivery via TLS and how to verify the authenticity of the 188 associated MX hosts. The first such mechanism that can work an 189 Internet scale is DANE TLSA, but use of DANE TLSA with MTA to MTA 190 SMTP must be cognizant of the lack of any realistic role for the 191 existing public CA PKI. 193 1.3. Terminology 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in [RFC2119]. 199 2. Hardening Opportunistic TLS 201 This memo describes opportunistic SMTP over TLS security, where 202 traffic from DANE TLSA aware SMTP clients to domains that implement 203 DANE TLSA records in accordance with this memo is secure. Traffic to 204 other domains continues to be sent in the same manner as before 205 (either manually configured for security or unauthenticated and often 206 unencrypted). It is hoped that, over time, more domains will 207 implement DNSSEC and publish DANE TLSA records for their MX hosts. 208 This will enable an incremental transition of the email backbone to 209 authenticated TLS delivery. 211 Since email addresses and MX hostnames (or submission SRV records) 212 neither signal nor deny support for TLS by the receiving domain, it 213 is possible to use DANE TLSA records to securely signal TLS support 214 and simultaneously to provide the means by which SMTP clients can 215 successfully authenticate legitimate SMTP servers. 217 2.1. TLS discovery 219 As noted previously (Section 1.2), opportunistic TLS with SMTP 220 servers that advertise TLS support via STARTTLS is subject to a man 221 in the middle downgrade attack. Some SMTP servers erroneously 222 advertise STARTTLS in default configurations that are not, in fact, 223 TLS capable, and clients need to be prepared to retry plaintext 224 delivery after STARTTLS fails. This memo specifies a downgrade 225 resistant mechanism that allows a server to advertise TLS support 226 based on DANE TLSA records. DNSSEC validated TLSA records are 227 unlikely to be accidentally published for servers that do not in fact 228 support TLS, and thus clients can safely interpret their presence as 229 a commitment by the server operator to implement STARTTLS. 231 SMTP is a store & forward protocol. An MTA that is not the final 232 destination for a message recipient forwards the message one hop 233 closer to the recipient's mailbox. To do so, it must determine the 234 appropriate next-hop destination, and locate one or more associated 235 SMTP servers. When DNSSEC validated TLSA records are available for a 236 given next-hop SMTP server, the TLS connection to that server will be 237 downgrade resistant. If the records in question are "usable" 238 ([RFC6698], Section 4.1) to authenticate the server, the connection 239 will also be authenticated and thus immune to eavesdropping or 240 tampering (unless DNSSEC itself is compromised). 242 Typically, the next-hop destination will be the domain part of the 243 recipient address, which is then subject to MX resolution. The next- 244 hop destination may also be configured by the MTA administrator to be 245 a next-hop destination host (explicitly exempt from MX resolution), 246 or a next-hop destination domain (subject to MX resolution) which 247 takes the place of the domain part of the recipient address. 249 The protocol in this memo is "opportunistic"; it should be used 250 whenever possible but communication should continue when it is not 251 available. Absent "secure" (DNSSEC validated) TLSA records, mail 252 delivery should fall back to pre-DANE opportunistic TLS. The SMTP 253 client MAY be configured to require DANE verified delivery for some 254 or all destinations, in which case mail delivery will be deferred 255 when "secure" TLSA records are absent. 257 Below we explain how to determine for a given next-hop destination 258 the associated SMTP servers, the TLSA base domain and TLSA records. 260 2.1.1. Non-MX destinations 262 As mentioned above, the next-hop destination domain may in some cases 263 be exempt from MX lookups. In addition, MX lookups for the next-hop 264 domain may yield no results. In either case, the destination server 265 for such a domain is determined by looking up the corresponding A or 266 AAAA records. 268 When "bogus" records are encountered either during CNAME expansion, 269 or when retrieving the associated TLSA RRset, the SMTP client MUST 270 proceed as if the next-hop domain were unreachable. Delivery should 271 either be deferred or may be attempted via any fallback next-hop 272 configured by the SMTP client administrator. Fallback next-hop 273 destinations may also employ opportunistic DANE TLS. Proceeding with 274 the original next-hop despite "bogus" DNS responses would destroy 275 protection against downgrade attacks. 277 Following [RFC5321] Section 5.1, if the A or AAAA lookup of the 278 initial name yields a CNAME, we replace it with the resulting name as 279 if it were the initial name and perform a lookup again using the new 280 name. This replacement is performed recursively, although MTAs 281 typically support only limited recursion in CNAME expansion. We 282 consider the following cases: 284 Non-CNAME: The next-hop destination domain is not a CNAME alias. 285 The lookup key for the DNSSEC validated TLSA records is obtained 286 by prepending service labels ("_._tcp") to the 287 initial next-hop destination domain. If associated "secure" TLSA 288 records are found (see Section 2.1.3) the TLSA base domain is the 289 next-hop domain. If no secure TLSA records are found, 290 opportunistic DANE TLS is not applicable and mail delivery 291 proceeds with pre-DANE opportunistic TLS. 293 Insecure CNAME: The next-hop destination domain is a CNAME alias, 294 but at least one of the CNAME RRs leading to the ultimate target 295 of this alias (during recursive CNAME expansion) is "insecure". 296 We treat this case just like the non-CNAME case above. 298 Secure CNAME, no TLSA: The next-hop destination domain is a CNAME 299 alias, and all the CNAME RRs leading to the ultimate target of 300 this alias (during recursive CNAME expansion) are "secure" (DNSSEC 301 validated), but no "secure" TLSA RRs are found after prefixing the 302 service labels to the CNAME-expanded next-hop domain. This case 303 is also treated just like the non-CNAME case. 305 Secure CNAME, TLSA: The next-hop destination domain is a CNAME 306 alias, all the CNAME RRs leading to the ultimate target of this 307 alias (during recursive CNAME expansion) are "secure", and in 308 addition "secure" TLSA RRs are found after prefixing the service 309 labels to the CNAME-expanded next-hop domain. In this case the 310 CNAME-expanded next-hop domain is taken as the TLSA base domain. 311 The original next-hop domain is (see Section 2.2.2) used only as 312 an alternative name in certificate peername verification if 313 applicable. 315 In summary, if it is possible to securely obtain the full, CNAME- 316 expanded, DNSSEC-validated address records for the non-MX next-hop 317 domain then that name is the preferred TLSA base domain. If that is 318 not possible, then the original next-hop domain is used as the TLSA 319 base domain. When no "secure" TLSA records are found at either the 320 CNAME expanded or original next-hop domain, then opportunistic DANE 321 TLS does not apply for mail delivery to the non-MX destination in 322 question. 324 2.1.2. MX resolution 326 In this section we consider next-hop domains that are subject to MX 327 resolution and have MX records. When DANE TLS is applicable, the 328 TLSA base domain will be associated with the MX host selected for 329 message delivery. Therefore, the MX host names must be determined 330 securely by performing a DNSSEC validated MX lookup to obtain the 331 list of associated MX hosts. If the MX RRset is "insecure", DANE 332 TLSA does not apply and mail delivery proceeds with pre-DANE 333 opportunistic TLS (subject to its various MITM attacks and unecrypted 334 transmission when STARTTLS is not supported by the destination). 336 When "bogus" DNSSEC records are encountered during CNAME expansion of 337 the next-hop domain or when processing the actual MX RRset, delivery 338 MUST either be deferred, or MAY be attempted via any fallback next- 339 hop (which may also employ opportunistic DANE TLS) configured by the 340 SMTP client administrator. Proceeding with the original next-hop 341 despite "bogus" DNS responses would destroy protection against 342 downgrade attacks. When "bogus" DNSSEC records are encountered with 343 CNAME expansion or TLSA RRset lookup for a particular MX host, 344 delivery MUST proceed as if MX host in question were unreachable. 346 MX records MUST be sorted by preference; an MX host with a better 347 preference and no TLSA records MUST NOT be preempted by a host with a 348 worse MX preference but with TLSA records. In other words, avoiding 349 delivery loops by following MX preferences must take place even if it 350 means insecure delivery. 352 In accordance with Section 5.1 of [RFC5321], if the MX lookup of the 353 initial name yields a CNAME, we replace the initial name with the 354 resulting name and perform a new lookup with the new name. MTAs 355 typically support recursion in CNAME expansion, so this replacement 356 is performed repeatedly until the ultimate non-CNAME domain is found 357 (or the limit on the number of CNAMEs to examine is reached). If at 358 any stage of CNAME expansion the DNS result is "bogus", MX resolution 359 fails with a temporary error. In that case, mail delivery MUST 360 either be deferred, or attempted via any alternative delivery channel 361 configured by the MTA administrator. We consider the following 362 cases: 364 Non-CNAME: The next-hop destination domain is not a CNAME alias, 365 that is, it resolves directly to a set of DNSSEC validated 366 ("secure") MX hosts. With each MX host, if MX host CNAME 367 expansion is supported by the MTA, and the full CNAME expansion of 368 the MX host name is "secure", then the CNAME expanded MX host name 369 is the TLSA base domain provided secure TLSA records are found 370 there after prefixing service labels ("_._tcp"). 371 Otherwise, the initial MX host name is the TLSA base domain 372 provided secure TLSA records are found there after prefixing 373 service labels. With the MX hostname (or its CNAME expansion) as 374 the TLSA base domain, the original next-hop domain SHOULD be used 375 only in certificate name checks. If no "secure" TLSA RRs are 376 found, and no "bogus" records encountered, DANE TLSA is not 377 applicable with the MX host in question and delivery proceeds as 378 with pre-DANE opportunistic TLS. 380 CNAME: The next-hop destination domain is a CNAME alias, and 381 resolves via a chain of "secure" CNAME records to a final domain 382 with "secure" MX records. The TLSA base domain for each MX host 383 in this case is the same as in the "Non-CNAME" case above, but now 384 both the initial domain and its CNAME-expansion are candidate 385 names in certificate name checks. If the CNAME chain contains 386 "insecure" elements, DANE TLSA does not apply to the next-hop 387 domain, and delivery proceeds via pre-DANE opportunistic TLS. 389 Note: CNAMEs are not legal in the exchange field of MX records, thus 390 MTAs are not obligated to perform MX exchange CNAME expansion. If an 391 MTA does not perform CNAME expansion, there is potential risk, that 392 the MTA may fail to notice that it is one of the MX hosts for the 393 destination and that it must skip MX records with equal or worse 394 (numerically higher precedence). If an MTA does allow CNAMEs to be 395 used in MX records, it SHOULD process them recursively as described 396 above to determine the most appropriate TLSA RRset base domain. 398 2.1.3. TLSA record lookup 400 Each TLSA base domain obtained above (for a non-MX destination, or 401 for a particular MX host of an MX destination), when prefixed with 402 appropriate service labels leads to associated "secure" TLSA RRs 403 (possibly via a chain of "secure" CNAME RRs). If, for example, the 404 base domain is "mail.example.com", the TLSA RRset is obtained via a 405 DNSSEC query of the form: 407 _25._tcp.mail.example.com. IN TLSA ? 409 Typically, the destination TCP port is 25, but this may be different 410 with custom routes specified by the MTA administrator or when an MUA 411 connects to a submission server on port 587. The SMTP client MUST 412 use the appropriate "_" prefix in place of "_25" when 413 the port number is not equal to 25. The query response may be a 414 CNAME (or a DNAME + CNAME combination), or the TLSA RRset. If the 415 record is a CNAME or DNAME, the SMTP client restarts the TLSA query 416 at the target domain, following CNAMEs as appropriate. 418 CNAMEs encountered during TLSA record lookups can be used to share a 419 single TLSA RRset specifying a common certificate authority or a 420 common leaf certificate for multiple TLS services. Such CNAME 421 expansion does not change the SMTP client's notion of the TLSA base 422 domain, thus when _25._tcp.mail.example.com is a CNAME the base 423 domain remains mail.example.com and is still used in peer certificate 424 name checks. For example: 426 example.com. IN MX 0 mail.example.com. 427 example.com. IN MX 0 mail2.example.com. 428 _25._tcp.mail.example.com. IN CNAME 2.1.1._dane.example.com. 429 _25._tcp.mail2.example.com. IN CNAME 2.1.1._dane.example.com. 430 2.1.1._dane.example.com. IN TLSA 2 1 1 e3b0c44298fc1c14 431 9afbf4c8996fb924 432 27ae41e4649b934c 433 a495991b7852b855 435 Here, mail.example.com and mail2.example.com have certificates issued 436 under a common trust-anchor, but each MX host's TLSA base domain 437 remains its hostname and MUST match the subject name (or subject 438 alternative name) in its certificate. 440 If, after possible CNAME indirection, at least one "secure" TLSA 441 record is found (even if not usable because it is unsupported by the 442 implementation or administratively disabled) the next-hop host has 443 committed to TLS support. The SMTP client SHOULD NOT deliver mail 444 via such a next-hop host unless a TLS session is negotiated via 445 STARTTLS. This avoids man in the middle STARTTLS downgrade attacks. 447 As noted previously (Section 2.1.1, Section 2.1.2), when no TLSA 448 records are found at a CNAME-expanded name (due to an insecure 449 response or a lack of TLSA records verified by DNSSEC's proof-of-non- 450 existence), the unexpanded name MUST be tried instead. This supports 451 clients of hosting providers where the provider's zone is not DNSSEC 452 validated, but the client has shared appropriate key material with 453 the hosting provider to enable TLS via SNI. 455 SMTP clients may deploy opportunistic DANE TLS incrementally by 456 enabling it only for selected sites, or may occasionally need to 457 disable opportunistic DANE TLS for peers that fail to interoperate 458 due to misconfiguration or software defects on either end. Unless 459 local policy specifies that opportunistic DANE TLS is not to be used 460 for a particular destination, client MUST NOT deliver mail via a 461 server whose certificate chain fails to match at least one TLSA 462 record when usable TLSA records are available. 464 SMTP clients employing opportunistic DANE TLS and TLSA record 465 publishers for SMTP servers need to follow the guidance outlined in 466 [I-D.ietf-dane-ops]'s "Certificate Name Check Conventions", "Service 467 Provider and TLSA Publisher Synchronization" and "TLSA Base Domain 468 and CNAMEs" sections. 470 2.2. DANE authentication 472 2.2.1. TLSA certificate usages 474 TLSA Publishers should follow the TLSA publication size guidance 475 found in [I-D.ietf-dane-ops] about "DANE DNS Record Size Guidelines". 477 2.2.1.1. Certificate usage 3 479 Since opportunistic DANE TLS will be used by non-interactive MTAs, 480 with no user to "press OK" when authentication fails, reliability of 481 peer authentication is paramount. TLSA records published for SMTP 482 servers SHOULD be "3 1 1" records to support opportunistic SMTP over 483 TLS with DANE. This record specifies the SHA-256 digest of the 484 server's public key. Since all DANE implementations are required to 485 support SHA-256, this record works for all clients and need not 486 change across certificate renewals with the same key. 488 Authentication via certificate usage "3" TLSA records involves simply 489 checking that the server's leaf certificate matches the TLSA record. 490 Other than extracting the relevant certificate elements for 491 comparison, no other use is made of the certificate content. 492 Authentication via certificate usage "3" TLSA records involves no 493 certificate authority signature checks. It also involves no server 494 name checks, and thus does not impose any new requirements on the 495 names contained in the server certificate (SNI is not required when 496 the TLSA record matches server's default certificate). 498 Two TLSA records will need to be published before updating a server's 499 public key, one matching the currently deployed key and the other 500 matching the new key scheduled to replace it. Once sufficient time 501 has elapsed for all DNS caches to time out the previous TLSA RRset, 502 which contains only the old key, the server may be reconfigured to 503 use the new private key and associated public key certificate. The 504 amount of time a server should wait before using a new key that is 505 referenced by new TLSA records should be at least twice the TTL of 506 the previously published TLSA records. Once the server is using a 507 new key, the obsolete TLSA RR can be removed from DNS, leaving only 508 the RR that matches the new key. 510 2.2.1.2. Certificate usage 2 512 Some domains may prefer to reduce the operational complexity of 513 publishing unique TLSA RRs for each TLS service. If the domain 514 employs a common issuing certificate authority to create certificates 515 for multiple TLS services, it may be simpler to publish the issuing 516 authority's public key as a trust-anchor for the certificate chains 517 of all relevant services. The TLSA RRs for each service issued by 518 the same TA may then be CNAMEs to a common TLSA RRset that matches 519 the TA. In this case, the certificate chain presented in the TLS 520 handshake of each service SHOULD include the TA certificate, as SMTP 521 clients cannot generally be expected to have domain-issued trust- 522 anchor certificates in their trusted certificate store. TLSA 523 Publishers should publish either "2 1 1" or "2 0 1" TLSA parameters, 524 which specify the SHA-256 digest of the trust-anchor public key or 525 certificate respectively. As with leaf certificate rollover 526 discussed in Section 2.2.1.1, two such TLSA RRs need to be published 527 to facilitate TA certificate rollover. 529 The usability of "2 1 1" or "2 0 1" TLSA RRs with SMTP is not 530 assured. If server operators employing these RRs universally ensure 531 that the corresponding TA certificate is included in the SMTP 532 server's TLS handshake certificate chain, clients can safely enable 533 support for these RRs. If sufficiently many server administrators 534 negligently omit the TA certificate from the server's TLS certificate 535 chain, SMTP clients will be hesitant to support usage "2" TLSA RRs, 536 since mail delivery will not work to many destination domains if they 537 do. Server operators are encouraged to implement these RRs, if they 538 are operationally a better fit for their organization, provided they 539 do so with care. It is critical to not forget to include trust- 540 anchor certificates in server trust chains. SMTP client 541 implementations SHOULD support these TLSA RRs, unless, despite the 542 above warning, a non-trivial fraction of server operators fail to 543 publish certificate chains that include the required TA certificate. 545 2.2.1.3. Certificate usages 0 and 1 547 SMTP servers SHOULD NOT publish TLSA RRs with certificate usage "0" 548 or "1". SMTP clients cannot be expected to be configured with a 549 suitably complete set of trusted public CAs. Even with a full set of 550 public CAs, SMTP clients cannot (without relying on DNSSEC for secure 551 MX records) perform [RFC6125] server identity verification. 553 SMTP client treatment of TLSA RRs with certificate usages "0" or "1" 554 is undefined. For example, clients MAY (will likely) treat such TLSA 555 records as unusable. 557 2.2.2. Certificate matching 559 When at least one usable "secure" TLSA record is found, the SMTP 560 client SHOULD use TLSA records to authenticate the next-hop host, 561 mail SHOULD not be delivered via this next-hop host if authentication 562 fails, otherwise the SMTP client is vulnerable to TLS man in the 563 middle attacks. 565 To match a server via a TLSA record with certificate usage "2", the 566 client MUST perform name checks to ensure that it has reached the 567 correct server. In all cases the SMTP client MUST accept the TLSA 568 base domain as a valid DNS name in the server certificate. 570 MX: If the TLSA base domain was obtained indirectly via an MX lookup 571 (it is the name of an MX exchange that may be securely CNAME 572 expanded), then the initial query name used in the MX lookup 573 SHOULD be accepted in the peer certificate. The CNAME-expanded 574 initial query name SHOULD also be accepted if different from the 575 initial query name. 577 Non-MX: If no MX records were found and the TLSA base domain is the 578 CNAME-expanded initial query name, then the initial query name 579 SHOULD also be accepted. 581 Accepting certificates with the next-hop domain in addition to the 582 next-hop MX host allows a domain with multiple MX hosts to field a 583 single certificate bearing the email domain name across all the MX 584 hosts, this is also compatible with pre-DANE SMTP clients that are 585 configured to look for the email domain name in server certificates. 587 The SMTP client MUST NOT perform certificate usage name checks with 588 certificate usage "3", since with usage "3" the server is 589 authenticated directly by matching the TLSA RRset to its certificate 590 or public key without resort to any issuing authority. The 591 certificate content is ignored except in so far as it is used to 592 match the certificate or public key (ASN.1 object or its digest) with 593 the TLSA RRset. 595 To ensure that the server sends the right certificate chain, the SMTP 596 client MUST send the TLS SNI extension containing the TLSA base 597 domain. Since DANE-aware clients are obligated to send SNI 598 information, which requires at least TLS 1.0, SMTP servers for which 599 DANE TLSA records are published MUST support TLS 1.0 or later with 600 any client authorized to use the service. 602 Each SMTP server MUST present a certificate chain (see [RFC2246] 603 Section 7.4.2) that matches at least one of the TLSA records. The 604 server MAY rely on SNI to determine which certificate chain to 605 present to the client. Clients that don't send SNI information may 606 not see the expected certificate chain. 608 If the server's TLSA RRset includes records with a matching type 609 indicating a digest record (i.e., a value other than "0"), the 610 SHA-256 digest of any object SHOULD be provided along with any other 611 digest published, since clients may support only SHA-256. Unless 612 SHA-256 proves vulnerable to a "second preimage" attack, it should be 613 the only digest algorithm used in TLSA records. 615 If the server's TLSA records match the server's default certificate 616 chain, the server need not support SNI. The server need not include 617 the extension in its TLS HELLO, simply returning a matching 618 certificate chain is sufficient. Servers MUST NOT enforce the use of 619 SNI by clients, if the client sends no SNI extension, or sends an SNI 620 extension for an unsupported domain the server MUST simply use its 621 default certificate chain. The client may be using unauthenticated 622 opportunistic TLS and may not expect any particular certificate from 623 the server. 625 The client may even offer to use anonymous TLS ciphersuites and 626 servers SHOULD support these. No security is gained by sending a 627 certificate the client is willing to ignore. Indeed support for 628 anonymous ciphersuites in the server makes audit trails more useful 629 when the chosen ciphersuite is logged, as this will in many cases 630 record which clients did not care to authenticate the server. (The 631 Postfix SMTP server supports anonymous TLS ciphersuites by default, 632 and the Postfix SMTP client offers these at its highest preference 633 when server authentication is not applicable). 635 With opportunistic DANE TLS, both the TLS support implied by the 636 presence of DANE TLSA records and the verification parameters 637 necessary to authenticate the TLS peer are obtained together, 638 therefore authentication via this protocol is expected to be less 639 prone to connection failure caused by incompatible configuration of 640 the client and server. 642 3. Opportunistic TLS for Submission 644 Prior to [RFC6409], the SMTP submission protocol was a poster-child 645 for PKIX TLS. The MUA typically connects to one or more submission 646 servers explicitly configured by the user. There is no indirection 647 via insecure MX records, and unlike web browsers, there is no need to 648 authenticate a large set of TLS servers. Once TLS is enabled for the 649 desired submission server or servers, provided the server certificate 650 is correctly maintained, the MUA is able to reliably use TLS to 651 authenticate the submission server. 653 [RFC6186] aims to simplify the configuration of the MUA submission 654 service by dynamically deriving the submission service from the 655 user's email address. This is done via SRV records, but at the cost 656 of introducing the same TLS security problems faced by MTA to MTA 657 SMTP. Prompting the user when the SRV record domain is different 658 from the email domain is not a robust solution. 660 The protocol defined in this memo can also be used to secure 661 submission service discovery. If the email domain is DNSSEC signed, 662 the SRV records are "secure" and the SRV host publishes secure TLSA 663 records for submission, then the MUA can safely auto-configure to 664 authenticate the submission server via DANE. When DANE TLSA records 665 are not available, the client SHOULD fall back to legacy behavior 666 (this may involve prompting the user to accept the resulting server 667 and perhaps "pin" its certificate). 669 Specifically, MUAs that dynamically determine the submission server 670 via SRV records SHOULD support DNSSEC and DANE TLSA records. They 671 SHOULD use TLSA records to authenticate the server. The processing 672 of usage 2 and 3 TLSA associations by an MUA is the same as by an MTA 673 with SRV records replaced by corresponding MX records. 675 Just as with MX service on port 25, SMTP submission servers SHOULD 676 NOT publish usage 0 or 1 TLSA associations, and MUAs that support 677 DANE TLSA are not expected to trust a full list of public CAs. 678 Server certificate subjectAltNames should include at least the server 679 name. When the server administrator is able to obtain a certificate 680 for the email domain, the server certificate should also include the 681 email domain name. MUAs that are not able to support DNSSEC may then 682 be able to authenticate the server domain. If it is practical to 683 field additional certificates for hosted domains, SNI may be used by 684 the server to select the appropriate domain's certificate. 686 4. Mandatory TLS Security 688 An MTA implementing this protocol may require a stronger security 689 assurance when sending email to selected destinations to which the 690 sending organization sends sensitive email and may have regulatory 691 obligations to protect its content. This protocol is not in conflict 692 with such a requirement, and in fact it can often simplify 693 authenticated delivery to such destinations. 695 Specifically, with domains that publish DANE TLSA records for their 696 MX hosts a sending MTA can be configured to use the receiving 697 domains's DANE TLSA records to authenticate the corresponding MX 698 hosts, thereby obviating the complex manual provisioning process. In 699 anticipation of, or in response to, a failure to obtain the expected 700 TLSA records, the sending system's administrator may choose from a 701 selection of fallback options, if supported by the sending MTA: 703 o Defer mail if no usable TLSA records are found. This is useful 704 when the destination is known to publish TLSA records, and lack of 705 TLSA records is most likely a transient misconfiguration. 707 o Authenticate the peer via a manually configured certificate 708 digest. This may be obtained, for example, after a problem is 709 detected and confirmed to be valid by some out-of-band mechanism. 711 o Authenticate the peer via the existing public CA PKI, if the peer 712 server has usable CA issued certificates. In many cases the 713 sending MTA will need custom certificate name matching rules to 714 match the destination's gateways. And the sending server must 715 explicitly configure policy for the destination to always require 716 TLS to prevent MITM attacks. 718 o Send via unauthenticated mandatory TLS. This is useful if the 719 requirement is merely to always encrypt transmissions to protect 720 against only eavesdropping, and the possibility of MITM attacks is 721 less of a concern than timely email delivery. 723 It should be noted that barring administrator intervention, email 724 SHOULD be deferred when DNSSEC lookups fail, (as distinct from 725 "secure" non-existence of TLSA records, or secure evidence that the 726 domain is no longer signed). In addition to configuring fallback 727 strategies when TLSA records are unexpectedly absent, administrators 728 may, in hopefully rare cases, need to disable DNSSEC lookups for a 729 destination to work around a DNSSEC outage. 731 5. Acknowledgements 733 The authors would like to extend great thanks to Tony Finch, who 734 started the original version of a DANE SMTP document. His work is 735 greatly appreciated and has been incorporated into this document. 736 The authors would like to additionally thank Phil Pennock for his 737 comments and advice on this document. 739 Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded 740 me into participating in DANE working group discussions. Thanks to 741 Paul Hoffman who motivated me to produce this memo and provided 742 feedback on early drafts. Thanks also to Wietse Venema who created 743 Postfix, and patiently guided the Postfix DANE implementation to 744 production quality. 746 6. Security Considerations 748 This protocol leverages DANE TLSA records to implement MITM resistant 749 opportunistic channel security for SMTP. For destination domains 750 that sign their MX records and publish signed TLSA records for their 751 MX hosts, this protocol allows sending MTAs (and perhaps dynamically 752 configured MUAs) to securely discover both the availability of TLS 753 and how to authenticate the destination. 755 This protocol does not aim to secure all SMTP traffic, as that is not 756 practical until DNSSEC and DANE adoption are universal. The 757 incremental deployment provided by following this specification is a 758 best possible path for securing SMTP. This protocol coexists and 759 interoperates with the existing insecure Internet email backbone. 761 The protocol does not preclude existing non-opportunistic SMTP TLS 762 security arrangements, which can continue to be used as before via 763 manual configuration and negotiated out-of-band key and TLS 764 configuration exchanges. 766 Opportunistic SMTP TLS depends critically on DNSSEC for downgrade 767 resistance and secure resolution of the destination name. If DNSSEC 768 is compromised, it is not possible to fall back on the public CA PKI 769 to prevent MITM attacks. A successful breach of DNSSEC enables the 770 attacker to publish TLSA usage 3 certificate associations, and 771 thereby bypass any security benefit the legitimate domain owner might 772 hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of 773 public CA PKI support in existing MTA deployments, deprecating 774 certificate usages 0 and 1 in this specifications improves 775 interoperability without degrading security. 777 7. Normative References 779 [I-D.ietf-dane-ops] 780 Dukhovni, V. and W. Hardaker, "DANE TLSA implementation 781 and operational guidance", draft-ietf-dane-ops-00 (work in 782 progress), October 2013. 784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, March 1997. 787 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 788 RFC 2246, January 1999. 790 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 791 Transport Layer Security", RFC 3207, February 2002. 793 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 794 and T. Wright, "Transport Layer Security (TLS) 795 Extensions", RFC 3546, June 2003. 797 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 798 Rose, "DNS Security Introduction and Requirements", RFC 799 4033, March 2005. 801 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 802 Rose, "Resource Records for the DNS Security Extensions", 803 RFC 4034, March 2005. 805 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 806 Rose, "Protocol Modifications for the DNS Security 807 Extensions", RFC 4035, March 2005. 809 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 810 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 812 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 813 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 815 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 816 Housley, R., and W. Polk, "Internet X.509 Public Key 817 Infrastructure Certificate and Certificate Revocation List 818 (CRL) Profile", RFC 5280, May 2008. 820 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 821 October 2008. 823 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 824 Extension Definitions", RFC 6066, January 2011. 826 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 827 Verification of Domain-Based Application Service Identity 828 within Internet Public Key Infrastructure Using X.509 829 (PKIX) Certificates in the Context of Transport Layer 830 Security (TLS)", RFC 6125, March 2011. 832 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 833 Submission/Access Services", RFC 6186, March 2011. 835 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 836 STD 72, RFC 6409, November 2011. 838 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 839 of Named Entities (DANE) Transport Layer Security (TLS) 840 Protocol: TLSA", RFC 6698, August 2012. 842 Authors' Addresses 844 Viktor Dukhovni 845 Unaffiliated 847 Email: ietf-dane@dukhovni.org 849 Wes Hardaker 850 Parsons 851 P.O. Box 382 852 Davis, CA 95617 853 US 855 Email: ietf@hardakers.net