IETF Logo Mail Archive

Re: [TLS] Single round trip abbreviated handshake

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Tue, 09 February 2010 15:59 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 C2D493A73E0 for <tls@core3.amsl.com>; Tue, 9 Feb 2010 07:59:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
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 6Is0NsZc0euT for <tls@core3.amsl.com>; Tue, 9 Feb 2010 07:59:24 -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 CCD293A73DA for <tls@ietf.org>; Tue, 9 Feb 2010 07:59:23 -0800 (PST)
Received: from [IPv6:2002:508f:f7f7::224:36ff:feef:67d1] (unknown [IPv6:2002:508f:f7f7:0:224:36ff:feef:67d1]) by mail-n.franken.de (Postfix) with ESMTP id A8A761C0B461C; Tue, 9 Feb 2010 17:00:27 +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: <0d6201caa9af$d2217760$76646620$@briansmith.org>
Date: Tue, 09 Feb 2010 17:00:26 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8DBCC508-44A2-4A43-8176-FF5D7E458AFF@lurchi.franken.de>
References: <3561bdcc1002022012s2867aac2vaa154013b62e8489@mail.gmail.com> <000601caa694$cf3e2ed0$6dba8c70$@org> <3561bdcc1002051905r24d9dadbi7d815d0d1dc4a19c@mail.gmail.com> <0d6201caa9af$d2217760$76646620$@briansmith.org>
To: Brian Smith <brian@briansmith.org>
X-Mailer: Apple Mail (2.1077)
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 15:59:24 -0000

On Feb 9, 2010, at 6:46 PM, 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.
... not if you run DTLS over a connection oriented transport protocol
like DCCP or SCTP. For the new transport connection you need to
establish a new DTLS connection.

Best regards
Michael
> 
> Regards,
> Brian
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email