Re: [Tcpcrypt] New version of the charter text

[Wesley Eddy <[e-mail]>]

On 4/24/2014 1:43 AM, Joe Touch wrote:
> 
> 
> 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)


This was the one I thought of too, but wasn't sure if there might
be some IKE extensions possible to get a similar effect that might
be lower-impact (like done in user-space, and maybe valuable for other
flows than just TCP).


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


This part is interesting and I hadn't thought of it; thanks.


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


Yeah, and I hesitated to suggest that too, because it winds up looking
like an RTCWEB towering Jenga stack of protocols.


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


Yes, I know AO just a little since I was co-chair of the working group
for it :).

At the time AO was done, some of the criticisms of IPsec were captured
in:
http://tools.ietf.org/html/draft-bellovin-tcpsec-01

I could summarize those as:
- no good API for protecting an individual TCP connection
- NAT traversal issues
- masking fields used for QoS or TE

I don't think "TCP in IPsec in UDP" was considered at the time.


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


Nor am I, but adding it (if needed) would *seem to me* simpler than
the equivalent TCP modifications, plus be deployable and upgradeable
in userland.  I'm sure there are dozens of people who know better
though.


-- 
Wes Eddy
MTI Systems