idnits 2.17.1 draft-fanf-dane-smtp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 25, 2012) is 4354 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-23) exists of draft-ietf-dane-protocol-21 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS-Based Authentication of Named T. Finch 3 Entities (DANE) University of Cambridge 4 Internet-Draft May 25, 2012 5 Intended status: Standards Track 6 Expires: November 26, 2012 8 Secure inter-domain SMTP with TLS, DNSSEC and TLSA records. 9 draft-fanf-dane-smtp-00 11 Abstract 13 SMTP supports STARTTLS for inter-domain mail transfer, but it only 14 provides very limited security because the server's certificate 15 cannot be authenticated. This memo specifies how TLSA records in the 16 DNS can be used for proper MX target server authentication. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 26, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Details of SMTP with TLSA . . . . . . . . . . . . . . . . . . . 4 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Security considerations . . . . . . . . . . . . . . . . . . . . 6 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 59 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 60 Appendix A. Rationale - choice of certificate identity . . . . . . 7 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 1. Introduction 65 The specification for SMTP over TLS [RFC3207] does not describe how 66 to authenticate a server: which identity relating to the connection 67 ought to be authenticated by the server's certificate. In practice, 68 most certificates presented by publicly-referenced SMTP servers 69 either cannot be validated with respect to a well-known certification 70 authority, or do not verify any identity expected by the client. 72 As a result, inter-domain SMTP clients cannot require working server 73 authentication if they want to successfully send mail using TLS. 74 Therefore TLS currently provides only a limited amount of additional 75 security for inter-domain SMTP. Its encryption protects against on- 76 path passive eavesdropping; but it does not protect against an active 77 attack, since the client has no way to detect when an attacker is 78 spoofing the server. 80 This memo describes how to fix this using DNSSEC [RFC4033] and TLSA 81 records [I-D.ietf-dane-protocol]. 83 We use DNSSEC to secure the association between a mail domain and its 84 SMTP server host names. A server's TLS certificate authenticates its 85 host name. 87 As well as its normal function of providing an association between a 88 domain name and a certificate, we are using the existance of a TLSA 89 record to signal to the client that it can expect a valid server 90 certificate. 92 The protocol described in this memo adds new security checks that can 93 cause email delivery to be delayed when a security failure is 94 detected. 96 2. Terminology 98 ADMD: An ADministrative Management Domain, as described in the 99 Internet Mail Architecture [RFC5598]. 101 SMTP server host name: The target of a (possibly implicit) MX 102 record. 104 Inter-domain SMTP: SMTP between different ADMDs across the public 105 Internet, where a client sends mail to a publicly-referenced SMTP 106 server. 108 Mail domain: The part of an email address after the "@"; also the 109 owner name of a (possibly implicit) MX record. 111 MX resolution: The algorithm for resolving a mail domain into a set 112 of SMTP server hosts, described in [RFC5321] section 5. 114 Publicly-referenced SMTP server: An SMTP server which runs on port 115 25 of an Internet host located using MX resolution. (This term is 116 from [RFC3207].) 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 memo are to be interpreted as described in [RFC2119]. 122 3. Details of SMTP with TLSA 124 In the following we describe some additions to the usual MX 125 resolution algorithm described in [RFC5321] section 5. If there is 126 any conflict between [RFC5321] and this memo, that is an error in 127 this memo. 129 The client SHALL look up the MX RRset for the mail domain. There are 130 three succesful results that yield a list of SMTP server host names: 132 o A list of one or more MX records; 134 o An implicit MX record, in lieu of an empty list of MX records; 136 o A CNAME to a successful result. 138 If the lookup is not successful, the client SHALL proceed as usual. 140 All of these DNS RRsets MUST be "secure" according to DNSSEC 141 validation ([RFC4033] section 5). In the case of an implicit MX 142 record, there MUST be a secure denial of existence of an MX RRset for 143 the mail domain. In the case of a (chain of) CNAME RRs, all the 144 CNAMEs MUST be secure as well as their ultimate target. 146 If any of the responses is "bogus", the client MUST treat this as a 147 temporary error. 149 If these security requirements are not satisfied, this protocol does 150 not take effect. The client SHOULD fall back to insecure delivery 151 (which might be over unauthenticated TLS). 153 The client now has an authentic list of SMTP server host names and 154 priority values. It processes this list as usual. 156 The rest of this section applies to each SMTP server host name 157 individually. 159 When connecting to a server, the client SHALL look up its TLSA RRset 160 as described in [I-D.ietf-dane-protocol] section 3. That is, the 161 TLSA RRset owner name SHALL be "_25._tcp.hostname" where "hostname" 162 is the SMTP server host name. The response can be one of the 163 following (as listed in [I-D.ietf-dane-protocol] section 4.1): 165 o A secure answer containing one or more TLSA records, in which case 166 the client SHALL proceed as descrbed below. 168 o A bogus answer, which the client SHALL treat as a temporary error. 170 o In the other cases the client SHOULD deliver to this server 171 insecurely (which might be over unauthenticated TLS). 173 The client now has one or more TLSA records for the server it is 174 connecting to. 176 The client MUST ensure that the server offers the STARTTLS service 177 extension [RFC3207] in its response to the client's EHLO command 178 ([RFC5321] section 4.1.1.1). 180 The client SHALL then issue the STARTTLS command which MUST be 181 successful. It then proceeds with TLS negotiation. 183 The client SHALL validate the server's certificate as described in 184 [I-D.ietf-dane-protocol] section 2.1. 186 The client SHALL verify the server's identity as described in 187 [RFC6125] section 6. Its list of reference identifiers MUST include 188 the SMTP server host name with type DNS-ID, and MAY include a second 189 copy of the host name with type CN-ID. 191 If any of these checks fail, the client MUST disconnect from the 192 server and treat this as a temporary failure. 194 The client can now proceed to deliver mail securely. 196 The client MAY wish to insert a header at the start of the message to 197 record the fact that it authenticated the server. XXX: Perhaps the 198 form of this header should be specified here. 200 4. IANA Considerations 202 No IANA action is required. 204 5. Security considerations 206 This memo provides only conditional security. It allows a server to 207 publish in the DNS the details of how it can be authenticated. 208 Clients that implement this protocol can use it to provide a strong 209 guarantee that they are sending mail to the correct place. 211 There is no way for a server to tell if a client has authenticated it 212 using this protocol, since SMTP has no mechanism to signal this 213 information. 215 We do not specify that clients check that all of a mail domain's SMTP 216 server host names consistently have or do not have TLSA records. 217 This is so that partial or incremental deployment does not break mail 218 delivery. Inconsistencies are likely if a domain has a third-party 219 backup MX, for example. 221 We do not specify that clients check the DNSSEC state of the SMTP 222 server address records. This is not necessary since the certificate 223 checks ensure that the client has connected to the correct server. 224 (The address records will normally have the same security state as 225 the TLSA records, but they can differ if there are CNAME or DNAME 226 indirections.) 228 This memo does not make any changes to SMTP client authentication. 229 Inter-domain SMTP client authentication remains extremely weak. 231 6. References 233 6.1. Normative References 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 239 Transport Layer Security", RFC 3207, February 2002. 241 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 242 Rose, "DNS Security Introduction and Requirements", 243 RFC 4033, March 2005. 245 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 246 October 2008. 248 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 249 Verification of Domain-Based Application Service Identity 250 within Internet Public Key Infrastructure Using X.509 251 (PKIX) Certificates in the Context of Transport Layer 252 Security (TLS)", RFC 6125, March 2011. 254 [I-D.ietf-dane-protocol] 255 Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 256 of Named Entities (DANE) Transport Layer Security (TLS) 257 Protocol: TLSA", draft-ietf-dane-protocol-21 (work in 258 progress), May 2012. 260 6.2. Informative References 262 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 263 Extension Definitions", RFC 6066, January 2011. 265 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 266 July 2009. 268 Appendix A. Rationale - choice of certificate identity 270 There are a number of reasons for the certificate to authenticate the 271 SMTP server host name rather than the mail domain. 273 SMTP allows a client to transfer mail to recipients at multiple 274 domains in the same connection. If the certificate identifies the 275 host name then it does not need to list all the possible mail 276 domains. 278 It is not in general feasible for the server to select a mail domain 279 certificate based on the recipient domains when the connection is 280 established (using Server Name Indication, [RFC6066] section 3), 281 because an SMTP client might not know all of the recipients when it 282 establishes the connection. 284 Outgoing SMTP relays and message submission servers handle mail for 285 any domain, so in those cases the only sensible option is for the 286 certificate to contain the host name. It is more consistent for 287 incoming MX server certificates to match. 289 It is common for SMTP servers to act in multiple roles, as outgoing 290 relays or as incoming MX servers, depending on the client identity. 291 It is simpler if the server can present the same certificate 292 regardless of the role in which it is to act. 294 Sometimes the server does not know its role until the client has 295 authenticated, which usually occurs after TLS has been established. 297 Author's Address 299 Tony Finch 300 University of Cambridge Computing Service 301 New Museums Site 302 Pembroke Street 303 Cambridge CB2 3QH 304 ENGLAND 306 Phone: +44 797 040 1426 307 Email: dot@dotat.at 308 URI: http://dotat.at/