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. This still doesn't protect against host CPU exhaustion attacks, because ServerKeyExchange may require some heavy crypto. But since all this is being discussed in a context of "obfuscated TCP" and "opportunistic encryption", then using anonymous DH suite might be a feasible option. The above is trivial to implement, it is backward compatible with existing TLS implementations (as per the same section of RFC - records of unknown types are silently discarded) and all it requires little standardization effort. As I said, this is just a quick thought, so in all likelihood I might be reinventing a (broken) bike here. Alex _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
