<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.30 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc rfcedstyle="yes"?>

<rfc ipr="trust200902" docName="draft-ietf-tcpinc-use-tls-01" category="std">

  <front>
    <title abbrev="TCP-use-TLS">Using TLS to Protect TCP Streams</title>

    <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
      <organization>Mozilla</organization>
      <address>
        <email>ekr@rtfm.com</email>
      </address>
    </author>

    <date year="2016" month="May" day="03"/>

    <area>TSV</area>
    <workgroup>TCPING</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document defines the use of TLS <xref target="RFC5246"/> with the TCP-ENO
option <xref target="I-D.bittau-tcpinc-tcpeno"/>.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>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.</t>

<t>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) <xref target="I-D.bittau-tcpinc-tcpeno"/>
which allows for negotiation of encryption at the TCP layer. This
document describes a binding of TLS <xref target="RFC5246"/> to TCP-ENO as
what ENO calls an “encryption spec”, thus allowing TCP-ENO
to negotiate TLS.</t>

</section>
<section anchor="overview" title="Overview">

<t>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.</t>

<figure anchor="negotiate"><artwork><![CDATA[
             Client                                    Server
      
             SYN + TCP-ENO [TLS]->
                                   <- SYN/ACK + TCP-ENO [TLS]
             ACK + TCP-ENO ->
             <---------------- TLS Handshake --------------->
             <--------- Application Data over TLS ---------->
]]></artwork></figure>

<figure title="Fall back to TCP" anchor="fall-back"><artwork><![CDATA[
             Client                                    Server
      
             SYN + TCP-ENO [TLS] ->
                                                   <- SYN/ACK
             ACK ->
             <--------- Application Data over TCP ---------->
]]></artwork></figure>

<t>If use of TLS is negotiated, the data sent over TCP simply is
TLS data in compliance with TLS 1.2 <xref target="RFC5246"/> or TLS 1.3
<xref target="I-D.ietf-tls-tls13"/>.</t>

<t>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.</t>

<t>If the TLS handshake fails, the endpoint MUST tear
down the TCP connection and MUST NOT send plaintext data over the
connection.</t>

</section>
<section anchor="tcp-eno-binding" title="TCP-ENO Binding">

<section anchor="suboption-definition" title="Suboption Definition">

<t>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.</t>

<figure><artwork><![CDATA[
    bit   7   6   5   4   3   2   1   0
        +---+---+---+---+---+---+---+---+
        | 0 |           TBD             |
        +---+---+---+---+---+---+---+---+
]]></artwork></figure>

<t>[[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.]]</t>

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

<t><list style="symbols">
  <t>A 1-byte suboption as in the SYN.</t>
  <t>A variable-length suboption. In this case, the remainder of the
option contains a nonce to be used for 0-RTT (see
<xref target="zero-rtt-exchange"/>. This nonce MUST be globally unique. Servers
MUST NOT use this form of
the suboption unless explicitly configured (see <xref target="api-considerations"/>).
[[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?]]</t>
</list></t>

<t>The ACK simply contains the bare TCP-ENO suboption.</t>

</section>
<section anchor="session-id" title="Session ID">

<t>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 <xref target="RFC5705"/> using the Exporter Label [[TBD]] and
without a context value (the TCP-ENO transcript is incorporated via
the TCPENOTranscript extension).</t>

</section>
<section anchor="channel-close" title="Channel Close">

<t>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.</t>

</section>
</section>
<section anchor="tls-profile" title="TLS Profile">

<t>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 <xref target="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 those
applications are likely to already have support for TLS 1.2
<xref target="RFC5246"/>. In order to accomodate both cases, we specify a wire
encoding that allows for negotiation of multiple TLS versions
(<xref target="suboption-definition"/>) but encourage implementations to
implement only TLS 1.3. Implementations which also implement TLS 1.2
MUST implement the profile described in <xref target="tls12-profile"/></t>

<section anchor="tls13-profile" title="TLS 1.3 Profile">

<t>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 
<xref target="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 <xref target="I-D.bittau-tcpinc-tcpeno"/>;
Section 3.1) and “server” to indicate the “B” role.</t>

