[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-bittau-tcpinc-tcpeno) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19

Network Working Group                                          A. Bittau
Internet-Draft                                                  D. Boneh
Intended status: Experimental                                  D. Giffin
Expires: August 22, 2016                             Stanford University
                                                              M. Handley
                                               University College London
                                                             D. Mazieres
                                                     Stanford University
                                                                E. Smith
                                                       Kestrel Institute
                                                       February 19, 2016


                 TCP-ENO: Encryption Negotiation Option
                      draft-ietf-tcpinc-tcpeno-01

Abstract

   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.

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 August 22, 2016.





Bittau, et al.           Expires August 22, 2016                [Page 1]


Internet-Draft                   tcpeno                    February 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.

Table of Contents

   1.  Requirements language . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The TCP-ENO option  . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  TCP-ENO roles . . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  TCP-ENO handshake . . . . . . . . . . . . . . . . . . . .   8
       3.2.1.  Handshake examples  . . . . . . . . . . . . . . . . .  10
     3.3.  General suboptions  . . . . . . . . . . . . . . . . . . .  11
     3.4.  Specifying suboption data length  . . . . . . . . . . . .  13
     3.5.  Negotiation transcript  . . . . . . . . . . . . . . . . .  14
   4.  Requirements for encryption specs . . . . . . . . . . . . . .  15
     4.1.  Session IDs . . . . . . . . . . . . . . . . . . . . . . .  15
     4.2.  Option kind sharing . . . . . . . . . . . . . . . . . . .  17
   5.  API extensions  . . . . . . . . . . . . . . . . . . . . . . .  17
   6.  Open issues . . . . . . . . . . . . . . . . . . . . . . . . .  17
     6.1.  Experiments . . . . . . . . . . . . . . . . . . . . . . .  17
     6.2.  Multiple Session IDs  . . . . . . . . . . . . . . . . . .  18
   7.  Security considerations . . . . . . . . . . . . . . . . . . .  18
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  19
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     10.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Requirements language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].





Bittau, et al.           Expires August 22, 2016                [Page 2]


Internet-Draft                   tcpeno                    February 2016


2.  Introduction

   Many applications and protocols running on top of TCP today do not
   encrypt traffic.  This failure to encrypt lowers the bar for certain
   attacks, harming both user privacy and system security.
   Counteracting the problem demands a minimally intrusive, backward-
   compatible mechanism for incrementally deploying encryption.  The TCP
   Encryption Negotiation Option (TCP-ENO) specified in this document
   provides such a mechanism.

   While the need for encryption is immediate, future developments could
   alter trade-offs and change the best approach to TCP-level encryption
   (beyond introducing new cipher suites).  For example:

   o  Increased option space in TCP [I-D.ietf-tcpm-tcp-edo][I-D.briscoe-
      tcpm-inspace-mode-tcpbis][I-D.touch-tcpm-tcp-syn-ext-opt] could
      reduce round trip times and simplify protocols.

   o  API revisions to socket interfaces [RFC3493] could benefit from
      integration with TCP-level encryption, particularly if combined
      with technologies such as DANE [RFC6394].

   o  The forthcoming TLS 1.3 [I-D.ietf-tls-tls13] standard could reach
      more applications given an out-of-band, backward-compatible
      mechanism for enabling encryption.

   o  TCP fast open [RFC7413], as it gains more widespread adoption and
      middlebox acceptance, could potentially benefit from tailored
      encryption support.

   o  Cryptographic developments that either shorten or lengthen the
      minimal key exchange messages required could affect how such
      messages are best encoded in TCP segments.

   Introducing TCP options, extending operating system interfaces to
   support TCP-level encryption, and extending applications to take
   advantage of TCP-level encryption will all require effort.  To the
   greatest extent possible, this effort ought to remain applicable if
   the need arises to change encryption strategies.  To this end, it is
   useful to consider two questions separately:

   1.  How to negotiate the use of encryption at the TCP layer, and

   2.  How to perform encryption at the TCP layer.

   This document addresses question 1 with a new option called TCP-ENO.
   TCP-ENO provides a framework in which two endpoints can agree on one
   among multiple possible TCP encryption _specs_.  For future



Bittau, et al.           Expires August 22, 2016                [Page 3]


Internet-Draft                   tcpeno                    February 2016


   compatibility, encryption specs can vary widely in terms of wire
   format, use of TCP option space, and integration with the TCP header
   and segmentation; however, such changes will ideally be transparent
   to applications that take advantage of TCP-level encryption.  A
   companion document, the TCPINC encryption spec, addresses question 2.
   TCPINC enables TCP-level traffic encryption today.  TCP-ENO ensures
   that the effort invested to deploy TCPINC can benefit future
   encryption specs should a different approach at some point be
   preferable.

   At a lower level, TCP-ENO was designed to achieve the following
   goals:

   1.  Enable endpoints to negotiate the use of a separately specified
       encryption _spec_.

   2.  Transparently fall back to unencrypted TCP when not supported by
       both endpoints.

   3.  Provide signaling through which applications can better take
       advantage of TCP-level encryption (for instance by improving
       authentication mechanisms in the presence of TCP-level
       encryption).

   4.  Provide a standard negotiation transcript through which specs can
       defend against tampering with TCP-ENO.

   5.  Make parsimonious use of TCP option space.

   6.  Define roles for the two ends of a TCP connection, so as to name
       each end of a connection for encryption or authentication
       purposes even following a symmetric simultaneous open.

