idnits 2.17.1 draft-fanf-dane-mua-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6186, but the abstract doesn't seem to mention this, which it should. 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 27, 2012) is 4311 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 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-04) exists of draft-fanf-dane-smtp-03 == Outdated reference: A later version (-04) exists of draft-miller-xmpp-dnssec-prooftype-01 Summary: 4 errors (**), 0 flaws (~~), 4 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 Updates: 6186 (if approved) 6 Intended status: Standards Track 7 Expires: December 29, 2012 9 DNSSEC and TLSA records for IMAP, POP3, and message submission 10 draft-fanf-dane-mua-00 12 Abstract 14 This specification describes the effect that DNSSEC has on SRV-based 15 autoconfiguration and TLS certificate verification in the mail user 16 agent protocols IMAP, POP3, and message submission. It also 17 describes how to use TLSA DNS records to provide stronger 18 authentication of server TLS certificates. 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 December 29, 2012. 37 Copyright Notice 39 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. DNSSEC, TLS, and mail server SRV records . . . . . . . . . . . 3 56 3. Mail server TLSA records . . . . . . . . . . . . . . . . . . . 4 57 4. Guidance for mail service providers . . . . . . . . . . . . . . 4 58 5. Guidance for mail server software authors . . . . . . . . . . . 5 59 6. Security considerations . . . . . . . . . . . . . . . . . . . . 5 60 7. Internationalization Considerations . . . . . . . . . . . . . . 5 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 64 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 65 Appendix A. Rationale - where to put TLSA records . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 The mail user agent protocols IMAP [RFC3501], POP3 [RFC1939], and 71 message submission [RFC4409] support upgrade from cleartext to TLS 72 [RFC5246]. The STARTTLS command is part of the core IMAP 73 specification [RFC3501]. Message submission is a profile of SMTP 74 [RFC5321] for which there is a STARTTLS extension [RFC3207]. In POP3 75 the equivalent command is STLS [RFC2595]. IMAP and POP3 are also 76 often deployed using TLS-on-connect on alternate TCP ports. 78 [RFC6186] specifies how an MUA can use SRV records to automatically 79 locate mail server host names given the user's mail domain. 80 Section 2 of this specification updates [RFC6186] to clarify how MUAs 81 handle mail server SRV records and TLS negotiation in the presence 82 and absence of DNSSEC. 84 Section 3 of this specification describes how to use TLSA DNS records 85 [I-D.ietf-dane-protocol] to provide stronger authentication of server 86 TLS certificates. We also use the existance of a TLSA record to 87 signal to the MUA that it can expect the server to offer TLS. 89 In the rest of this memo, the key words "MUST", "MUST NOT", 90 "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 91 "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 92 described in [RFC2119]. 94 2. DNSSEC, TLS, and mail server SRV records 96 When negotiating TLS, the MUA MUST use the Server Name Indication 97 extension (TLS SNI) [RFC6066] with its preferred name as defined 98 below. This is a stricter requirement than [RFC6186]. 100 When a security-aware MUA looks up [RFC6186] SRV records, it SHALL 101 take note of the DNSSEC status [RFC4033] of each record. It 102 constructs the list of reference identifiers for verifying each 103 server's TLS certificate [RFC6125] and chooses the preferred name for 104 TLS SNI as follows: 106 bogus: The MUA MUST abort. (If this occurs during auto- 107 configuration, it might fall back to a manual setup procedure.) 109 insecure or indeterminate: The reference identifiers SHALL include 110 the source domain (i.e. the user's mail domain) and MUST NOT 111 include the derived domain (i.e. the SRV target host name). The 112 source domain is the preferred name for TLS SNI. 114 secure: The reference identifiers SHALL include both the source 115 domain (i.e. the user's mail domain) and the derived domain (i.e. 116 the SRV target host name). The derived domain is the preferred 117 name for TLS SNI. 119 3. Mail server TLSA records 121 MUAs SHALL look up the TLSA record(s) for a mail server using its 122 host name and port number, as described in section 3 of 123 [I-D.ietf-dane-protocol]. The MUA MUST only do this if the host name 124 and port number have been obtained securely, from the "target" and 125 "port" fields of a SRV record that is secure as described in the 126 previous section, or from user configuration. 128 If a TLSA record is usable as described in section 4.1 of 129 [I-D.ietf-dane-protocol], then the server MUST support TLS. It MUST 130 present a certificate that matches the TLSA record and that 131 authenticates the server host name. 133 When an MUA is configuring itself as described in section 4 of 134 [RFC6186], it SHOULD use the presence of a TLSA record to indicate 135 that use of TLS is obligatory when connecting to the corresponding 136 server. 138 4. Guidance for mail service providers 140 A mail server that is the target of an [RFC6186] SRV record MUST have 141 a TLS certificate that authenticates the SRV owner domain (i.e. the 142 user's mail domain). This is necessary for clients that cannot 143 perform DNSSEC validation. This certificate MUST be the default that 144 is presented if the client does not use the TLS Server Name 145 Indication extension (TLS SNI) [RFC6066]. 147 In order to support this specification, the mail server MUST also 148 have a certificate that authenticates the SRV target domain (the mail 149 server hostname). This can be done using a multi-name certificate or 150 by using the client's TLS SNI to select the appropriate certificate. 151 The mail server's TLSA record MUST correspond to this certificate. 153 Note: old pre-[RFC6186] clients expect a mail server's TLS 154 certificate to authenticate its host name; they are also unlikely to 155 support SNI. This means that servers for old clients need a 156 different default certificate from [RFC6186] servers. If the server 157 does not have a certificate that authenticates all relevant names, it 158 is necessary to segregate old and new clients. This can be done by 159 using different target hosts or non-standard ports in the SRV 160 targets. (The latter avoids the need for yet more certificates.) 162 5. Guidance for mail server software authors 164 In order to support this specification, mail server software MUST 165 implement the TLS Server Name Indication extension [RFC6066] for 166 selecting the appropriate certificate. 168 6. Security considerations 170 The MUA autoconfiguration specification [RFC6186] does not have a 171 complete mechanism for signalling whether a server supports TLS. 172 IMAP and POP3 have alternate TLS-on-connect ports, but not message 173 submission. This gap is filled by using the presence of TLSA records 174 to indicate that a client can expect a server to support TLS. This 175 prevents a downgrade attack. 177 The guidance in Section 2 is mostly a straightforward consequence of 178 the requirements set out in [RFC6125] and [RFC6186]. 180 7. Internationalization Considerations 182 If any of the DNS queries are for an internationalized domain name, 183 then they need to use the A-label form [RFC5890]. 185 8. IANA Considerations 187 No IANA action is needed. 189 9. References 191 9.1. Normative References 193 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", 194 STD 53, RFC 1939, May 1996. 196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 197 Requirement Levels", BCP 14, RFC 2119, March 1997. 199 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", 200 RFC 2595, June 1999. 202 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 203 Transport Layer Security", RFC 3207, February 2002. 205 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 206 4rev1", RFC 3501, March 2003. 208 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 209 Rose, "DNS Security Introduction and Requirements", 210 RFC 4033, March 2005. 212 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 213 RFC 4409, April 2006. 215 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 216 October 2008. 218 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 219 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 221 [RFC5890] Klensin, J., "Internationalized Domain Names for 222 Applications (IDNA): Definitions and Document Framework", 223 RFC 5890, August 2010. 225 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 226 Extension Definitions", RFC 6066, January 2011. 228 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 229 Verification of Domain-Based Application Service Identity 230 within Internet Public Key Infrastructure Using X.509 231 (PKIX) Certificates in the Context of Transport Layer 232 Security (TLS)", RFC 6125, March 2011. 234 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email 235 Submission/Access Services", RFC 6186, March 2011. 237 [I-D.ietf-dane-protocol] 238 Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 239 of Named Entities (DANE) Transport Layer Security (TLS) 240 Protocol: TLSA", draft-ietf-dane-protocol-23 (work in 241 progress), May 2012. 243 9.2. Informative References 245 [I-D.fanf-dane-smtp] 246 Finch, T., "Secure SMTP with TLS, DNSSEC and TLSA 247 records.", draft-fanf-dane-smtp-03 (work in progress), 248 June 2012. 250 [I-D.miller-xmpp-dnssec-prooftype] 251 Miller, M. and P. Saint-Andre, "Using DNSSEC and DANE as a 252 Prooftype for XMPP Delegation", 253 draft-miller-xmpp-dnssec-prooftype-01 (work in progress), 254 June 2012. 256 Appendix A. Rationale - where to put TLSA records 258 The long-term goal of this specification is to settle on TLS 259 certificates that verify the server host name rather than the mail 260 domain, since this is more convenient for servers hosting multiple 261 domains and scales up more easily to larger numbers of domains. 263 There are a number of other reasons for doing it this way: 265 o The certificate is part of the server configuration, so it makes 266 sense to associate it with the server name rather than the mail 267 domain. 269 o When the server certificate is replaced it is much easier if there 270 is one part of the DNS that needs updating to match, instead of an 271 unbounded number of hosted mail domains. 273 o The same TLSA records work with and without [RFC6186] SRV records. 275 o Consistency with [I-D.fanf-dane-smtp] and 276 [I-D.miller-xmpp-dnssec-prooftype]. 278 There is no option to put TLSA records under the mail domain in order 279 to keep the specification simple and to make it easier to deploy 280 correctly. 282 The disadvantage is that the expected certificate differs between 283 pure [RFC6186] clients and clients that are implemented to this spec. 284 This means that Server Name Indication support is necessary for 285 backwards compatibility. 287 Author's Address 289 Tony Finch 290 University of Cambridge Computing Service 291 New Museums Site 292 Pembroke Street 293 Cambridge CB2 3QH 294 ENGLAND 296 Phone: +44 797 040 1426 297 Email: dot@dotat.at 298 URI: http://dotat.at/