[p2p-hackers] IETF rejects Obfuscated TCP

[Eric Rescorla]

At Tue, 19 Aug 2008 20:57:33 -0700,
Alex Pankratov wrote:
> 
> CC'ing cryptography mail list as it may be of some interest to the 
> folks over there.
> 
> > -----Original Message-----
> > From: p2p-hackers-bounces at lists.zooko.com [mailto:p2p-hackers-
> > bounces at lists.zooko.com] On Behalf Of Lars Eggert
> > Sent: August 19, 2008 5:34 PM
> > To: David Barrett; theory and practice of decentralized computer
> > networks
> > Subject: Re: [p2p-hackers] IETF rejects Obfuscated TCP
> > 
> > On 2008-8-19, at 17:20, ext David Barrett wrote:
> > > On Tue, 19 Aug 2008 4:19 pm, Lars Eggert wrote:
> > >> Actually, in 1994, the IETF standardized Transactional TCP (T/TCP)
> > in
> > >> RFC1644, which allows just that. However, there are serious DDoS
> > >> issues with T/TCP which have prevented it seeing significant
> > >> deployment.
> > >
> > > Hm, I'm sorry I don't know the history there -- why is this more
> > > costly
> > > or abusive than SSL over standard TCP?  Is it due to something
> > > specific
> > > to SSL, or due to it a simple lack of congestion control on those
> > > first
> > > payloads?
> > 
> > 
> > The issue is unrelated to a specific kind of SYN payload (SSL or
> > otherwise.) The issue is that a SYN flood of SYNs with data consumes
> > much more memory on the receiver than a regular SYN flood, because the
> > receiver is obligated to cache the data if a T/TCP liveness check
> > fails. You can't use SYN cookies with data SYNs, either.
> 
> This is just a quick thought, but a variation of SYN cookies for TLS
> appears to be quite easy to do. It does require defining new record 
> type, but latter is permitted by TLS spec as per Section 6, RFC 2246.
> 
> The idea, obviously, is to include a copy of ClientHello message in a
> second batch of records sent by the client. This should allow server
> to generate ServerKeyExchange parameters from the original ClientHello
> message (ClientHello.random + IP/port quintet + server "cookie secret"),
> then discard ClientHello and delay creating the state .. exactly the
> same way SYN cookies mechanism does it.

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.

-Ekr

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