3.  The TCP-ENO option

   TCP-ENO is a TCP option used during connection establishment to
   negotiate how to encrypt traffic.  As an option, TCP-ENO can be
   deployed incrementally.  Legacy hosts unaware of the option simply
   ignore it and never send it, causing traffic to fall back to
   unencrypted TCP.  Similarly, middleboxes that strip out unknown
   options including TCP-ENO will downgrade connections to plaintext
   without breaking them.  Of course, downgrading makes TCP-ENO
   vulnerable to active attackers, but appropriately modified
   applications can protect themselves by considering the state of TCP-
   level encryption during authentication, as discussed in Section 7.

   The ENO option takes two forms.  In TCP segments with the SYN flag
   set, it acts as a container for a series of one or more suboptions,



Bittau, et al.           Expires August 22, 2016                [Page 4]


Internet-Draft                   tcpeno                    February 2016


   labeled "Opt_0", "Opt_1", ... in Figure 1.  In non-SYN segments, ENO
   conveys only a single bit of information, namely an acknowledgment
   that the sender received an ENO option in the other host's SYN
   segment.  (Such acknowledgments enable graceful fallback to
   unencrypted TCP in the event that a middlebox strips ENO options in
   one direction.)  Figure 2 illustrates the non-SYN form of the ENO
   option.  Encryption specs MAY include extra bytes in a non-SYN ENO
   option, but TCP-ENO itself MUST ignore them.  In accordance with TCP
   [RFC0793], the first two bytes of the ENO option always consist of
   the kind (ENO) and the total length of the option.

         byte    0     1     2     3            2+i  3+i ... N-1
              +-----+-----+-----+-----+--...--+-----+----...----+
              |Kind=|Len= |Opt_0|Opt_1|       |Opt_i|   Opt_i   |
              | ENO |  N  |     |     |       |     |   data    |
              +-----+-----+-----+-----+--...--+-----+----...----+

    Figure 1: TCP-ENO option in SYN segment (MUST contain at least one
                                suboption)

          byte    0     1                0     1     2     N-1
               +-----+-----+          +-----+-----+-----...----+
               |Kind=|Len= |          |Kind=|Len= |  ignored   |
               | ENO |  2  |    or    | ENO |  N  | by TCP-ENO |
               +-----+-----+          +-----+-----+-----...----+

       Figure 2: non-SYN TCP-ENO option in segment without SYN flag

   Every suboption starts with a byte of the form illustrated in
   Figure 3.  The seven-bit value "cs" specifies the meaning of the
   suboption.  Each value of "cs" specifies general parameters
   (discussed in Section 3.3), provides information about suboption
   length (discussed in Section 3.4), or indicates the willingness to
   use a specific encryption spec detailed in a separate document.

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

        v  - non-zero to indicate suboption data is present
        cs - global configuration option or encryption spec identifier

                    Figure 3: Format of suboption byte

   The high bit "v" in a suboption's first byte plays a role in
   determining whether a suboption carries additional data, and if so
   the length of that data.  When "v = 0", a suboption carries no data



Bittau, et al.           Expires August 22, 2016                [Page 5]


Internet-Draft                   tcpeno                    February 2016


   and consists simply of the seven-bit value "cs".  When "v = 1" and
   "cs < 0x20", the suboption is a marker byte, specifying the length of
   the following suboption data, as discussed in Section 3.4.  A marker
   byte MUST be followed by an encryption spec identifier with "v = 1"
   and one or more bytes of suboption data.  In the absence of a marker
   byte, a suboption with "v = 1" extends to the end of the TCP option;
   in that case the length of the suboption data is determined by the
   total length of the TCP option.  This design optimizes the common
   case that only the last suboption has any data, as no marker byte is
   needed under such circumstances.  In Figure 1, "Opt_i" is the only
   option with data and there are no marker bytes; "Opt_i"'s total size
   is N-(2+i) bytes--one byte for "Opt_i" itself and N-(3+i) bytes for
   additional data.

   Suboption data MAY be used for session caching, cipher suite
   negotiation, key exchange, or other purposes, as determined by the
   value of "cs".

   A TCP SYN segment MUST contain at most one ENO TCP option.  If a SYN
   segment contains multiple TCP options of kind ENO, the receiver MUST
   behave as though the segment contained no ENO options and disable
   encryption.

   Table 1 summarizes the allocation of values of "cs".  Values under
   0x10 are assigned to _general suboptions_ whose meaning applies
   across encryption specs, as discussed in Section 3.3, and values from
   0x10-0x1f are reserved for possible future use by general suboptions.
   Values greater than or equal to 0x20 will be assigned to _spec
   identifiers_.  When "v = 1", values in the range 0x00-0x1f become
   marker bytes while "cs" values greater than or equal to 0x20 MUST be
   followed by one or more bytes of suboption data.  Implementations
   MUST ignore all unknown and reserved suboptions.

   +-----------+-------------------------------------------------------+
   | cs        | Meaning                                               |
   +-----------+-------------------------------------------------------+
   | 0x00-0x0f | General options (Section 3.3) and marker bytes        |
   |           | (Section 3.4)                                         |
   | 0x10-0x1f | Marker bytes and future general options               |
   | 0x20-0x7f | Used to designate encryption specs                    |
   +-----------+-------------------------------------------------------+

           Table 1: Allocation of cs bits in TCP-ENO suboptions








