idnits 2.17.1 draft-fanf-dane-smtp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 349 has weird spacing: '...ocument this ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 27, 2012) is 4321 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 4409 (Obsoleted by RFC 6409) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS-Based Authentication of Named T. Finch 3 Entities (DANE) University of Cambridge 4 Internet-Draft June 27, 2012 5 Intended status: Standards Track 6 Expires: December 29, 2012 8 Secure SMTP with TLS, DNSSEC and TLSA records. 9 draft-fanf-dane-smtp-04 11 Abstract 13 SMTP has a STARTTLS extension, but (especially in the case of inter- 14 domain mail transfer) it only provides very limited security because 15 it does not specify how to authenticate the server's certificate. 16 This memo specifies how TLSA records in the DNS can be used for 17 proper SMTP server authentication. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 29, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Questions for reviewers . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Inter-domain SMTP with TLSA . . . . . . . . . . . . . . . . . 4 57 3.1. MX lookup checks . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. SMTP server checks . . . . . . . . . . . . . . . . . . . . 5 59 4. Intra-domain SMTP with TLSA . . . . . . . . . . . . . . . . . 6 60 5. The Transmitted: header field . . . . . . . . . . . . . . . . 7 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 6.1. "with" protocol types . . . . . . . . . . . . . . . . . . 8 63 6.2. Permanent message header field registration . . . . . . . 8 64 6.3. "dane" MTA-name-type . . . . . . . . . . . . . . . . . . . 8 65 7. Security considerations . . . . . . . . . . . . . . . . . . . 9 66 7.1. Fallback to insecure SMTP . . . . . . . . . . . . . . . . 9 67 7.2. A mail domain trusts its SMTP servers . . . . . . . . . . 9 68 7.3. Temporary failures and denial of service . . . . . . . . . 9 69 7.4. Deliberate omissions . . . . . . . . . . . . . . . . . . . 10 70 8. Internationalization Considerations . . . . . . . . . . . . . 10 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 75 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 12 76 Appendix B. Rationale - choice of certificate identity . . . . . 13 77 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 13 78 C.1. Changes in version -04 . . . . . . . . . . . . . . . . . . 13 79 C.2. Changes in version -03 . . . . . . . . . . . . . . . . . . 14 80 C.3. Changes in version -02 . . . . . . . . . . . . . . . . . . 14 81 C.4. Changes in version -01 . . . . . . . . . . . . . . . . . . 14 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 The specification for SMTP over TLS [RFC3207] does not describe how 87 to authenticate a server: which identity relating to the connection 88 ought to be authenticated by the server's certificate. In practice, 89 most certificates presented by publicly-referenced SMTP servers 90 either cannot be validated with respect to a well-known certification 91 authority, or do not verify any identity expected by the client. 93 As a result, inter-domain SMTP clients cannot require working server 94 authentication if they want to successfully send mail using TLS. 95 Therefore TLS currently provides only a limited amount of additional 96 security for inter-domain SMTP. Its encryption protects against on- 97 path passive eavesdropping; but it does not protect against an active 98 attack, since the client has no way to detect when an attacker is 99 spoofing the server. 101 This memo describes how to fix this using DNSSEC [RFC4033] and TLSA 102 records [I-D.ietf-dane-protocol] with owner names of the form 103 "_25._tcp.hostname". 105 We use DNSSEC to secure the association between a mail domain and its 106 SMTP server host names, and between the host names and their 107 certificates. Connections to servers are authenticated by their TLS 108 certificates. 110 As well as its normal function of providing an association between a 111 domain name and a certificate, we are also using the existance of a 112 TLSA record to signal to the client that it can expect the server to 113 offer TLS with a valid certificate. 115 The security situation is better for intra-domain SMTP, because in 116 this case the client and server can be configured with prior 117 knowledge of how to authenticate each other. This specification can 118 also be used for authenticating servers in intra-domain SMTP. 120 This memo does not cover message submission [RFC4409] [RFC5068] 121 [RFC6186], nor does it cover LMTP [RFC2033], since they use the DNS 122 in a different way than MTA-to-MTA SMTP. 124 The protocol described in this memo adds new security checks that can 125 cause email delivery to be delayed when a security failure is 126 detected. We specify that clients treat a problems as a "temporary 127 failure", causing the message to be queued for a later delivery 128 attempt, in the hope that the attack (or configuration error) will 129 have been dealt with. 131 1.1. Questions for reviewers 133 Is the Transmitted: header useful enough to include in this spec? 134 Should it be dropped, or perhaps moved to another document? 136 Is the "dane" MTA-name-type for use in delivery status notifications 137 a good idea? Is it likely to cause interoperability problems? 139 Is the description of DNSSEC validation over-done? Can it be trimmed 140 down so it relies more on the core DNSSEC specs? 142 2. Terminology 144 ADMD: An ADministrative Management Domain, as described in the 145 Internet Mail Architecture [RFC5598]. 147 Inter-domain SMTP: SMTP between different ADMDs across the public 148 Internet, where a client MTA sends mail to a publicly-referenced 149 SMTP server MTA. 151 Intra-domain SMTP: SMTP between MTAs within an ADMD. 153 Mail domain: The part of an email address after the "@"; also the 154 owner name of a (possibly implicit) MX record. 156 MX resolution: The algorithm for resolving a mail domain into a set 157 of SMTP server hosts, described in [RFC5321] section 5. 159 Publicly-referenced SMTP server: An SMTP server which runs on port 160 25 of an Internet host located using MX resolution. (This term is 161 from [RFC3207].) 163 SMTP server host name: The target of a (possibly implicit) MX 164 record. 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 memo are to be interpreted as described in [RFC2119]. 170 3. Inter-domain SMTP with TLSA 172 In the following we describe some additions to the usual MX 173 resolution algorithm described in [RFC5321] section 5. If there is 174 any conflict between this memo and the other specifications cited in 175 this section, that is an error in this memo. 177 3.1. MX lookup checks 179 The client SHALL look up the MX RRset for the mail domain. There are 180 three succesful results that yield a list of SMTP server host names: 182 o A list of one or more MX records; 184 o An implicit MX record, in lieu of an empty list of MX records; 186 o A CNAME or DNAME pointing to a successful result. 188 If the lookup is not successful, the client SHALL proceed as 189 described in [RFC5321] section 5. 191 If any of the responses is "bogus" according to DNSSEC validation 192 ([RFC4033] section 5) the client MUST treat this as a temporary 193 error. 195 For this protocol to take effect, all of these DNS RRsets MUST be 196 "secure" according to DNSSSEC validation. In the case of an implicit 197 MX record, there MUST be a secure denial of existence of an MX RRset 198 for the mail domain. In the case of a (chain of) CNAME or DNAME RRs, 199 the whole chain MUST be secure as well as the ultimate target. 201 If they are not all secure, this protocol has not been fully 202 deployed. The client SHOULD fall back to insecure delivery (which 203 might be over unauthenticated TLS). 205 (If the client is using a non-validating security-aware stub resolver 206 (see [RFC4033] section 7), it can rely on its recursive name server 207 to perform these checks and set the AD bit according to the result - 208 see [RFC4035] section 3.2.3.) 210 The client now has an authentic list of SMTP server host names and 211 priority values. It processes this list as described in [RFC5321] 212 section 5 (sorting the host names etc.) without regard to the 213 presence or absence of DNSSEC or TLSA records. 215 3.2. SMTP server checks 217 This sub-section applies to each SMTP server host name individually. 219 When connecting to a server, the client SHALL look up the server's 220 TLSA RRset as described in [I-D.ietf-dane-protocol] section 3. That 221 is, the TLSA RRset owner name SHALL be "_25._tcp.hostname" where 222 "hostname" is the SMTP server host name. The response can be one of 223 the following (as listed in [I-D.ietf-dane-protocol] section 4.1): 225 o A secure answer containing one or more TLSA records, in which case 226 the client SHALL proceed as descrbed below. 228 o A bogus answer or other failure, which the client MUST treat as a 229 temporary error. 231 o If there is no TLSA record or its DNSSEC validation state is 232 insecure or indeterminate, this protocol has not been fully 233 deployed. The client SHOULD deliver to this server insecurely 234 (which might be over unauthenticated TLS). 236 The client now has one or more TLSA records for the server it is 237 connecting to. 239 The client MUST ensure that the server offers the STARTTLS service 240 extension [RFC3207] in its response to the client's EHLO command 241 ([RFC5321] section 4.1.1.1). 243 The client SHALL then issue the STARTTLS command which MUST be 244 successful. It then proceeds with TLS negotiation [RFC5246]. If the 245 client uses the Server Name Indication TLS extension ([RFC6066] 246 section 3) it MUST use the SMTP server host name as the value for the 247 ServerName field. 249 The client SHALL validate the server's certificate as described in 250 [I-D.ietf-dane-protocol] section 2.1. 252 The client SHALL verify the server's identity as described in 253 [RFC6125] section 6. Its list of reference identifiers SHOULD 254 include the SMTP server host name with type DNS-ID, and MAY include a 255 second copy of the host name with type CN-ID. 257 If any of these checks fail, the client MUST disconnect from the 258 server and treat this as a temporary failure. 260 The client can now proceed to deliver mail securely. 262 4. Intra-domain SMTP with TLSA 264 Mail transmission within an ADMD can be based on MX records (such as 265 when delivering incoming mail to its destination host) or on 266 statically configured host names (such as when routing outgoing mail 267 via a border relay). 269 When routing internal mail using MX records, Section 3 applies the 270 same as for inter-domain SMTP. 272 When routing mail using host names, the MX lookup step is skipped and 273 only Section 3.2 applies. 275 5. The Transmitted: header field 277 The client MAY wish to insert a Transmitted: header field at the 278 start of the message header just before transmitting the message. 279 This records the result of the checks specified in the previous 280 section. (See Section 7 for some comments on its utility or lack 281 thereof.) It is a client-side counterpart to the Received: header 282 field ([RFC5321] section 4.4) and has very similar syntax. It SHOULD 283 be treated as a trace field. 285 The syntax of the Transmitted: header field is described using ABNF 286 [RFC5234]. Non-terminal syntax rules not defined in this memo are 287 defined in [RFC5321], or [RFC5322], or [RFC5234]. 289 Transmitted-line = "Transmitted:" FWS To-domain By-domain 290 Opt-info [CFWS] ";" date-time CRLF 292 To-domain = "TO" FWS Extended-Domain 294 A SHALL include: 296 o A clause describing the SMTP server. The 297 part of a SHALL be the same as the SMTP server host 298 name. 300 o A clause identifying the SMTP client that added the 301 header. (If the client also acts as a server this is the same 302 clause it would include in any Received: header fields 303 it adds.) This clause helps with recovery if the original order 304 of a message header's fields has been lost. 306 o Various clauses, which MUST include a clause. 307 The part of this clause is used to indicate whether the 308 client successfully authenticated the server, using one of the 309 types specified in Section 6.1. 311 o And a to further help with disordering in case a 312 message is transmitted by the same client more than once. 314 6. IANA Considerations 316 6.1. "with" protocol types 318 The "with" protocol type registry includes a number of keywords that 319 indicate the use of SMTP with or without TLS and/or AUTH [RFC3848]. 320 When these types appear in a Transmitted: header field "with" clause 321 they indicate that the client did not authenticate the server as 322 described in Section 3. 324 o The new keyword "ESMTPT" indicates the use of ESMTP [RFC5321] with 325 STARTTLS [RFC3207] when the client successfully authenticated the 326 server. 328 o The new keyword "ESMTPTA" indicates the use of ESMTP [RFC5321] 329 with STARTTLS [RFC3207] and AUTH [RFC4954] when the client 330 successfully authenticated the server. 332 These new keywords are not for use in Received: header fields since 333 the server cannot tell whether or not the client authenticated it. 335 There are no keywords corresponding to a client trying and failing to 336 authenticate the server, since in this case no message transmission 337 occurs. 339 6.2. Permanent message header field registration 341 Header field name: Transmitted: 343 Applicable protocol: mail 345 Status: standard 347 Change controller: IETF 349 Specification document this memo 351 6.3. "dane" MTA-name-type 353 Delivery status notifications [RFC3464] can include a Remote-MTA 354 field recording an SMTP server host name. When this has been 355 authenticated according to Section 3 the reporting MTA MAY use an 356 MTA-type-name of "dane". 358 a. MTA-type-name: "dane" 360 b. Syntax: same as the "dns" MTA-type-name [RFC3461] 361 c. Translation into US-ASCII: none needed 363 7. Security considerations 365 7.1. Fallback to insecure SMTP 367 This memo provides only conditional security. It allows a server to 368 publish in the DNS the details of how it can be authenticated. 369 Clients that implement this protocol can use it to provide a strong 370 guarantee that they are sending mail to the correct place. If either 371 of these is missing, mail delivery will be insecure. 373 There is no secure way for a server to tell if a client has 374 authenticated it using this protocol. This is a general limitation 375 of TLS. The Transmitted: header field records this information for 376 tracing and debugging and measuring deployment, not for security 377 purposes. 379 We do not specify that clients check that all of a mail domain's SMTP 380 server host names are consistent in whether they have or do not have 381 TLSA records. This is so that partial or incremental deployment does 382 not break mail delivery. Different levels of deployment are likely 383 if a domain has a third-party backup MX, for example. 385 The MX sorting rules are unchanged; in particular they have not been 386 altered in order to prioritize secure servers over insecure servers. 387 If a site wants to be secure it needs to deploy this protocol 388 completely; a partial deployment is not secure and we make no special 389 effort to support it. 391 7.2. A mail domain trusts its SMTP servers 393 By signing their zone with DNSSEC, a mail domain owner implicitly 394 instructs SMTP clients to check their SMTP server TLSA records. This 395 implies another point in the trust relationship between mail domain 396 owner and smtp server operator. Most of the setup requirements for 397 this protocol fall on the SMTP server operator: installing a TLS 398 certificate with the correct name, and publishing a TLSA record under 399 that name. If these are not correct then mail delivery from TLSA- 400 aware clients might be delayed. 402 7.3. Temporary failures and denial of service 404 Many provisioning failures in SMTP cause "permanent" failures, that 405 is the immediate and final rejection of the message. This includes 406 missing DNS records, an SMTP server that is not configured to accept 407 mail for the recipient domain, and so forth. 409 In this protocol, provisioning an incorrect TLS certificate triggers 410 a temporary error. This is because we want to minimise the damage 411 that occurs when an on-path attacker intercepts the TCP connection 412 between an SMTP client and server. An attacker can cause delays, but 413 is not able to trigger immediate delivery failures. 415 7.4. Deliberate omissions 417 We do not specify that clients check the DNSSEC state of the SMTP 418 server address records. This is not necessary since the certificate 419 checks ensure that the client has connected to the correct server. 420 (The address records will normally have the same security state as 421 the TLSA records, but they can differ if there are CNAME or DNAME 422 indirections.) 424 This memo does not specify any changes to SMTP client authentication. 425 Inter-domain SMTP client authentication remains extremely weak. 426 Intra-domain SMTP can be configured as strong as necessary (using 427 SMTP AUTH or TLS client certificates, for instance) but that is out 428 of scope for this memo. 430 8. Internationalization Considerations 432 If any of the DNS queries are for an internationalized domain name, 433 then they need to use the A-label form [RFC5890]. 435 9. Acknowledgements 437 Thanks to Mark Andrews for arguing that authenticating the SMTP 438 server host name is the right thing, and that we ought to rely on 439 DNSSEC to secure the MX lookup. Thanks to Ned Freed, Olafur 440 Gudmundsson, Paul Hoffman, Phil Pennock, Hector Santos, and 441 Alessandro Vesely for helpful suggestions. 443 10. References 445 10.1. Normative References 447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 448 Requirement Levels", BCP 14, RFC 2119, March 1997. 450 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 451 Transport Layer Security", RFC 3207, February 2002. 453 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 454 Extension for Delivery Status Notifications (DSNs)", 455 RFC 3461, January 2003. 457 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 458 for Delivery Status Notifications", RFC 3464, 459 January 2003. 461 [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types 462 Registration", RFC 3848, July 2004. 464 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 465 Rose, "DNS Security Introduction and Requirements", 466 RFC 4033, March 2005. 468 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 469 Rose, "Protocol Modifications for the DNS Security 470 Extensions", RFC 4035, March 2005. 472 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 473 for Authentication", RFC 4954, July 2007. 475 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 476 Specifications: ABNF", STD 68, RFC 5234, January 2008. 478 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 479 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 481 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 482 October 2008. 484 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 485 October 2008. 487 [RFC5890] Klensin, J., "Internationalized Domain Names for 488 Applications (IDNA): Definitions and Document Framework", 489 RFC 5890, August 2010. 491 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 492 Extension Definitions", RFC 6066, January 2011. 494 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 495 Verification of Domain-Based Application Service Identity 496 within Internet Public Key Infrastructure Using X.509 497 (PKIX) Certificates in the Context of Transport Layer 498 Security (TLS)", RFC 6125, March 2011. 500 [I-D.ietf-dane-protocol] 501 Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 502 of Named Entities (DANE) Transport Layer Security (TLS) 503 Protocol: TLSA", draft-ietf-dane-protocol-23 (work in 504 progress), May 2012. 506 10.2. Informative References 508 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, 509 October 1996. 511 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 512 RFC 4409, April 2006. 514 [RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. 515 Finch, "Email Submission Operations: Access and 516 Accountability Requirements", BCP 134, RFC 5068, 517 November 2007. 519 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 520 July 2009. 522 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 523 Submission/Access Services", RFC 6186, March 2011. 525 Appendix A. Example 527 In the following, most of the DNS resource data is elided for 528 simplicity. 530 ; mail domain 531 example.com. MX 1 mx.example.net. 532 example.com. RRSIG MX ... 534 ; SMTP server host name 535 mx.example.net. A 192.0.2.1 536 mx.example.net. AAAA 2001:db8:212:8::e:1 538 ; TLSA resource record 539 _25._tcp.mx.example.net. TLSA ... 540 _25._tcp.mx.example.net. RRSIG TLSA ... 542 Mail for addresses at example.com is delivered by SMTP to 543 mx.example.net. Connections to mx.example.net port 25 that use 544 STARTTLS will get a server certificate that authenticates the name 545 mx.example.net. 547 Appendix B. Rationale - choice of certificate identity 549 There are a number of reasons for the certificate to authenticate the 550 SMTP server host name rather than the mail domain. 552 SMTP allows a client to transfer mail to recipients at multiple 553 domains in the same connection. If the certificate identifies the 554 host name then it does not need to list all the possible mail 555 domains. 557 It is not in general feasible for the server to select a mail domain 558 certificate based on the recipient domains when the connection is 559 established (using Server Name Indication, [RFC6066] section 3), 560 because an SMTP client might not know all of the recipients when it 561 establishes the connection. 563 Outgoing SMTP relays and message submission servers handle mail for 564 any domain, so in those cases the only sensible option is for the 565 certificate to contain the host name. It is more consistent for 566 incoming MX server certificates to match. 568 It is common for SMTP servers to act in multiple roles, as outgoing 569 relays or as incoming MX servers, depending on the client identity. 570 It is simpler if the server can present the same certificate 571 regardless of the role in which it is to act. 573 Sometimes the server does not know its role until the client has 574 authenticated, which usually occurs after TLS has been established. 576 This protocol does not provide an option for directly authenticating 577 the mail domain because that would add complexity without providing 578 any benefit, and security protocols are best kept simple. As 579 described above, there are real-world cases where authenticating the 580 mail domain cannot be made to work, so there are complicated criteria 581 for when mail domain TLSA records might be used and when they cannot. 582 This is all avoided by authenticating the SMTP server host name. 584 Finally, this protocol only affects the logic in the SMTP client and 585 requires no additional SMTP server functionality, such as support for 586 the TLS Server Name Indication extension. 588 Appendix C. Change log 590 C.1. Changes in version -04 592 Add some questions for reviewers 593 Add a note about stub resolvers and the AD bit. 595 Internationalization considerations. 597 C.2. Changes in version -03 599 Clarify how to use SNI with this protocol. 601 Clarify lack of changes to MX sorting rules. 603 Mention DNAME as well as CNAME. 605 An example. 607 C.3. Changes in version -02 609 Clarify the wording that describes how a client determines that this 610 protocol is in effect. 612 Divide the security considerations into sub-sections, and add a 613 subsection on denial of service. 615 Clarify intro, mentioning TLSA owner name format. 617 Extend the scope to cover MTA-to-MTA mail within an ADMD as well as 618 between ADMDs. 620 C.4. Changes in version -01 622 More about why not to authenticate mail domains in the rationale. 624 Change DNS-ID requirement from MUST to SHOULD to follow RFC 6125. 626 Acknowledgments section. 628 Transmitted: header trace field. Not sure if this is a good idea; 629 feedback wanted. 631 "dane" MTA-name-type for use in DSNs. Even less sure if this is a 632 good idea. 634 Author's Address 636 Tony Finch 637 University of Cambridge Computing Service 638 New Museums Site 639 Pembroke Street 640 Cambridge CB2 3QH 641 ENGLAND 643 Phone: +44 797 040 1426 644 Email: dot@dotat.at 645 URI: http://dotat.at/