idnits 2.17.1 draft-ietf-dane-smtp-with-dane-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 : ---------------------------------------------------------------------------- ** 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: 2.2.2. Certificate matching 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 (November 24, 2013) is 3807 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) == Unused Reference: 'RFC3546' is defined on line 865, but no explicit reference was found in the text == Unused Reference: 'RFC4346' is defined on line 881, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 887, 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: Standards Track W.H. Hardaker 5 Expires: May 28, 2014 Parsons 6 November 24, 2013 8 SMTP security via opportunistic DANE TLS 9 draft-ietf-dane-smtp-with-dane-03 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 May 28, 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 . . . . . . . . . . . . . . . . . . . 11 64 2.2.1. TLSA certificate usages . . . . . . . . . . . . . . . 11 65 2.2.2. Certificate matching . . . . . . . . . . . . . . . . 12 66 2.2.3. Digest algorithm agility . . . . . . . . . . . . . . 14 67 3. Opportunistic TLS for Submission . . . . . . . . . . . . . . 16 68 4. Mandatory TLS Security . . . . . . . . . . . . . . . . . . . 17 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 71 7. Normative References . . . . . . . . . . . . . . . . . . . . 19 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 74 1. Introduction 76 Lacking verified DNS and "Server Name Indication" (SNI), there has 77 historically been no scalable way for SMTP server operators to deploy 78 certificates with a client-trusted subject name. It's only with the 79 deployment of DNSSEC and DANE that authenticated TLS for SMTP to MX 80 becomes possible between parties that have not already established an 81 identity convention out-of-band. 83 1.1. Background 85 The Domain Name System Security Extensions (DNSSEC) add data origin 86 authentication and data integrity to the Domain Name System. DNSSEC 87 is defined in [RFC4033], [RFC4034] and [RFC4035]. 89 As described in the introduction of [RFC6698], TLS authentication via 90 the existing public Certificate Authority (CA) Public Key 91 Infrastructure (PKI) suffers from an over-abundance of trusted 92 certificate authorities capable of issuing certificates for any 93 domain of their choice. DNS-Based Authentication of Named Entities 94 (DANE) leverages the DNSSEC infrastructure to publish trusted keys 95 and certificates for use with TLS via a new TLSA record type. With 96 DANE, the public CA PKI can be augmented or replaced by DNSSEC 97 validated TLSA records. 99 The Transport Layer Security (TLS [RFC5246]) protocol enables secure 100 TCP communication. In the context of this memo, channel security is 101 assumed to be provided by TLS. Used without authentication, TLS 102 protects only against eavesdropping. With authentication, TLS also 103 protects against man-in-the-middle (MITM) attacks. 105 1.2. SMTP Channel Security 107 The Simple Mail Transfer Protocol (SMTP) ([RFC5321]) is multi-hop 108 store & forward, while TLS security is hop-by-hop. The number of 109 hops from the sender's Mail User Agent to the recipient mailbox is 110 rarely less than 2 and is often higher. Some hops may be TLS 111 protected, some may not. The same SMTP TCP endpoint can serve both 112 TLS and non-TLS clients, with TLS negotiated via the SMTP STARTTLS 113 command ([RFC3207]). DNS MX records abstract the next-hop transport 114 end-point. SMTP addresses are not transport addresses and are 115 security agnostic. Unlike HTTP, there is no URI scheme for email 116 addresses to designate whether the SMTP server should be contacted 117 with or without security. 119 A Mail Transport Agent (MTA) may need to forward a message to a 120 particular email recipient . To deliver the 121 message, the MTA needs to retrieve the MX hosts of example.com from 122 DNS, and then deliver the message to one of them. Absent DNSSEC, the 123 MX lookup is vulnerable to man-in-the-middle and cache poisoning 124 attacks. An active attacker can forge DNS replies with fake MX 125 records, and can direct traffic to a server of his choice. 126 Therefore, secure verification of MX host certificates is not 127 possible without DNSSEC. A man in the middle can also suppress the 128 MX host's STARTTLS EHLO response, convincing the client that 129 communication over TLS is unavailable. 131 One might try to harden STARTTLS with SMTP against DNS attacks by 132 requiring each MX host to posess an X.509 certificate for the 133 recipient domain that is obtained from the message envelope and is 134 not subject to DNS reply forgery. Unfortunately, this is 135 impractical, as email for many domains is handled by third parties, 136 which are not in a position to obtain certificates for all the 137 domains they serve. Deployment of SNI (see [RFC6066] Section 3.1) is 138 no panacea, since SNI key management is operationally challenging 139 except when the email service provider is also the domain's registrar 140 and its certificate issuer; this is rarely the case for email. 142 Since the recipient domain name cannot be used as the SMTP server 143 authentication identity, and neither can the MX hostname without 144 DNSSEC, large scale deployment of authenticated TLS for SMTP requires 145 secure DNS. At this time, DNSSEC is not yet widely deployed and MTA 146 to MTA traffic between Internet connected organizations rarely uses 147 TLS at all, or simply uses TLS opportunistically without 148 authentication and protects against only passive eavesdropping 149 attacks. 151 The exceptions are cases in which the sending MTA is statically 152 configured to use TLS for mail sent to specific selected peer domains 153 and is configured with appropriate subject names (or content digests) 154 to expect in the presented MX host certificates of those domains. 155 Such statically configured SMTP secure channels are used rarely, 156 generally between domains that make bilateral arrangements with their 157 business partners. Internet email, on the other hand, requires 158 contacting many new domains for which security configurations can not 159 be established in advance. 161 Note, the above does not apply to mail submission [RFC6409], where a 162 mail user agent is pre-configured to send all email to a fixed Mail 163 Submission Agent (MSA). Submission servers usually offer TLS and the 164 Mail User Agent (MUA) can be statically configured to require TLS 165 with its chosen MSA. The situation changes when submission servers 166 are configured dynamically via SRV records (see [RFC6186] Section 6). 167 Applications to submission via SRV records will be discussed later in 168 this memo. 170 With little opportunity to use TLS authentication, MX hosts that 171 support STARTTLS often use self-signed or private CA issued X.509 172 certificates. Sending systems are rarely configured with a 173 comprehensive list of trusted CAs and do not check CRLs or implement 174 OCSP. In essence, they don't and can't rely on the existing public 175 CA PKI. This is not a result of complacency on the part SMTP server 176 administrators and MTA developers. Nor is it just a consequence of 177 the relative maturity of the SMTP infrastructure at the time that TLS 178 was introduced. Rather, the abstraction of the SMTP transport 179 endpoint via DNS MX records, often across organization boundaries, 180 limits the use of public CA PKI with SMTP to a small set of sender- 181 configured peer domains. 183 This does not mean, however, that the Internet email backbone cannot 184 benefit from TLS. The fact that transport security is not explicitly 185 specified in either the recipient address or the MX record means that 186 new protocols can furnish out-of-band information to SMTP, making it 187 possible to simultaneously discover both which peer domains support 188 secure delivery via TLS and how to verify the authenticity of the 189 associated MX hosts. The first such mechanism that can work an 190 Internet scale is DANE TLSA, but use of DANE TLSA with MTA to MTA 191 SMTP must be cognizant of the lack of any realistic role for the 192 existing public CA PKI. 194 1.3. Terminology 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in [RFC2119]. 200 2. Hardening Opportunistic TLS 202 This memo describes opportunistic SMTP over TLS security, where 203 traffic from DANE TLSA aware SMTP clients to domains that implement 204 DANE TLSA records in accordance with this memo is secure. Traffic to 205 other domains continues to be sent in the same manner as before 206 (either manually configured for security or unauthenticated and often 207 unencrypted). It is hoped that, over time, more domains will 208 implement DNSSEC and publish DANE TLSA records for their MX hosts. 209 This will enable an incremental transition of the email backbone to 210 authenticated TLS delivery. 212 Since email addresses and MX hostnames (or submission SRV records) 213 neither signal nor deny support for TLS by the receiving domain, it 214 is possible to use DANE TLSA records to securely signal TLS support 215 and simultaneously to provide the means by which SMTP clients can 216 successfully authenticate legitimate SMTP servers. 218 2.1. TLS discovery 220 As noted previously (Section 1.2), opportunistic TLS with SMTP 221 servers that advertise TLS support via STARTTLS is subject to a man 222 in the middle downgrade attack. Some SMTP servers erroneously 223 advertise STARTTLS in default configurations that are not, in fact, 224 TLS capable, and clients need to be prepared to retry plaintext 225 delivery after STARTTLS fails. This memo specifies a downgrade 226 resistant mechanism that allows a server to advertise TLS support 227 based on DANE TLSA records. DNSSEC validated TLSA records are 228 unlikely to be accidentally published for servers that do not in fact 229 support TLS, and thus clients can safely interpret their presence as 230 a commitment by the server operator to implement STARTTLS. 232 SMTP is a store & forward protocol. An MTA that is not the final 233 destination for a message recipient forwards the message one hop 234 closer to the recipient's mailbox. To do so, it must determine the 235 appropriate next-hop destination, and locate one or more associated 236 SMTP servers. When DNSSEC validated TLSA records are available for a 237 given next-hop SMTP server, the TLS connection to that server will be 238 downgrade resistant. If the records in question are "usable" 239 ([RFC6698], Section 4.1) to authenticate the server, the connection 240 will also be authenticated and thus immune to eavesdropping or 241 tampering (unless DNSSEC itself is compromised). 243 Typically, the next-hop destination will be the domain part of the 244 recipient address, which is then subject to MX resolution. The next- 245 hop destination may also be configured by the MTA administrator to be 246 a next-hop destination host (explicitly exempt from MX resolution), 247 or a next-hop destination domain (subject to MX resolution) which 248 takes the place of the domain part of the recipient address. 250 The protocol in this memo is "opportunistic"; it should be used 251 whenever possible but communication should continue when it is not 252 available. Absent "secure" (DNSSEC validated) TLSA records, mail 253 delivery should fall back to pre-DANE opportunistic TLS. The SMTP 254 client MAY be configured to require DANE verified delivery for some 255 or all destinations, in which case mail delivery will be deferred 256 when "secure" TLSA records are absent. 258 Below we explain how to determine for a given next-hop destination 259 the associated SMTP servers, the TLSA base domain and TLSA records. 261 2.1.1. Non-MX destinations 263 As mentioned above, the next-hop destination domain may in some cases 264 be exempt from MX lookups. In addition, MX lookups for the next-hop 265 domain may yield no results. In either case, the destination server 266 for such a domain is determined by looking up the corresponding A or 267 AAAA records. 269 When "bogus" records are encountered either during CNAME expansion, 270 or when retrieving the associated TLSA RRset, the SMTP client MUST 271 proceed as if the next-hop domain were unreachable. Delivery should 272 either be deferred or may be attempted via any fallback next-hop 273 configured by the SMTP client administrator. Fallback next-hop 274 destinations may also employ opportunistic DANE TLS. Proceeding with 275 the original next-hop despite "bogus" DNS responses would destroy 276 protection against downgrade attacks. 278 Following [RFC5321] Section 5.1, if the A or AAAA lookup of the 279 initial name yields a CNAME, we replace it with the resulting name as 280 if it were the initial name and perform a lookup again using the new 281 name. This replacement is performed recursively, although MTAs 282 typically support only limited recursion in CNAME expansion. We 283 consider the following cases: 285 Non-CNAME: The next-hop destination domain is not a CNAME alias. 286 The lookup key for the DNSSEC validated TLSA records is obtained 287 by prepending service labels ("_._tcp") to the 288 initial next-hop destination domain. If associated "secure" TLSA 289 records are found (see Section 2.1.3) the TLSA base domain is the 290 next-hop domain. If no secure TLSA records are found, 291 opportunistic DANE TLS is not applicable and mail delivery 292 proceeds with pre-DANE opportunistic TLS. 294 Insecure CNAME: The next-hop destination domain is a CNAME alias, 295 but at least one of the CNAME RRs leading to the ultimate target 296 of this alias (during recursive CNAME expansion) is "insecure". 297 We treat this case just like the non-CNAME case above. 299 Secure CNAME, no TLSA: The next-hop destination domain is a CNAME 300 alias, and all the CNAME RRs leading to the ultimate target of 301 this alias (during recursive CNAME expansion) are "secure" (DNSSEC 302 validated), but no "secure" TLSA RRs are found after prefixing the 303 service labels to the CNAME-expanded next-hop domain. This case 304 is also treated just like the non-CNAME case. 306 Secure CNAME, TLSA: The next-hop destination domain is a CNAME 307 alias, all the CNAME RRs leading to the ultimate target of this 308 alias (during recursive CNAME expansion) are "secure", and in 309 addition "secure" TLSA RRs are found after prefixing the service 310 labels to the CNAME-expanded next-hop domain. In this case the 311 CNAME-expanded next-hop domain is taken as the TLSA base domain. 312 The original next-hop domain is (see Section 2.2.2) used only as 313 an alternative name in certificate peername verification if 314 applicable. 316 In summary, if it is possible to securely obtain the full, CNAME- 317 expanded, DNSSEC-validated address records for the non-MX next-hop 318 domain then that name is the preferred TLSA base domain. If that is 319 not possible, then the original next-hop domain is used as the TLSA 320 base domain. When no "secure" TLSA records are found at either the 321 CNAME expanded or original next-hop domain, then opportunistic DANE 322 TLS does not apply for mail delivery to the non-MX destination in 323 question. 325 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 511 Some domains may prefer to reduce the operational complexity of 512 publishing unique TLSA RRs for each TLS service. If the domain 513 employs a common issuing certificate authority to create certificates 514 for multiple TLS services, it may be simpler to publish the issuing 515 authority's public key as a trust-anchor for the certificate chains 516 of all relevant services. The TLSA RRs for each service issued by 517 the same TA may then be CNAMEs to a common TLSA RRset that matches 518 the TA. In this case, the certificate chain presented in the TLS 519 handshake of each service SHOULD include the TA certificate, as SMTP 520 clients cannot generally be expected to have domain-issued trust- 521 anchor certificates in their trusted certificate store. TLSA 522 Publishers should publish either "2 1 1" or "2 0 1" TLSA parameters, 523 which specify the SHA-256 digest of the trust-anchor public key or 524 certificate respectively. As with leaf certificate rollover 525 discussed in Section 2.2.1.1, two such TLSA RRs need to be published 526 to facilitate TA certificate rollover. 528 The usability of "2 1 1" or "2 0 1" TLSA RRs with SMTP is not 529 assured. If server operators employing these RRs universally ensure 530 that the corresponding TA certificate is included in the SMTP 531 server's TLS handshake certificate chain, clients can safely enable 532 support for these RRs. If sufficiently many server administrators 533 negligently omit the TA certificate from the server's TLS certificate 534 chain, SMTP clients will be hesitant to support usage "2" TLSA RRs, 535 since mail delivery will not work to many destination domains if they 536 do. Server operators are encouraged to implement these RRs, if they 537 are operationally a better fit for their organization, provided they 538 do so with care. It is critical to not forget to include trust- 539 anchor certificates in server trust chains. SMTP client 540 implementations SHOULD support these TLSA RRs, unless, despite the 541 above warning, a non-trivial fraction of server operators fail to 542 publish certificate chains that include the required TA certificate. 544 2.2.1.3. Certificate usages 0 and 1 546 SMTP servers SHOULD NOT publish TLSA RRs with certificate usage "0" 547 or "1". SMTP clients cannot be expected to be configured with a 548 suitably complete set of trusted public CAs. Even with a full set of 549 public CAs, SMTP clients cannot (without relying on DNSSEC for secure 550 MX records) perform [RFC6125] server identity verification. 552 SMTP client treatment of TLSA RRs with certificate usages "0" or "1" 553 is undefined. For example, clients MAY (will likely) treat such TLSA 554 records as unusable. 556 2.2.2. Certificate matching 557 When at least one usable "secure" TLSA record is found, the SMTP 558 client SHOULD use TLSA records to authenticate the next-hop host, 559 mail SHOULD not be delivered via this next-hop host if authentication 560 fails, otherwise the SMTP client is vulnerable to TLS man in the 561 middle attacks. 563 To match a server via a TLSA record with certificate usage "2", the 564 client MUST perform name checks to ensure that it has reached the 565 correct server. In all cases the SMTP client MUST accept the TLSA 566 base domain as a valid DNS name in the server certificate. 568 MX: If the TLSA base domain was obtained indirectly via an MX lookup 569 (it is the name of an MX exchange that may be securely CNAME 570 expanded), then the initial query name used in the MX lookup 571 SHOULD be accepted in the peer certificate. The CNAME-expanded 572 initial query name SHOULD also be accepted if different from the 573 initial query name. 575 Non-MX: If no MX records were found and the TLSA base domain is the 576 CNAME-expanded initial query name, then the initial query name 577 SHOULD also be accepted. 579 Accepting certificates with the next-hop domain in addition to the 580 next-hop MX host allows a domain with multiple MX hosts to field a 581 single certificate bearing the email domain name across all the MX 582 hosts, this is also compatible with pre-DANE SMTP clients that are 583 configured to look for the email domain name in server certificates. 585 The SMTP client MUST NOT perform certificate usage name checks with 586 certificate usage "3", since with usage "3" the server is 587 authenticated directly by matching the TLSA RRset to its certificate 588 or public key without resort to any issuing authority. The 589 certificate content is ignored except in so far as it is used to 590 match the certificate or public key (ASN.1 object or its digest) with 591 the TLSA RRset. 593 To ensure that the server sends the right certificate chain, the SMTP 594 client MUST send the TLS SNI extension containing the TLSA base 595 domain. This precludes the use of SSLv2-compatible SSL HELLO by the 596 SMTP client. The minimum SSL/TLS version for SMTP clients performing 597 DANE authentication is SSLv3. 599 Each SMTP server MUST present a certificate chain (see [RFC2246] 600 Section 7.4.2) that matches at least one of the TLSA records. The 601 server MAY rely on SNI to determine which certificate chain to 602 present to the client. Clients that don't send SNI information may 603 not see the expected certificate chain. 605 If the server's TLSA RRset includes records with a matching type 606 indicating a digest record (i.e., a value other than "0"), the 607 SHA-256 digest of any object SHOULD be provided along with any other 608 digest published, since clients may support only SHA-256. Unless 609 SHA-256 proves vulnerable to a "second preimage" attack, it should be 610 the only digest algorithm used in TLSA records. 612 If the server's TLSA records match the server's default certificate 613 chain, the server need not support SNI. The server need not include 614 the extension in its TLS HELLO, simply returning a matching 615 certificate chain is sufficient. Servers MUST NOT enforce the use of 616 SNI by clients, if the client sends no SNI extension, or sends an SNI 617 extension for an unsupported domain the server MUST simply use its 618 default certificate chain. The client may be using unauthenticated 619 opportunistic TLS and may not expect any particular certificate from 620 the server. 622 The SMTP client MAY include anonymous TLS ciphersuites in its SSL 623 HELO. MX hosts that receive email from the Internet MUST 624 interoperate with opportunistic TLS SMTP clients. If they advertise 625 support for STARTTLS in their SMTP EHLO response, they MUST NOT fail 626 to complete the TLS handshake merely because the SMTP client offered 627 some ciphersuites that do not provide for server authentication. 629 While server operators are under no obligation to implement or enable 630 anonymous ciphers, no security is gained by sending certificates 631 clients are willing to ignore. Indeed support for anonymous 632 ciphersuites in the server makes audit trails more useful when the 633 chosen ciphersuite is logged, as this will in many cases record which 634 clients did not care to authenticate the server. For example, the 635 Postfix SMTP server enables anonymous TLS ciphersuites by default, 636 and the Postfix SMTP client offers these at its highest preference 637 when server authentication is not applicable. 639 With opportunistic DANE TLS, both the TLS support implied by the 640 presence of DANE TLSA records and the verification parameters 641 necessary to authenticate the TLS peer are obtained together, 642 therefore authentication via this protocol is expected to be less 643 prone to connection failure caused by incompatible configuration of 644 the client and server. 646 2.2.3. Digest algorithm agility 647 While [RFC6698] specifies multiple digest algorithms it does not 648 explicitly specify a protocol by which the publisher can agree on the 649 strongest shared algorithm, and thereby avoind exposure to any 650 deprecated weaker algorithms that are published out of 651 interoperability concerns, but should if possible be ignored. We 652 specify such a protocol below. 654 Suppose that a DANE TLS client authenticating TLS server considers 655 digest algorithm X stronger than digest algorithm Y. Suppose further 656 that that a server's TLSA RRset contains some records with X as the 657 digest algorithm. Suppose that for every raw public key or 658 certificate object that is included in the server's TLSA RRset in 659 digest form, whenever that object appears with digest Y (with some 660 usage and selector) it also appears with digest X (with the same 661 usage and selector). In that case our client can safely ignore TLSA 662 records with the weaker digest Y, because it suffices to check the 663 records with the stronger algorithm X. 665 We take the simplest appraoch and mandate that all published TLSA 666 RRsets conform to the above assumptions. Then clients can 667 unconditionally ignore all but the (equal) strongest digest records 668 with a given usage and selector. 670 Records with a matching type of "0", that publish the verbatim object 671 value play no role in digest algorithm agility. They neither preempt 672 the processing of records that employ digests, nor are they ignored 673 in the presence of any digest records. 675 Therefore, server operators MUST ensure that for any given usage and 676 selector, ALL objects with certificate association data with that 677 usage and selector that are published with a digest matching type are 678 published with the SAME SET of digests (non-zero matching types). In 679 other words, for each usage and selector, the records with non-zero 680 matching types will be a cross-product of a set of underlying objects 681 and a fixed set of digests that apply uniformly to all the objects. 683 SMTP clients SHOULD use digest algorithm agility when processing the 684 DANE TLSA records of an SMTP server. Algorithm agility is to be 685 applied after first discarding any unusable or malformed records 686 (unsupported digest algorithm, or incorrect digest length). Thus, 687 for each usage and selector, the client SHOULD only process any 688 usable records with a matching type of "0" and any usable records 689 whose digest is the strongest among usable records with the same 690 usage and selector. 692 The main impact of this requirement is on key rotation, when the TLSA 693 RRset is pre-populated with digests of new certificates or public 694 keys, before these replace their predecessors. Were the newly 695 introduced RRs to include previously unused digest algorithms, 696 clients that employ this protocol could potentially ignore all the 697 digests corresponding to the currently deployed certificates causing 698 connectivity issues until new keys or certificates are fielded. 699 Similarly, publishing new records with fewer digests could cause 700 problems once the new keys are deployed. 702 Therefore, server operators SHOULD follow the following rule. When 703 adding or removing objects from the TLSA RRset (e.g. during key 704 rotation), DO NOT change the set of digests used, change just the 705 list of objects. When changing the set of digests used, change only 706 the digests, and generate a new RRset in which all the existing 707 objects are re-published with the new set of digests. 709 The client-side of this "digest algorithm agility" protocol is 710 enabled by default in the first DANE for SMTP implementation. For 711 key rotation to work non-disruptively server operators MUST ensure 712 that their TLSA records conform with the above specification. 714 3. Opportunistic TLS for Submission 716 Prior to [RFC6409], the SMTP submission protocol was a poster-child 717 for PKIX TLS. The MUA typically connects to one or more submission 718 servers explicitly configured by the user. There is no indirection 719 via insecure MX records, and unlike web browsers, there is no need to 720 authenticate a large set of TLS servers. Once TLS is enabled for the 721 desired submission server or servers, provided the server certificate 722 is correctly maintained, the MUA is able to reliably use TLS to 723 authenticate the submission server. 725 [RFC6186] aims to simplify the configuration of the MUA submission 726 service by dynamically deriving the submission service from the 727 user's email address. This is done via SRV records, but at the cost 728 of introducing the same TLS security problems faced by MTA to MTA 729 SMTP. Prompting the user when the SRV record domain is different 730 from the email domain is not a robust solution. 732 The protocol defined in this memo can also be used to secure 733 submission service discovery. If the email domain is DNSSEC signed, 734 the SRV records are "secure" and the SRV host publishes secure TLSA 735 records for submission, then the MUA can safely auto-configure to 736 authenticate the submission server via DANE. When DANE TLSA records 737 are not available, the client SHOULD fall back to legacy behavior 738 (this may involve prompting the user to accept the resulting server 739 and perhaps "pin" its certificate). 741 Specifically, MUAs that dynamically determine the submission server 742 via SRV records SHOULD support DNSSEC and DANE TLSA records. They 743 SHOULD use TLSA records to authenticate the server. The processing 744 of usage 2 and 3 TLSA associations by an MUA is the same as by an MTA 745 with SRV records replaced by corresponding MX records. 747 Just as with MX service on port 25, SMTP submission servers SHOULD 748 NOT publish usage 0 or 1 TLSA associations, and MUAs that support 749 DANE TLSA are not expected to trust a full list of public CAs. 750 Server certificate subjectAltNames should include at least the server 751 name. When the server administrator is able to obtain a certificate 752 for the email domain, the server certificate should also include the 753 email domain name. MUAs that are not able to support DNSSEC may then 754 be able to authenticate the server domain. If it is practical to 755 field additional certificates for hosted domains, SNI may be used by 756 the server to select the appropriate domain's certificate. 758 4. Mandatory TLS Security 760 An MTA implementing this protocol may require a stronger security 761 assurance when sending email to selected destinations to which the 762 sending organization sends sensitive email and may have regulatory 763 obligations to protect its content. This protocol is not in conflict 764 with such a requirement, and in fact it can often simplify 765 authenticated delivery to such destinations. 767 Specifically, with domains that publish DANE TLSA records for their 768 MX hosts a sending MTA can be configured to use the receiving 769 domains's DANE TLSA records to authenticate the corresponding MX 770 hosts, thereby obviating the complex manual provisioning process. In 771 anticipation of, or in response to, a failure to obtain the expected 772 TLSA records, the sending system's administrator may choose from a 773 selection of fallback options, if supported by the sending MTA: 775 o Defer mail if no usable TLSA records are found. This is useful 776 when the destination is known to publish TLSA records, and lack of 777 TLSA records is most likely a transient misconfiguration. 779 o Authenticate the peer via a manually configured certificate 780 digest. This may be obtained, for example, after a problem is 781 detected and confirmed to be valid by some out-of-band mechanism. 783 o Authenticate the peer via the existing public CA PKI, if the peer 784 server has usable CA issued certificates. In many cases the 785 sending MTA will need custom certificate name matching rules to 786 match the destination's gateways. And the sending server must 787 explicitly configure policy for the destination to always require 788 TLS to prevent MITM attacks. 790 o Send via unauthenticated mandatory TLS. This is useful if the 791 requirement is merely to always encrypt transmissions to protect 792 against only eavesdropping, and the possibility of MITM attacks is 793 less of a concern than timely email delivery. 795 It should be noted that barring administrator intervention, email 796 SHOULD be deferred when DNSSEC lookups fail, (as distinct from 797 "secure" non-existence of TLSA records, or secure evidence that the 798 domain is no longer signed). In addition to configuring fallback 799 strategies when TLSA records are unexpectedly absent, administrators 800 may, in hopefully rare cases, need to disable DNSSEC lookups for a 801 destination to work around a DNSSEC outage. 803 5. Acknowledgements 805 The authors would like to extend great thanks to Tony Finch, who 806 started the original version of a DANE SMTP document. His work is 807 greatly appreciated and has been incorporated into this document. 808 The authors would like to additionally thank Phil Pennock for his 809 comments and advice on this document. 811 Acknowledgments from Viktor: Thanks to Tony Finch who finally prodded 812 me into participating in DANE working group discussions. Thanks to 813 Paul Hoffman who motivated me to produce this memo and provided 814 feedback on early drafts. Thanks also to Wietse Venema who created 815 Postfix, and patiently guided the Postfix DANE implementation to 816 production quality. 818 6. Security Considerations 820 This protocol leverages DANE TLSA records to implement MITM resistant 821 opportunistic channel security for SMTP. For destination domains 822 that sign their MX records and publish signed TLSA records for their 823 MX hosts, this protocol allows sending MTAs (and perhaps dynamically 824 configured MUAs) to securely discover both the availability of TLS 825 and how to authenticate the destination. 827 This protocol does not aim to secure all SMTP traffic, as that is not 828 practical until DNSSEC and DANE adoption are universal. The 829 incremental deployment provided by following this specification is a 830 best possible path for securing SMTP. This protocol coexists and 831 interoperates with the existing insecure Internet email backbone. 833 The protocol does not preclude existing non-opportunistic SMTP TLS 834 security arrangements, which can continue to be used as before via 835 manual configuration and negotiated out-of-band key and TLS 836 configuration exchanges. 838 Opportunistic SMTP TLS depends critically on DNSSEC for downgrade 839 resistance and secure resolution of the destination name. If DNSSEC 840 is compromised, it is not possible to fall back on the public CA PKI 841 to prevent MITM attacks. A successful breach of DNSSEC enables the 842 attacker to publish TLSA usage 3 certificate associations, and 843 thereby bypass any security benefit the legitimate domain owner might 844 hope to gain by publishing usage 0 or 1 TLSA RRs. Given the lack of 845 public CA PKI support in existing MTA deployments, deprecating 846 certificate usages 0 and 1 in this specifications improves 847 interoperability without degrading security. 849 7. Normative References 851 [I-D.ietf-dane-ops] 852 Dukhovni, V. and W. Hardaker, "DANE TLSA implementation 853 and operational guidance", draft-ietf-dane-ops-00 (work in 854 progress), October 2013. 856 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 857 Requirement Levels", BCP 14, RFC 2119, March 1997. 859 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 860 RFC 2246, January 1999. 862 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 863 Transport Layer Security", RFC 3207, February 2002. 865 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 866 and T. Wright, "Transport Layer Security (TLS) 867 Extensions", RFC 3546, June 2003. 869 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 870 Rose, "DNS Security Introduction and Requirements", RFC 871 4033, March 2005. 873 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 874 Rose, "Resource Records for the DNS Security Extensions", 875 RFC 4034, March 2005. 877 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 878 Rose, "Protocol Modifications for the DNS Security 879 Extensions", RFC 4035, March 2005. 881 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 882 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 884 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 885 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 887 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 888 Housley, R., and W. Polk, "Internet X.509 Public Key 889 Infrastructure Certificate and Certificate Revocation List 890 (CRL) Profile", RFC 5280, May 2008. 892 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 893 October 2008. 895 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 896 Extension Definitions", RFC 6066, January 2011. 898 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 899 Verification of Domain-Based Application Service Identity 900 within Internet Public Key Infrastructure Using X.509 901 (PKIX) Certificates in the Context of Transport Layer 902 Security (TLS)", RFC 6125, March 2011. 904 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 905 Submission/Access Services", RFC 6186, March 2011. 907 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 908 STD 72, RFC 6409, November 2011. 910 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 911 of Named Entities (DANE) Transport Layer Security (TLS) 912 Protocol: TLSA", RFC 6698, August 2012. 914 Authors' Addresses 916 Viktor Dukhovni 917 Unaffiliated 919 Email: ietf-dane@dukhovni.org 921 Wes Hardaker 922 Parsons 923 P.O. Box 382 924 Davis, CA 95617 925 US 927 Email: ietf@hardakers.net