Bittau, et al.           Expires August 22, 2016                [Page 6]


Internet-Draft                   tcpeno                    February 2016


3.1.  TCP-ENO roles

   TCP-ENO uses abstract roles to distinguish the two ends of a TCP
   connection: One host plays the "A" role, while the other host plays
   the "B" role.  Following a normal three-way handshake with no special
   configuration, the active opener plays the A role and the passive
   opener plays the B role.  An active opener is a host that sends a SYN
   segment without the ACK flag set (after a "connect" system call on
   socket-based systems).  A passive opener's first SYN segment always
   contains the ACK flag (and follows a "listen" call on socket-based
   systems).

   Roles are abstracted from the active/passive opener distinction to
   deal with simultaneous open, in which both hosts are active openers.
   For simultaneous open, the general suboptions discussed in
   Section 3.3 define a role-override bit "b", where the host with "b =
   1" plays the B role, and the host with "b = 0" plays the A role.  If
   two active openers have the same "b" bit, TCP-ENO fails and reverts
   to unencrypted TCP.

   More precisely, the above role assignment can be reduced to comparing
   a two-bit role _priority_ for each host, shown in Figure 4.  The most
   significant bit, "b", is the role-override bit.  The least
   significant bit, "p", is 1 for a passive opener and 0 for an active
   opener.  The host with the lower priority assumes the A role; the
   host with the higher priority assumes the B role.  In the event of a
   tie, TCP-ENO fails and MUST continue with unencrypted TCP as if the
   ENO options had not been present in SYN segments.

            bit   1   0
                +---+---+
                | b   p |
                +---+---+

                b - b bit from general suboptions sent by host
                p - 0 for active opener, 1 for passive opener

                  Figure 4: Role priority of an endpoint

   Each host knows its own "p" bit is 0 if it sent a SYN segment without
   an ACK flag (a "SYN-only" segment), and is 1 otherwise.  Each host
   estimates the other host's "p" bit as 0 if it receives a SYN-only
   segment, and as 1 otherwise.  An important subtlety is that because
   of a lost or delayed SYN-only segment, one of the two hosts in a
   simultaneous open may incorrectly assume the other host has "p" set
   to 1.  In the event that the two hosts set different "b" bits, no
   harm is done as the "b" bit overrides the "p" bit for role selection.
   In the event that both "b" bits are the same, both hosts have the



Bittau, et al.           Expires August 22, 2016                [Page 7]


Internet-Draft                   tcpeno                    February 2016


   same role priority and TCP-ENO MUST be aborted.  Fortunately, at
   least one host will always detect a priority tie before sending a
   SYN-ACK segment, and hence will force TCP-ENO to abort by sending its
   SYN-ACK without an ENO option.

   Encryption specs SHOULD refer to TCP-ENO's A and B roles to specify
   asymmetric behavior by the two hosts.  For the remainder of this
   document, we will use the terms "host A" and "host B" to designate
   the hosts with role A and B respectively in a connection.

3.2.  TCP-ENO handshake

   The TCP-ENO option is intended for use during TCP connection
   establishment.  To enable incremental deployment, a host needs to
   ensure both that the other host supports TCP-ENO and that no
   middlebox has stripped the ENO option from its own TCP segments.  In
   the event that either of these conditions does not hold,
   implementations MUST immediately cease sending TCP-ENO options and
   MUST continue with unencrypted TCP as if the ENO option had not been
   present.

   More precisely, for negotiation to succeed, the TCP-ENO option MUST
   be present in the SYN segment sent by each host, so as to indicate
   support for TCP-ENO.  Additionally, the ENO option MUST be present in
   the first ACK segment sent by each host, so as to indicate that no
   middlebox stripped the ENO option from the ACKed SYN.  Depending on
   whether a host is an active or a passive opener, the first ACK
   segment may or may not be the same as the SYN segment.  Specifically:

   o  An active opener in a three-way handshake begins with a SYN-only
      segment, and hence must send two segments containing ENO options.
      The initial SYN-only segment MUST contain an ENO option with at
      least one suboption, as pictured in Figure 1.  If ENO succeeds,
      the active opener's first ACK segment MUST subsequently contain a
      non-SYN ENO option, as pictured in Figure 2.

   o  A passive opener's first transmitted segment has both the SYN and
      ACK flags set.  Therefore, a passive opener sends an ENO option of
      the type shown in Figure 1 in its single SYN-ACK segment and does
      not need to send a non-SYN ENO option.

   o  Under simultaneous open, each host sends both a SYN-only segment
      and a SYN-ACK segment.  In this case, if negotiation succeeds, ENO
      options must be identical in each hosts's SYN-only and SYN-ACK
      segment.  If negotiation fails (for instance because of a tie in
      role priority), then a host detecting this failure MUST send a
      SYN-ACK segment without an ENO option.




