[p2p-hackers] IETF rejects Obfuscated TCP
ap at poneyhot.org
Wed Aug 20 16:15:15 EDT 2008
> -----Original Message-----
> From: Eric Rescorla [mailto:ekr at networkresonance.com]
> Sent: August 20, 2008 12:29 PM
> To: Alex Pankratov
> Cc: 'Eric Rescorla'; 'theory and practice of decentralized computer
> networks'; cryptography at metzdowd.com
> Subject: Re: [p2p-hackers] IETF rejects Obfuscated TCP
> At Wed, 20 Aug 2008 11:59:48 -0700,
> Alex Pankratov wrote:
> > > May I ask what you're trying to accomplish? Recall that TLS doesn't
> > > start until a TCP connection has been established, so there's
> > > aready a proof of the round trip.
> > >
> > > That said, a mechanism of this type has already been described
> > > for DTLS (RFC 4347), so no new invention would be needed.
> > My comment was in a context of a thread discussing Obfuscated TCP.
> > One of the suggestions was to piggyback SSL handshake on TCP
> > handshake, to which someone pointed at an issue with SYN-flood
> > like DoS attacks. My response was to the latter comment.
> Well, as I stated in the original discussion on obfuscated TCP (on
> TCPM), I'm not convinced that the latency problem is that severe, and
> if it is there are a number of potential performance improvements one
> could make to TLS before one started screwing around with TCP.
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.
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography