TCP-ENO: Encryption Negotiation OptionGoogle345 Spear StreetSan Francisco, CA94105USbittau@google.comStanford University353 Serra Mall, Room 288Stanford, CA94305USdbg@scs.stanford.eduUniversity College LondonGower St.LondonWC1E 6BTUKM.Handley@cs.ucl.ac.ukStanford University353 Serra Mall, Room 290Stanford, CA94305USdm@uun.orgKestrel Institute3260 Hillview AvenuePalo Alto, CA94304USeric.smith@kestrel.edu
Internet
tcpencryptionDespite growing adoption of TLS, 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.
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 .
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.
Introducing TCP options, extending operating system interfaces to
support TCP-level encryption, and extending applications to take
advantage of TCP-level encryption all require effort. To the greatest
extent possible, the effort invested in realizing TCP-level encryption
today needs to remain applicable in the future should the need arise
to change encryption strategies. To this end, it is useful to
consider two questions separately:
How to negotiate the use of encryption at the TCP layer, andHow to perform encryption at the TCP layer.This document addresses question 1 with a new TCP option, ENO.
TCP-ENO provides a framework in which two endpoints can agree on one
among multiple possible TCP encryption protocols or TEPs. For
future compatibility, TEPs can vary widely in terms of wire format,
use of TCP option space, and integration with the TCP header and
segmentation. However, ENO abstracts these differences to ensure the
introduction of new TEPs can be transparent to applications taking
advantage of TCP-level encryption.
Question 2 is addressed by one or more companion TEP specification
documents. While current TEPs enable TCP-level traffic encryption
today, TCP-ENO ensures that the effort invested to deploy today's TEPs
will additionally benefit future ones.
TCP-ENO was designed to achieve the following goals:
Enable endpoints to negotiate the use of a separately specified
TCP encryption protocol or TEP.Transparently fall back to unencrypted TCP when not supported by
both endpoints.Provide out-of-band 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).Provide a standard negotiation transcript through which TEPs can
defend against tampering with TCP-ENO.Make parsimonious use of TCP option space.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.We define the following terms, which are used throughout this
document:
A TCP segment in which the SYN flag is set
A TCP segment in which the ACK flag is set (which includes most
segments other than an initial SYN segment)
A TCP segment in which the SYN flag is clear
A TCP segment in which the SYN flag is set but the ACK flag is
clear
A TCP segment in which the SYN and ACK flags are both set
A host that initiates a connection by sending a SYN-only segment.
With the BSD socket API, an active opener calls connect. In
client-server configurations, active openers are typically clients.
A host that does not send a SYN-only segment, but responds to one
with a SYN-ACK segment. With the BSD socket API, passive openers
call listen and accept, rather than connect. In
client-server configurations, passive openers are typically
servers.
The act of symmetrically establishing a TCP connection between two
active openers (both of which call connect with BSD sockets).
Each host of a simultaneous open sends both a SYN-only and a
SYN-ACK segment. Simultaneous open is less common than asymmetric
open with one active and one passive opener, but can be used for
NAT traversal by peer-to-peer applications .
A TCP encryption protocol intended for use with TCP-ENO and
specified in a separate document.
A unique 7-bit value in the range 0x20-0x7f that IANA has assigned
to a TEP.
The single TEP governing a TCP connection, determined by use of the
TCP ENO option specified in this document.TCP-ENO extends TCP connection establishment to enable encryption
opportunistically. It uses a new TCP option kind to negotiate one
among multiple possible TCP encryption protocols or TEPs. The
negotiation involves hosts exchanging sets of supported TEPs, where
each TEP is represented by a suboption within a larger TCP ENO
option in the offering host's SYN segment.
If TCP-ENO succeeds, it yields the following information:
A negotiated TEP, represented by a unique 7-bit TEP identifier,A few extra bytes of suboption data from each host, if needed by the
TEP,A negotiation transcript with which to mitigate attacks on the
negotiation itself,Role assignments designating one endpoint "host A" and the other
endpoint "host B", andA bit available to higher-layer protocols at each endpoint for
out-of-band negotiation of updated behavior in the presence of TCP
encryption.If TCP-ENO fails, encryption is disabled and the connection falls back
to traditional unencrypted TCP.
The remainder of this section provides the normative description of
the TCP ENO option and handshake protocol.
TCP-ENO employs an option in the TCP header .
illustrates the high-level format of this option.
The contents of an ENO option can take one of two forms. A SYN form,
illustrated in , appears only in SYN segments. A non-SYN
form, illustrated in , appears only in non-SYN segments.
The SYN form of ENO acts as a container for zero or more suboptions,
labeled Opt_0, Opt_1, ... in . The non-SYN form, by its
presence, acts as a one-bit acknowledgment, with the actual contents
ignored by ENO. Particular TEPs MAY assign additional meaning to the
contents of non-SYN ENO options. When a negotiated TEP does not
assign such meaning, the contents of a non-SYN ENO option MUST be zero
bytes in sent segments and MUST be ignored in received segments.
Every suboption starts with a byte of the form illustrated in
. The high bit v, when set, introduces suboptions with
variable-length data. When v = 0, the byte itself constitutes the
entirety of the suboption. The 7-bit value glt expresses one of:
Global configuration data (discussed in ),Suboption data length for the next suboption (discussed in
), orAn offer to use a particular TEP defined in a separate TEP
specification document. summarizes the meaning of initial suboption bytes.
Values of glt below 0x20 are used for global suboptions and length
information (the gl in glt), while those greater than or equal to
0x20 are TEP identifiers (the t). When v = 0, the initial
suboption byte constitutes the entirety of the suboption and all
information is expressed by the 7-bit glt value, which can be either
a global suboption or a TEP identifier. When v = 1, it indicates a
suboption with variable-length suboption data. Only TEP identifiers
may have suboption data, not global suboptions. Hence, bytes with v
= 1 and glt < 0x20 are not global suboptions but rather length
bytes governing the length of the next suboption (which MUST be a TEP
identifer). In the absence of a length byte, a TEP identifier
suboption with v = 1 has suboption data extending to the end of the
TCP option.
gltvMeaning0x00-0x1f0Global suboption ()0x00-0x1f1Length byte ()0x20-0x7f0TEP identifier without suboption data0x20-0x7f1TEP identifier followed by suboption dataA SYN segment MUST contain at most one TCP ENO option. If a SYN
segment contains more than one ENO option, the receiver MUST behave as
though the segment contained no ENO options and disable encryption. A
TEP MAY specify the use of multiple ENO options in a non-SYN segment.
For non-SYN segments, ENO itself only distinguishes between the
presence or absence of ENO options; multiple ENO options are
interpreted the same as one.
Suboptions 0x00-0x1f are used for global configuration that applies
regardless of the negotiated TEP. A TCP SYN segment MUST include at
most one ENO suboption in this range. A receiver MUST ignore all but
the first suboption in this range in any given TCP segment so as to
anticipate updates to ENO that assign new meaning to bits in
subsequent global suboptions. The value of a global suboption byte is
interpreted as a bitmask, illustrated in .
The fields of the bitmask are interpreted as follows:
The passive role bit MUST be 1 for all passive openers. For active
openers, it MUST default to 0, but implementations MUST provide an API
through which an application can explicitly set b = 1 before
initiating an active open. (Manual configuration of b is necessary
to enable encryption with a simultaneous open.)
Legacy applications can benefit from ENO-specific updates that
improve endpoint authentication or avoid double encryption. The
application-aware bit a is an out-of-band signal through which
higher-layer protocols can enable ENO-specific updates that would
otherwise not be backwards-compatible. Implementations MUST set this
bit to 0 by default, and MUST provide an API through which
applications can change the value of the bit as well as examine the
value of the bit sent by the remote host. Implementations MUST
furthermore support a mandatory application-aware mode in which
TCP-ENO is automatically disabled if the remote host does not set a =
1.
The z bits are reserved for future updates to TCP-ENO. They MUST
be set to zero in sent segments and MUST be ignored in received
segments.A SYN segment without an explicit global suboption has an implicit
global suboption of 0x00. Because passive openers MUST always set b
= 1, they cannot rely on this implicit 0x00 byte and MUST include an
explicit global suboption in their SYN-ACK segments.
TCP-ENO uses abstract roles to distinguish the two ends of a TCP
connection. These roles are determined by the b bit in the global
suboption. The host that sent an implicit or explicit suboption with
b = 0 plays the "A" role. The host that sent b = 1 plays the "B"
role.
If both sides of a connection set b = 1 (which can happen if the
active opener misconfigures b before calling connect), or both
sides set b = 0 (which can happen with simultaneous open), then
TCP-ENO MUST be disabled and the connection MUST fall back to
unencrypted TCP.
TEP specifications 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 roles A and B, respectively, in a connection.
A TEP MAY optionally make use of one or more bytes of suboption data.
The presence of such data is indicated by setting v = 1 in the
initial suboption byte (see ). By default, suboption
data extends to the end of the TCP option. Hence, if only one
suboption requires data, the most compact way to encode it is to place
it last in the ENO option, after all other suboptions. As an example,
in , the last suboption, Opt_i, has suboption data and
thus requires v = 1; however, the suboption data length is inferred
from the total length of the TCP option.
When a suboption with data is not last in an ENO option, the sender
MUST explicitly specify the suboption data length for the receiver to
know where the next suboption starts. The sender does so by preceding
the suboption with a length byte, depicted in . The
length byte encodes a 5-bit value nnnnn. Adding one to nnnnn
yields the length of the suboption data (not including the length byte
or the TEP identifier). Hence, a length byte can designate anywhere
from 1 to 32 bytes of suboption data (inclusive).
A suboption preceded by a length byte MUST be a TEP identifier
(glt >= 0x20) and MUST have v = 1.
shows an example of such a suboption.
A host MUST ignore an ENO option in a SYN segment and MUST disable
encryption if either:
A length byte indicates that suboption data would extend beyond the
end of the TCP ENO option, orA length byte is followed by an octet in the range 0x00-0x9f
(meaning the following byte has v = 0 or glt < 0x20).Because the last suboption in an ENO option is special-cased to have
its length inferred from the 8-bit TCP option length, it MAY contain
more than 32 bytes of suboption data. Other suboptions are limited to
32 bytes by the length byte format. The TCP header itself can only
accommodate a maximum of 40 bytes of options, however. Hence,
regardless of the length byte format, a segment would not be able to
contain more than one suboption over 32 bytes in size. That said,
TEPs MAY define the use of multiple suboptions with the same TEP
identifier in the same SYN segment, providing another way to convey
over 32 bytes of suboption data even with length bytes.
A TEP identifier glt (with glt >= 0x20) is valid for a
connection when:
Each side has sent a suboption for glt in its SYN-form ENO option,Any suboption data in these glt suboptions is valid according to
the TEP specification and satisfies any runtime constraints, andIf an ENO option contains multiple suboptions with glt, then such
repetition is well-defined by the TEP specification.A passive opener (which is always host B) sees the remote host's SYN
segment before constructing its own SYN-ACK segment. Hence, a passive
opener SHOULD include only one TEP identifier in SYN-ACK segments and
SHOULD ensure this TEP identifier is valid. However, simultaneous
open or implementation considerations can prevent host B from offering
only one TEP.
To accommodate scenarios in which host B sends multiple TEP
identifiers in the SYN-ACK segment, the negotiated TEP is defined as
the last valid TEP identifier in host B's SYN-form ENO option. This
definition means host B specifies TEP suboptions in order of
increasing priority, while host A does not influence TEP priority.
A host employing TCP-ENO for a connection MUST include an ENO option
in every TCP segment sent until either encryption is disabled or the
host receives a non-SYN segment. In particular, this means an active
opener MUST include a non-SYN-form ENO option in the third segment of
a three-way handshake.
A host MUST disable encryption, refrain from sending any further ENO
options, and fall back to unencrypted TCP if any of the following
occurs:
Any segment it receives up to and including the first received ACK
segment does not contain a ENO option (or contains an ill-formed
SYN-form ENO option),The SYN segment it receives does not contain a valid TEP
identifier, orIt receives a SYN segment with an incompatible global suboption.
(Specifically, incompatible means the two hosts set the same b
value or the connection is in mandatory application-aware mode and
the remote host set a = 0.)Hosts MUST NOT alter SYN-form 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
unilaterally disable ENO (and thus remove the ENO option) between
retransmissions of a SYN-only segment. (Such removal could enable
recovery from middleboxes dropping segments with ENO options.)
Second, an active opener performing simultaneous open MAY include no
TCP-ENO option in its SYN-ACK if the received SYN caused it to disable
encryption according to the above rules (for instance because role
negotiation failed).
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 specification of the negotiated TEP and MUST NOT
present raw TCP payload data to the application. In particular, data
segments MUST NOT contain plaintext application data, but rather
ciphertext, key negotiation parameters, or other messages as
determined by the negotiated TEP.
A host MAY send a vacuous SYN-form ENO option containing zero TEP
identifier suboptions. If either host sends a vacuous ENO option, it
follows that there are no valid TEP identifiers for the connection and
hence the connection must fall back to unencrypted TCP. Hosts MAY
send vacuous ENO options to indicate that ENO is supported but
unavailable by configuration, or to probe network paths for robustness
to ENO options. However, a passive opener MUST NOT send a vacuous ENO
option in a SYN-ACK segment unless there was an ENO option in the SYN
segment it received. Moreover, a passive opener's SYN-form ENO option
MUST still include a global suboption with b = 1, as discussed in
.
TEPs MAY specify the use of data in SYN segments so as to reduce the
number of round trips required for connection setup. The meaning of
data in a SYN segment with an ENO option (a SYN+ENO segment) is
determined by the last TEP identifier in the ENO option, which we term
the segment's SYN TEP.
A host sending a SYN+ENO segment MUST NOT include data in the segment
unless the SYN TEP's specification defines the use of such data.
Furthermore, to avoid conflicting interpretations of SYN data, a
SYN+ENO segment MUST NOT include a non-empty TCP Fast Open (TFO) option
.
Because a host can send SYN data before knowing which if any TEP will
govern a connection, hosts implementing ENO are REQUIRED to discard
data from SYN+ENO segments when the SYN TEP does not govern the
connection or when there is any ambiguity over the meaning of the SYN
data. This requirement applies to hosts that implement ENO even when
ENO has been disabled by configuration. However, note that discarding
SYN data is already common practice and the new
requirement applies only to segments containing ENO options.
More specifically, a host that implements ENO MUST discard the data in
a received SYN+ENO segment if any of the following applies:
ENO fails and TEP-indicated encryption is disabled for the
connection,The received segment's SYN TEP is not the negotiated TEP,The negotiated TEP does not define the use of SYN data, orThe SYN segment contains a non-empty TFO option or any other TCP
option implying a conflicting definition of SYN data.A host discarding SYN data in compliance with the above requirement
MUST NOT acknowledge the sequence number of the discarded data, but
rather MUST acknowledge the other host's initial sequence number as if
the received SYN segment contained no data. Furthermore, after
discarding SYN data, such a host MUST NOT assume the SYN data will be
identically retransmitted, and MUST process data only from non-SYN
segments.
If a host sends a SYN+ENO segment with data and receives
acknowledgment for the data, but the SYN TEP governing the data is not
the negotiated TEP (either because a different TEP was negotiated or
because ENO failed to negotiate encryption), then the host MUST abort
the TCP connection. Proceeding in any other fashion risks
misinterpreted SYN data.
If a host sends a SYN-only SYN+ENO segment bearing data and
subsequently receives a SYN-ACK segment without an ENO option, that
host MUST abort the connection even if the SYN-ACK segment does not
acknowledge the SYN data. The issue is that unacknowledged data may
nonetheless have been cached by the receiver; later retransmissions
intended to supersede this unacknowledged data could fail to do so if
the receiver gives precedence to the cached original data.
Implementations MAY provide an API call for a non-default mode in
which unacknowledged SYN data does not cause a connection abort, but
applications MUST use this mode only when a higher-layer integrity
check would anyway terminate a garbled connection.
To avoid unexpected connection aborts, ENO implementations MUST
disable the use of data in SYN-only segments by default. Such data
MAY be enabled by an API command. In particular, implementations MAY
provide a per-connection mandatory encryption mode that automatically
aborts a connection if ENO fails, and MAY enable SYN data in this
mode.
To satisfy the requirement of the previous paragraph, all TEPs SHOULD
support a normal mode of operation that avoids data in SYN-only
segments. An exception is TEPs intended to be disabled by default.
To defend against attacks on encryption negotiation itself, a TEP MUST
with high probability fail to establish a working connection between
two ENO-compliant hosts when SYN-form ENO options have been altered in
transit. (Of course, in the absence of endpoint authentication, two
compliant hosts can each still be connected to a man-in-the-middle
attacker.) To detect SYN-form ENO option tampering, TEPs must
reference a transcript of TCP-ENO's negotiation.
TCP-ENO defines its negotiation transcript as a packed data structure
consisting of two TCP-ENO options exactly as they appeared in the TCP
header (including the TCP option kind and TCP option length byte as
illustrated in ). The transcript is constructed from the
following, in order:
The TCP-ENO option in host A's SYN segment, including the kind and
length bytes.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 as specified by TCP, the transcript unambiguously delimits A's
and B's ENO options.
TCP-ENO affords TEP specifications a large amount of design
flexibility. However, to abstract TEP differences away from
applications requires fitting them all into a coherent framework. As
such, any TEP claiming an ENO TEP identifier MUST satisfy the
following normative list of properties.
TEPs MUST protect TCP data streams with authenticated encryption.
(Note "authenticated encryption" designates the REQUIRED form
encryption algorithm ; it does not imply any actual
endpoint authentication.)TEPs 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 TEP.
describes the requirements of the session ID in more detail.TEPs MUST NOT permit the negotiation of any encryption algorithms
with significantly less than 128-bit security.TEPs 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.)TEPs MUST NOT depend on long-lived secrets for data confidentiality,
as implementations SHOULD provide forward secrecy some bounded,
short time after the close of a TCP connection. (Exceptions to
forward secrecy are permissible only at the implementation level,
and only in response to hardware or architectural constraints--e.g.,
storage that cannot be securely erased.)TEPs MUST protect and authenticate the end-of-file marker conveyed
by TCP's FIN flag. In particular, a receiver MUST with high
probability detect a FIN flag that was set or cleared in transit and
does not match the sender's intent. A TEP MAY discard a segment
with such a corrupted FIN bit, or may abort the connection in
response to such a segment. However, any such abort MUST raise an
error condition distinct from an authentic end-of-file condition.TEPs MUST prevent corrupted packets from causing urgent data to be
delivered when none has been sent. A TEP MAY do so by
cryptographically protecting the URG flag and urgent pointer
alongside ordinary payload data. Alternatively, a TEP MAY disable
urgent data functionality by clearing the URG flag on all received
segments and returning errors in response to sender-side urgent-data
API calls. Implementations SHOULD avoid negotiating TEPs that
disable urgent data by default. The exception is when applications
and protocols are known never to send urgent data.Each TEP MUST define a session ID that is computable by both endpoints
and uniquely identifies each encrypted TCP connection.
Implementations MUST expose the session ID to applications via an API
extension. The API extension MUST return an error when no session ID
is available because ENO has failed to negotiate encryption or because
no connection is yet established. Applications that are aware of
TCP-ENO SHOULD, when practical, authenticate the TCP endpoints by
incorporating the values of the session ID and TCP-ENO role (A or B)
into higher-layer authentication mechanisms.
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 violating the TEP specification, to
establish two TCP connections with the same session ID to remote hosts
properly implementing the TEP.
To prevent session IDs from being confused across TEPs, all session
IDs begin with the negotiated TEP identifier--that is, the last valid
TEP identifier in host B's SYN segment. Futhermore, this initial byte
has bit v set to the same value that accompanied the negotiated TEP
identifier in B's SYN segment. However, only this single byte is
included, not any suboption data. shows the resulting
format. This format is designed for TEPs 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. (An exception is for non-security-relevant purposes,
such as gathering statistics about negotiated TEPs.)
Though TEP specifications retain considerable flexibility in their
definitions of the session ID, all session IDs MUST meet the following
normative list of requirements:
The session ID MUST be at least 33 bytes (including the one-byte
suboption), though TEPs MAY choose longer session IDs.The session ID MUST depend in a collision-resistant way on all of
the following (meaning it is computationally infeasible to produce
collisions of the session ID derivation function unless all of the
following quantities are identical):
Fresh data contributed by both sides of the connection,Any public keys, public Diffie-Hellman parameters, or other
public asymmetric cryptographic parameters that are employed by
the TEP and have corresponding private data that is known by
only one side of the connection, andThe negotiation transcript specified in
.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.Applications MAY choose to make session IDs public. Therefore, TEPs
MUST NOT place any confidential data in the session ID (such as data
permitting the derivation of session keys).This subsection illustrates the TCP-ENO handshake with a few
non-normative examples.
shows a three-way handshake with a successful TCP-ENO
negotiation. Host A includes two ENO suboptions with TEP identifiers
X and Y. The two sides agree to follow the TEP identified by
suboption Y.
shows a failed TCP-ENO negotiation. The active
opener (A) indicates support for TEPs corresponding to suboptions X
and Y. Unfortunately, at this point one of several things occurs:
The passive opener (B) does not support TCP-ENO,B supports TCP-ENO, but supports neither of TEPs X and Y, and so
does not reply with an ENO option,B supports TCP-ENO, but has the connection configured in mandatory
application-aware mode and thus disables ENO because A's SYN
segment does not set the application-aware bit, orThe 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.
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 a non-SYN-form ENO option in
segment 3 when ACKing B's SYN. Had A not disabled encryption,
would have required it to include a non-SYN ENO
option in segment 3. The omission of this option informs B that
encryption negotiation has failed, after which the two hosts proceed
with unencrypted TCP.
shows a successful TCP-ENO negotiation with
simultaneous open. Here the first four segments contain a SYN-form
ENO option, as each side sends both a SYN-only and a SYN-ACK segment.
The ENO option in each host'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. The last valid TEP in
host B's ENO option is Y, so Y is the negotiated TEP.
TCP-ENO is designed to capitalize on future developments that could
alter trade-offs and change the best approach to TCP-level encryption
(beyond introducing new cipher suites). By way of example, we discuss
a few such possible developments.
Various proposals exist to increase the maximum space for options in
the TCP header. These proposals are highly experimental--particularly
those that apply to SYN segments. Hence, future TEPs are unlikely to
to benefit from extended SYN option space. In the unlikely event that
SYN option space is one day extended, however, future TEPs could
benefit by embedding key agreement messages directly in SYN segments.
Under such usage, the 32-byte limit on length bytes could prove
insufficient. This draft intentionally aborts TCP-ENO if a length
byte is followed by an octet in the range 0x00-0x9f. If necessary, a
future update to this document can define a format for larger
suboptions by assigning meaning to such currently undefined byte
sequences.
New revisions to socket interfaces could involve library
calls that simultaneously have access to hostname information and an
underlying TCP connection. Such an API enables the possibility of
authenticating servers transparently to the application, particularly
in conjunction with technologies such as DANE . An update
to TCP-ENO can adopt one of the z bits in the global suboption to
negotiate the use of an endpoint authentication protocol before any
application use of the TCP connection. Over time, the consequences of
failed or missing endpoint authentication can gradually be increased
from issuing log messages to aborting the connection if some as yet
unspecified DNS record indicates authentication is mandatory. Through
shared library updates, such endpoint authentication can potentially
be added transparently to legacy applications without recompilation.
TLS can currently only be added to legacy applications whose protocols
accommodate a STARTTLS command or equivalent. TCP-ENO, because it
provides out-of-band signaling, opens the possibility of future TLS
revisions being generically applicable to any TCP application.
This section describes some of the design rationale behind TCP-ENO.
Incremental deployment of TCP-ENO depends critically on failure cases
devolving to unencrypted TCP rather than causing the entire TCP
connection to fail.
Because a network path may drop ENO options in one direction only, a
host must know not just that the peer supports encryption, but that
the peer has received an ENO option. To this end, ENO disables
encryption unless it receives an ACK segment bearing an ENO option.
To stay robust in the face of dropped segments, hosts continue to
include non-SYN form ENO options in segments until such point as they
have received a non-SYN segment from the other side.
One particularly pernicious middlebox behavior found in the wild is
load balancers that echo unknown TCP options found in SYN segments
back to an active opener. The passive role bit b in global
suboptions ensures encryption will always be disabled under such
circumstances, as sending back a verbatim copy of an active opener's
SYN-form ENO option always causes role negotiation to fail.
TEPs can employ suboption data for session caching, cipher suite
negotiation, or other purposes. However, TCP currently limits total
option space consumed by all options to only 40 bytes, making it
impractical to have many suboptions with data. For this reason, ENO
optimizes the case of a single suboption with data by inferring the
length of the last suboption from the TCP option length. Doing so
saves one byte.
TCP-ENO, TEPs, and applications all have asymmetries that require an
unambiguous way to identify one of the two connection endpoints. As
an example, specifies that host A's ENO
option comes before host B's in the negotiation transcript. As
another example, an application might need to authenticate one end of
a TCP connection with a digital signature. To ensure the signed
message cannot not be interpreted out of context to authenticate the
other end, the signed message would need to include both the session
ID and the local role, A or B.
A normal TCP three-way handshake involves one active and one passive
opener. This asymmetry is captured by the default configuration of
the b bit in the global suboption. With simultaneous open, both
hosts are active openers, so TCP-ENO requires that one host explicitly
configure b = 1. An alternate design might automatically break the
symmetry to avoid this need for explicit configuration. However, all
such designs we considered either lacked robustness or consumed
precious bytes of SYN option space even in the absence of simultaneous
open. (One complicating factor is that TCP does not know it is
participating in a simultaneous open until after it has sent a SYN
segment. Moreover, with packet loss, one host might never learn it
has participated in a simultaneous open.)
This draft does not specify the use of ENO options beyond the first
few segments of a connection. Moreover, it does not specify the
content of ENO options in non-SYN segments, only their presence. As a
result, any use of option kind TBD after the SYN exchange does not
conflict with this document. Because, in addition, ENO guarantees at
most one negotiated TEP per connection, TEPs will not conflict with
one another or ENO if they use ENO's option kind for out-of-band
signaling in non-SYN segments.
This document has experimental status because TCP-ENO's viability
depends on middlebox behavior that can only be determined a
posteriori. Specifically, we must determine 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:
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.Middleboxes causing TCP-ENO connections to fail completely. This
can happen if middleboxes perform deep packet inspection and start
dropping segments that unexpectedly contain ciphertext, or if
middleboxes strip ENO options from non-SYN segments after allowing
them in SYN segments.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.
An obvious use case for TCP-ENO is opportunistic encryption--that is,
encrypting some connections, but only where supported and without any
kind of endpoint authentication. Opportunistic encryption protects
against undetectable large-scale eavesdropping. However, it does not
protect against detectable large-scale eavesdropping (for instance, if
ISPs terminate TCP connections and proxy them, or simply downgrade
connections to unencrypted). Moreover, opportunistic encryption
emphatically does not protect against targeted attacks that employ
trivial spoofing to redirect a specific high-value connection to a
man-in-the-middle attacker.
Achieving stronger security with TCP-ENO requires verifying session
IDs. Any application relying on ENO for communications security MUST
incorporate session IDs into its endpoint authentication. By way of
example, an authentication mechanism based on keyed digests (such as
Digest Access Authentication ) can be extended to include
the role and session ID in the input of the keyed digest.
Higher-layer protocols MAY use the application-aware a bit to
negotiate the inclusion of session IDs in authentication even when
there is no in-band way to carry out such a negotiation. Because
there is only one a bit, however, a protocol extension that
specifies use of the a bit will likely require a built-in versioning
or negotiation mechanism to accommodate crypto agility and future
updates.
Because TCP-ENO enables multiple different TEPs to coexist, security
could potentially be only as strong as the weakest available TEP. In
particular, if session IDs do not depend on the TCP-ENO transcript in
a strong way, an attacker can undetectably tamper with ENO options to
force negotiation of a deprecated and vulnerable TEP. To avoid such
problems, TEPs MUST compute session IDs using only well-studied and
conservative hash functions. That way, even if other parts of a TEP
are vulnerable, it is still intractable for an attacker to induce
identical session IDs at both ends after tampering with ENO contents
in SYN segments.
Implementations MUST NOT send ENO options unless they have access to
an adequate source of randomness . Without secret
unpredictable data at both ends of a connection, it is impossible for
TEPs to achieve confidentiality and forward secrecy. Because systems
typically have very little entropy on bootup, implementations might
need to disable TCP-ENO until after system initialization.
With a regular three-way handshake (meaning no simultaneous open), the
non-SYN form ENO option in an active opener's first ACK segment MAY
contain N > 0 bytes of TEP-specific data, as shown in .
Such data is not part of the TCP-ENO negotiation transcript, and hence
MUST be separately authenticated by the TEP.
[RFC-editor: please replace TBD in this section, in , and in with the assigned option kind number. Please also replace RFC-TBD with this document's final RFC number.]
This document defines a new TCP option kind for TCP-ENO, assigned a
value of TBD from the TCP option space. This value is defined as:
KindLengthMeaningReferenceTBDNEncryption Negotiation (TCP-ENO)[RFC-TBD]Early implementations of TCP-ENO and a predecessor TCP encryption
protocol made unauthorized use of TCP option kind 69.
[RFC-editor: please glue the following text to the previous paragraph iff TBD == 69, otherwise delete it.]
These earlier uses of option 69 are not compatible with TCP-ENO and
could disable encryption or suffer complete connection failure when
interoperating with TCP-ENO-compliant hosts. Hence, legacy use of
option 69 MUST be disabled on hosts that cannot be upgraded to
TCP-ENO.
[RFC-editor: please glue this to the previous paragraph regardless of the value of TBD.]
More recent implementations used experimental option 253 per
with 16-bit ExID 0x454E, and MUST migrate to option TBD.
requires at most one SYN-form ENO option per segment,
which means hosts MUST NOT not include both option TBD and option 253
with ExID 0x454E in the same TCP segment.
This document defines a 7-bit glt field in the range of 0x20-0x7f,
for which IANA is to create and maintain a new registry entitled "TCP
encryption protocol identifiers" under the "Transmission Control
Protocol (TCP) Parameters" registry. The initial contents of the TCP
encryption protocol identifier registry is shown in ,
reflecting that this document reserves one TEP identifier for
experimental use. Subsequent assignments are to be made under the
"RFC Required" policy detailed in , relying on early
allocation to facilitate testing before an RFC is
finalized.
ValueMeaningReference0x20Experimental Use[RFC-TBD]We are grateful for contributions, help, discussions, and feedback
from the TCPINC working group, including Marcelo Bagnulo, David Black,
Bob Briscoe, Jake Holland, Jana Iyengar, Tero Kivinen, Mirja
Kuhlewind, Yoav Nir, Christoph Paasch, Eric Rescorla, Kyle Rose,
Michael Scharf, and Joe Touch. This work was partially funded by
DARPA CRASH and the Stanford Secure Internet of Things Project.
Dan Boneh was a co-author of the draft that became this document.