Cryptographic protection of TCP Streams (tcpcrypt)
draft-ietf-tcpinc-tcpcrypt-06
1. Summary
Document Shepherd: Kyle Rose
Responsible AD: Mirja Kühlewind
This document specifies tcpcrypt, a TCP encryption protocol designed
for use in conjunction with the TCP Encryption Negotiation Option
(TCP-ENO) [I-D.ietf-tcpinc-tcpeno]. 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.
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.
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).
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 Yoav Nir and Jana Iyengar, with important
additional feedback from mailing list members of CFRG. No fundamental blocking
issues have been revealed through review. The chairs would like an additional
review by the Security Area Directorate.
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.
Tcpcrypt requires the addition of an IANA registry with expert review for
"tcpcrypt AEAD parameter", the initial values for which are listed in section
7: this is code point allocation for the AEAD algorithm used for bulk
encryption, symmetric authentication, and integrity protection. Expert
reviewers for this registry should understand the implications of individual
AEAD encryption modes and how they relate to the requirements of both TCP-ENO
and tcpcrypt.
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.