Technical Summary
This document specifies tcpcrypt, a TCP encryption protocol designed
for use in conjunction with the TCP Encryption Negotiation Option
(TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating
resegmentation, NATs, and other manipulations of the TCP header.
The protocol is self-contained and specifically tailored to TCP
implementations, which often reside in kernels or other environments
in which large external software dependencies can be undesirable.
Because the size of TCP options is limited, the protocol requires one
additional one-way message latency to perform key exchange before
application data may be transmitted. However, this cost can be avoided
between two hosts that have recently established a previous tcpcrypt
connection.
Working Group Summary
Initially in the wg, there were two competing proposals, the Stanford-led
tcpcrypt and a profile of TLS with authentication removed (tcpinc-use-TLS).
As both tcpcrypt and tcpinc-use-TLS are independent and fully-realized
protocols, this led to an inability to achieve consensus. After the split off
of tcp-eno, an extension notably 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),
the working group 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. However, due to 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, the tcpinc-use-TLS
scheme was not further maintain (at least up to now). 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.
Document Quality
There is only one current implementation of tcpcrypt (together with tcpeno),
that being the reference implementation by the Stanford team. At least one
other implementation effort is in progress. The 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. The
WG chairs believe that a reliable implementation distributed as part of a major
operating system based on this experimental documen is the best approach to
rekindling interest in this project and for encouraging the development of
additional interoperating implementations.
Personnel
The document shepherd is Kyle Rose.
The responsible AD is Mirja Kühlewind.
IESG Note
Based on comments received during IETF last cast, the latest version of this
document (-08) now recommends a different AEAD algorithm as MIT. There
is still some on-going discussion with the SEC ADs if only one MIT is acceptable.
There is consensus in the working group to move forward with only one but
they are also open for other recommendations as feedback from the IESG evaluation.