Bittau, et al.           Expires August 22, 2016                [Page 8]


Internet-Draft                   tcpeno                    February 2016


   A spec identifier in one host's SYN segment is _valid_ if it is
   compatible with a suboption in the other host's SYN segment.  Two
   suboptions are _compatible_ when they have the same "cs" value (>=
   0x20) and when the contents or lack of suboption data in the two SYN
   segments is well-defined by the corresponding encryption spec.  Specs
   MAY require, allow, or disallow suboption data in each of the two SYN
   segments.

   Once the two sides have exchanged SYN segments, the _negotiated spec_
   is the last valid spec identifier in the SYN segment of host B (that
   is, the passive opener in the absence of simultaneous open).  In
   other words, the order of suboptions in host B's SYN segment
   determines spec priority, while the order of suboptions in host A's
   SYN segment has no effect.  Hosts must disable TCP-ENO if there is no
   valid spec in host B's SYN segment.  Note that negotiation
   prioritizes the last rather than the first valid suboption because it
   is most space efficient to place a variable-length suboption at the
   end of a TCP-ENO option.  When using this optimization, favoring the
   last suboption favors the spec with suboption data.

   When possible, host B SHOULD send only one spec identifier (suboption
   with "cs" in the range 0x20-0x7f), and SHOULD ensure this option is
   valid.  However, sending a single valid spec identifier is not
   required, as doing so could be impractical in some cases, such as
   simultaneous open or library-level implementations that can only
   provide a static TCP-ENO option to the kernel.

   A host MUST disable ENO if any of the following conditions holds:

   1.  The host receives a SYN segment without an ENO option,

   2.  The host receives a SYN segment that contains no valid encryption
       specs when paired with the SYN segment that the host has already
       sent or would otherwise have sent,

   3.  The host receives a SYN segment containing general suboptions
       that are incompatible with the SYN segment that it has already
       sent or would otherwise have sent, or

   4.  The first ACK segment received by a host does not contain an ENO
       option.

   After disabling ENO, a host MUST NOT transmit any further ENO options
   and MUST fall back to unencrypted TCP.

   Conversely, once a host has both sent and received an ACK segment
   containing an ENO option, encryption MUST be enabled.  Once
   encryption is enabled, hosts MUST follow the encryption protocol of



Bittau, et al.           Expires August 22, 2016                [Page 9]


Internet-Draft                   tcpeno                    February 2016


   the negotiated spec and MUST NOT present raw TCP payload data to the
   application.  In particular, data segments MUST contain ciphertext or
   key agreement messages as determined by the negotiated spec, and MUST
   NOT contain plaintext application data.

   Note that with a regular three-way handshake (meaning no simultaneous
   open), the mandatory ENO option in an active opener's first ACK
   segment MAY contain spec-specific data, as shown on the right in
   Figure 2.  Such data is not part of the TCP-ENO negotiation
   transcript.  Hence, an encryption spec MUST take steps to
   authenticate any data it embeds in non-SYN ENO options.

3.2.1.  Handshake examples

          (1) A -> B:  SYN      ENO<X,Y>
          (2) B -> A:  SYN-ACK  ENO<Y>
          (3) A -> B:  ACK      ENO<>
          [rest of connection encrypted according to spec for Y]

     Figure 5: Three-way handshake with successful TCP-ENO negotiation

   Figure 5 shows a three-way handshake with a successful TCP-ENO
   negotiation.  The two sides agree to follow the encryption spec
   identified by suboption Y.

                (1) A -> B:  SYN      ENO<X,Y>
                (2) B -> A:  SYN-ACK
                (3) A -> B:  ACK
                [rest of connection unencrypted legacy TCP]

       Figure 6: Three-way handshake with failed TCP-ENO negotiation

   Figure 6 shows a failed TCP-ENO negotiation.  The active opener (A)
   indicates support for specs corresponding to suboptions X and Y.
   Unfortunately, at this point one of thee things occurs:

   1.  The passive opener (B) does not support TCP-ENO,

   2.  B supports TCP-ENO, but supports neither of specs X and Y, and so
       does not reply with an ENO option, or

   3.  The network stripped the ENO option out of A's SYN segment, so B
       did not receive it.

   Whichever of the above applies, the connection transparently falls
   back to unencrypted TCP.





Bittau, et al.           Expires August 22, 2016               [Page 10]


