[Tcpcrypt] New version of the charter text

[marcelo bagnulo braun <[e-mail]>]

Hi,

Thanks for the lively discussion on the charter text.
I attach a new version of the charter trying to include the received 
comments.
I have tried to be carefull using the should and the must, so please 
look into those.
I tried to reflect the different levels of requirements for the 
resulting protocol.
As usual comments are welcome.



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 the
TCP extensions to perform an unauthenticated key exchange resulting in 
encryption
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.  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 working group is looking to produce experimental documents 
specifying the
required TCP extensions and any additional informational documents needed.

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

- Deployable and usable without significant changes to existing Internet
   infrastructure, 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).

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

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

- When encryption is enabled, it must always provide forward secrecy.

- When encryption is enabled, it 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)

- When encryption is enabled, it must always provide payload encryption.

- Should attempt to use the least amount of TCP option space.

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

- Hooks for allowing upper layers to disable encryption must be made 
available.
   The protocol may try to avoid redundant encryption when it is 
possible e.g.
   by detecting encryption performed by upper layers (notably, when TLS 
is used).

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

- Client fingerprinting: some clients may want to avoid appearing as the 
same
   client when connecting to a remote peer on subsequent occasions.  
This should either
   be the default (clients cannot be "fingerprinted" by the server based 
on shared state)
   or some mechanism should be available for clients to drop or ignore 
shared state to avoid
   being fingerprintable.

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.

- Extensions to current TCP to support unauthenticated key exchange and 
encryption and
integrity protection. This covers all the protocol changes required. 
This will be a
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 and the hooks for disabling encryption.
This will be an informational document.