Cryptographic protection of TCP Streams (tcpcrypt)
draft-ietf-tcpinc-tcpcrypt-11

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, tcpinc@ietf.org, krose@krose.org, tcpinc-chairs@ietf.org, ietf@kuehlewind.net, Kyle Rose <krose@krose.org>, draft-ietf-tcpinc-tcpcrypt@ietf.org, rfc-editor@rfc-editor.org
Subject: Document Action: 'Cryptographic protection of TCP Streams (tcpcrypt)' to Experimental RFC (draft-ietf-tcpinc-tcpcrypt-07.txt)

The IESG has approved the following document:
- 'Cryptographic protection of TCP Streams (tcpcrypt)'
  (draft-ietf-tcpinc-tcpcrypt-07.txt) as Experimental RFC

This document is the product of the TCP Increased Security Working Group.

The IESG contact persons are Mirja K├╝hlewind and Spencer Dawkins.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/


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.