Internet-Draft                   tcpeno                    February 2016


        (1) A -> B:  SYN      ENO<X,Y>
        (2) B -> A:  SYN-ACK  ENO<X>    [ENO stripped by middlebox]
        (3) A -> B:  ACK
        [rest of connection unencrypted legacy TCP]

     Figure 7: Failed TCP-ENO negotiation because of network filtering

   Figure 7 Shows another handshake with a failed encryption
   negotiation.  In this case, the passive opener B receives an ENO
   option from A and replies.  However, the reverse network path from B
   to A strips ENO options.  Hence, A does not receive an ENO option
   from B, disables ENO, and does not include the required non-SYN ENO
   option when ACKing the other host's SYN segment.  The lack of ENO in
   A's ACK segment signals to B that the connection will not be
   encrypted.  At this point, the two hosts proceed with an unencrypted
   TCP connection.

          (1) A -> B:  SYN      ENO<Y,X>
          (2) B -> A:  SYN      ENO<0x01,X,Y,Z>
          (3) A -> B:  SYN-ACK  ENO<Y,X>
          (4) B -> A:  SYN-ACK  ENO<0x01,X,Y,Z>
          [rest of connection encrypted according to spec for Y]

      Figure 8: Simultaneous open with successful TCP-ENO negotiation

   Figure 8 shows a successful TCP-ENO negotiation with simultaneous
   open.  Here the first four segments MUST contain an ENO option, as
   each side sends both a SYN-only and a SYN-ACK segment.  The ENO
   option in each hosts's SYN-ACK is identical to the ENO option in its
   SYN-only segment, as otherwise connection establishment could not
   recover from the loss of a SYN segment.  Note the use of the role-
   override bit in general suboption 0x01 assigns B its role, as
   discussed in Section 3.3.  The last valid spec in B's ENO option is
   Y, so Y is the negotiated spec.

3.3.  General suboptions

   Suboptions 0x00-0x0f are used for general conditions that apply
   regardless of the negotiated encryption spec.  A TCP segment MUST
   include at most one ENO suboption whose high nibble is 0.  The value
   of the low nibble is interpreted as a bitmask, illustrated in
   Figure 9.  A receiver SHOULD disable TCP-ENO upon receipt of a SYN
   segment with multiple general suboptions.








Bittau, et al.           Expires August 22, 2016               [Page 11]


Internet-Draft                   tcpeno                    February 2016


             bit   7   6   5   4   3   2   1   0
                 +---+---+---+---+---+-------+---+
                 | 0   0   0   0   z    aa     b |
                 +---+---+---+---+---+-------+---+

                 z  - Zero bit (reserved for future use)
                 aa - Application-aware bits
                 b  - Role-override bit for simultaneous open

                Figure 9: Format of the general option byte

   The fields of the bitmask are interpreted as follows:

   z  The "z" bit is reserved for future revisions of TCP-ENO.  Its
      value MUST be set to zero in sent segments and ignored in received
      segments.

   aa The two application-aware bits indicate that the application on
      the sending host is aware of TCP-ENO and has been extended to
      alter its behavior in the presence of encrypted TCP.  There are
      four possible values, as shown in Table 2.  The default, when
      applications have not been modified to take advantage of TCP-ENO,
      MUST be 00.  However, implementations SHOULD provide an API
      through which applications can set the bits to other values and
      query for the other host's application-aware bits.  The value 01
      indicates that the application is aware of TCP-ENO.  The value 10
      (binary) is reserved for future use.  It MUST be interpreted as
      the application being aware of TCP-ENO, but MUST never be sent.

      Value 11 (binary) indicates that an application is aware of TCP-
      ENO and requires application awareness from the other side.  If
      one host sends value 00 and the other host sends 11, then TCP-ENO
      MUST be disabled and fall back to unencrypted TCP.  Any other
      combination of values (including the reserved 10) is compatible
      with enabling encryption.  A possible use of value 11 is for
      applications that perform legacy encryption and wish to disable
      TCP-ENO unless higher-layer encryption can be disabled.

     +-------+-------------------------------------------------------+
     | Value | Meaning                                               |
     +-------+-------------------------------------------------------+
     |    00 | Application is not aware of TCP-ENO                   |
     |    01 | Application is aware of TCP-ENO                       |
     |    10 | Reserved but interpreted as ENO-aware                 |
     |    11 | Application awareness is mandatory for use of TCP-ENO |
     +-------+-------------------------------------------------------+

            Table 2: Meaning of the two application-aware bits



Bittau, et al.           Expires August 22, 2016               [Page 12]


Internet-Draft                   tcpeno                    February 2016


   b  This is the role-override bit in role priority, discussed in
      Section 3.1.

   A SYN segment without an explicit general suboption has an implicit
   general suboption of 0x00.

