[p2p-hackers] IETF rejects Obfuscated TCP
ekr at networkresonance.com
Wed Aug 20 17:23:26 EDT 2008
At Wed, 20 Aug 2008 13:27:50 -0700,
Adam Langley wrote:
> On Wed, Aug 20, 2008 at 1:15 PM, Alex Pankratov <ap at poneyhot.org> wrote:
> > Based on this reply alone I'm not sure I follow. I also read quickly
> > through your exchange on TCPM and your comments appear to be specific
> > to Adam's draft.
> > My comment was not related to either a latency or a potential performance
> > problems of TLS. It was in a response to another idea - that of bundling
> > TLS handshake with TCP handshake. The goal of this (and I apologize for
> > stating the obvious, just want to make sure we are on the same page here)
> > is to provide transparent to application layer opportunistic encryption
> > of TCP streams. Whether this goal makes any sense and if it is worth
> > pursuing is a separate issue; it's the DoS aspect of the implementation
> > idea that I was commenting on.
> Sorry, I'm loosing this conversation a little, I think half of it's
> occuring on mailing lists that I'm not on.
Indeed. I'm not on p2p-hackers, so I'm reading this on cryptography at .
> If I might speak for another: ekr doesn't believe that an extra RTT of
> latency is important. This is perfectly reasonable since I can't
> release any numbers. Thus, Eric is taking the perfectly respectable
> view that we shouldn't complicate things for dubious benefit.
That's probably a reasonably accurate summary of my position.
> TLS is only one RTT if the session is cached (either server side
> caching or client side). Without modifying TCP, one could push the
> server's exchange into the SYNACK and get this down to 0 extra round
> trips. (needs kernel changes) This would really involve cramming TLS
> into a very small space and the result would look little like TLS.
I actually am not sure I agree with this assessment of "look little
like TLS". I haven't spent that much time on this particular
issue, but most of the schemes I've seen for optimizing out TLS round trips
(e.g., FastTrack) are actually quite minor modifications to TLS.
> However, the issue is that, if clients started doing this, they
> couldn't know if the other end supports it. Thus it wouldn't be very
Well, maybe, maybe not. Remember that if you're doing session
caching, the client and a server have an opportunity do do
discovery in the first handshake.
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography