On Aug 3, 2014, at 12:33 AM, Watson Ladd <[email protected]> wrote:
> 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. TCP encryption is a goal. There are several mechanisms proposed for doing that. >> 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. No hard numbers, but the company I work for (Check Point) is one of the big enterprise firewall vendors, and looking at the code right now (I usually work on VPN, not firewall), we ignore unrecognized TCP Options. So what does that mean for a scheme based on TCP options? The first SYN / SYN-ACK go through fine despite their having TCP options. Then, depending on scheme, you either have a TLS ClientHello, or TCPCrypt’s INIT message. Either way, if the firewall looks into the protocol more deeply then just ports, the content will make no sense and the connection will be reset. This will affect protocols that are inspected, including HTTP, FTP, SMTP, and some others. >> 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? 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. >> 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? The standard operating procedure for the IETF in such cases is to ignore their existence. We know that network administrators like these firewalls so much that they install them on pretty much all networks, and even internal networks get IDS/IDP systems that do much of the same. If you want to write such a draft, the title should be “firewalls considered harmful”, similar to address translation [1], TCP Extensions [2], non-routable IP addresses [3], IP addresses [4], and .sex [5]. Yoav [1] draft-vogt-address-translation-harmfulness [2] RFC 1263 [3] RFC 1627 [4] RFC 4085 [5] RFC 3675
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
