Re: [TLS] Single round trip abbreviated handshake
Ravi Ganesan <ravi@findravi.com> Sat, 06 February 2010 03:04 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 8CAB23A687F for <tls@core3.amsl.com>; Fri, 5 Feb 2010 19:04:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.827
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8b+E6+oJOQe for <tls@core3.amsl.com>; Fri, 5 Feb 2010 19:04:53 -0800 (PST)
Received: from mail-pz0-f181.google.com (mail-pz0-f181.google.com [209.85.222.181]) by core3.amsl.com (Postfix) with ESMTP id CCFBA3A6831 for <tls@ietf.org>; Fri, 5 Feb 2010 19:04:53 -0800 (PST)
Received: by pzk11 with SMTP id 11so1298625pzk.32 for <tls@ietf.org>; Fri, 05 Feb 2010 19:05:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.237.32 with SMTP id k32mr2390351wah.55.1265425543613; Fri, 05 Feb 2010 19:05:43 -0800 (PST)
In-Reply-To: <000601caa694$cf3e2ed0$6dba8c70$@org>
References: <3561bdcc1002022012s2867aac2vaa154013b62e8489@mail.gmail.com> <000601caa694$cf3e2ed0$6dba8c70$@org>
Date: Fri, 05 Feb 2010 19:05:43 -0800
Message-ID: <3561bdcc1002051905r24d9dadbi7d815d0d1dc4a19c@mail.gmail.com>
From: Ravi Ganesan <ravi@findravi.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: text/plain; charset="UTF-8"
Cc: tls@ietf.org
Subject: Re: [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: 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 http://www.ietf.org/mail-archive/web/tls/current/msg05735.html), (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! 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