<section anchor="handshake-modes" title="Handshake Modes">

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

<t><list style="symbols">
  <t>A 1-RTT mode which is used when the client has no information
about the server’s keying material (see <xref target="tls-full"/>)</t>
  <t>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 <xref target="tls-0-rtt"/>)</t>
</list></t>

<t>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.</t>

<t>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.</t>

<figure title="Message flow for full TLS Handshake" anchor="tls-full"><artwork><![CDATA[
     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.
]]></artwork></figure>

<t>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.</t>

</section>
<section anchor="basic-1-rtt-handshake" title="Basic 1-RTT Handshake">

<section anchor="clients-first-flight" title="Client’s First Flight">

<section anchor="client-first-flight-sending" title="Sending">

<t>In order to initiate the TLS handshake, the client sends a “ClientHello”
message [S. 6.3.1.1].</t>

<figure><artwork><![CDATA[
       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;
]]></artwork></figure>

<t>The fields listed here have the following meanings:</t>

<t><list style="hanging">
  <t hangText='client_version'><vspace blankLines='0'/>
  The version of the TLS protocol by which the client wishes to
communicate during this session.</t>
  <t hangText='random'><vspace blankLines='0'/>
  A 32-byte random nonce.</t>
  <t hangText='cipher_suites'><vspace blankLines='0'/>
  This is a list of the cryptographic options supported by the
client, with the client’s first preference first.</t>
</list></t>

<t>extensions contains a set of extension fields. The client MUST include the
following extensions:</t>

<t><list style="hanging">
  <t hangText='SignatureAlgorithms [S. 6.3.2.1]'><vspace blankLines='0'/>
  A list of signature/hash algorithm pairs the client supports.</t>
  <t hangText='NamedGroup [S. 6.3.2.2]'><vspace blankLines='0'/>
  A list of ECDHE groups that the client supports</t>
  <t hangText='ClientKeyShare [S. 6.3.2.3]'><vspace blankLines='0'/>
  Zero or more ECDHE shares drawn from the groups in NamedGroup.
This SHOULD contain either a P-256 key or an X25519 key.</t>
</list></t>

<t>The client MUST also include a ServerCertTypeExtension containing
type “Raw Public Key” <xref target="RFC7250"/>, indicating its willingness to
accept a raw public key rather than an X.509 certificate in the
server’s Certificate message.</t>

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

</section>
</section>
<section anchor="the-tcpenotranscript" title="The TCPENOTranscript">

<t>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.</t>

<t>This serves two purposes:</t>

<t><list style="symbols">
  <t>It binds the TCP-ENO negotiation into the TLS handshake.</t>
  <t>In 0-RTT mode (see <xref target="zero-rtt-exchange"/>) it allows the
server to provide an anti-replay nonce which is then
mixed into the TLS handshake.</t>
</list></t>

<t>The server MUST validate that the TCPENOTranscript extension
matches the transcript. If not, it MUST fail the handshake
with a fatal “handshake_failure” exception.</t>

<section anchor="receiving" title="Receiving">

<t>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 <xref target="server-first-flight"/>). Otherwise, it
replies with a HelloRetryRequest (<xref target="hello-retry-request"/>), 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.</t>

</section>
</section>
<section anchor="server-first-flight" title="Server’s First Flight">

<section anchor="sending" title="Sending">

<t>The server responds to the client’s first flight with a sequence of
messages:</t>

<t><list style="hanging">
  <t hangText='ServerHello [6.3.1.2]'><vspace blankLines='0'/>
  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 <xref target="client-first-flight-sending"/> and MUST also ignore any extensions
