Yoav Nir <[email protected]> writes:
> These boxes are typical client OS: Windows, Mac OS, iOS, Android. What
> options they try to negotiate are the same when they’re in the
> corporate network and when they’re at home or on the road. The only
> way they can work everywhere is to try tcpcrypt and if the connection
> fails or gets reset early to try again without tcpcrypt. That both
> adds latency and opens the door to a tcpcrypt-stripping attack.
But just to clarify, the latency is effectively added to the DHCP lease
acquisition time (or equivalent), which doesn't happen that often and
typically takes several seconds anyway. Once a machine is determined to
be behind a DPI box, tcpinc has to be disabled.
While this obviously isn't great, the best way for tcpinc to have impact
is with maximum backwards compatibility over several phases of
deployment. In particular, the best-case scenario for tcpinc might look
something like this:
1. People start running tcpinc-enabled TCP stacks, and it kicks in
where there are no middleboxes, but gets disabled in a lot of
places because of option stripping and DPI.
2. Deployment reaches a point where firewall vendors decide to add an
"allow tcpinc" option.
3. Applications start making use of SessionIDs/channel binding when
tcpinc is available. For backwards compatibility, session
authentication may be negotiated through an out-of-band mechanism
like tcpcrypt's application-aware bit.
4. A standard emerges for authenticating session IDs with DANE.
Possibly some DNSSEC extension can announce the server is
tcpinc-aware and has a tcpinc-clean path to the network core, so
clients with tcpinc-clean paths should expect to use tcpcrypt. A
high degree of source-code compatibility is achieved, particularly
for languages that connect to hosts by name. Some RFC3493
extension also makes DANE very easy to use in C.
5. Tcpinc use becomes so ubiquitous that only weird old insecure
devices don't have it. Firewall vendors add a "require tcpinc"
option...
David
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
