IETF Logo Mail Archive

Re: [TLS] Single round trip abbreviated handshake

Eric Rescorla <ekr@networkresonance.com> Tue, 09 February 2010 16:36 UTC

Return-Path: <ekr@networkresonance.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 7A2A13A73EF for <tls@core3.amsl.com>; Tue, 9 Feb 2010 08:36:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.018
X-Spam-Level:
X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
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 Q9M8WOFZFkIt for <tls@core3.amsl.com>; Tue, 9 Feb 2010 08:36:20 -0800 (PST)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id C3FBF3A7368 for <tls@ietf.org>; Tue, 9 Feb 2010 08:36:20 -0800 (PST)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id D0DA76E7DF9; Tue, 9 Feb 2010 08:39:36 -0800 (PST)
Date: Tue, 09 Feb 2010 08:39:36 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Brian Smith <brian@briansmith.org>
In-Reply-To: <0d6201caa9af$d2217760$76646620$@briansmith.org>
References: <3561bdcc1002022012s2867aac2vaa154013b62e8489@mail.gmail.com> <000601caa694$cf3e2ed0$6dba8c70$@org> <3561bdcc1002051905r24d9dadbi7d815d0d1dc4a19c@mail.gmail.com> <0d6201caa9af$d2217760$76646620$@briansmith.org>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20100209163937.D0DA76E7DF9@kilo.networkresonance.com>
Cc: 'Ravi Ganesan' <ravi@findravi.com>, 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: Tue, 09 Feb 2010 16:36:21 -0000

At Tue, 9 Feb 2010 09:46:23 -0800,
Brian Smith wrote:
> 
> Ravi Ganesan wrote:
> > 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.
> 
> With DTLS, you can "resume a connection" and send application data
> all within *one* segment (half a round-trip). If you used DTLS then
> you wouldn't need to invent anything new, AFAICT.

When you say "With DTLS" you mean with some modification to DTLS,
correct? AFAIK DTLS currently requires the client to compute
the keys based on the ServerRandom which precludes what you
suggest here.

-Ekr

v2.23.0 | Report a Bug | By Email