it does not recognize; this implies that the server can implement
solely the extensions listed in <xref target="client-first-flight-sending"/>.</t>
  <t hangText='ServerKeyShare [6.3.3]'><vspace blankLines='0'/>
  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.</t>
  <t hangText='EncryptedExtensions [6.3.4]'><vspace blankLines='0'/>
  Responses to the extensions offered by the client. In this case,
the only relevant extension is the ServerCertTypeExtension.</t>
  <t hangText='Certificate [6.3.5]'><vspace blankLines='0'/>
  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
<xref target="RFC7250"/>.  Otherwise, it SHALL contain one or more X.509
Certificates, as specified in <xref target="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.</t>
  <t hangText='ServerConfiguration [6.3.7]'><vspace blankLines='0'/>
  A server configuration value for use in 0-RTT (see <xref target="zero-rtt-exchange"/>).</t>
  <t hangText='CertificateVerify [6.3.8]'><vspace blankLines='0'/>
  A signature over the handshake transcript using the key provided
in the certificate message.</t>
  <t hangText='Finished [6.3.9]'><vspace blankLines='0'/>
  A MAC over the entire handshake transcript up to this point.</t>
</list></t>

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

</section>
</section>
<section anchor="receiving-1" title="Receiving">

<t>Upon receiving the server’s first flight, the client proceeds as follows:</t>

<t><list style="symbols">
  <t>Read the ServerHello message to determine the cryptographic parameters.</t>
  <t>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.</t>
  <t>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.</t>
  <t>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.</t>
  <t>Read the server’s CertificateVerify message and verify the server’s
signature over the handshake transcript. If the signature does not
verify, the client terminates the handshake with an alert (Section 6.1.2).</t>
  <t>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.</t>
</list></t>

</section>
<section anchor="clients-second-flight" title="Client’s Second Flight">

<t>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.</t>

<t>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.</t>

</section>
</section>
<section anchor="hello-retry-request" title="Hello Retry Request [6.3.1.3]">

<t>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:</t>

<figure><artwork><![CDATA[
      struct {
          ProtocolVersion server_version;
          CipherSuite cipher_suite;
          NamedGroup selected_group;
          Extension extensions<0..2^16-1>;
      } HelloRetryRequest;
]]></artwork></figure>

<t>In response to the HelloRetryRequest the client re-sends its ClientHello
but with the addition of the group indicated in “selected_group”.</t>

</section>
<section anchor="zero-rtt-exchange" title="Zero-RTT Exchange">

<t>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. TLS 1.3 also includes
a “Zero-RTT” feature which allows the client to send data on
its first flight to the server.</t>

<t>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:</t>

<figure><artwork><![CDATA[
      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;
]]></artwork></figure>

<t>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 <xref target="deprecated-features"/>), the only valid value here is
“early_data”, indicating that the client can send data in 0-RTT.</t>

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

<t><list style="symbols">
  <t>It has been specifically configured to do so (see <xref target="api-considerations"/>).</t>
  <t>A ServerConfiguration is available.</t>
  <t>The server supplied a nonce in its SYN/ACK suboption
[[TODO: Work out how to make this work with TFO if at all.]]</t>
</list></t>

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

<figure title="Message flow for a zero round trip handshake" anchor="tls-0-rtt"><artwork><![CDATA[
       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.
]]></artwork></figure>

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

<t>Note: TLS 1.3 Zero-RTT data is inherently replayable (see the note in
<xref target="I-D.ietf-tls-tls13"></xref> Section 6.2.2). However, because the client and
server have already exchanged data in the <spanx style="emph">TCP</spanx> handshake, this data
can be used to provide anti-replay for a 0-RTT mode TLS handshake
via the TCPENOTranscript extension.</t>

</section>
<section anchor="key-schedule" title="Key Schedule">

<t>TLS 1.3 derives its traffic keys from two input keying material
values:</t>

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

<t>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).</t>

<t>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 <xref target="RFC5869"/>.</t>

</section>
<section anchor="record-protection" title="Record Protection">

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

