Internet-Draft T. Finch University of Cambridge February 2006 Message submission with TLS on connect Abstract This document specifies how to perform message submission using SMTP with TLS negotiation immediately after the TCP connection is established, instead of after the STARTTLS command. This reduces the time for the establishment of a secure connection from 6 round-trips to 3 round-trips. This significantly reduces the delay for interactive message submission over slow links. Document revision $Cambridge: hermes/doc/qsmtp/draft-fanf-smtp-tls-on-connect.xml,v 1.3 2006/03/14 13:16:40 fanf2 Exp $ Finch [Page 1] Internet-Draft Message submission with TLS on connect February 2006 Table of Contents 1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security considerations . . . . . . . . . . . . . . . . . . . . 5 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Normative references . . . . . . . . . . . . . . . . . . . 7 5.2. Informative references . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Finch [Page 2] Internet-Draft Message submission with TLS on connect February 2006 1. Rationale To establish a secure extended SMTP [RFC2821] session using the STARTTLS SMTP service extension [RFC3207] [RFC2246], a client and server must exchange the following fourteen packets: client | TCP SYN | server |------------------------>| | | | TCP SYN + ACK | |<------------------------| | | | TCP ACK | |------------------------>| | | | SMTP greeting | |<------------------------| | | | SMTP EHLO | |------------------------>| | | | SMTP extension list | |<------------------------| | | | SMTP STARTTLS | |------------------------>| | | | SMTP 220 OK | |<------------------------| | | | TLS hello | |------------------------>| | | | TLS hello etc. | |<------------------------| | | | TLS handshake finish | |------------------------>| | | | TLS handshake finish | |<------------------------| | | | SMTP EHLO | |------------------------>| | | | SMTP extension list | |<------------------------| Finch [Page 3] Internet-Draft Message submission with TLS on connect February 2006 By contrast, to establish a secure extended SMTP session with TLS negotiation immediately after the TCP connection is established (aka TLS-on-conenct), they must exchange the following eight packets: client | TCP SYN | server |------------------------>| | | | TCP SYN + ACK | |<------------------------| | | | TCP ACK + TLS hello | |------------------------>| | | | TLS hello etc. | |<------------------------| | | | TLS handshake finish | |------------------------>| | | | TLS finish + SMTP greet | |<------------------------| | | | SMTP EHLO | |------------------------>| | | | SMTP extension list | |<------------------------| This saves three round trips, which can be longer than a second on international links. This is a huge improvement for someone performing interactive message submission from an MUA. [RFC2817] states that, at the Washington DC IETF meeting in December 1997, the Applications Area Directors and the IESG reaffirmed that the practice of issuing parallel "secure" port numbers should be deprecated. However as the above shows, this policy has significant negative performance effects. Furthermore, the TLS-on-connect model continues to be popular despite the policy, both for email and elsewhere: in particular, it is common for message submission clients to support only TLS-on-connect and not STARTTLS. STARTTLS also has security disadvantages as explained in the next section. Therefore this document recommends the allocation of a port for [RFC2476] message submission with TLS-on-connect, known as the "smtps" port, as a counterpart to the existing "submission" port 587. Finch [Page 4] Internet-Draft Message submission with TLS on connect February 2006 (Note: A further round trip can be saved by the use of SMTP QUICKSTART [I-D.smtp-quickstart] after TLS negtiation. Because they work well together, this document registers "with" protocol types for TLS-on-connect with SMTP QUICKSTART as well as normal SMTP in Section 4.) We are not recommending the use of TLS-on-connect for MTA-to-MTA message delivery, because it is much less sensitive to latency than message submission. Furthermore, STARTTLS's ability to negotiate no security is useful in this context for backwards compatibility - most MTA-to-MTA traffic is still unencrypted and unauthenticated. 2. Security considerations The design of the STARTTLS protocol builds in the assumption that it is optional to negotiate TLS, and thereby perpetuates the attitude that security is an optional afterthought. This attitude encourages implementation and operational errors. For example, it is common for MUA software to offer a configuration setting which means "use STARTTLS if the server offers it, and don't worry if it doesn't". This leaves unwary users open to security downgrade attacks. It is typically safer to tell them to use the "SSL" (i.e. TLS-on-connect) option, because they are less likely to choose "optional TLS" instead of "mandatory TLS". The initial part of the SMTP conversation before STARTTLS occurs in the clear. This exposes the client's configured host name, which may reveal roughly where a roaming user's home is, or (if their host name is chosen badly) part of their name. If user is on a wireless network the information is broadcast to everyone nearby. This is not a problem for TLS-on-connect. 3. Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this section are to be interpreted as described in [RFC2119]. When a client connects to the "smtps" port, it MUST immediately perform a TLS [RFC2246] handshake. After the TLS handshake has been completed, both parties MUST immediately decide whether or not to continue based on the authentication and privacy achieved. The SMTP client and server SHOULD NOT move ahead if the TLS negotiation ended with no authentication and/or no privacy, because the purpose of using the "smtps" port instead of the "submission" port is to establish a secure connection. Finch [Page 5] Internet-Draft Message submission with TLS on connect February 2006 If the client decides that the level of authentication or privacy is not high enough for it to continue, it SHOULD issue an SMTP QUIT command immediately after receiving a greeting from the server. If the server decides that the level of authentication or privacy is not high enough for it to continue, it SHOULD reply to every SMTP command from the client (other than a QUIT command) with the 554 reply code (with a possible text string such as "Command refused due to lack of security"). The decision of whether or not to believe the authenticity of the other party in a TLS negotiation is a local matter. However, one general rule for the decision is that a client would probably only want to authenticate a server whose server certificate has a domain name that is the domain name that the client thought it was connecting to. On successful completion of the TLS handshake, the server MUST issue a greeting, as with SMTP connections that start unencrypted. (Note that this is different from STARTTLS [RFC3207] which omits the greeting after the TLS handshake.) Both the client and the server MUST know that there is a TLS session active. A client MUST NOT attempt to start another TLS session. A server MUST NOT list the STARTTLS extension in response to an EHLO command. A server SHOULD list the same extensions that it would in response to an EHLO command after a STARTTLS command on the "submission" port. The "smtps" port MUST only be used for message submission as described in [RFC2476]. It MUST NOT be used for MTA-to-MTA message delivery. 4. IANA Considerations This document introduces no new namespaces to be managed by IANA. This document requests IANA to allocate a port number for [RFC2476] message submission with TLS-on-connect, and to give it the "smtps" service name. IANA maintains a registry of "WITH protocol types" for use in the "with" clause of the Received header trace fields in an Internet message. Most of the contents of this registry are set out in [RFC3848]. This specification updates the registry as follows: o The new keyword "SMTPS" indicates the use of un-extended SMTP with TLS negotiated immediately after connection establishment, providing a strong transport encryption layer. Finch [Page 6] Internet-Draft Message submission with TLS on connect February 2006 o The new keyword "SESMTP" indicates the use of extended SMTP with TLS-on-connect. o The new keyword "SESMTPA" indicates the use of SMTP with TLS-on- connect when the SMTP AUTH [RFC2554] extension is also used and authentication is successfully achieved. o The new keyword "SQSMTP" indicates the use of SMTP QUICKSTART [I-D.smtp-quickstart] with TLS-on-connect. o The new keyword "SQSMTPA" indicates the use of SMTP QUICKSTART with TLS-on-connect when the SMTP AUTH extension is also used. 5. References 5.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC3848] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2004. 5.2. Informative references [RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998. [RFC2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. [I-D.smtp-quickstart] Finch, T., "SMTP QUICKSTART", February 2006. Finch [Page 7] Internet-Draft Message submission with TLS on connect February 2006 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 [Page 8]