"Eggert, Lars" <[email protected]> writes:
> Finally, there are systems where a relatively small and contained
> patch to the TCP stack (e.g., something like tcpcrypt) is easier to
> implement, test and deploy than an approach that introduces
> dependencies on a TLS library (no matter how profiled down it may be
> in the future). Additional complexities may arise if that library does
> not already support being run in kernel context and/or has a license
> that makes such usage problematic, esp. for commercial products.
>
> (I fully understand that the final paragraph here is irrelevant from
> an IETF standards perspective, but it is important for someone who'd
> actually like to ship and deploy things.)
There are reasons why this is relevant from an IETF standards point of
view. Because TLS, despite the name, is not really at the same layer as
TCP, it will be difficult to use in conjunction with other layer-4
standards such as TCP minion, fast open, and multipath, while there are
more or less straight-forward ways to extend tcpcrypt and other
TCP-layer standards to benefit each other.
Other points that could make a TLS solution harder to implement/deploy
than a purer TCP-layer solution:
- TLS may require resegmenting the TCP stream, making it harder to
implement at the "middlebox" layer without essentially terminating
the TCP stream and adding buffering, etc. This is mitigated by the
fact that a lot of TLS termination middleboxes already exist and
would be easy to tweak for TCP-use-TLS. On the other hand, if you
wanted to add it to NAT boxes and the like it would increase code
and data size.
- TCP has evolved into more than just a wire format to a whole API.
It's unclear whether or how many aspects of this API will translate
down to TLS. The prevailing sentiment seems to be that it's okay to
break urgent data. But what about SO_SNDBUF/SO_RCVBUF? What about
keeping Nagle by *not* setting TCP_NODELAY? Maybe these are
considered fringe options (though in my own development, I regularly
make use of small SO_SNDBUF/SO_RCVBUF sizes to test robustness of my
code against short reads/writes). But to maximize adoption it would
be better for tcpinc to work in as many fringe cases as possible.
- There are cases in which performance, particularly connection
latency, may be a limiting factor on deploying TLS. (Witness
various efforts to reduce connection latency.) So integrating with
the TCP handshake is going to reduce latency to the point that it
may make tcpinc appealing where TLS is not. E.g., tcpcrypt adds 1/2
round trip for uncached connections, 0 for cached.
So if tcpinc's goal is do drive adoption specifically in places where
TLS adoption has lagged for whatever reason (while of course continuing
to promote TLS adoption wherever possible), there is definitely an
argument to be made for diversity of approaches.
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
