DNS-Based Authentication of Named T. Finch Entities (DANE) University of Cambridge Internet-Draft June 27, 2012 Updates: 6186 (if approved) Intended status: Standards Track Expires: December 29, 2012 DNSSEC and TLSA records for IMAP, POP3, and message submission draft-fanf-dane-mua-00 Abstract This specification describes the effect that DNSSEC has on SRV-based autoconfiguration and TLS certificate verification in the mail user agent protocols IMAP, POP3, and message submission. It also describes how to use TLSA DNS records to provide stronger authentication of server TLS certificates. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 29, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Finch Expires December 29, 2012 [Page 1]
Internet-Draft DNSSEC and TLSA for MUAs June 2012 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. DNSSEC, TLS, and mail server SRV records . . . . . . . . . . . 3 3. Mail server TLSA records . . . . . . . . . . . . . . . . . . . 4 4. Guidance for mail service providers . . . . . . . . . . . . . . 4 5. Guidance for mail server software authors . . . . . . . . . . . 5 6. Security considerations . . . . . . . . . . . . . . . . . . . . 5 7. Internationalization Considerations . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Rationale - where to put TLSA records . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Finch Expires December 29, 2012 [Page 2]
Internet-Draft DNSSEC and TLSA for MUAs June 2012 1. Introduction The mail user agent protocols IMAP [RFC3501], POP3 [RFC1939], and message submission [RFC4409] support upgrade from cleartext to TLS [RFC5246]. The STARTTLS command is part of the core IMAP specification [RFC3501]. Message submission is a profile of SMTP [RFC5321] for which there is a STARTTLS extension [RFC3207]. In POP3 the equivalent command is STLS [RFC2595]. IMAP and POP3 are also often deployed using TLS-on-connect on alternate TCP ports. [RFC6186] specifies how an MUA can use SRV records to automatically locate mail server host names given the user's mail domain. Section 2 of this specification updates [RFC6186] to clarify how MUAs handle mail server SRV records and TLS negotiation in the presence and absence of DNSSEC. Section 3 of this specification describes how to use TLSA DNS records [I-D.ietf-dane-protocol] to provide stronger authentication of server TLS certificates. We also use the existance of a TLSA record to signal to the MUA that it can expect the server to offer TLS. In the rest of this memo, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119]. 2. DNSSEC, TLS, and mail server SRV records When negotiating TLS, the MUA MUST use the Server Name Indication extension (TLS SNI) [RFC6066] with its preferred name as defined below. This is a stricter requirement than [RFC6186]. When a security-aware MUA looks up [RFC6186] SRV records, it SHALL take note of the DNSSEC status [RFC4033] of each record. It constructs the list of reference identifiers for verifying each server's TLS certificate [RFC6125] and chooses the preferred name for TLS SNI as follows: bogus: The MUA MUST abort. (If this occurs during auto- configuration, it might fall back to a manual setup procedure.) insecure or indeterminate: The reference identifiers SHALL include the source domain (i.e. the user's mail domain) and MUST NOT include the derived domain (i.e. the SRV target host name). The source domain is the preferred name for TLS SNI. Finch Expires December 29, 2012 [Page 3]
Internet-Draft DNSSEC and TLSA for MUAs June 2012 secure: The reference identifiers SHALL include both the source domain (i.e. the user's mail domain) and the derived domain (i.e. the SRV target host name). The derived domain is the preferred name for TLS SNI. 3. Mail server TLSA records MUAs SHALL look up the TLSA record(s) for a mail server using its host name and port number, as described in section 3 of [I-D.ietf-dane-protocol]. The MUA MUST only do this if the host name and port number have been obtained securely, from the "target" and "port" fields of a SRV record that is secure as described in the previous section, or from user configuration. If a TLSA record is usable as described in section 4.1 of [I-D.ietf-dane-protocol], then the server MUST support TLS. It MUST present a certificate that matches the TLSA record and that authenticates the server host name. When an MUA is configuring itself as described in section 4 of [RFC6186], it SHOULD use the presence of a TLSA record to indicate that use of TLS is obligatory when connecting to the corresponding server. 4. Guidance for mail service providers A mail server that is the target of an [RFC6186] SRV record MUST have a TLS certificate that authenticates the SRV owner domain (i.e. the user's mail domain). This is necessary for clients that cannot perform DNSSEC validation. This certificate MUST be the default that is presented if the client does not use the TLS Server Name Indication extension (TLS SNI) [RFC6066]. In order to support this specification, the mail server MUST also have a certificate that authenticates the SRV target domain (the mail server hostname). This can be done using a multi-name certificate or by using the client's TLS SNI to select the appropriate certificate. The mail server's TLSA record MUST correspond to this certificate. Note: old pre-[RFC6186] clients expect a mail server's TLS certificate to authenticate its host name; they are also unlikely to support SNI. This means that servers for old clients need a different default certificate from [RFC6186] servers. If the server does not have a certificate that authenticates all relevant names, it is necessary to segregate old and new clients. This can be done by using different target hosts or non-standard ports in the SRV Finch Expires December 29, 2012 [Page 4]
Internet-Draft DNSSEC and TLSA for MUAs June 2012 targets. (The latter avoids the need for yet more certificates.) 5. Guidance for mail server software authors In order to support this specification, mail server software MUST implement the TLS Server Name Indication extension [RFC6066] for selecting the appropriate certificate. 6. Security considerations The MUA autoconfiguration specification [RFC6186] does not have a complete mechanism for signalling whether a server supports TLS. IMAP and POP3 have alternate TLS-on-connect ports, but not message submission. This gap is filled by using the presence of TLSA records to indicate that a client can expect a server to support TLS. This prevents a downgrade attack. The guidance in Section 2 is mostly a straightforward consequence of the requirements set out in [RFC6125] and [RFC6186]. 7. Internationalization Considerations If any of the DNS queries are for an internationalized domain name, then they need to use the A-label form [RFC5890]. 8. IANA Considerations No IANA action is needed. 9. References 9.1. Normative References [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999. [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Finch Expires December 29, 2012 [Page 5]
Internet-Draft DNSSEC and TLSA for MUAs June 2012 Transport Layer Security", RFC 3207, February 2002. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011. [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011. [RFC6186] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, March 2011. [I-D.ietf-dane-protocol] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", draft-ietf-dane-protocol-23 (work in progress), May 2012. 9.2. Informative References [I-D.fanf-dane-smtp] Finch, T., "Secure SMTP with TLS, DNSSEC and TLSA records.", draft-fanf-dane-smtp-03 (work in progress), June 2012. [I-D.miller-xmpp-dnssec-prooftype] Finch Expires December 29, 2012 [Page 6]
Internet-Draft DNSSEC and TLSA for MUAs June 2012 Miller, M. and P. Saint-Andre, "Using DNSSEC and DANE as a Prooftype for XMPP Delegation", draft-miller-xmpp-dnssec-prooftype-01 (work in progress), June 2012. Appendix A. Rationale - where to put TLSA records The long-term goal of this specification is to settle on TLS certificates that verify the server host name rather than the mail domain, since this is more convenient for servers hosting multiple domains and scales up more easily to larger numbers of domains. There are a number of other reasons for doing it this way: o The certificate is part of the server configuration, so it makes sense to associate it with the server name rather than the mail domain. o When the server certificate is replaced it is much easier if there is one part of the DNS that needs updating to match, instead of an unbounded number of hosted mail domains. o The same TLSA records work with and without [RFC6186] SRV records. o Consistency with [I-D.fanf-dane-smtp] and [I-D.miller-xmpp-dnssec-prooftype]. There is no option to put TLSA records under the mail domain in order to keep the specification simple and to make it easier to deploy correctly. The disadvantage is that the expected certificate differs between pure [RFC6186] clients and clients that are implemented to this spec. This means that Server Name Indication support is necessary for backwards compatibility. Finch Expires December 29, 2012 [Page 7]
Internet-Draft DNSSEC and TLSA for MUAs June 2012 Author's Address Tony Finch University of Cambridge Computing Service New Museums Site Pembroke Street Cambridge CB2 3QH ENGLAND Phone: +44 797 040 1426 Email: dot@dotat.at URI: http://dotat.at/ Finch Expires December 29, 2012 [Page 8]