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: [EMAIL PROTECTED] [mailto:p2p-hackers- > > [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
