Re: [p2p-hackers] IETF rejects Obfuscated TCP

[Eric Rescorla]

At Wed, 20 Aug 2008 13:27:50 -0700,
Adam Langley wrote:
> 
> On Wed, Aug 20, 2008 at 1:15 PM, Alex Pankratov <[EMAIL PROTECTED]> wrote:
> > 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.
> 
> Sorry, I'm loosing this conversation a little, I think half of it's
> occuring on mailing lists that I'm not on.

Indeed. I'm not on p2p-hackers, so I'm reading this on [EMAIL PROTECTED]


> If I might speak for another: ekr doesn't believe that an extra RTT of
> latency is important. This is perfectly reasonable since I can't
> release any numbers. Thus, Eric is taking the perfectly respectable
> view that we shouldn't complicate things for dubious benefit.

That's probably a reasonably accurate summary of my position.


> TLS is only one RTT if the session is cached (either server side
> caching or client side). Without modifying TCP, one could push the
> server's exchange into the SYNACK and get this down to 0 extra round
> trips. (needs kernel changes) This would really involve cramming TLS
> into a very small space and the result would look little like TLS.

I actually am not sure I agree with this assessment of "look little
like TLS". I haven't spent that much time on this particular
issue, but most of the schemes I've seen for optimizing out TLS round trips 
(e.g., FastTrack) are actually quite minor modifications to TLS.


> However, the issue is that, if clients started doing this, they
> couldn't know if the other end supports it. Thus it wouldn't be very
> opportunistic.

Well, maybe, maybe not. Remember that if you're doing session
caching, the client and a server have an opportunity do do
discovery in the first handshake.

-Ekr

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

RE: [p2p-hackers] IETF rejects Obfuscated TCP

[Alex Pankratov]

> -Original Message-
> From: Eric Rescorla [mailto:[EMAIL PROTECTED]
> Sent: August 20, 2008 12:29 PM
> To: Alex Pankratov
> Cc: 'Eric Rescorla'; 'theory and practice of decentralized computer
> networks'; cryptography@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.

Alex



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: [p2p-hackers] IETF rejects Obfuscated TCP

[Eric Rescorla]

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.

-Ekr

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

RE: [p2p-hackers] IETF rejects Obfuscated TCP

[Alex Pankratov]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:owner-
> [EMAIL PROTECTED] On Behalf Of Eric Rescorla
> Sent: August 20, 2008 10:31 AM
> To: Alex Pankratov
> Cc: 'theory and practice of decentralized computer networks';
> cryptography@metzdowd.com
> Subject: Re: [p2p-hackers] IETF rejects Obfuscated TCP

[snip]

> 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.

Alex

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: [p2p-hackers] IETF rejects Obfuscated TCP

[[EMAIL PROTECTED]]

>
> May I ask what you're trying to accomplish?
>
I assume  which uses the TCP
connection setup to do a key agreement. Slick but apparently
susceptible to DoS.

-Michael Heyman

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: [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: [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]

RE: [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: [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

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]