Re: [Tcpcrypt] New version of the charter text

[Joe Touch <[e-mail]>]

On 4/23/2014 9:21 PM, Wesley Eddy wrote:
> 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.
...
> 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?

I'll take a shot, because the reasons are very similar to the reason 
TCP-AO is needed vs. IPsec or TLS

- can easily use per-connection keys, unlike IPsec
	IPsec keys would be costly to setup per-connection (e.g.,
	IKE per connection), and would require pinning both
	source and dest ports; TCP has more state
	that can make deriving per-connection keys from
	IPsec-like aggregate keys feasible and more efficient
	(e.g., as was done in TCP-AO)

- can allow key rollover without TCP impact, unlike IPsec
	IPsec key rollover would result in losses that would
	impact TCP's congestion control. TCP-AO show show
	key rollover can be supported without impacting
	TCP, and even using TCP itself to coordinate the
	key rollover

I haven't considered the impact of running TCP over DTLS and whether it 
could support the above. The overhead would certainly be higher, but 
that alone might not be worth creating a new solution.

However, at a minimum, a TCP-based solution might at least traverse 
stateful firewalls in ways that a UDP-based layering might not.

> I know it's more fun to do it inside TCP, of course, but I wonder a
> little bit whether building a security sub-layer inside TCP (which
> is already hella complex and full of edge cases) is really a good
> idea when there are already a couple of reasonably decent security
> protocols designed to be layered over.

See TCP-AO. It wasn't sufficient to layer that over IPsec. We didn't 
consider a DTLS-based approach at the time because TCP-AO predates DTLS. 
But see above for reasons a TCP solution might still be useful.

I'm also not aware as to whether DTLS has an unauthenticated 
(BTNS-style) mode.

> Sorry for such a silly question, but it seems like it will come up
> during chartering and should be clearly motivated, as reading the
> requirements later on in the draft charter, it looks like you could
> cook up something with BTNS or DTLS under normal TCP to do all that,
> and it would protect the SYNs (which Joe mentioned is a challenge
> for TCP-based approaches).
>
> I think the charter should speak to this, at least very briefly.

I agree.

Joe