TCPING                                                       E. Rescorla
Internet-Draft                                                   Mozilla
Intended status: Standards Track                            May 03, 2016
Expires: November 4, 2016


                    Using TLS to Protect TCP Streams
                      draft-ietf-tcpinc-use-tls-01

Abstract

   This document defines the use of TLS [RFC5246] with the TCP-ENO
   option [I-D.bittau-tcpinc-tcpeno].

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 November 4, 2016.

Copyright Notice

   Copyright (c) 2016 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 November 4, 2016                [Page 1]


Internet-Draft                 TCP-use-TLS                      May 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  TCP-ENO Binding . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Suboption Definition  . . . . . . . . . . . . . . . . . .   3
     3.2.  Session ID  . . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Channel Close . . . . . . . . . . . . . . . . . . . . . .   4
   4.  TLS Profile . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  TLS 1.3 Profile . . . . . . . . . . . . . . . . . . . . .   5
       4.1.1.  Handshake Modes . . . . . . . . . . . . . . . . . . .   5
       4.1.2.  Basic 1-RTT Handshake . . . . . . . . . . . . . . . .   6
       4.1.3.  Hello Retry Request [6.3.1.3] . . . . . . . . . . . .  10
       4.1.4.  Zero-RTT Exchange . . . . . . . . . . . . . . . . . .  10
       4.1.5.  Key Schedule  . . . . . . . . . . . . . . . . . . . .  12
       4.1.6.  Record Protection . . . . . . . . . . . . . . . . . .  13
     4.2.  TLS 1.2 Profile . . . . . . . . . . . . . . . . . . . . .  13
     4.3.  Deprecated Features . . . . . . . . . . . . . . . . . . .  14
     4.4.  Cryptographic Algorithms  . . . . . . . . . . . . . . . .  14
   5.  Transport Integrity . . . . . . . . . . . . . . . . . . . . .  14
   6.  API Considerations  . . . . . . . . . . . . . . . . . . . . .  15
   7.  Implementation Considerations . . . . . . . . . . . . . . . .  15
   8.  NAT/Firewall considerations . . . . . . . . . . . . . . . . .  15
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  16
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     11.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18

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.  The WG is specifying The
   TCP Encryption Negotiation Option (TCP-ENO)
   [I-D.bittau-tcpinc-tcpeno] which allows for negotiation of encryption
   at the TCP layer.  This document describes a binding of TLS [RFC5246]
   to TCP-ENO as what ENO calls an "encryption spec", thus allowing TCP-
   ENO to negotiate TLS.







Rescorla                Expires November 4, 2016                [Page 2]


Internet-Draft                 TCP-use-TLS                      May 2016


2.  Overview

   The basic idea behind this draft is simple.  The SYN and SYN/ACK
   messages carry the TCP-ENO options indicating the willingness to do
   TLS.  If both sides want to do TLS, then a TLS handshake is started
   and once that completes, the data is TLS protected prior to being
   sent over TCP.  Otherwise, the application data is sent as usual.

                Client                                    Server

                SYN + TCP-ENO [TLS]->
                                      <- SYN/ACK + TCP-ENO [TLS]
                ACK + TCP-ENO ->
                <---------------- TLS Handshake --------------->
                <--------- Application Data over TLS ---------->

                                 Figure 1

                Client                                    Server

                SYN + TCP-ENO [TLS] ->
                                                      <- SYN/ACK
                ACK ->
                <--------- Application Data over TCP ---------->

                        Figure 2: Fall back to TCP

   If use of TLS is negotiated, the data sent over TCP simply is TLS
   data in compliance with TLS 1.2 [RFC5246] or TLS 1.3
   [I-D.ietf-tls-tls13].

   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, the endpoint MUST tear down the TCP
   connection and MUST NOT send plaintext data over the connection.

3.  TCP-ENO Binding

3.1.  Suboption Definition

   TCP-ENO suboption with cs value set to [TBD].  Specifically, this
   means that the SYN contains a 1-byte suboption indicating support for
   this specification.






