[p2p-hackers] IETF rejects Obfuscated TCP

[Alex Pankratov]

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.

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

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