At Wed, 20 Aug 2008 13:27:50 -0700, Adam Langley wrote: > > On Wed, Aug 20, 2008 at 1:15 PM, Alex Pankratov <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > 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 [EMAIL PROTECTED]
