Re: [Tcpcrypt] New version of the charter text

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

Sorry, didnt finish the previous email.
I am fine with all the other comments. Will add them in the next version.

El 23/04/14 18:54, Joe Touch escribió:
> 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
>
> _______________________________________________
> Tcpcrypt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpcrypt
>