Internet DRAFT - draft-fanf-dane-mua
draft-fanf-dane-mua
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]