<figure><artwork><![CDATA[
       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;
]]></artwork></figure>

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

<t><list style="symbols">
  <t>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 <xref target="RFC5116"/> Section 4) and XORing
it with the sequence number of the TLS record (left-padded with zeroes).</t>
  <t>The additional data is the sequence number + the TLS version
number.</t>
</list></t>

<t>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.</t>

</section>
</section>
<section anchor="tls12-profile" title="TLS 1.2 Profile">

<t>Implementations MUST implement and require the TLS Extended Master
Secret Extension <xref target="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.</t>

</section>
<section anchor="deprecated-features" title="Deprecated Features">

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

<t><list style="symbols">
  <t>TLS certificate-based client authentication</t>
  <t>Session resumption</t>
</list></t>

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

</section>
<section anchor="cryptographic-algorithms" title="Cryptographic Algorithms">

<t>Implementations of this specification MUST implement the following cipher
suite:</t>

<figure><artwork><![CDATA[
    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 
]]></artwork></figure>

<t>These cipher suites MUST support both digital signatures and key exchange
with secp256r1 (NIST P-256) and SHOULD support key agrement with X25519
<xref target="I-D.irtf-cfrg-curves"/>.</t>

<t>Implementations of this specification SHOULD implement the following cipher suites:</t>

<figure><artwork><![CDATA[
    TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
    TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
]]></artwork></figure>

</section>
</section>
<section anchor="transport-integrity" title="Transport Integrity">

<t>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.</t>

<t>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.</t>

<t>This attack could be countered by using TCP-TLS in combination
with TCP-AO <xref target="RFC5925"/>, using Application-Layer Protocol Negotiation (ALPN)
<xref target="RFC7301"/>
to negotiate the use of
AO. [[OPEN ISSUE: Is this something we want? Maybe in a separate
specification.]]</t>

</section>
<section anchor="api-considerations" title="API Considerations">

<t>Needed here:</t>

<t><list style="symbols">
  <t>How to configure 0-RTT and send 0-RTT data (some sort of sockopt).</t>
  <t>When is the session-id available (post-connect() completion).</t>
  <t>How to indicate that the certificate should be validated.</t>
</list></t>

</section>
<section anchor="implementation-considerations" title="Implementation Considerations">

<t>There are two primary implementation options for TCP-TLS:</t>

<t><list style="symbols">
  <t>Implement all of TCP-TLS in the operating system kernel.</t>
  <t>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.</t>
</list></t>

<t>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.</t>

</section>
<section anchor="natfirewall-considerations" title="NAT/Firewall considerations">

<t>If use of TLS is negotiated, the data sent over TCP simply is TLS data
in compliance with <xref target="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 <spanx style="emph">also</spanx> 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.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

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

<t>IANA [shall register/has registered] the ALPN code point “tcpao”
to indicate the use of TCP-TLS with TCP-AO.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>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.</t>

<t>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.</t>

<t>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.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor='RFC5116' target='http://www.rfc-editor.org/info/rfc5116'>
<front>
<title>An Interface and Algorithms for Authenticated Encryption</title>
<author initials='D.' surname='McGrew' fullname='D. McGrew'><organization /></author>
<date year='2008' month='January' />
<abstract><t>This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms.  The interface and registry can be used as an application-independent set of cryptoalgorithm suites.  This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5116'/>
<seriesInfo name='DOI' value='10.17487/RFC5116'/>
</reference>



<reference  anchor='RFC5246' target='http://www.rfc-editor.org/info/rfc5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2008' month='August' />
<abstract><t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5246'/>
<seriesInfo name='DOI' value='10.17487/RFC5246'/>
</reference>



