TCPING E. Rescorla Internet-Draft Mozilla Intended status: Standards Track July 3, 2014 Expires: January 4, 2015 TCP Use TLS Option draft-rescorla-tcpinc-tls-option-00 Abstract This document defines a TCP option (TCP-TLS) to indicate that TLS should be negotiated on a given TCP connection. 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 January 4, 2015. Copyright Notice Copyright (c) 2014 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Rescorla Expires January 4, 2015 [Page 1] Internet-Draft TCP/TLS Opt July 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4 4. Transport Integrity . . . . . . . . . . . . . . . . . . . . . . 5 5. Implementation Options . . . . . . . . . . . . . . . . . . . . 6 6. TLS Profile . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. NAT/Firewall considerations . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 Rescorla Expires January 4, 2015 [Page 2] Internet-Draft TCP/TLS Opt July 2014 1. Introduction RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this draft is maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/ekr/tcpinc-tls. Instructions are on that page as well. The TCPINC WG is chartered to define protocols to provide ubiquitous, transparent security for TCP connections. While TLS [RFC5246] is by far the most popular mechanism for securing TCP data, adding it to a given protocol requires some sort of coordination; if a client just tries to initiate TLS with a non-TLS server, the server will most likely reject the protocol messages because they do not conform to its expectations for the application layer protocol. This coordination can take a number of forms, including: o An external signal in the URL that the client should do TLS (e.g., "https:") o Using a separate port for the secure and non-secure versions of the protocol. o An extension to the application protocol to negotiate use or non- use of TLS ("STARTTLS") While mechanisms of this type are in wide use, they all require modifications to the application layer and thus do not meet the goals of TCPINC. This document describes a TCP option which allows a pair of communicating TCP endpoints to negotiate TLS use automatically without modifying the application layer protocols, thus allowing for transparent deployment. 2. Overview The basic idea behind the TCP-TLS option is simple. The SYN and SYN/ ACK messages carry TCP options indicating the willingness to do TLS and some basic information about the expected TLS modes. If both sides want to do TLS and have compatible modes, then the application data is automatically TLS protected prior to being sent over TCP. Otherwise, the application data is sent as usual. Rescorla Expires January 4, 2015 [Page 3] Internet-Draft TCP/TLS Opt July 2014 Client Server SYN + TCP-TLS -> <- SYN/ACK + TCP/TLS ACK -> <---------------- TLS Handshake ---------------> <--------- Application Data over TLS ----------> Figure 1: Negotiating TLS with TCP-TLS Client Server SYN + TCP-TLS -> <- SYN/ACK ACK -> <--------- Application Data over TLS ----------> Figure 2: Fall back to TCP If use of TLS is negotiated, the data sent over TCP simply is TLS data in compliance with {{RFC5246}. 3. Extension Definition The TCP-TLS option is very simple. +------------+------------+------------+------------+ | Kind=XX | Length | Reserved | +------------+------------+------------+------------+ | Tiebreaker | +---------------------------------------------------+ The reserved field MUST be all 0s and is present for alignment. The tiebreaker field is a 64-bit value which is used to determine the TLS roles, with the highest value being the TLS client and the lowest value being the TLS server. o In client/server applications, the active opener MUST set its tiebreaker value to all 1s (the maximum value) and the passive opener MUST set its tiebreaker to all 0s (the minimum value), thus ensuring that the TLS roles line up with the traditional TLS over TCP roles. o In applications which may use simultaneous opens, each side SHOULD randomly generate its tiebreaker value. If both sides generate the same tiebreaker value, then TCP-TLS MUST Rescorla Expires January 4, 2015 [Page 4] Internet-Draft TCP/TLS Opt July 2014 NOT be used (this has a vanishing probability of happening by accident.) If an endpoint sends the TCP-TLS option and receives it from the other side, it shall immediately negotiate TLS, taking on the role indicated by the tiebreaker value. Once the TLS handshake has completed, all application data SHALL be sent over that negotiated TLS channel. Application data MUST NOT be sent prior to the TLS handshake. If the TLS handshake fails for non-cryptographic reasons such as failure to negotiate a compatible cipher or the like, endpoints SHOULD behave as if the the TCP-TLS option was not present. This is obviously not the conventional behavior for TLS failure, but as the entire idea here is to be opportunistic and the attacker can simply suppress the TCP-TLS option entirely, this provides the maximum robustness against broken intermediaries. If the TLS handshake fails for cryptographic reasons that indicate damage to the datastream (e.g., a decryption failure or a Finished failure) then the endpoints SHOULD signal a connection failure, as this suggests that there is a middlebox modifying the data and there is a reasonable chance that the state is now corrupted. 4. Transport Integrity The basic operational mode defined by TCP-TLS protects only the application layer content, but not the TCP segment metadata. Upon receiving a packet, implementations MUST first check the TCP checksum and discard corrupt packets without presenting them to TLS. If the TCP checksum passes but TLS integrity fails, the connection MUST be torn down. Thus, TCP-TLS provides automatic security for the content, but not protection against DoS-style attacks. For instance, attackers will be able to inject RST packets, bogus application segments, etc., regardless of whether TLS authentication is used. Because the application data is TLS protected, this will not result in the application receiving bogus data, but it will constitute a DoS on the connection. This attack can be countered by using TCP-TLS in combination with TCP-AO [RFC5925], as follows: 1. The TLS connection is negotiated using the "tcpao" ALPN [I-D.ietf-tls-applayerprotoneg] indicator. Rescorla Expires January 4, 2015 [Page 5] Internet-Draft TCP/TLS Opt July 2014 2. Upon TLS handshake completion, a TLS Exporter [RFC5705] is used to generate keying material of appropriate length using exporter label TBD. 3. Further packets are protected using TCP-AO with the generated keys. The Finished messages MUST NOT be protected with AO. The first application data afterwards MUST be protected with AO. Note that because of retransmission, non-AO packets may be received after AO has been engaged; they MUST be ignored. [[OPEN ISSUE: How do we negotiate the parameters? Do we need a use_ao option like with RFC 5764? Is ALPN really what we want here?]] [[TODO: verify that the state machine matches up here.]] 5. Implementation Options There are two primary implementation options for TCP-TLS: o Implement all of TCP-TLS in the operating system kernel. o Implement just the TCP-TLS negotiation option in the operating system kernel with an interface to tell the application that TCP- TLS has been negotiated and therefore that the application must negotiate TLS. The former option obviously achieves easier deployment for applications, which don't have to do anything, but is more effort for kernel developers and requires a wider interface to the kernel to configure the TLS stack. The latter option is inherently more flexible but does not provide as immediate transparent deployment. It is also possible for systems to offer both options. 6. TLS Profile Implementations of this specification MUST at minimum support TLS 1.2 [RFC5246] and MUST support cipher suite XXX. Implementations MUST NOT negotiate versions of TLS prior to TLS 1.2. [[OPEN ISSUE: What cipher suites? Presumably we require one authenticated and one anonymous cipher suite, all with GCM.]] [[OPEN ISSUE: If TLS 1.3 is ready, we may want to require that.]] Rescorla Expires January 4, 2015 [Page 6] Internet-Draft TCP/TLS Opt July 2014 7. NAT/Firewall considerations If use of TLS is negotiated, the data sent over TCP simply is TLS data in compliance with {{RFC5246}. Thus it is extremely likely to pass through NATs, firewalls, etc. The only kind of middlebox that is likely to cause a problem is one which does protocol enforcement that blocks TLS on arbitrary (non-443) ports but _also_ passes unknown TCP options. Although no doubt such devices do exist, because this is a common scenario, a client machine should be able to probe to determine if it is behind such a device relatively readily. 8. IANA Considerations IANA [shall register/has registered] the TCP option XX for TCP-TLS. IANA [shall register/has registered] the ALPN code point "tcpao" to indicate the use of TCP-TLS with TCP-AO. 9. Security Considerations The mechanisms in this document are inherently vulnerable to active attack because an attacker can remove the TCP-TLS option. Thus, even when TCP-AO is used, all that is being provided is continuity of authentication from the initial handshake. If some sort of external authentication mechanism was provided or certificates are used, then you might get some protection against active attack. 10. References 10.1. Normative References [I-D.ietf-tls-applayerprotoneg] Friedl, S., Popov, A., Langley, A., and S. Emile, "Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension", draft-ietf-tls-applayerprotoneg-05 (work in progress), March 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. Rescorla Expires January 4, 2015 [Page 7] Internet-Draft TCP/TLS Opt July 2014 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010. [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010. 10.2. Informative References [I-D.bittau-tcp-crypt] Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres, D., and Q. Slack, "Cryptographic protection of TCP Streams (tcpcrypt)", draft-bittau-tcp-crypt-04 (work in progress), February 2014. Author's Address Eric Rescorla Mozilla EMail: ekr@rtfm.com Rescorla Expires January 4, 2015 [Page 8]