Re: [Tcpcrypt] New version of the charter text

[Joe Touch <[e-mail]>]

Hi, all,

Comments below...

Joe


On 4/23/2014 12:02 AM, marcelo bagnulo braun wrote:
...
> TCP Increased Security (TCP Inc.)

I like the title, FWIW.

> The TCP Inc. WG will develop the TCP extensions to provide unauthenticated
> encryption and integrity protection of TCP streams.

OK so far...

 > The WG will define the
> TCP extensions to perform an unauthenticated key exchange resulting in
> encryption
> without authentication.

This implies in-band. I don't think in-band key exchange is viable; 
there's no way to protect the SYNs, and it might sufficiently increase 
SYN processing and server state to make a much larger attack surface.

I would optimally prefer out-of-band exchange, perhaps that could be 
bootstrapped with an initial in-band exchange. Less optimal would be to 
leave this issue open for the WG to discuss, but I definitely don't 
agree with mandating only in-band key exchange.

I would thus prefer:

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

It also leverages the original principle of BTNS, FWIW.

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

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

When TLS is used, this defeats TCP-INC's ability to protect the TCP header.

It's OK to allow hooks to turn this off, but a better use case should be 
provided as motivation.

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

This should also include "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.
>
> - 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.
>
> _______________________________________________
> Tcpcrypt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpcrypt