[TLS] Single round trip abbreviated handshake

[Ravi Ganesan <[e-mail]>]

Hi,

I was hoping to make an RFC out of this with those in this list who
think alike and then post, but since the discussion has started
thought I'd join in the fun and  send on this link below.

http://www.safemashups.com/downloads/Optimizing_the_SSL_and_MashSSL_Handshakes.pdf

Basically, we ran into the 'ssl handshakes need at least two
roundtrips' about a year ago in our work in MashSSL (see
www.mashssl.org). Almost all MashSSL handshakes will be "abbreviated
handshakes" (aka session resumption), and since our "transport" was
HTTP, we were in the awkward position of having to do two HTTP
requests to complete the handshake.  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).

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

Now, having the counter party in an auth protocol suggest which
'random' number you should use is on the surface utterly preposterous.
 So I went about trying to understand WHY we have these random numbers
in the abbreviated handshake (keep in mind that at this point both
sides have a shared master_secret). The SSL history here was not
entirely clear, but if you see the Schneier and Kocher papers from
that time you can start trying to reconstruct the rationale for them.
And, my analysis was that you can get away with not having the
server-random be truly random, as long as you constrain it.

Anyway, after weighing the unknown RISK introduced against the HUGE
benefits for reducing the number of round trips, our thinking is that,
different apps should be allowed to make different decisions on the
risk/reward trade-off.

(i) the Client should be able to SUGGEST (in an extension) that the
Server use a particular server-random, and then send along the
client-finished optimistically assuming the Server will cooperate.
(ii) the Server can be nice and cooperate, or coldly ignore the Client
and respond as if the extension was not there (taking care either way
to construct the running hashes with only the appropriate messages).

As protection one does not want to let the Client suggest ANY
server-random. Rather, we probably limit attacks (if any) caused by
this model, by setting server-random = function(client-random,
unix_gmt).

Adam/Google was going down this road independently. Adam has suggested
server-random = function(client-random, unix-gmt, epoch) where last
value is derived from Server cert.

Adam has also suggested this can work for full handshake as well. In
the rough paper I reference above we actually considered that
possibility but to put it bluntly 'chickened out'.

(and yes the backing out of data sent etc., reversing change cipher
specs, etc. is not elegant, but its ok if the plumbing looks ugly as
along as it works real fast...!)

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.

Cheers,

Ravi