3.4.  Specifying suboption data length

   When a TCP-ENO option contains multiple suboptions with data, or when
   a suboption other than the last one has data, it is necessary to
   specify the length of the suboption so that the receiver knows at
   what point to start parsing the next suboption.  The length of
   suboption data can be specified by placing a marker byte immediately
   before a suboption.

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

                   nnnnn - 5-bit value encodes (length - 1)

                    Figure 10: Format of a marker byte

   Figure 10 shows the format of a marker byte.  It encodes a 5-bit
   value "nnnnn".  Adding one to this value specifies the length of the
   suboption data.  Hence a marker byte can designate a suboption
   carrying anywhere from 1 to 32 bytes of data (inclusive).  Note that
   the length does not count the marker byte or suboption byte, only
   suboption data following the suboption byte.  For instance, marker
   byte 0x9f would be followed by a suboption byte and 32 bytes of
   suboption data, together occupying a total of 34 bytes within an ENO
   TCP option.

   The suboption following a marker byte MUST always have "v = 1", and
   must always contain at least one byte of suboption data.

   bit   15  14  13  12  11  10  9   8   7   6   5   4   3   2   1   0
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
       | 1   0   0         mmmmm       | 0 |            nnnnnnn        |
       +---+---+---+-------------------+---+---------------------------+

       mmmmm   - 5 most significant bits of 12-bit value (length - 1)
       nnnnnnn - 7 least significant bits of 12-bit value (length - 1)

                    Figure 11: Format of a marker word





Bittau, et al.           Expires August 22, 2016               [Page 13]


Internet-Draft                   tcpeno                    February 2016


   If the octet following a marker byte has the high bit clear (meaning
   "v = 0"), then the marker byte and following octet together are
   interpreted as a marker word, as shown in Figure 11.  The length thus
   encoded does not count the marker word or suboption byte, only the
   suboption data following the suboption byte.  Marker words are
   primarily intended for use in conjunction with future TCP extensions
   for large options.  (Such an extention would need to overcome both
   TCP's 40-byte option limit and the single-byte TCP option length to
   make use of all 12 bits of length.)

   If a marker byte or word in a received SYN segment indicates that a
   TCP-ENO option would extend beyond the end of the TCP option, the
   receiver MUST behave as though the received SYN segment contains no
   TCP-ENO options and fall back to unencrypted TCP.

3.5.  Negotiation transcript

   To defend against attacks on encryption negotiation itself,
   encryption specs need a way to reference a transcript of TCP-ENO's
   negotiation.  In particular, an encryption spec MUST fail with high
   probability if its selection resulted from tampering with or forging
   initial SYN segments.

   TCP-ENO defines its negotiation transcript as a packed data structure
   consisting of a series of TCP-ENO options (each including the ENO and
   length bytes, as they appeared in the TCP header).  Specifically, the
   transcript is constructed from the following, in order:

   1.  The TCP-ENO option in host A's SYN segment, including the kind
       and length bytes.

   2.  The TCP-ENO option in host B's SYN segment, including the kind
       and length bytes.

   Note that because the ENO options in the transcript contain length
   bytes, the transcript unambiguously delimits A's and B's ENO options.

   For the transcript to be well defined, hosts MUST NOT alter ENO
   options in retransmitted segments, or between the SYN and SYN-ACK
   segments of a simultaneous open, with two exceptions for an active
   opener.  First, an active opener MAY remove the ENO option altogether
   from a retransmitted SYN-only segment and disable TCP-ENO.  Such
   removal could be useful if middleboxes are dropping segments with the
   ENO option.  Second, an active opener performing simultaneous open
   MAY include no TCP-ENO option in its SYN-ACK if the two hosts' SYN-
   only segments contain incompatible TCP-ENO options (for instance
   because role negotiation failed).




Bittau, et al.           Expires August 22, 2016               [Page 14]


Internet-Draft                   tcpeno                    February 2016


4.  Requirements for encryption specs

   TCP-ENO was designed to afford encryption spec authors a large amount
   of design flexibility.  Nonetheless, to fit all encryption specs into
   a coherent framework and abstract most of the differences away for
   application writers, all encryption specs claiming ENO "cs" numbers
   MUST satisfy the following properties.

   o  Specs MUST protect TCP data streams with authenticated encryption.

   o  Specs MUST define a session ID whose value identifies the TCP
      connection and, with overwhelming probability, is unique over all
      time if either host correctly obeys the spec.  Section 4.1
      describes the requirements of the session ID in more detail.

   o  Specs MUST NOT permit the negotiation of any encryption algorithms
      with significantly less than 128-bit security.

   o  Specs MUST NOT allow the negotiation of null cipher suites, even
      for debugging purposes.  (Implementations MAY support debugging
      modes that allow applications to extract their own session keys.)

   o  Specs MUST NOT allow the negotiation of encryption modes that do
      not provide forward secrecy some bounded, short time after the
      close of a TCP connection.

   o  Specs MUST protect and authenticate the end-of-file marker
      traditionally conveyed by TCP's FIN flag when the remote
      application calls "close" or "shutdown".  However, end-of-file MAY
      be conveyed though a mechanism other than TCP FIN.  Moreover,
      specs MAY permit attacks that cause TCP connections to abort, but
      such an abort MUST raise an error that is distinct from an end-of-
      file condition.

   o  Specs MAY disallow the use of TCP urgent data by applications, but
      MUST NOT allow attackers to manipulate the URG flag and urgent
      pointer in ways that are visible to applications.

