TCPING                                                       E. Rescorla
Internet-Draft                                                   Mozilla
Intended status: Standards Track                            July 3, 2014
Expires: January 4, 2015

                           TCP Use TLS Option


   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

   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
   ( 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

   draft is maintained in GitHub.  Suggested changes should be submitted
   as pull requests at  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,

   o  An external signal in the URL that the client should do TLS (e.g.,

   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

   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

   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

   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

   [[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",
                                    (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


Rescorla                 Expires January 4, 2015                [Page 8]