<reference  anchor='RFC5925' target='http://www.rfc-editor.org/info/rfc5925'>
<front>
<title>The TCP Authentication Option</title>
<author initials='J.' surname='Touch' fullname='J. Touch'><organization /></author>
<author initials='A.' surname='Mankin' fullname='A. Mankin'><organization /></author>
<author initials='R.' surname='Bonica' fullname='R. Bonica'><organization /></author>
<date year='2010' month='June' />
<abstract><t>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5).  TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5.  TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints.  The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes.  TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously.  TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5925'/>
<seriesInfo name='DOI' value='10.17487/RFC5925'/>
</reference>



<reference  anchor='RFC5705' target='http://www.rfc-editor.org/info/rfc5705'>
<front>
<title>Keying Material Exporters for Transport Layer Security (TLS)</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2010' month='March' />
<abstract><t>A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes.  This document describes a general mechanism for allowing that.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5705'/>
<seriesInfo name='DOI' value='10.17487/RFC5705'/>
</reference>



<reference  anchor='RFC5869' target='http://www.rfc-editor.org/info/rfc5869'>
<front>
<title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
<author initials='H.' surname='Krawczyk' fullname='H. Krawczyk'><organization /></author>
<author initials='P.' surname='Eronen' fullname='P. Eronen'><organization /></author>
<date year='2010' month='May' />
<abstract><t>This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications.  The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions.  This document is not an Internet  Standards Track specification; it is published for informational  purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='5869'/>
<seriesInfo name='DOI' value='10.17487/RFC5869'/>
</reference>



<reference  anchor='RFC7250' target='http://www.rfc-editor.org/info/rfc7250'>
<front>
<title>Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
<author initials='P.' surname='Wouters' fullname='P. Wouters' role='editor'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig' role='editor'><organization /></author>
<author initials='J.' surname='Gilmore' fullname='J. Gilmore'><organization /></author>
<author initials='S.' surname='Weiler' fullname='S. Weiler'><organization /></author>
<author initials='T.' surname='Kivinen' fullname='T. Kivinen'><organization /></author>
<date year='2014' month='June' />
<abstract><t>This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).  The new certificate type allows raw public keys to be used for authentication.</t></abstract>
</front>
<seriesInfo name='RFC' value='7250'/>
<seriesInfo name='DOI' value='10.17487/RFC7250'/>
</reference>



<reference anchor='I-D.ietf-tls-applayerprotoneg'>
<front>
<title>Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension</title>

<author initials='S' surname='Friedl' fullname='Stephan Friedl'>
    <organization />
</author>

<author initials='A' surname='Popov' fullname='Andrey Popov'>
    <organization />
</author>

<author initials='A' surname='Langley' fullname='Adam Langley'>
    <organization />
</author>

<author initials='S' surname='Emile' fullname='Stephan Emile'>
    <organization />
</author>

<date month='March' day='3' year='2014' />

<abstract><t>This document describes a Transport Layer Security (TLS) extension for application layer protocol negotiation within the TLS handshake. For instances in which the TLS connection is established over a well known TCP or UDP port not associated with the desired application layer protocol, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-applayerprotoneg-05' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-applayerprotoneg-05.txt' />
</reference>



<reference anchor='I-D.ietf-tls-session-hash'>
<front>
<title>Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension</title>

<author initials='K' surname='Bhargavan' fullname='Karthikeyan Bhargavan'>
    <organization />
</author>

<author initials='A' surname='Delignat-Lavaud' fullname='Antoine Delignat-Lavaud'>
    <organization />
</author>

<author initials='A' surname='Pironti' fullname='Alfredo Pironti'>
    <organization />
</author>

<author initials='A' surname='Langley' fullname='Adam Langley'>
    <organization />
</author>

<author initials='M' surname='Ray' fullname='Marsh Ray'>
    <organization />
</author>

<date month='July' day='5' year='2015' />

<abstract><t>The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate.  Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same.  Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server.  This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-session-hash-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-session-hash-06.txt' />
</reference>



<reference anchor='I-D.ietf-tls-tls13'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month='March' day='22' year='2016' />

<abstract><t>This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol.  The TLS protocol allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-tls13-12' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-12.txt' />
</reference>



