TCP-ENO: Encryption Negotiation Option
draft-ietf-tcpinc-tcpeno-08
1. Summary
Document Shepherd: David Black
Responsible AD: Mirja Kuehlewind
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.
The WG has requested Experimental status because this draft specifies a new
protocol for which implementation and usage experience is desired before
producing a proposed standard.
2. Review and Consensus
In response to concerns about pervasive surveillance, the tcpinc WG was formed
in 2014 to produce a TCP extension that provides unauthenticated
(opportunistic) encryption of TCP streams. The goal is universal encryption of
TCP streams, increasing the burden of pervasive surveillance from passive
dragnet attacks to per-connection active (e.g., man-in-the-middle) attacks.
An inability to achieve consensus on a single approach best characterizes the
first year and a half of the WG's existence. There were two competing
proposals, the Stanford-led tcpcrypt and a profile of TLS with authentication
removed (tcpinc-use-TLS). As both tcpcrypt and TLS are independent and
fully-realized protocols, this mooted any collaboration or compromise. This
inability to achieve consensus damaged the WG, as parties looking for a
solution in this space grew weary of the lack of progress. Many who initially
expressed interest in working on independent implementations lost interest and
moved on to other work. Some progress was made during this time, notably the WG
decided to provide length information for all data sent (rather than relying on
packet length) to protect against resegmentation in the network.
The logjam was successfully broken by three WG actions in the second half of
2015. The first was that the TCP extension functionality of tcpcrypt was split
off into a separate proposal called TCP-ENO (Encryption Negotiation Option).
This extension notably has the ability to negotiate multiple TCP stream
encryption protocols, allowing potentially for runtime negotiation of either
tcpcrypt or tcpinc-use-TLS (or indeed any other future encryption protocol).
This draft contains the resulting TCP-ENO specification.
The second action was initiated by the chairs. After the Transport AD changed
the WG chairs in July 2015, the new chairs made a call for adoption of both
tcpcrypt and tcpinc-use-TLS. ENO enabled this action by making it credible that
both protocols could be concurrently deployed.
The logjam was finally broken by competing demands for the TLS community,
including for the editor of the tcpinc-use-TLS draft, especially for completion
of TLS 1.3 work in early 2016. This was discussed in the tcpinc WG, and the
resulting rough consensus of the WG was that the appropriate course of action
was to complete work on tcpcrypt and TCP-ENO as soon as possible, making sure
that ENO could eventually support a TLS profile.
Following this decision, rough consensus was achieved fairly rapidly, with only
minor tweaks to the protocol since March 2016. Mailing list traffic has been
very quiet since September 2016, and no tcpinc session was held at IETF 98 in
Chicago.
Expert reviews were conducted by Jake Holland and Wes Eddy, with important
additional feedback from transport experts who are members of the tcpinc WG. No
fundamental blocking issues have been revealed through review. The chairs would
like an additional review by the Security Area Directorate in conjunction with
the tcpcrypt draft.
There is only one current implementation of tcpcrypt, that being the reference
implementation by the Stanford team. At least one other implementation effort
is in progress. The WG chairs believe that a reliable implementation
distributed as part of a major operating system is the best approach to
rekindling interest in this project and for encouraging the development of
additional interoperating implementations.
3. Intellectual Property
Each draft author has stated his/her direct, personal knowledge that any IPR
related to this document has already been disclosed, in conformance with BCPs
78 and 79.
4. Other Points
The original implementation of tcpcrypt squatted on TCP option kind 69, which
caused some controversy and animated discussion on the mailing list. After some
negotiation with Joe Touch, it was decided that tcpcrypt would be willing to
bear the cost of this decision by requesting the same option for assignment by
IANA. This draft anticipates the assignment of TCP option kind 69 to TCP-ENO.
Tcpcrypt requires the addition of an IANA registry with expert review for
"TCP-ENO Protocol Identifiers", the initial values for which are listed in
section 10: this is code point allocation for the encryption protocols
negotiated by TCP-ENO. In the case of tcpcrypt, this negotiation also includes
the algorithm for initial exchange of ephemeral keys. Expert reviewers for this
registry should be able to analyze a proposed key exchange algorithm for
compatibility with the cryptographic requirements of tcpcrypt, and be generally
familiar with security protocol design when reviewing applications for values
to be assigned for TEPs other than tcpcrypt. A common reviewer is suggested for
this registry and the "tcpcrypt AEAD parameter" registry created by the
tcpcrypt draft, as tcpcrypt cryptographic parameter and algorithm changes
impact both registries.
Minimum criteria for a move from Experimental to Proposed Standard status
should include substantive deployment experience spanning multiple
implementations and networks and a BCP document describing deployment
challenges and mitigations, especially with respect to successfully transiting
middle boxes.