4.1.  Session IDs

   Each spec MUST define a session ID that uniquely identifies each
   encrypted TCP connection.  Implementations SHOULD expose the session
   ID to applications via an API extension.  Applications that are aware
   of TCP-ENO SHOULD incorporate the session ID value and TCP-ENO role
   (A or B) into any authentication mechanisms layered over TCP
   encryption so as to authenticate actual TCP endpoints.





Bittau, et al.           Expires August 22, 2016               [Page 15]


Internet-Draft                   tcpeno                    February 2016


   In order to avoid replay attacks and prevent authenticated session
   IDs from being used out of context, session IDs MUST be unique over
   all time with high probability.  This uniqueness property MUST hold
   even if one end of a connection maliciously manipulates the protocol
   in an effort to create duplicate session IDs.  In other words, it
   MUST be infeasible for a host, even by deviating from the encryption
   spec, to establish two TCP connections with the same session ID to
   remote hosts obeying the spec.

   To prevent session IDs from being confused across specs, all session
   IDs begin with the negotiated spec identifier--that is, the last
   valid spec identifier in host B's SYN segment.  If the "v" bit was 1
   in host B's SYN segment, then it is also 1 in the session ID.
   However, only the first byte is included, not the suboption data.
   Figure 12 shows the resulting format.  This format is designed for
   spec authors to compute unique identifiers; it is not intended for
   application authors to pick apart session IDs.  Applications SHOULD
   treat session IDs as monolithic opaque values and SHOULD NOT discard
   the first byte to shorten identifiers.

                 byte    0     1     2        N-1    N
                      +-----+------------...------------+
                      | sub-| collision-resistant hash  |
                      | opt | of connection information |
                      +-----+------------...------------+

                     Figure 12: Format of a session ID

   Though specs retain considerable flexibility in their definitions of
   the session ID, all session IDs MUST meet certain minimum
   requirements.  In particular:

   o  The session ID MUST be at least 33 bytes (including the one-byte
      suboption), though specs may choose longer session IDs.

   o  The session ID MUST depend in a collision-resistant way on fresh
      data contributed by both sides of the connection.

   o  The session ID MUST depend in a collision-resistant way on any
      public keys, public Diffie-Hellman parameters, or other public
      asymmetric cryptographic parameters that are employed by the
      encryption spec and have corresponding private data that is known
      by only one side of the connection.

   o  Unless and until applications disclose information about the
      session ID, all but the first byte MUST be computationally
      indistinguishable from random bytes to a network eavesdropper.




Bittau, et al.           Expires August 22, 2016               [Page 16]


Internet-Draft                   tcpeno                    February 2016


   o  Applications MAY chose to make session IDs public.  Therefore,
      specs MUST NOT place any confidential data in the session ID (such
      as data permitting the derivation of session keys).

   o  The session ID MUST depend on the negotiation transcript specified
      in Section 3.5 in a collision-resistant way.

4.2.  Option kind sharing

   This draft does not specify the use of ENO options in any segments
   other than the initial SYN and ACK segments of a connection.
   Moreover, it does not specify the content of ENO options in an
   initial ACK segment that has the SYN flag clear.  As a result, any
   use of the ENO option kind after the SYN exchange will not conflict
   with TCP-ENO.  Therefore, encryption specs that require TCP option
   space MAY re-purpose the ENO option kind for use in segments after
   the initial SYN.

5.  API extensions

   Implementations SHOULD provide API extensions through which
   applications can query and configure the behavior of TCP-ENO,
   including retrieving session IDs, setting and reading application-
   aware bits, and specifying which specs to negotiate.  The specifics
   of such an API are outside the scope of this document.

6.  Open issues

   This document has experimental status because of several open issues.
   Some questions about TCP-ENO's viability depend on middlebox behavior
   that can only be determined a posteriori.  Hence, initial deployment
   of ENO will be an experiment.  In addition, a few design questions
   exists on which consensus is not clear, and hence for which greater
   discussion and justification of TCP-ENO's design may be helpful.

6.1.  Experiments

   One of the primary open questions is to what extent middleboxes will
   permit the use of TCP-ENO.  Once TCP-ENO is deployed, we will be in a
   better position to gather data on two types of failure:

   1.  Middleboxes downgrading TCP-ENO connections to unencrypted TCP.
       This can happen if middleboxes strip unknown TCP options or if
       they terminate TCP connections and relay data back and forth.

   2.  Middleboxes causing TCP-ENO connections to fail completely.  This
       can happen if applications perform deep packet inspection and
       start dropping segments that unexpectedly contain ciphertext.



Bittau, et al.           Expires August 22, 2016               [Page 17]


Internet-Draft                   tcpeno                    February 2016


   The first type of failure is tolerable since TCP-ENO is designed for
   incremental deployment anyway.  The second type of failure is more
   problematic, and, if prevalent, will require the development of
   techniques to avoid and recover from such failures.

