TCP-ENO: Encryption Negotiation Option

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: IETF-Announce <>
Cc: The IESG <>,,,,,, David Black <>,
Subject: Document Action: 'TCP-ENO: Encryption Negotiation Option' to Experimental RFC (draft-ietf-tcpinc-tcpeno-19.txt)

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:

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.


   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."