[p2p-hackers] IETF rejects Obfuscated TCP

Eric Rescorla 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
> opportunistic.

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 mailing list