On Sat, Aug 2, 2014 at 2:03 PM, Yoav Nir <[email protected]> wrote: > > 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.
You don't think tcp encryption is a security mechanism? Or have you forgotten all the screwups caused by design by committee from PKIX complexity, to DNSSEC, to the F-35 Lighting. > 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. Do you have hard numbers on this one? I'm sure its a problem, but I don't know how big of one it is. > > 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. Why can't the boxes "protected" by these products not negotiate the option? > > 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. Well, you won't have one if an attacker can drop a client to cleartext with a single ICMP packet. However, it might be okay to deploy with that problem to get it fixed, and then later fix it. Blegh. Can we write a middlebox elimination RFC or BCP sometime? Sincerely, Watson Ladd > > Yoav > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
