Re: [TLS] Single round trip abbreviated handshake

"Brian Smith" <> Fri, 05 February 2010 18:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98D6F3A6882 for <>; Fri, 5 Feb 2010 10:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9FzOBKKxfsrx for <>; Fri, 5 Feb 2010 10:54:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8C1513A6801 for <>; Fri, 5 Feb 2010 10:54:48 -0800 (PST)
Received: from T60 (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E06A8509E1; Fri, 5 Feb 2010 13:55:32 -0500 (EST)
From: "Brian Smith" <>
To: "'Ravi Ganesan'" <>, <>
References: <>
In-Reply-To: <>
Date: Fri, 5 Feb 2010 12:55:31 -0600
Message-ID: <000601caa694$cf3e2ed0$6dba8c70$@org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: en-us
Thread-Index: AcqkhxX+ZQxrgGA9QheVG0J3G44obQCB7myw
Subject: Re: [TLS] Single round trip abbreviated handshake
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Feb 2010 18:54:49 -0000

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 +

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.