The IESG has approved the following document: - 'TCP-ENO: Encryption Negotiation Option' (draft-ietf-tcpinc-tcpeno-19.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-tcpeno/ Technical Summary 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. 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. As a consequence the working group decided to split the TCP extension functionality of tcpcrypt 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). There is strong concensus in the group for this step. Document Quality There is only one current implementation of tcpeno (together with tcpcrypt), 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 David Black. The responsible AD is Mirja Kühlewind. RFC Editor Note In Section 4.2 at the end of the paragraph that specifies the ‘b’ bit in Figure 5, please add the following sentence: "See Section 8.3 for further discussion." In Section 4.2 at the end of the paragraph that specifies the ‘a’ bit in Figure 5, please add the following sentence: "See Section 8.4 for further discussion."