<reference anchor='I-D.bittau-tcpinc-tcpeno'>
<front>
<title>TCP-ENO: Encryption Negotiation Option</title>

<author initials='A' surname='Bittau' fullname='Andrea Bittau'>
    <organization />
</author>

<author initials='D' surname='Boneh' fullname='Dan Boneh'>
    <organization />
</author>

<author initials='D' surname='Giffin' fullname='Daniel Giffin'>
    <organization />
</author>

<author initials='M' surname='Handley' fullname='Mark Handley'>
    <organization />
</author>

<author initials='D' surname='Mazieres' fullname='David Mazieres'>
    <organization />
</author>

<author initials='E' surname='Smith' fullname='Eric Smith'>
    <organization />
</author>

<date month='September' day='10' year='2015' />

<abstract><t>Despite growing adoption of TLS [RFC5246], a significant fraction of TCP traffic on the Internet remains unencrypted.  The persistence of unencrypted traffic can be attributed to at least two factors. First, some legacy protocols lack a signaling mechanism (such as a "STARTTLS" command) by which to convey support for encryption, making incremental deployment impossible.  Second, legacy applications themselves cannot always be upgraded, requiring a way to implement encryption transparently entirely within the transport layer.  The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-bittau-tcpinc-tcpeno-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-bittau-tcpinc-tcpeno-02.txt' />
</reference>



<reference anchor='I-D.ietf-tls-chacha20-poly1305'>
<front>
<title>ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)</title>

<author initials='A' surname='Langley' fullname='Adam Langley'>
    <organization />
</author>

<author initials='W' surname='Chang' fullname='Wan-Teh Chang'>
    <organization />
</author>

<author initials='N' surname='Mavrogiannopoulos' fullname='Nikos Mavrogiannopoulos'>
    <organization />
</author>

<author initials='J' surname='Strombergson' fullname='Joachim Strombergson'>
    <organization />
</author>

<author initials='S' surname='Josefsson' fullname='Simon Josefsson'>
    <organization />
</author>

<date month='December' day='16' year='2015' />

<abstract><t>This document describes the use of the ChaCha stream cipher and Poly1305 authenticator in the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-chacha20-poly1305-04' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-chacha20-poly1305-04.txt' />
</reference>



<reference anchor='I-D.irtf-cfrg-curves'>
<front>
<title>Elliptic Curves for Security</title>

<author initials='A' surname='Langley' fullname='Adam Langley'>
    <organization />
</author>

<author initials='M' surname='Hamburg' fullname='Mike Hamburg'>
    <organization />
</author>

<date month='October' day='9' year='2015' />

<abstract><t>This memo specifies two elliptic curves over prime fields that offer high practical security in cryptographic applications, including Transport Layer Security (TLS).  These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-irtf-cfrg-curves-11' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-irtf-cfrg-curves-11.txt' />
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor='RFC5929' target='http://www.rfc-editor.org/info/rfc5929'>
<front>
<title>Channel Bindings for TLS</title>
<author initials='J.' surname='Altman' fullname='J. Altman'><organization /></author>
<author initials='N.' surname='Williams' fullname='N. Williams'><organization /></author>
<author initials='L.' surname='Zhu' fullname='L. Zhu'><organization /></author>
<date year='2010' month='July' />
<abstract><t>This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for-telnet, in accordance with RFC 5056 (On Channel Binding).</t><t>Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5929'/>
<seriesInfo name='DOI' value='10.17487/RFC5929'/>
</reference>