Rescorla                Expires November 4, 2016                [Page 3]


Internet-Draft                 TCP-use-TLS                      May 2016


       bit   7   6   5   4   3   2   1   0
           +---+---+---+---+---+---+---+---+
           | 0 |           TBD             |
           +---+---+---+---+---+---+---+---+

   [[OPEN ISSUE: It would be nice to indicate the desire to have 0-RTT,
   but that would require a variable length suboption, which seems
   perhaps excessive.  Maybe that's the right answer anyway.]]

   The SYN/ACK can be in one of two forms:

   o  A 1-byte suboption as in the SYN.

   o  A variable-length suboption.  In this case, the remainder of the
      option contains a nonce to be used for 0-RTT (see Section 4.1.4.
      This nonce MUST be globally unique.  Servers MUST NOT use this
      form of the suboption unless explicitly configured (see
      Section 6).  [[OPEN ISSUE: I just thought this up recently, so
      it's possible it's totally half-baked and won't work.  In
      particular, am I chewing up too much option space?]]

   The ACK simply contains the bare TCP-ENO suboption.

3.2.  Session ID

   TCP-ENO Section 4.1 defines a session ID feature (not to be confused
   with TLS Session IDs).  When the protocol in use is TLS, the session
   ID is computed via a TLS Exporter [RFC5705] using the Exporter Label
   [[TBD]] and without a context value (the TCP-ENO transcript is
   incorporated via the TCPENOTranscript extension).

3.3.  Channel Close

   Because TLS security is provided in the TCP transport stream rather
   than at the segment level, the FIN is not an authenticated indicator
   of end of data.  Instead implementations following this specification
   MUST send a TLS close_notify alert prior to sending a FIN and MUST
   raise an error if a FIN or RST is receive prior to receiving a
   close_notify.

4.  TLS Profile

   The TLS Profile defined in this document is intended to be a
   compromise between two separate use cases.  For the straight TCPINC
   use case of ubiquitous transport encryption, we desire that
   implementations solely implement TLS 1.3 [I-D.ietf-tls-tls13] or
   greater.  However, we also want to allow the use of TCP-ENO as a
   signal for applications to do out-of-band negotiation of TLS, and



Rescorla                Expires November 4, 2016                [Page 4]


Internet-Draft                 TCP-use-TLS                      May 2016


   those applications are likely to already have support for TLS 1.2
   [RFC5246].  In order to accomodate both cases, we specify a wire
   encoding that allows for negotiation of multiple TLS versions
   (Section 3.1) but encourage implementations to implement only TLS
   1.3.  Implementations which also implement TLS 1.2 MUST implement the
   profile described in Section 4.2

4.1.  TLS 1.3 Profile

   TLS 1.3 is the preferred version of TLS for this specification.  In
   order to facilitate implementation, this section provides a non-
   normative description of the parts of TLS 1.3 which are relevant to
   TCPINC and defines a normative baseline of algorithms and modes which
   MUST be supported.  Other modes, cipher suites, key exchange
   algorithms, certificate formats as defined in [I-D.ietf-tls-tls13]
   MAY also be used and that document remains the normative reference
   for TLS 1.3.  Bracketed references (e.g., [S. 1.2.3.4] refer to the
   corresponding section in that document.)  In order to match TLS
   terminology, we use the term "client" to indicate the TCP-ENO "A"
   role (See [I-D.bittau-tcpinc-tcpeno]; Section 3.1) and "server" to
   indicate the "B" role.

4.1.1.  Handshake Modes

   TLS 1.3 as used in TCPINC supports two handshake modes, both based on
   Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.

   o  A 1-RTT mode which is used when the client has no information
      about the server's keying material (see Figure 3)

   o  A 0-RTT mode which is used when the client and server have
      connected previous and which allows the client to send data on the
      first flight (see Figure 4)

   In both case, the server is expected to have an Elliptic-Curve
   Digital Signature Algorithm (ECDSA) signing key which may either be a
   freshly-generated key or a long-term key (allowing Trust-On-First-Use
   (TOFU) style applications).  The key need not be associated with any
   certificate and can simply be a bare key.

   Full TLS 1.3 includes support for additional modes based on pre-
   shared keys, but TCPINC implementations MAY opt to omit them.
   Implementations MUST implement the 1-RTT mode and SHOULD implement
   the 0-RTT mode.







Rescorla                Expires November 4, 2016                [Page 5]


Internet-Draft                 TCP-use-TLS                      May 2016


        Client                                               Server

        ClientHello
          + ClientKeyShare
          + TCPENOTranscript      ------->
                                                        ServerHello
                                                     ServerKeyShare
                                              {EncryptedExtensions}
                                             {ServerConfiguration*}
                                                      {Certificate}
                                                {CertificateVerify}
                                  <--------              {Finished}
                                  <--------      [Application Data]
        {Finished}                -------->
        [Application Data]        <------->      [Application Data]

               *  Indicates optional or situation-dependent
                  messages that are not always sent.

               {} Indicates messages protected using keys
                  derived from the ephemeral secret.

               [] Indicates messages protected using keys
                  derived from the master secret.

               Figure 3: Message flow for full TLS Handshake

   Note: Although these diagrams indicate a message called
   "Certificate", this message MAY either contain a bare public key or
   an X.509 certificate (this is intended to support the out-of-band use
   case indicated above).  Implementations MUST support bare public keys
   and MAY support X.509 certificates.

4.1.2.  Basic 1-RTT Handshake

4.1.2.1.  Client's First Flight

4.1.2.1.1.  Sending

   In order to initiate the TLS handshake, the client sends a
   "ClientHello" message [S. 6.3.1.1].










Rescorla                Expires November 4, 2016                [Page 6]


Internet-Draft                 TCP-use-TLS                      May 2016


       struct {
           ProtocolVersion client_version = { 3, 4 };    /* TLS v1.3 */
           Random random;
           uint8 session_id_len_RESERVED;                /* Must be zero */
           CipherSuite cipher_suites<2..2^16-2>;
           uint8 compression_methods_len_RESERVED;       /* Must be zero */
           Extension extensions<0..2^16-1>;
       } ClientHello;

   The fields listed here have the following meanings:

   client_version
      The version of the TLS protocol by which the client wishes to
      communicate during this session.

   random
      A 32-byte random nonce.

   cipher_suites
      This is a list of the cryptographic options supported by the
      client, with the client's first preference first.

   extensions contains a set of extension fields.  The client MUST
   include the following extensions:

   SignatureAlgorithms [S. 6.3.2.1]
      A list of signature/hash algorithm pairs the client supports.

   NamedGroup [S. 6.3.2.2]
      A list of ECDHE groups that the client supports

   ClientKeyShare [S. 6.3.2.3]
      Zero or more ECDHE shares drawn from the groups in NamedGroup.
      This SHOULD contain either a P-256 key or an X25519 key.

   The client MUST also include a ServerCertTypeExtension containing
   type "Raw Public Key" [RFC7250], indicating its willingness to accept
   a raw public key rather than an X.509 certificate in the server's
   Certificate message.

   The client MUST include a TCPENOTranscript extension containing the
   TCP-ENO options that were used to negotiate ENO.

4.1.2.2.  The TCPENOTranscript

   TCPENOTranscript TLS Extension is used to carry the TCP ENO
   negotiation transcript.  The body of the extension simply includes
   the TCP-ENO negotiation transcript as defined in TCP-ENO Section 3.4.



Rescorla                Expires November 4, 2016                [Page 7]


Internet-Draft                 TCP-use-TLS                      May 2016


   This serves two purposes:

   o  It binds the TCP-ENO negotiation into the TLS handshake.

   o  In 0-RTT mode (see Section 4.1.4) it allows the server to provide
      an anti-replay nonce which is then mixed into the TLS handshake.

   The server MUST validate that the TCPENOTranscript extension matches
   the transcript.  If not, it MUST fail the handshake with a fatal
   "handshake_failure" exception.

4.1.2.2.1.  Receiving

   Upon receiving the client's ClientHello, the server selects a
   ciphersuite and ECDHE group out of the lists provided by the client
   in the cipher_suites list and the NamedGroup extension.  If the
   client supplied an appropriate ClientKeyShare for that group, then
   the server responds with a ServerHello (see Section 4.1.2.3).
   Otherwise, it replies with a HelloRetryRequest (Section 4.1.3),
   indicating that the client needs to re-send the ClientHello with an
   appropriate key share; because all TCPINC implementations are
   required to support P-256, this should not happen unless P-256 is
   deprecated by a subsequent specification.

4.1.2.3.  Server's First Flight

4.1.2.3.1.  Sending

   The server responds to the client's first flight with a sequence of
   messages:

   ServerHello [6.3.1.2]
      Contains a nonce and the cipher suite that the server has selected
      out of the client's list.  The server MUST support the extensions
      listed in Section 4.1.2.1.1 and MUST also ignore any extensions it
      does not recognize; this implies that the server can implement
      solely the extensions listed in Section 4.1.2.1.1.

   ServerKeyShare [6.3.3]
      Contains the server's ECDHE share for one of the groups offered in
      the client's ClientKeyShare message.  All messages after
      ServerKeyShare are encrypted using keys derived from the
      ClientKeyShare and ServerKeyShare.

   EncryptedExtensions [6.3.4]
      Responses to the extensions offered by the client.  In this case,
      the only relevant extension is the ServerCertTypeExtension.




Rescorla                Expires November 4, 2016                [Page 8]


Internet-Draft                 TCP-use-TLS                      May 2016


   Certificate [6.3.5]
      The server's certificate.  If the client offered a "Raw Public
      Key" type in ServerCertTypeExtension this message SHALL contain a
      SubjectPublicKeyInfo value for the server's key as specified in
      [RFC7250].  Otherwise, it SHALL contain one or more X.509
      Certificates, as specified in [I-D.ietf-tls-tls13], Section 6.3.5.
      In either case, this message MUST contain a key which is
      consistent with the client's SignatureAlgorithms and NamedGroup
      extensions.

   ServerConfiguration [6.3.7]
      A server configuration value for use in 0-RTT (see Section 4.1.4).

   CertificateVerify [6.3.8]
      A signature over the handshake transcript using the key provided
      in the certificate message.

   Finished [6.3.9]
      A MAC over the entire handshake transcript up to this point.

   Once the server has sent the Finished message, it can immediately
   generate the application traffic keys and start sending application
   traffic to the client.

4.1.2.4.  Receiving

   Upon receiving the server's first flight, the client proceeds as
   follows:

   o  Read the ServerHello message to determine the cryptographic
      parameters.

   o  Read the ServerKeyShare message and use that in combination with
      the ClientKeyShare to compute the keys which are used to encrypt
      the rest of the handshake.

   o  Read the EncryptedExtensions message.  As noted above, the main
      extension which needs to be processed is ServerCertTypeExtension,
      which indicates the format of the server's certificate message.

   o  Read the server's certificate message and store the server's
      public key.  Unless the implementation is specifically configured
      otherwise, it SHOULD NOT attempt to validate the certificate, even
      if it is of type X.509 but merely extract the key.

   o  Read the server's CertificateVerify message and verify the
      server's signature over the handshake transcript.  If the




Rescorla                Expires November 4, 2016                [Page 9]


Internet-Draft                 TCP-use-TLS                      May 2016


      signature does not verify, the client terminates the handshake
      with an alert (Section 6.1.2).

   o  Read the server's Finished message and verify the finished MAC
      based on the DH shared secret.  If the MAC does not verify, the
      client terminates the handshake with an alert.

4.1.2.5.  Client's Second Flight

   Finally, the client sends a Finished message which contains a MAC
   over the handshake transcript (except for the server's Finished).
   [[TODO: In the upcoming draft of TLS 1.3, the client's Finished will
   likely include the server's Finished.]] Once the client has
   transmitted the Finished, it can begin sending encrypted traffic to
   the server.

   The server reads the client's Finished message and verifies the MAC.
   If the MAC does not verify, the client terminates the handshake with
   an alert.

4.1.3.  Hello Retry Request [6.3.1.3]

   Because there are a small number of recommended groups, the
   ClientKeyShare will generally contain a key share for a group that
   the server supports.  However, it is possible that the client will
   not send such a key share, but there may be another group that the
   client and server jointly support.  In that case, the server MUST
   send a HelloRetryRequest indicating the desired group:

         struct {
             ProtocolVersion server_version;
             CipherSuite cipher_suite;
             NamedGroup selected_group;
             Extension extensions<0..2^16-1>;
         } HelloRetryRequest;

   In response to the HelloRetryRequest the client re-sends its
   ClientHello but with the addition of the group indicated in
   "selected_group".

4.1.4.  Zero-RTT Exchange

   TLS 1.3 allows the server to send its first application data message
   to the client immediately upon receiving the client's first handshake
   message (which the client can send upon receiving the server's SYN/
   ACK).  However, in the basic handshake, the client is required to
   wait for the server's first flight before it can send to the server.




Rescorla                Expires November 4, 2016               [Page 10]


Internet-Draft                 TCP-use-TLS                      May 2016


   TLS 1.3 also includes a "Zero-RTT" feature which allows the client to
   send data on its first flight to the server.

   In order to enable this feature, in an initial handshake the server
   sends a ServerConfiguration message which contains the server's semi-
   static (EC)DH key which can be used for a future handshake:

         struct {
             opaque configuration_id<1..2^16-1>;
             uint32 expiration_date;
             NamedGroup group;
             opaque server_key<1..2^16-1>;
             EarlyDataType early_data_type;
             ConfigurationExtension extensions<0..2^16-1>;
         } ServerConfiguration;

   The group and server_key fields contain the server's (EC)DH key and
   the early_data_type field is used to indicate what data can be sent
   in zero-RTT.  Because client authentication is forbidden in TCPINC-
   uses of TLS 1.3 (see Section 4.3), the only valid value here is
   "early_data", indicating that the client can send data in 0-RTT.

   In a future connection, a client MAY send 0-RTT data only if the
   following three conditions obtain:

   o  It has been specifically configured to do so (see Section 6).

   o  A ServerConfiguration is available.

   o  The server supplied a nonce in its SYN/ACK suboption [[TODO: Work
      out how to make this work with TFO if at all.]]

   In this case, the client sends an EarlyDataIndication extension in
   its ClientHello and can start sending data immediately, as shown
   below.
















Rescorla                Expires November 4, 2016               [Page 11]


Internet-Draft                 TCP-use-TLS                      May 2016


          Client                                               Server

          ClientHello
            + ClientKeyShare
            + EarlyDataIndication
            + TCPENOTranscript
          (EncryptedExtensions)
          (Application Data)        -------->
                                                          ServerHello
                                                + EarlyDataIndication
                                                       ServerKeyShare
                                                {EncryptedExtensions}
                                               {ServerConfiguration*}
                                                        {Certificate}
                                                  {CertificateVerify}
                                    <--------              {Finished}
                                    <--------      [Application Data]
          {Finished}                -------->

          [Application Data]        <------->      [Application Data]

               () Indicates messages protected using keys
                  derived from the static secret.

          Figure 4: Message flow for a zero round trip handshake

   IMPORTANT NOTE: TLS 1.3 Zero-RTT does not provide PFS and therefore
   MUST only be used when explicitly configured.

   Note: TLS 1.3 Zero-RTT data is inherently replayable (see the note in
   [I-D.ietf-tls-tls13] Section 6.2.2).  However, because the client and
   server have already exchanged data in the _TCP_ handshake, this data
   can be used to provide anti-replay for a 0-RTT mode TLS handshake via
   the TCPENOTranscript extension.

4.1.5.  Key Schedule

   TLS 1.3 derives its traffic keys from two input keying material
   values:

   Ephemeral Secret (ES): A secret which is derived from ClientKeyShare
   and ServerKeyShare.

   Static Secret (SS): A secret which which is derived from
   ClientKeyShare and either ServerKeyShare (in the 1-RTT case) or the
   public key in the ServerConfiguration (in the 0-RTT case).





Rescorla                Expires November 4, 2016               [Page 12]


Internet-Draft                 TCP-use-TLS                      May 2016


   The handshake is encrypted under keys derived from ES.  The ordinary
   traffic keys are derived from the combination of ES and SS.  The
   0-RTT traffic keys are derived solely from ES and therefore have
   limited forward security.  All key derivation is done using the HKDF
   key-derivation algorithm [RFC5869].

4.1.6.  Record Protection

   Once the TLS handshake has completed, all data is protected as a
   series of TLS Records.

       struct {
           ContentType opaque_type = application_data(23); /* see fragment.type */
           ProtocolVersion record_version = { 3, 1 };    /* TLS v1.x */
           uint16 length;
           aead-ciphered struct {
              opaque content[TLSPlaintext.length];
              ContentType type;
              uint8 zeros[length_of_padding];
           } fragment;
       } TLSCiphertext;

   Each record is encrypted with an Authenticated Encryption with
   Additional Data (AEAD) cipher with the following parameters:

   o  The AEAD nonce is constructed by generating a per-connection nonce
      mask of length max(8 bytes, N_MIN) for the AEAD algorithm (N_MIN
      is the minimum nonce size defined in [RFC5116] Section 4) and
      XORing it with the sequence number of the TLS record (left-padded
      with zeroes).

   o  The additional data is the sequence number + the TLS version
      number.

   The record data MAY BE padded with zeros to the right.  Because the
   content type byte value is always non-zero, the padding is removed by
   removing bytes from the right until a non-zero byte is encountered.

4.2.  TLS 1.2 Profile

   Implementations MUST implement and require the TLS Extended Master
   Secret Extension [I-D.ietf-tls-session-hash] and MUST NOT negotiate
   versions of TLS prior to TLS 1.2.  Implementations MUST NOT negotiate
   non-AEAD cipher suites and MUST use only PFS cipher suites with a key
   of at least 2048 bits (finite field) or 256 bites (elliptic curve).
   TLS 1.2 implementations MUST NOT initiate renegotiation and MUST
   respond to renegotiation with a fatal "no_renegotiation" alert.




Rescorla                Expires November 4, 2016               [Page 13]


Internet-Draft                 TCP-use-TLS                      May 2016


4.3.  Deprecated Features

   When TLS is used with TCPINC, a number of TLS features MUST NOT be
   used, including:

   o  TLS certificate-based client authentication

   o  Session resumption

   These features have only minimal advantage in this context and
   interfere with offering a reduced profile.

4.4.  Cryptographic Algorithms

   Implementations of this specification MUST implement the following
   cipher suite:

       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

   These cipher suites MUST support both digital signatures and key
   exchange with secp256r1 (NIST P-256) and SHOULD support key agrement
   with X25519 [I-D.irtf-cfrg-curves].

   Implementations of this specification SHOULD implement the following
   cipher suites:

       TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

5.  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 could be countered by using TCP-TLS in combination with
   TCP-AO [RFC5925], using Application-Layer Protocol Negotiation (ALPN)



Rescorla                Expires November 4, 2016               [Page 14]


Internet-Draft                 TCP-use-TLS                      May 2016


   [RFC7301] to negotiate the use of AO.  [[OPEN ISSUE: Is this
   something we want?  Maybe in a separate specification.]]

6.  API Considerations

   Needed here:

   o  How to configure 0-RTT and send 0-RTT data (some sort of sockopt).

   o  When is the session-id available (post-connect() completion).

   o  How to indicate that the certificate should be validated.

7.  Implementation Considerations

   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.

8.  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.

9.  IANA Considerations

   IANA [shall register/has registered] the TCP-ENO suboption XX for
   TCP-TLS.





Rescorla                Expires November 4, 2016               [Page 15]


Internet-Draft                 TCP-use-TLS                      May 2016


   IANA [shall register/has registered] the ALPN code point "tcpao" to
   indicate the use of TCP-TLS with TCP-AO.

10.  Security Considerations

   The mechanisms in this document are inherently vulnerable to active
   attack because an attacker can remove the TCP-TLS option, thus
   downgrading you to ordinary TCP.  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.

   Once the TCP-TLS option has been negotiated, then the connection is
   resistant to active data injection attacks.  If TCP-AO is not used,
   then injected packets appear as bogus data at the TLS layer and will
   result in MAC errors followed by a fatal alert.  The result is that
   while data integrity is provided, the connection is not resistant to
   DoS attacks intended to terminate it.

   If TCP-AO is used, then any bogus packets injected by an attacker
   will be rejected by the TCP-AO integrity check and therefore will
   never reach the TLS layer.  Thus, in this case, the connection is
   also resistant to DoS attacks, provided that endpoints require
   integrity protection for RST packets.  If endpoints accept
   unauthenticated RST, then no DoS protection is provided.

11.  References

11.1.  Normative References

   [I-D.bittau-tcpinc-tcpeno]
              Bittau, A., Boneh, D., Giffin, D., Handley, M., Mazieres,
              D., and E. Smith, "TCP-ENO: Encryption Negotiation
              Option", draft-bittau-tcpinc-tcpeno-02 (work in progress),
              September 2015.

   [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.









Rescorla                Expires November 4, 2016               [Page 16]


Internet-Draft                 TCP-use-TLS                      May 2016


   [I-D.ietf-tls-chacha20-poly1305]
              Langley, A., Chang, W., Mavrogiannopoulos, N.,
              Strombergson, J., and S. Josefsson, "ChaCha20-Poly1305
              Cipher Suites for Transport Layer Security (TLS)", draft-
              ietf-tls-chacha20-poly1305-04 (work in progress), December
              2015.

   [I-D.ietf-tls-session-hash]
              Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley,
              A., and M. Ray, "Transport Layer Security (TLS) Session
              Hash and Extended Master Secret Extension", draft-ietf-
              tls-session-hash-06 (work in progress), July 2015.

   [I-D.ietf-tls-tls13]
              Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-12 (work in progress),
              March 2016.

   [I-D.irtf-cfrg-curves]
              Langley, A. and M. Hamburg, "Elliptic Curves for
              Security", draft-irtf-cfrg-curves-11 (work in progress),
              October 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <http://www.rfc-editor.org/info/rfc5116>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC5705]  Rescorla, E., "Keying Material Exporters for Transport
              Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
              March 2010, <http://www.rfc-editor.org/info/rfc5705>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <http://www.rfc-editor.org/info/rfc5869>.






Rescorla                Expires November 4, 2016               [Page 17]


Internet-Draft                 TCP-use-TLS                      May 2016


   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <http://www.rfc-editor.org/info/rfc5925>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <http://www.rfc-editor.org/info/rfc7250>.

11.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.

   [I-D.ietf-tls-falsestart]
              Langley, A., Modadugu, N., and B. Moeller, "Transport
              Layer Security (TLS) False Start", draft-ietf-tls-
              falsestart-01 (work in progress), November 2015.

   [RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
              for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
              <http://www.rfc-editor.org/info/rfc5929>.

   [RFC6919]  Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
              for Use in RFCs to Indicate Requirement Levels", RFC 6919,
              DOI 10.17487/RFC6919, April 2013,
              <http://www.rfc-editor.org/info/rfc6919>.

   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <http://www.rfc-editor.org/info/rfc7301>.

Author's Address

   Eric Rescorla
   Mozilla

   EMail: ekr@rtfm.com








Rescorla                Expires November 4, 2016               [Page 18]