On Aug 2, 2014, at 11:43 PM, John-Mark Gurney <[email protected]> wrote:
> Yoav Nir wrote this message on Sat, Aug 02, 2014 at 23:09 +0300: >> The charter calls for the group to ?develop the TCP extensions to provide >> unauthenticated encryption and integrity protection of TCP streams? and >> ?define an unauthenticated key exchange mechanism." This pretty much calls >> for design by committee. >> >> As for shortcomings of tcpcrypt, there are two varieties to these >> shortcomings: >> >> Security shortcomings - here I wholeheartedly agree that security mechanisms >> are best developed by one or a few of the right people, with everybody else >> just examining and looking for issues. That?s why in CFRG we?re not >> designing curves be committee, but arguing the pros and cons of several >> proposed curves. Similarly here, all proposals have their own key exchange >> and crypto mechanisms, and the discussions of the group are not designing >> them, merely comparing them. > > So, what specificly are the security shortcomings of tcpcrypt? You then > go off to talk about CFRG designing curves which is unrelated to the > topic at hand… I’m sorry if what I wrote seems to imply that I know of any short-comings in tcpcrypt. I don’t. I used CFRG as an example of not doing design-by-committee for security mechanisms. And tcpinc is also not doing so. >> Deployability shortcomings - this is where claims are made in the vein of >> ?your proposal works well in the lab, but it won?t work in this or that >> scenario in the real world.?, or ?when blocked, your proposal does not fall >> back gracefully to unencrypted?. Unfortunately the Internet is full of boxes >> that don?t behave the way we expect them, and you do need a committee to >> consider all of the ways a connection might be broken because of deploying >> the proposed mechanism. The obvious ones are NAT devices and firewalls, but >> mandatory proxies are not far behind in the amount of trouble they cause. >> You can see a lot of that in httpbis, and some of that in TLS?s 1.3 >> discussion. It?s not very pretty, but it turns out to be necessary to get >> something widely deployed. > > 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. They typical design philosophy for traditional firewalls is that they know what Internet traffic looks like, and anything that doesn’t look like typical Internet traffic is dropped or rejected. For some firewalls, the existence of unrecognized TCP options may be enough to flag a connection as “not typical Internet”. The response may be to drop the traffic, or else to strip the option. Other firewalls may ignore the TCP option, but then notice that the TCP stream does not look like the protocol that the firewall was expecting on that port. That’s reason enough to drop and reject the TCP stream. This has two implications. First, any tcpinc solution has to be ready to be dropped by a firewall. 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. 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. The second implication is that we have a chicken-and-egg problem here. Any firewall vendor has a bunch of things they want to do with their product. If tcpcrypt (or any other solution) begins being deployed, support for tcpcrypt would be on that list. But it won’t get a high priority unless there’s a significant portion of the traffic on the Internet that uses it. OTOH it doesn’t make sense for applications and OS-es to deploy tcpcrypt as long as it doesn’t work in a significant part of the Internet. A good story for fall-back really helps, because it allows the use of tcpcrypt (or whatever solution) to proliferate even in the presence of firewalls that strip tcpcrypt. That proliferation (plus the bad press such firewalls will get for stripping a security mechanism) will convince firewall vendors to support the mechanism. But first we need a good fall-back story. Yoav _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
