Re: [TLS] Single round trip abbreviated handshake

Ravi Ganesan <> Sat, 06 February 2010 03:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CAB23A687F for <>; Fri, 5 Feb 2010 19:04:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.827
X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_DIET=2.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y8b+E6+oJOQe for <>; Fri, 5 Feb 2010 19:04:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CCFBA3A6831 for <>; Fri, 5 Feb 2010 19:04:53 -0800 (PST)
Received: by pzk11 with SMTP id 11so1298625pzk.32 for <>; Fri, 05 Feb 2010 19:05:43 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id k32mr2390351wah.55.1265425543613; Fri, 05 Feb 2010 19:05:43 -0800 (PST)
In-Reply-To: <000601caa694$cf3e2ed0$6dba8c70$@org>
References: <> <000601caa694$cf3e2ed0$6dba8c70$@org>
Date: Fri, 5 Feb 2010 19:05:43 -0800
Message-ID: <>
From: Ravi Ganesan <>
To: Brian Smith <>
Content-Type: text/plain; charset=UTF-8
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: Sat, 06 Feb 2010 03:04:54 -0000

i) I never said the shortcut is "obviously safe"!!! On the contrary I
went to great lengths to say that (a) on surface it if "preposterous",
(b) that I tried my best to dig up the historical reason those random
numbers were added when one moved from ssl 2.0 to ssl 3.0, (I
explained this in separate thread, (c)
then suggested that the client SUGGEST a server random which is
constrained to be a function of the client_random and the unix_gmt
(not let client pick arbitrary random). and (d) let the server decide
where it is in the risk/reward spectrum and decide whether to take the
additional risk or not.  I want to emphasize this, as this is not
something that one does lightly, and in the post, and in the paper
referenced I go to great lengths to point out the risks.

ii) Absolutely recognize replay issue, which requires caching within
clock slew you tolerate, or Adam's epoch scheme. Does all this make
protocol messier...absolutely! Backing out of a ChangeCipherCpecs,
having the application presumptuously send data and then back out when
it realizes something went wrong is all messy. Point is some might be
willing to live with this messiness for the gain in performance.

iii) Your point about "tls security analysis" cannot be applied
blindly is completely true but is not what I was saying. My point was
that if you gave me two alternates: (i) a very close descendant of SSL
with the only change being that on session resumption the
server-random is a function of client_random and client unix_gmt,
versus (ii) a completely new protocol a bunch of people came up with
today because they wanted a one round trip protocol, THEN I for one
would take the TLS descendant in a heartbeat.

Hope this helps!