<reference  anchor='RFC6919' target='http://www.rfc-editor.org/info/rfc6919'>
<front>
<title>Further Key Words for Use in RFCs to Indicate Requirement Levels</title>
<author initials='R.' surname='Barnes' fullname='R. Barnes'><organization /></author>
<author initials='S.' surname='Kent' fullname='S. Kent'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2013' month='April' />
<abstract><t>RFC 2119 defines a standard set of key words for describing requirements of a specification.  Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification.  This document defines additional key words that can be used to address alternative requirements scenarios.  Authors who follow these guidelines should incorporate this phrase near the beginning of their document:</t><t>The key words &quot;MUST (BUT WE KNOW YOU WON\'T)&quot;, &quot;SHOULD CONSIDER&quot;, &quot;REALLY SHOULD NOT&quot;, &quot;OUGHT TO&quot;, &quot;WOULD PROBABLY&quot;, &quot;MAY WISH TO&quot;, &quot;COULD&quot;, &quot;POSSIBLE&quot;, and &quot;MIGHT&quot; in this document are to be interpreted as described in RFC 6919.</t></abstract>
</front>
<seriesInfo name='RFC' value='6919'/>
<seriesInfo name='DOI' value='10.17487/RFC6919'/>
</reference>



<reference  anchor='RFC7301' target='http://www.rfc-editor.org/info/rfc7301'>
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
<author initials='S.' surname='Friedl' fullname='S. Friedl'><organization /></author>
<author initials='A.' surname='Popov' fullname='A. Popov'><organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<author initials='E.' surname='Stephan' fullname='E. Stephan'><organization /></author>
<date year='2014' month='July' />
<abstract><t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t></abstract>
</front>
<seriesInfo name='RFC' value='7301'/>
<seriesInfo name='DOI' value='10.17487/RFC7301'/>
</reference>



<reference anchor='I-D.bittau-tcp-crypt'>
<front>
<title>Cryptographic protection of TCP Streams (tcpcrypt)</title>

<author initials='A' surname='Bittau' fullname='Andrea Bittau'>
    <organization />
</author>

<author initials='D' surname='Boneh' fullname='Dan Boneh'>
    <organization />
</author>

<author initials='M' surname='Hamburg' fullname='Mike Hamburg'>
    <organization />
</author>

<author initials='M' surname='Handley' fullname='Mark Handley'>
    <organization />
</author>

<author initials='D' surname='Mazieres' fullname='David Mazieres'>
    <organization />
</author>

<author initials='Q' surname='Slack' fullname='Quinn Slack'>
    <organization />
</author>

<date month='February' day='14' year='2014' />

<abstract><t>This document presents tcpcrypt, a TCP extension for cryptographically protecting TCP segments.  Tcpcrypt maintains the confidentiality of data transmitted in TCP segments against a passive eavesdropper.  It protects connections against denial-of-service attacks involving desynchronizing of sequence numbers, and when enabled, against forged RST segments.  Finally, applications that perform authentication can obtain end-to-end confidentiality and integrity guarantees by tying authentication to tcpcrypt Session ID values.  The extension defines two new TCP options, CRYPT and MAC, which are designed to provide compatible interworking with TCPs that do not implement tcpcrypt.  The CRYPT option allows hosts to negotiate the use of tcpcrypt and establish shared secret encryption keys.  The MAC option carries a message authentication code with which hosts can verify the integrity of transmitted TCP segments.  Tcpcrypt is designed to require relatively low overhead, particularly at servers, so as to be useful even in the case of servers accepting many TCP connections per second.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-bittau-tcp-crypt-04' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-bittau-tcp-crypt-04.txt' />
</reference>



<reference anchor='I-D.ietf-tls-falsestart'>
<front>
<title>Transport Layer Security (TLS) False Start</title>

<author initials='A' surname='Langley' fullname='Adam Langley'>
    <organization />
</author>

<author initials='N' surname='Modadugu' fullname='Nagendra Modadugu'>
    <organization />
</author>

<author initials='B' surname='Moeller' fullname='Bodo Moeller'>
    <organization />
</author>

<date month='November' day='2' year='2015' />

<abstract><t>This document specifies an optional behavior of TLS client implementations, dubbed False Start.  It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally.  A TLS False Start reduces handshake latency to one round trip.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-falsestart-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-falsestart-01.txt' />
</reference>




    </references>




  </back>
</rfc>

