zooko wrote: > On Aug 19, 2008, at 16:08 PM, David Barrett wrote: > > > One of the requirements from the start was that it was not allowed to > add even one round trip more than an unencrypted TCP connection. > Adam Langley has evidence that this is a necessary requirement for > the target use case, but unfortunately much of the data is > proprietary. The target use case is "all TCP connections routinely > encrypted". > > My intuition agrees with Adam's: zero-added-round-trips, backwards- > compatible, ubiquitous encryption of TCP would be a huge win.
Wow, interesting. This is my third time starting this email, and each time has been with a different response. First I was like "hell ya, this is awesome!" then I'm like "Wait, why not just use SSL?" but now I realize the goal is to have something a user can install on his OS that transparently makes all applications secure. After all, the application layer already has the ability to use SSL if it wants; this is a way to force encryption on applications that aren't otherwise coded to do so. I guess my first question would be if this is a useful goal. The reason webservers don't all use SSL all the time is because it's expensive. It's *got* to be expensive to be secure; if it weren't expensive to do, then it would be easy to brute force. So the cost issue of encryption will remain a bottleneck forever, even with rising CPU speeds. Furthermore, in the case of web servers where the accumulation of small per-connection CPU costs matters more than in client-side applications, the decision whether to encrypt still rests with the web admin -- even if every visitor to your website supports ObfTCP, if the admin disables it, it's gone. So both sides must want to support it for it to work, and that capability is already there -- just use HTTPS for everything and bam, secure. Said another way, if the goal is to enable admins to secure their sites, that capability already exists and is in use. If a website isn't encrypted it's by choice of the web admin -- a choice ObsTCP doesn't override. Regardless, web traffic probably isn't what the author had in mind. Thus I can see the benefit of giving a passive degree of defense against broad snooping. It forces unencrypted protocols to become encrypted if both sides want. But even here I don't see why a new protocol needs creating. SSL is bloated, but it does the trick. SSH is even better. I agree it sucks to wait until the TCP connection has already finished establishing before starting key negotiation, so why not just insert the first SSL packet in with the SYN, the first SSL response in with the SYN-ACK, and so on? This way you get the benefit of a proven stack while also cutting down on connection setup time. The ITEF would still probably puke on including data in the SYN/SYN-ACK, but at least you'd win over the SSL fans. Basically, I can see no reason to create a new encrypted protocol standard when SSL and SSH are entirely adequate (if not ideal), and connection setup time could be cut by inserting data into SYN/SYN-ACK/ACK. And if data can't be included in the SYN/SYN-ACK/ACK, then all you really need to do is insert a capability bit into the SYN and everything else can be handled after TCP setup. I'm imagining a Hamachi-like VPN layer: rather than having apps open directly over your real interface, open over this virtual interface. It injects the "let's encrypt" bit into the SYN packet, and if the other side is also running this same thing, the layer establishes a SSL connection. It could even use setsockopt() and getsockopt() so ObsTCP-aware apps can make decisions appropriately. So, anyway, long winded thought. ObsTCP looks pretty cool, but tying it to a new and inflexible encryption scheme sorta torpedos it. I can get behind the new SYN capability bit, and I can even get behind inserting a payload into SYN/SYN-ACK/ACK. But since the goal is encryption, it needs to be sound on that front first and foremost. -david _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
