[tcpinc] Document Action: 'Cryptographic protection of TCP Streams (tcpcrypt)' to Experimental RFC (draft-ietf-tcpinc-tcpcrypt-15.txt)
The IESG <firstname.lastname@example.org> Tue, 08 January 2019 16:19 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09467130EBF; Tue, 8 Jan 2019 08:19:28 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
From: The IESG <email@example.com>
To: "IETF-Announce" <firstname.lastname@example.org>
Cc: The IESG <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Kyle Rose <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org
Content-Type: text/plain; charset="utf-8"
Date: Tue, 08 Jan 2019 08:19:28 -0800
Subject: [tcpinc] Document Action: 'Cryptographic protection of TCP Streams (tcpcrypt)' to Experimental RFC (draft-ietf-tcpinc-tcpcrypt-15.txt)
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jan 2019 16:19:28 -0000
The IESG has approved the following document: - 'Cryptographic protection of TCP Streams (tcpcrypt)' (draft-ietf-tcpinc-tcpcrypt-15.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.