Hi,

I have just submitted the attached draft to the IESG for consideration.

Thank you all very much for the useful discussions.

Hope to start soon the more technical discussions.

TCP Increased Security (TCP Inc.)

The TCP Inc. WG will develop the TCP extensions to provide unauthenticated
encryption and integrity protection of TCP streams. The WG will define an
unauthenticated key exchange mechanism. In addition, the WG will define the
TCP extensions to utilize unauthenticated keys, resulting in encryption and
integrity protection without authentication. This is better than plain-text
because it thwarts passive eavesdropping, but is weaker than using
authenticated keys, because it is vulnerable to man-in-the-middle attacks
during the initial unathenticated key exchange. This work is part of the 
IETF
effort to harness the Internet architecture given the latest events of
pervasive monitoring (see draft-farrell-perpass-attack).

The goal of this WG is to provide an additional security tool that 
complements
existing protocols at other layers in the stack. The WG will be looking 
for the
designs that find the right tradeoff spot between conflicting 
requirements: to
provide reasonable security for the majority of connections. Because we are
dealing with unprotected connections, we are more focussed on improving 
from
baseline of no security than achieving the high standard of security 
that is
already available to users of TLS. Providing unauthenticated
encryption and integrity protection at the TCP layer will provide a set of
features that cannot be achieved with existing tools, namely, encryption 
and
integrity protection without modifications to the upper ayers (no API 
changes),
encryption and integrity protection with forward secrecy with a 
per-connection
granularity, simple NAT and firewall traversal capabilities, key 
rollover without
significant impact to the TCP connection, lower overhead compared to 
solutions
relying in stacking multiple protocols to achieve different features, no 
manual
configuration required. A more detailed description of the motivations for
TCP-based solutions can be found in draft-bellovin-tcpsec-01 and in RFC5925.

The working group is looking to produce experimental documents 
specifying the
required TCP extensions and any additional documents needed.

The high-level requirements for the protocol for providing TCP 
unauthenticated
encryption and integrity protection are:

- It should work over the vast majority of paths that unmodified TCP 
works over,
   in particular it must be compatible with NATs (at the very minimum 
with the NATs
   that comply with BEHAVE requirements as documented in RFC4787, 
RFC5382 and RFC5508);

- The protocol must be usable by unmodified applications.  This effort is
   complementary to other security protocols developed in the IETF (such 
as TLS) as
   it protects those applications and protocols that are difficult to 
change or may
   even not be changed in a backward compatible way.  It also provides 
some protection
   in scenarios where people are unwilling to do any change just for the 
sake of
   security (e.g., like configure encryption in an application).

- The protocol must provide cryptographic algorithm agility.

- Must gracefully fall-back to TCP if the remote peer does not support the
   proposed extensions

- When encryption is enabled, it must at least provide protection against
   passive eavesdropping by default,

- Should attempt to use the least amount of TCP option space, especially 
in SYN
   segments.

- Must not require any authentication or configuration from
   applications or users.  However, hooks for external authentication 
must be
   made available.  The WG will not work on new authentication mechanisms.

- The protocol must have acceptable performance, including acceptable 
latency and
   processing overheads.  For example, the protocol may try to re-use 
existing
   cryptographic material for future communication between the same 
endpoints to avoid
   expensive public key operations on connection set up.

When encryption is enabled, then the protocol:

- must always provide forward secrecy.

- must always provide integrity protection of the payload data (it is 
open for
   discussion for the WG if the TCP header should or not be protected)

- must always provide payload encryption.

- must not provide extra linkability. When encryption is enabled the TCP 
traffic should
   not give a third party observer any extra way to associate those 
packets with the
   specific peers beyond information that would have been present in a 
cleartext session.

- must allow the initiator of the connection to avoid fingerprinting: 
some initiators
   may want to avoid appearing as the same endpoint when connecting to a 
remote peer on
   subsequent occasions. This should either be the default or some 
mechanism should be
   available for initiators to drop or ignore shared state to avoid 
being fingerprintable
   any more than would be present for a cleartext session.

Security features at the TCP-level can benefit other TCP extensions.  For
example, both Multipath TCP and TCP Fast Open require proof that some 
connections are
related.  Session resumption and Message Authentication Codes (MACs) can 
provide
this evidence.  The working group should identify synergies and design the
security protocol in such a way that other TCP efforts can benefit from 
it.  Of
course, TCP extensions that break must be identified too, and kept to a 
minimum.

The working group will produce the following documents:

- A framework for unauthenticated encryption and integrity protection of 
TCP connections.
This document will describe basic design considerations, including the 
motivation and the
applicability of the proposed mechanism, the interaction with other 
security mechanisms in
different layers of the stack, the interaction with external 
authentication mechanisms, the
expected protection, privacy considerations and residual threats.

- Definition of the unauthenticated key exchange mechanism and the 
extensions to current TCP
to utilize unauthenticated key to provide encryption and integrity 
protection. This covers
all the protocol changes required. This will be an experimental document.

- An extended API describing how applications can obtain further 
benefits of the
proposed extensions. In particular, the hooks for supporting external 
authentication
will be defined in this document. This will be an informational document.