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

[Eric Rescorla <[e-mail]>]

At Wed, 13 Aug 2008 11:45:07 -0700,
Adam Langley wrote:
> 
> On Wed, Aug 13, 2008 at 11:16 AM, Eric Rescorla
> <[e-mail]> wrote:
> > 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?
> 
> Yes, the data is part of the application stream. However, including a
> payload in the SYN/ACK frame is permitted by TCP. Thus application
> protocols in which the server speaks first could include payloads in
> the SYN/ACK today, with no changes. Admittedly many stacks will only
> ACK the SYN flag and not the data, so the data has to be
> retransmitted, but the changes needed don't need any standard work.
>
> The option proposed here is just for "client speaks first" to escape
> that mode and switch to a "server speaks first" mode.

Right, but this has application-level semantics because the content
of the server's data is not what an unmodified client expects. So,
it's not just a timing issue: the server sends different data 
to the client if this option is included or not.


> > OK, this wasn't entirely clear from reading the draft.
> 
> I didn't include it in the draft because it seemed out of scope, but
> maybe I should since attentive readers are obviously picking up on it.
> 
> > 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.
> 
> (1) is certainly a concern today. Even a single round trip. Most
> actual numbers on this are considered secrets by the organisations in
> a good place to gather them, but here's one soundbite:
> 
> "every 100ms of latency costs Amazon 1% of profit"
> http://radar.oreilly.com/2008/08/radar-theme-web-ops.html

Well, this is just an unsupported claim in the presentation, so I have
no idea what the underlying data is. However, superficially I find it
deeply implausible. I have a Comcast business line, a fast computer,
and a modern version of Firefox and it takes about 5 seconds to load
Amazon's home page. There are lots of things Amazon could do to
improve that performance (e.g., show me less images on the
main page). Given that they don't, it's pretty hard to take complaints
about a couple of hundred ms latency seriously.


> (2) is also a concern: simply put, users type http by habit.

And the servers could say "use TLS next time" and the browsers could 
remember that. 


> Additionally, getting TLS certificates is a pain for small sites.

Huh? I've done this. It's cheap (< $50/yr) and simple (< 10 minutes).


> As
> for server load, curve25519 can be performed in 240us on a Core2 and
> Salsa20/8 runs at 2 cycles/byte (same hardware). That reduces server
> load.

You're conflating unrelated issues, since TLS is perfectly capable
of using these algorithms, if someone thought it was worth defining
a cipher suite.


> But, really, I don't really know the reasons why TLS isn't ubiquitous
> even with ubiquitous support. But, given that it isn't, I'm looking to
> the best that I can with a very low-cost (i.e. computation, latency)
> system.

This sounds to me like a classic case of premature optimization.
For all you know the reason TLS isn't ubiquitous is that it
doesn't have a cool name. Maybe we should work on that instead.


> > 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.
> 
> I can reasonably fit 14 bytes in a SYN frame. I did consider trying to
> get RSA in the SYN (because then the computation costs could be mostly
> put on the server), but I don't think I can fit anything useful in
> there. (Not even a good elliptic key).

I'm talking about a different dataflow.  your dataflow is:

      Client                           Server
      ------                           ------
      SYN + PPExt ->
      
          <- SYN/ACK + PPExt + [Crypto stuff]
      
      [Crypto Stuff] ->
      [HTTP Req]    


Consider the basic TLS handshake from 4346:

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data
      


But the client can techncially start sending data as soon as it has
sent Finished, so that leaves us with:


      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
      Application Data

Which is the same number of messages as in your example. The problem
is now sending them before the 3-way handshake completes.

The Server's first message can be stuffed in the SYN/ACK payload, but
the ClientHello cannot be stuffed in a SYN option. But if you were
willing to define compressed versions of the most common ClientHello
options, you could just say in the SYN option "I speak package 9" and
then the server could send the ServerHello right away. You'd need to
move some of the ClientHello (e.g., the Random) to the Client's first
real message, but that's technically feasible.

-Ekr



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