On 2/08/2014 22:03 pm, Yoav Nir wrote: ... >> And how do any of this apply directly to tcpcrypt? You say there are >> deployability shortcomings, but do not enumerate any of them. >> >> Please be specific. > > Sure. Pretty much all corporate networks (and many home networks) have > firewalls. ...
It's pretty much a foregone conclusion that TCPInc will have to run the gauntlet of the middle boxen. Gotta break some eggs on this one. > This has two implications. First, any tcpinc solution has to be ready to be > dropped by a firewall. yup. > So either the API has to be ready to reconnect in clear-text, or the > application should be modified to retry in cleartext. There has been quite a > bit of controversy about this in the last week, because the second option > involves changing the application, which some believe is wrong. It's not wrong, it's just outside the problem space of this group. Out of scope. Deliberately, because the view post-Snowden is that the "modify application to use TLS" approach has more or less not worked out in practice, across large swathes of the net. If anyone's got good ideas here then fine, just not in this WG. So, TCPInc has to fall back to TCP if the firewall drops it. > Either way, an easy way to make the client re-try with cleartext is a > security vulnerability, especially if an attacker can drop a client to > cleartext with a single ICMP packet. Again, this is out of scope because we are only about passive attacks. Any active attack is fine, it is totally expected that an active attacker can cause a TCPInc to fall back or even be blocked. This is actually a good thing. If we can cause attackers to become active, then we can deal with it. What we can't deal with is passive attackers if we just sit here and wait for them to announce their attacks ... > The second implication is that we have a chicken-and-egg problem here. Any > firewall vendor... Yes. So, the one that wins will be the one that least offends the user. It will work most-ish enough to get deployment, it will be benign (TCP) when not working, and it will *ignore the cases of firewall knock-back* in exchange for deployment success elsewhere. It has to build up deployment before the vendors will act. For this reason, I personally would err to not doing anything about say RSTs, and only do data stream protection in v0. I'd love to get some active attacks happening... > A good story for fall-back really helps... Yes, but good experience trumps ;) tcpcrypt has an advantage here... iang _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