6.2.  Multiple Session IDs

   Though currently specs must output a single session ID, it might
   alternatively be useful to define multiple identifiers per
   connection.  As an example, a public session ID might be used to
   authenticate a connection, while a private session ID could be used
   as an authentication key to link out-of-band data (such as another
   TCP connection) to the original connection.  Should multiple session
   IDs be required, it might be necessary to require all encryption
   specs to provide a feature similar to TLS exporters [RFC5705].

7.  Security considerations

   An obvious use case for TCP-ENO is opportunistic encryption.
   However, if applications do not check and verify the session ID, they
   will be open to man-in-the-middle attacks as well as simple downgrade
   attacks in which an attacker strips off the TCP-ENO option.  Hence,
   where possible, applications SHOULD be modified to fold the session
   ID into authentication mechanisms, and SHOULD employ the application-
   aware bits as needed to enable such negotiation in a backward-
   compatible way.

   Because TCP-ENO enables multiple different encryption specs to
   coexist, security could potentially be only as strong as the weakest
   available encryption spec.  For this reason, it is crucial for
   session IDs to depend on the TCP-ENO transcript in a strong way.
   Hence, encryption specs SHOULD compute session IDs using only well-
   studied and conservative hash functions.  Thus, even if an encryption
   spec is broken, and even if people deprecate it instead of disabling
   it, and even if an attacker tampers with ENO options to force
   negotiation of the broken spec, it should still be intractable for
   the attacker to induce identical session IDs at both hosts.

   Implementations MUST not send ENO options unless encryption specs
   have access to a strong source of randomness or pseudo-randomness.
   Without secret unpredictable data at both ends of a connection, it is
   impossible for encryption specs to satisfy the confidentiality and
   forward secrecy properties required by this document.








Bittau, et al.           Expires August 22, 2016               [Page 18]


Internet-Draft                   tcpeno                    February 2016


8.  IANA Considerations

   A new TCP option kind number needs to be assigned to ENO by IANA.

   In addition, IANA will need to maintain an ENO suboption registry
   mapping suboption "cs" values to encryption specs.

9.  Acknowledgments

   This work was funded by DARPA CRASH under contract #N66001-10-2-4088.

10.  References

10.1.  Normative References

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <http://www.rfc-editor.org/info/rfc793>.

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

10.2.  Informative References

   [I-D.briscoe-tcpm-inspace-mode-tcpbis]
              Briscoe, B., "Inner Space for all TCP Options (Kitchen
              Sink Draft - to be Split Up)", draft-briscoe-tcpm-inspace-
              mode-tcpbis-00 (work in progress), March 2015.

   [I-D.ietf-tcpm-tcp-edo]
              Touch, J. and W. Eddy, "TCP Extended Data Offset Option",
              draft-ietf-tcpm-tcp-edo-04 (work in progress), November
              2015.

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

   [I-D.touch-tcpm-tcp-syn-ext-opt]
              Touch, J. and T. Faber, "TCP SYN Extended Option Space
              Using an Out-of-Band Segment", draft-touch-tcpm-tcp-syn-
              ext-opt-03 (work in progress), October 2015.






Bittau, et al.           Expires August 22, 2016               [Page 19]


Internet-Draft                   tcpeno                    February 2016


   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
              Stevens, "Basic Socket Interface Extensions for IPv6",
              RFC 3493, DOI 10.17487/RFC3493, February 2003,
              <http://www.rfc-editor.org/info/rfc3493>.

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

   [RFC6394]  Barnes, R., "Use Cases and Requirements for DNS-Based
              Authentication of Named Entities (DANE)", RFC 6394,
              DOI 10.17487/RFC6394, October 2011,
              <http://www.rfc-editor.org/info/rfc6394>.

   [RFC7413]  Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
              Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
              <http://www.rfc-editor.org/info/rfc7413>.

Authors' Addresses

   Andrea Bittau
   Stanford University
   353 Serra Mall, Room 288
   Stanford, CA  94305
   US

   Email: bittau@cs.stanford.edu


   Dan Boneh
   Stanford University
   353 Serra Mall, Room 475
   Stanford, CA  94305
   US

   Email: dabo@cs.stanford.edu










Bittau, et al.           Expires August 22, 2016               [Page 20]


Internet-Draft                   tcpeno                    February 2016


   Daniel B. Giffin
   Stanford University
   353 Serra Mall, Room 288
   Stanford, CA  94305
   US

   Email: dbg@scs.stanford.edu


   Mark Handley
   University College London
   Gower St.
   London  WC1E 6BT
   UK

   Email: M.Handley@cs.ucl.ac.uk


   David Mazieres
   Stanford University
   353 Serra Mall, Room 290
   Stanford, CA  94305
   US

   Email: dm@uun.org


   Eric W. Smith
   Kestrel Institute
   3260 Hillview Avenue
   Palo Alto, CA  94304
   US

   Email: eric.smith@kestrel.edu

















Bittau, et al.           Expires August 22, 2016               [Page 21]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/