Re: [tcpm] SYN/ACK Payloads, draft 01

[Eric Rescorla <[e-mail]>]

At Wed, 13 Aug 2008 10:47:57 -0700,
Adam Langley wrote:
> 
> On Wed, Aug 13, 2008 at 10:27 AM, Eric Rescorla
> <[e-mail]> wrote:
> > S 4. Opportunistic HTTP Encryption
> >
> > As I understand this mechanism, what's being proposed is this:
> [snip]
> > Do I have that right?
> 
> Yep,
> 
> > 1. The PPExt payload is overloaded here. First, it's signalling
> >   a transport message "it's OK to put stuff in the SYN/ACK". Second,
> >   it's signalling an application layer message "It's OK to send me
> >   a crypto handshake as the first thing you send." Note that in
> >   an ordinary HTTP connection, this data would be invalid.
> 
> Actually, it's only signaling the application extension. The SYNACK
> payloads are valid in any TCP connection, although this spec does make
> some guarantees about weather the stacks will process them.

I'm srory, I don't understand what you're saying here. Does this
data appear to the application to be part of the data stream
or not? 


> >   This overloading seems fairly unwise, since it would preclude
> >   any other use of this SYN/ACK payload in the future.
> 
> The format of the SYNACK payload for this scheme is similar to the
> option space: i.e. it's a tagged, extensible payload.

OK, this wasn't entirely clear from reading the draft.


 
> > 2. It's not clear to me that opportunistic security for HTTP is that
> >   great. Unlike, for instance, SMTP, HTTP fetches are nearly always
> >   the result of some URI, so it's very easy to simply indicate
> >   in the URI that the server supports HTTPS. This is superior
> >   from a security perspective for the usual reasons (referential
> >   integrity, etc...)
> 
> I believe that there's a use for a low-cost cryptographic scheme, such
> as this. Despite widespread TLS deployment, most traffic is still in
> the clear, including semi-sensitive information. I would rather that
> traffic be protected with TLS but, since that isn't happening, I would
> rather this than nothing.

But the premise of this scheme is that people don't do TLS
because of either (1) latency or (2) lack of opportunistic 
negotiation. As far as I can tell, neither is correct. Rather,
it's concerns about server performance. And server performance
can be improved by a number of mechanisms within TLS that
are (1) backward compatible with TLS and (2) don't require
modifying the kernel. 

That said, if you're willing to burn even very small amounts
of data in the SYN, you can do something TLS-compatible by
passing a compressed ClientHello of some kind + FastTrack.
This only works with static RSA one the server side, but
so does the scheme you propose.


> Opinions on this vary. Some folks think it's a great idea (including
> some working on implementing the TLS Fast-Track you cite below), some,
> like you are unimpressed. Fundamentally, I'm only asking for an option
> number to try it out.

As I indicated earlier, I'm not taking a position on whether you
should be assigned an 


> > 4. Some of the latency benefit you're getting here is from not
> >   negotiating the crypto algorithms; this is why in TLS the
> >   client speaks first. This isn't an issue for the symmetric
> >   algorithm since the server could provide a list, but it's
> >   a real issue for the asymmetric algorithm, since it provides
> >   no agility in the case of upgrade or compromise. If, for
> >   instance, someone successfully attacks this curve but there
> >   are other, strong curves available, then we'd be hosed.
> 
> Firstly, this isn't rigorous crypto, so the primitives here are in the
> enviable situation of being good enough if it's infeasible to break
> them in near-real time. If you want real security, use TLS.

Yeah, I'm not a big fan of inventing new things we know to be weaker
than the old things we already have, especially when the benefit
claimed by the newer thing seems marginal.

-Ekr

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm