[TLS] Single round trip abbreviated handshake
Ravi Ganesan <ravi@findravi.com> Wed, 03 February 2010 04:11 UTC
Return-Path: <ravi@findravi.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9BF73A699C for <tls@core3.amsl.com>; Tue, 2 Feb 2010 20:11:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62W9IWd9oLzD for <tls@core3.amsl.com>; Tue, 2 Feb 2010 20:11:30 -0800 (PST)
Received: from mail-pz0-f179.google.com (mail-pz0-f179.google.com [209.85.222.179]) by core3.amsl.com (Postfix) with ESMTP id 54E6B3A694E for <tls@ietf.org>; Tue, 2 Feb 2010 20:11:30 -0800 (PST)
Received: by pzk9 with SMTP id 9so944950pzk.31 for <tls@ietf.org>; Tue, 02 Feb 2010 20:12:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.243.14 with SMTP id q14mr4680399wah.168.1265170328235; Tue, 02 Feb 2010 20:12:08 -0800 (PST)
Date: Tue, 02 Feb 2010 20:12:08 -0800
Message-ID: <3561bdcc1002022012s2867aac2vaa154013b62e8489@mail.gmail.com>
From: Ravi Ganesan <ravi@findravi.com>
To: tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Subject: [TLS] Single round trip abbreviated handshake
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2010 04:11:32 -0000
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
- [TLS] Single round trip abbreviated handshake Ravi Ganesan
- Re: [TLS] Single round trip abbreviated handshake Adam Langley
- Re: [TLS] Single round trip abbreviated handshake Ravi Ganesan
- Re: [TLS] Single round trip abbreviated handshake Adam Langley
- Re: [TLS] Single round trip abbreviated handshake Brian Smith
- Re: [TLS] Single round trip abbreviated handshake Ravi Ganesan
- Re: [TLS] Single round trip abbreviated handshake Brian Smith
- Re: [TLS] Single round trip abbreviated handshake Michael Tüxen
- Re: [TLS] Single round trip abbreviated handshake Ravi Ganesan
- Re: [TLS] Single round trip abbreviated handshake Eric Rescorla
- Re: [TLS] Single round trip abbreviated handshake Michael Tüxen
- Re: [TLS] Single round trip abbreviated handshake Ravi Ganesan
- Re: [TLS] Single round trip abbreviated handshake Brian Smith