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