On Aug 19, 2008, at 16:08 PM, David Barrett wrote: > Was it tied to a single encryption scheme? Why not just fall back on > SSL? Indeed, I'm not sure why you'd need a payload in the SYN-ACK at > all: I would think a simple bit saying: > > SYN: Hi, let's set up a TCP connection. Also, I support SSL. > SYN-ACK: Cool, once we're set up, let's switch to SSL. > ACK: Roger that. Next packet will be SSL; I'm assuming the same of > you. > > After all, key exchange and all the other SSL junk will take a ton > more > packets than a simple 3-way-handshake. Perhaps I'll need to read > up on > that spec.
You should. http://code.google.com/p/obstcp Also, apropos the discussion on this list, see the obstcp blog: http://obstcp.blogspot.com/2008/08/sorry-folks-i-think-obfuscated-tcp- died.html 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. I'm very disappointed that IETF is not moving us forward toward that goal. Regards, Zooko http://allmydata.org -- Tahoe, the Least-Authority Filesystem http://allmydata.com -- back up all your files for $5/month _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
