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

["Adam Langley" <[e-mail]>]

On Wed, Aug 13, 2008 at 12:50 PM, Eric Rescorla
<[e-mail]> wrote:
> 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.

Yes, it absolutely has application level semantics, that's its purpose:

"Modifications to take advantage of SYNACK payloads would then require
changes to the application level protocol ... Because of this, we also
describe a TCP option that lets the application layer on both sides
... agree to use an alternative protocol which takes advantage of it."

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

As I suggested, this data is considered secret by the organisations
who have it. But I can say that, had I suggested an opportunistic
system that required an extra round trip, various teams here (at
Google) would have (rightfully) laughed at me. I know that sucks as an
argument, but I can't release company data. I'm a bit stuck here
sadly.

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

And that's not a bad idea either. If I get around to it I might sketch
something like that out and see what the Mozilla folks think of it.

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

At which point, I think we have basically the same scheme, but with
different names!

ClientHello (1 bit)  ---->
<----- ServerHello, ServerHelloDone
ClientRandom, Finished, Application Data ----->

For implementation reasons I'm reducing the "I speak package 9" to a
single bit. The sockets API makes it very painful to have applications
process each SYN frame. One could imagine giving the kernel a list of
different payloads to send in the case of different options in the
SYN, but I didn't for complexity reasons. The major advantage would be
that we could more easily recover from primitive compromise but, as
I've outlined in a previous email, the tagged nature of the payload
makes it doable anyway.

We can't fit any certificates in the ServerHello and (unless we're
moving this into the kernel) the key agreement value has to be
constant. So we define a new cipher spec for a Diffie-Hellman function
that works in the face of constant public values and is very fast
(curve25519).

I, indeed, put the client's random in the first real message. I could
support client certificates with the tagged structure, currently I
don't.

So, given the space constraints, it's largely isomorphic, right? If
there's anything important that I've missed please put me straight.


Cheers

AGL

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