TCP-ENO: Encryption Negotiation Option
draft-bittau-tcpinc-tcpeno-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Andrea Bittau, Dan Boneh , Daniel B. Giffin , Mark J. Handley , David Mazieres , Eric W. Smith | ||
| Last updated | 2015-07-30 | ||
| Replaced by | draft-ietf-tcpinc-tcpeno, RFC 8547 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bittau-tcpinc-tcpeno-00
Network Working Group A. Bittau
Internet-Draft D. Boneh
Intended status: Experimental D. Giffin
Expires: January 31, 2016 Stanford University
M. Handley
University College London
D. Mazieres
Stanford University
E. Smith
Kestrel Institute
July 30, 2015
TCP-ENO: Encryption Negotiation Option
draft-bittau-tcpinc-tcpeno-00
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 January 31, 2016.
Bittau, et al. Expires January 31, 2016 [Page 1]
Internet-Draft tcpeno July 2015
Copyright Notice
Copyright (c) 2015 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The TCP-ENO option . . . . . . . . . . . . . . . . . . . . . 4
2.1. TCP-ENO handshake . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Handshake examples . . . . . . . . . . . . . . . . . 8
2.2. General suboptions . . . . . . . . . . . . . . . . . . . 9
2.3. Negotiation transcript . . . . . . . . . . . . . . . . . 11
3. Requirements for encryption specs . . . . . . . . . . . . . . 12
3.1. Session IDs . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Option kind sharing . . . . . . . . . . . . . . . . . . . 14
4. API extensions . . . . . . . . . . . . . . . . . . . . . . . 14
5. Security considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. 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:
Bittau, et al. Expires January 31, 2016 [Page 2]
Internet-Draft tcpeno July 2015
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
compatibility, encryption specs can vary widely in terms of wire
format, use of TCP option space, and integration with the TCP header
and segmentation. A companion document, the tcpcrypt encryption spec
[I-D.bittau-tcpinc-tcpcrypt], addresses question 2. Tcpcrypt enables
TCP-level traffic encryption today. TCP-ENO ensures that the effort
invested to deploy tcpcrypt today 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_.
Bittau, et al. Expires January 31, 2016 [Page 3]
Internet-Draft tcpeno July 2015
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 to reference a session ID).
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. Allow role negotiation during simultaneous open.
2. 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 integrating encryption with
authentication as discussed in Section 5.
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,
as shown in Figure 1. In non-SYN segments, ENO MUST take the minimal
form illustrated in Figure 2. The minimal form merely conveys one
bit of information, namely an acknowledgment that the sender received
the ENO option in the other host's SYN segment. A minimal ENO option
requires only two bytes; any additional bytes are ignored by TCP-ENO,
but MAY be used by encryption specs. 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)
Bittau, et al. Expires January 31, 2016 [Page 4]
Internet-Draft tcpeno July 2015
Byte 0 1 0 1 2 N-1
+-----+-----+ +-----+-----+-----...----+
|Kind=|Len= | |Kind=|Len= | ignored |
| ENO | 2 | OR | ENO | N | by TCP-ENO |
+-----+-----+ +-----+-----+-----...----+
Figure 2: Minimal TCP-ENO option in non-SYN segment
Each ENO suboption either specifies general parameters (discussed in
Section 2.2) or indicates the willingness to use a specific
encryption spec detailed in a separate document. There are two types
of suboption: one-byte suboptions, numbered 0x00-0x7f, and variable-
length suboptions, numbered 0x80-0xff. One-byte suboptions are
further subdivided into _general suboptions_, which apply across all
encryption specs, and _spec identifiers_, offering to follow a
specific encryption spec for the connection. Variable-length
suboptions are always spec identifiers and contain additional data as
described in the corresponding spec. Possible uses of suboption data
include session caching, early cipher suite negotiation in SYN
segments, or even key agreement.
All but the last suboption of an ENO option MUST be one-byte
suboptions (below 0x80). The last suboption MAY be a variable-length
suboption. Its length is determined by the total length of the TCP
option. In Figure 1, "Opt_i" is the variable-length option; its
total size is N-(2+i) bytes--one byte for the spec identifier "Opt_i"
itself, and N-(3+i) bytes for data. Multiple variable-length
suboptions may be included in a single TCP segment by repeating the
ENO option.
Table 1 shows initially assigned suboptions. Future specs will
ascribe meaning to additional values, requiring updated versions of
this table. Implementations MUST ignore all unknown suboptions.
+-----------+-----------------------------------------------------+
| Suboption | Meaning |
+-----------+-----------------------------------------------------+
| 0x00-0x0f | General options (see Section 2.2) |
| 0x10-0x1f | Reserved for possible use by future general options |
| 0x20 | Specified by TCP-CS1 spec |
| 0x22-0x23 | Specified by tcpcrypt spec |
| 0x24-0x25 | Specified by TLS working group |
| 0xa0 | Specified by TCP-CS1 spec |
| 0xa2-0xa3 | Specified by tcpcrypt spec |
| 0xa4-0xa5 | Specified by TLS working group |
+-----------+-----------------------------------------------------+
Table 1: TCP-ENO suboptions (options >= 0x80 are variable-length)
Bittau, et al. Expires January 31, 2016 [Page 5]
Internet-Draft tcpeno July 2015
2.1. TCP-ENO handshake
The TCP-ENO option is intended for use during TCP connection
establishment. To enable incremental deployment, a host must ensure
both that the other host supports TCP-ENO and that middleboxes have
not stripped the ENO option from TCP segments. In the event that
either of these conditions does not hold, implementations MUST
immediately cease sending TCP-ENO options and MUST gracefully fall
back to unencrypted TCP.
More precisely, for negotiation to succeed, the TCP-ENO option MUST
be present in the first 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 opener (where the
application called "connect") or a passive opener (where the
application called "listen" and "accept"), the first ACK segment may
or may not be the same as the first SYN segment. Specifically:
o An active opener 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 minimal 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 MUST restrict ENO
options to the single SYN-ACK segment it sends.
A spec identifier in a passive opener's SYN segment is _valid_ if it
is compatible with one of the suboptions in the active opener's ENO
option. Two suboptions are _compatible_ when they are allocated to
the same encryption spec and the spec defines their combined use.
Generally, two suboptions will be compatible when they are equal and
incompatible when they are not. However, specs that have been
allocated multiple suboptions MAY deviate from this behavior to pair
a one-byte suboption with a variable-length suboption or to use the
low bit of the spec identifier as an additional signaling mechanism.
Once the two sides have exchanged SYN segments, the _negotiated spec_
is the first valid spec identifier in the passive opener's SYN
segment. To handle simultaneous open (which has no passive opener),
TCP-ENO introduces a notion of _virtual passive opener_. More
precisely, then, the negotiated spec as the first valid spec
identifier in the virtual passive opener's SYN segment. In other
words, the order of suboptions in the virtual passive opener's SYN
Bittau, et al. Expires January 31, 2016 [Page 6]
Internet-Draft tcpeno July 2015
segment determines spec priority, while the order of suboptions in
the other SYN segment has no effect. Hosts must disable TCP-ENO if
the virtual passive opener's SYN segment contains no valid encryption
specs.
When possible, passive openers SHOULD send only one spec identifier
(suboption in the range 0x20-0xff), and SHOULD ensure this option is
valid. However, sending a single valid spec identifier is not
required, because doing so could be impractical in several cases,
including simultaneous open or role reversal by means of the "p" bit
discussed in Section 2.2, or library-level implementations that must
provide the TCP-ENO option contents to the kernel as a static byte
array.
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 for which it accepts none of the
encryption spec suboptions,
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, if a host receives an ACK segment containing an ENO
option, then encryption MUST be enabled. From this point the host
MUST follow the encryption protocol of 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.
Under simultaneous open, both hosts behave like active openers, with
each sending two ENO options as described above. Nonetheless, it is
necessary to break the symmetry of simultaneous open and select one
host as the _virtual passive opener_ for the purposes of determining
the negotiated spec. The virtual passive opener role is negotiated
by means of the "p" bit described in Section 2.2.
Bittau, et al. Expires January 31, 2016 [Page 7]
Internet-Draft tcpeno July 2015
2.1.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 3: Three-way handshake with successful TCP-ENO negotiation.
Figure 3 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 4: Three-way handshake with failed TCP-ENO negotiation.
Figure 4 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 does not support suboptions X or Y, 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.
(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 5: Failed TCP-ENO negotiation because of network filtering.
Figure 5 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 minimal ENO
option in its first ACK segment. The lack ENO in its A's ACK segment
Bittau, et al. Expires January 31, 2016 [Page 8]
Internet-Draft tcpeno July 2015
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<X,Y>
(2) B -> A: SYN ENO<0x01,Z,Y,X>
(3) A -> B: ACK ENO<>
(4) B -> A: ACK ENO<>
[rest of connection encrypted according to spec for Y]
Figure 6: Simultaneous open with successful TCP-ENO negotiation.
Figure 6 shows a successful TCP-ENO negotiation with simultaneous
open. Here the first four segments MUST contain an ENO option (the
first SYN and first ACK from each host). Note the use of general
suboption 0x01 selects B as the virtual passive opener, as discussed
in Section 2.2. Unless exactly one host can be designated the
virtual passive opener, TCP-ENO MUST fail and fall back to
unencrypted TCP.
2.2. 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 suboption whose high nibble is 0. The value of
the low nibble is interpreted as a bitmask, illustrated in Figure 7.
bit 7 6 5 4 3 2 1 0
+---+---+---+---+---+-------+---+
| 0 0 0 0 z aa p |
+---+---+---+---+---+-------+---+
z - Zero bit (reserved for future use)
aa - Application-aware bits
p - Virtual passive opener bit
Figure 7: 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 are used to 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-
Bittau, et al. Expires January 31, 2016 [Page 9]
Internet-Draft tcpeno July 2015
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 values 01
and 10 (binary) indicate that the application is aware of TCP-ENO.
The distinction between 01 and 10 is left to the application.
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. 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 | Application is aware of TCP-ENO |
| 11 | Application awareness is mandatory for use of TCP-ENO |
+-------+-------------------------------------------------------+
Table 2: Meaning of the two application-aware bits
p The "p" bit indicates that, for the purposes of encryption, the
sender will play the role of virtual passive opener. If a passive
opener sends a general option in a SYN-ACK segment, the "p" bit
MUST be 1 by default. An active opener sending a general
suboption MUST set the bit to 0 by default. However,
implementations SHOULD provide an API by which applications can
explicitly change the value of this bit so as to break the
symmetry of simultaneous open or reverse the virtual active/
passive opener roles.
If both ends of a connection specify the same value of "p", ENO
fails and the connection MUST fall back to unencrypted TCP. One
consequence is that an application employing TCP simultaneous open
will always fall back to unencrypted TCP unless the application is
modified to request a "p" bit of 1 at exactly one host.
If a general suboption is not present in either host's TCP SYN
segment, then the general suboption is implicitly 0x00 for a SYN-only
segment and 0x01 for a SYN-ACK segment. If exactly one host includes
an explicit general suboption in its SYN segment, then the other SYN
segment implicitly has a general suboption in which "z" = 0, "aa" =
00, and "p" is the complement of the other SYN segment's "p" bit.
Bittau, et al. Expires January 31, 2016 [Page 10]
Internet-Draft tcpeno July 2015
We refer to the host with a "p" bit of 1 (in either an explicit or
implicit general option) as the _virtual passive opener_.
Conversely, we call the host sending a "p" bit of 0 the _virtual
active opener_. The defaults were selected such that the virtual
passive and active openers are the same as the actual passive and
active openers in the absence of applications changing the "p" bit.
Encryption specs SHOULD refer to TCP-ENO's virtual active opener and
virtual passive opener when they need to break symmetry in their
protocols.
2.3. 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. Every TCP-ENO option in the virtual active opener's SYN segment,
in the order they appeared in that SYN segment.
2. A minimal two-byte ENO option, as shown in Figure 2.
3. Every TCP-ENO option in the virtual passive opener's SYN segment,
in the order they appeared in that SYN segment.
4. A minimal two-byte ENO option, as shown in Figure 2.
Note that 2 and 4 merely serve as delimiters to separate the two
hosts' options from each other and from any data that follows the
transcript. Even when the minimal ENO option contains ignored data,
this data does not appear in the transcript. Because SYN segments
MUST NOT contain minimal ENO options, this encoding is unique.
For the transcript to be well defined, hosts MUST NOT alter ENO
options in retransmitted segments, except that an active opener MAY
remove the ENO option altogether from a retransmitted SYN segment and
disable TCP-ENO. Such removal could be useful if middleboxes are
dropping segments with the ENO option.
Bittau, et al. Expires January 31, 2016 [Page 11]
Internet-Draft tcpeno July 2015
3. 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 from
application writers, all encryption specs claiming ENO suboption
numbers MUST satisfy the following properties.
o Specs MUST always cryptographically protect both the integrity and
confidentiality of TCP data streams.
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 3.1
describes the requirements of the session ID in more detail.
o Specs MUST NOT permit the negotiation of any encryption algorithms
with weaker 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.
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 with
errors.
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.
3.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, such as the one discussed in
Section 4. Applications that are aware of TCP-ENO SHOULD incorporate
the session ID value into any authentication mechanisms layered over
TCP encryption so as to authenticate actual TCP endpoints.
In order to avoid replay attacks and prevent authenticated session
IDs from being used out of context, session IDs MUST be unique over
Bittau, et al. Expires January 31, 2016 [Page 12]
Internet-Draft tcpeno July 2015
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 first
valid spec identifier in the virtual passive opener's SYN segment.
For variable-length suboptions, only the one-byte suboption is
included, not the associated data. Figure 8 shows the resulting
format.
Byte 0 1 2 N-1 N
+-----+------------...------------+
| sub-| collision-resistant hash |
| opt | of connection information |
+-----+------------...------------+
Figure 8: Format of a session ID
Though the 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 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 The session ID MUST NOT contain any confidential data (such as
data permitting the derivation of session keys).
o The session ID MUST depend on the negotiation transcript specified
in Section 2.3 in a collision-resistant way.
Bittau, et al. Expires January 31, 2016 [Page 13]
Internet-Draft tcpeno July 2015
3.2. Option kind sharing
This draft specifically prohibits ENO options from appearing in any
segments other than the initial SYN and ACK segments of a connection.
This means any use of the ENO option kind in subsequent segments 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 TCP handshake.
4. API extensions
Implementations SHOULD provide a few API extensions through which
applications can query and configure the behavior of TCP-ENO and
associated specs. Operating systems with a Berkeley-sockets-like API
SHOULD implement these extensions via the "getsockopt" and
"setsockopt" system calls at level "IPPROTO_TCP". Other operating
systems SHOULD provide some equivalent mechanism.
Table 3 summarizes the options that SHOULD be made available to
applications, along with whether they are read-only (R) or read-write
(RW), and the type of the option's value. Except for
TCPENO_VPASSIVE, read-write options, when read, always return the
previously successfully written value or the default if they have not
been written. Options of type "bytes" consist of a variable-length
array of bytes, while options of type "int" consist of a small one-
or two-bit positive integer. Below we discuss each option in more
detail.
+-------------------+----+-------+
| Option | RW | Type |
+-------------------+----+-------+
| TCPENO_SESSID | R | bytes |
| TCPENO_SPECS | RW | bytes |
| TCPENO_SELF_AWARE | RW | int |
| TCPENO_PEER_AWARE | R | int |
| TCPENO_VPASSIVE | RW | int |
| TCPENO_RAW | RW | bytes |
| TCPENO_TRANSCRIPT | R | bytes |
+-------------------+----+-------+
Table 3: Suggested new IPPROTO_TCP socket options
TCPENO_SESSID Returns the session ID of the connection, as defined
by the encryption spec in use. The first byte can be used to
determine which encryption spec is in use. This option MUST
return an error if encryption is disabled, the connection is not
yet established, or the transport layer does not implement the
negotiated spec.
Bittau, et al. Expires January 31, 2016 [Page 14]
Internet-Draft tcpeno July 2015
TCPENO_SPECS Allows the application to specify an ordered list of
encryption specs different from the system default list. If the
list is empty, TCP-ENO is disabled for the connection. Each byte
in the list specifies one suboption type from 0x20-0xff as listed
in Table 1. The list contains no suboption data for variable-
length suboptions, only the one-byte spec identifier. The order
of the list matters only for the virtual passive opener.
Implementations MUST return an error if an application attempts to
set this option after the SYN segment has been sent.
Implementations SHOULD return an error if any of the bytes are
below 0x20 or are not implemented by the TCP stack.
TCPENO_SELF_AWARE The value is an integer from 0-3, allowing
applications to specify the "aa" bits in the general suboption
sent by the host (see Section 2.2). Implementations MUST return
an error if an application attempts to set this option after a SYN
segment has been sent.
TCPENO_PEER_AWARE The value is an integer from 0-3 reporting the
"aa" bits in the general suboption of the peer's segment.
Implementations MUST return an error if an application attempts to
read this value before the connection is established.
TCPENO_VPASSIVE The value is an integer from 0-1, specifying the "p"
bit to set in the host's general suboption. Implementations MUST
return an error if applications attempt to set this option after
the SYN segment has been sent. Note that when a host does not
send a general suboption, its implicit "p" bit may depend on the
other suboption. Hence, when this option is read after the
connection is established, it should return 1 if and only if the
local host is the virtual passive opener.
TCPENO_RAW This option is for use by library-level implementations
of encryption specs. It allows applications to make use of the
TCP-ENO option, potentially including encryption specs not
supported by the transport layer, and then entirely bypass any
TCP-level encryption so as to encrypt above the transport layer.
The default value of this option is a 0-byte vector, which
disables RAW mode. If the option is set to any other value, it
disables all other socket options described in this section except
for TCPENO_TRANSCRIPT.
The value of the option is a raw ENO option contents (without the
kind and length) to be included in the host's SYN segment. In raw
mode, the TCP layer considers negotiation successful when there is
an encryption spec that appears in both SYN segments. For an
active opener in raw mode, the TCP layer automatically sends a
two-byte minimal ENO option when negotiation is successful. Raw
Bittau, et al. Expires January 31, 2016 [Page 15]
Internet-Draft tcpeno July 2015
mode does not provide the full flexibility of implementing
compatible but different suboptions, but nonetheless allows
encryption spec authors to facilitate user-mode implementations by
simply requiring identical one-byte suboptions to appear in both
SYN segments.
TCPENO_TRANSCRIPT Returns the negotiation transcript as specified in
Section 2.3. Implementations MUST return an error if negotiation
failed or has not yet completed.
In addition to these per-socket options, implementations SHOULD
provide a mechanism, such as "sysctl", by which an administrator can
set a system-wide default for TCPENO_SPECS.
5. 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 make use of the
application-aware bits, and use application awareness to fold the
session ID into authentication mechanisms. An example would be using
a secret cookie to compute and exchange a message authentication code
of the session ID.
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.
6. IANA Considerations
The following numbers need assignment by IANA:
o A new TCP option kind number for ENO
In addition, going forward IANA will maintain a registry of ENO
suboptions. The suboption registry will reflect new specs that claim
particular suboption numbers, and will therefore supersede Table 1 of
this document.
Bittau, et al. Expires January 31, 2016 [Page 16]
Internet-Draft tcpeno July 2015
7. Acknowledgments
This work was funded by DARPA CRASH under contract #N66001-10-2-4088.
8. References
8.1. Normative References
[I-D.bittau-tcpinc-tcpcrypt]
Bittau, A., Boneh, D., Giffin, D., Hamburg, M., Handley,
M., Mazieres, D., and Q. Slack, "Cryptographic protection
of TCP Streams (tcpcrypt)", draft-bittau-tcpinc-
tcpcrypt-03 (work in progress), July 2015.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
8.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-03 (work in progress), April 2015.
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-07 (work in progress),
July 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-02 (work in progress), April 2015.
[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>.
Bittau, et al. Expires January 31, 2016 [Page 17]
Internet-Draft tcpeno July 2015
[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
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
Bittau, et al. Expires January 31, 2016 [Page 18]
Internet-Draft tcpeno July 2015
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 January 31, 2016 [Page 19]