Re: [TLS] Single round trip abbreviated handshake

["Brian Smith" <[e-mail]>]

Ravi Ganesan wrote:
 
> This is awkward for us not just from a latency perspective, but it
> would be very nice if the initial request came with all
> the information needed for the Server to figure out who is on the
> other end. (e.g. a cross domain XHR request).

The client finished message verifies that the client has the master secret
because the protocol requires the client to combine the master secret with
bits that the server just provided in this connection. If the server hasn't
provided any input to the client finished message, then it cannot use the
client finished message to verify that the client has the master secret. In
particular, it cannot verify that the client isn't replaying the client
finished message from another connection.

> So here is what we came up with. The abbreviated handshake is:
> 
> C   ->  Client Hello (including client-random and unix_gmt)  -> S
> (neither party know who is at other end at this point)
> 
> C   <-   Server Finished (including server-random and unix_gmt)  <- S
> (client has auth server at this point)
> 
> C   ->  Client Finished     -> S
> (only now does server authenticate client)
> 
> If we want to reduce this to a single round trip, then the C needs to
> send the Client Finished in first message.

How does it help to reduce this from three segments to two segments? The
third segment (C -> Client Finished -> S) will usually look like (C ->
Client Finished || Application Data -> S). Unless you include the
application data in the first segment too, you're not really reducing the
number of segments.


> BUT the Client Finished depends on the server-random and unix_gmt
> response from S which C does not know.
> 
> So the idea is for the C to SUGGEST a server-random, and if the S
> accepts the suggestion then for the S to use the suggested
> server_random and the same unix_gmt as sent by the C (after ensuring
> it is within some range; hence loose clock synchronization).

   key_block = PRF(SecurityParameters.master_secret,
                      "key expansion",
                      SecurityParameters.server_random +
                      SecurityParameters.client_random);

If you let the client choose both server_random and client_random, then
you're effectively letting the client choose the encryption keys and
initialization vectors. Common block cipher modes are very sensitive to
reusing initialization vectors. At a minimum, the server would have to keep
a cache to ensure that the "suggested" server random values are never
reused. And, that cache has to be *serialized* across all server threads and
all machines in the server cluster. That seems very unrealistic. 

Even then, the server can't verify that the suggested server_random is
actually random or random enough. That means that the server is relying
solely on the correctness of the client to ensure the randomness of the
resulting initialization vectors and keys. Previous experience has shown
that this isn't safe.

> If you truly hate this thinking I suspect you will say so; but then do
> also consider proposing an alternative. I think the world NEEDS a one
> round trip abbreviated handshake (and perhaps to Adam's point, a full
> handshake also).  We can either meet that need within the umbrella of
> the TLS we know and love, or else the world will eventually come up
> with a completely new alternative which will not take advantage of the
> 15 years of SSL analysis and the SSL trust infrastructure. I am not
> sure why latter is better alternative.

Like I said above, the TLS resumption handshake already adds only a single
round-trip, compared to a transaction that doesn't even use TLS at all.

Secondly, it seems like you are assuming that your shortcut is obviously
safe, and so would be able to reuse the security analysis of TLS that was
done without this shortcut in mind. AFAICT, that isn't true.

In fact, I don't see how this is safe at all. If I am overlooking something
then please let me know.

Regards,
Brian