Re: [Tcpcrypt] New version of the charter text

[Wesley Eddy <[e-mail]>]

On 4/24/2014 11:55 AM, John-Mark Gurney wrote:
> Wesley Eddy wrote this message on Thu, Apr 24, 2014 at 00:21 -0400:
>> On 4/23/2014 3:02 AM, marcelo bagnulo braun wrote:
>>> 
>>> 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).
>> 
>> 
>> I'm probably just very bad at locating this in all the discussion,
>> but I have a sort of fundamental question ... why are we trying to
>> do this inside TCP rather than just running TCP over IPsec w/ BTNS
>> (over UDP, if NAT is the concern), or over DTLS?
> 
> Have you read the original tcpcrypt paper?


Yes (assuming you mean USENIX 2010).


>> 
>> I think the charter should speak to this, at least very briefly.
> 
> It does very briefly: - The protocol must be usable by unmodified
> applications.
> 
> All the things you mentioned seems like it would require agreement 
> between systems and management by a sysadmin, but this is targeted
> to end users system (like smart phones) too...  If TCP is the only 
> protocol allowed through a firewall, how are any of your other
> solutions going to work?


Automation only requires a little imagination, so I guess while I know
the claims about configuration and management are based on some reality,
I don't find them very compelling.

TCP being the only way through a particular firewall does indeed sound
like a good scenario to motivate this work over other options though.
Thanks for that example.

Personally, I think applicability for MPTCP and TFO is another good
motivation, and might even find those as more compelling than the
the data encryption functionality.  Marcelo's draft already nicely
mentions those, and I'm fine with what he has written there.  Using
some odd layering of DTLS or IPsec+UDP would seem less easy to apply to
the MPTCP and TFO problems than a tcpcrypt-like approach.


-- 
Wes Eddy
MTI Systems