[p2p-hackers] IETF rejects Obfuscated TCP

[Eric Rescorla]

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.

-Ekr

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com