IETF Logo Mail Archive

Re: [TLS] Single round trip abbreviated handshake

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Tue, 09 February 2010 17:50 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 CDE3528C16F for <tls@core3.amsl.com>; Tue, 9 Feb 2010 09:50:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.279
X-Spam-Level: *
X-Spam-Status: No, score=1.279 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, 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 Z7AjPSduLta4 for <tls@core3.amsl.com>; Tue, 9 Feb 2010 09:50:49 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 9FE5728C24B for <tls@ietf.org>; Tue, 9 Feb 2010 09:50:48 -0800 (PST)
Received: from [192.168.1.190] (p508FF7F7.dip.t-dialin.net [80.143.247.247]) by mail-n.franken.de (Postfix) with ESMTP id 255731C0B461C; Tue, 9 Feb 2010 18:51:54 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <20100209163937.D0DA76E7DF9@kilo.networkresonance.com>
Date: Tue, 09 Feb 2010 18:51:53 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <B2A5E458-6AFC-4D5E-804C-FC719F39B8B3@lurchi.franken.de>
References: <3561bdcc1002022012s2867aac2vaa154013b62e8489@mail.gmail.com> <000601caa694$cf3e2ed0$6dba8c70$@org> <3561bdcc1002051905r24d9dadbi7d815d0d1dc4a19c@mail.gmail.com> <0d6201caa9af$d2217760$76646620$@briansmith.org> <20100209163937.D0DA76E7DF9@kilo.networkresonance.com>
To: Eric Rescorla <ekr@networkresonance.com>
X-Mailer: Apple Mail (2.1077)
Cc: tls@ietf.org, 'Ravi Ganesan' <ravi@findravi.com>
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 17:50:49 -0000

On Feb 9, 2010, at 5:39 PM, Eric Rescorla wrote:

> 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.
I assume that he just "continues to use an existing DTLS connect",
or am I wrong? 

Best regards
Michael
> 
> -Ekr
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email