Re: [TLS] DTLS 1.0 and DTLS 1.2 issues with retransmission

Nikos Mavrogiannopoulos <nmav@gnutls.org> Wed, 09 March 2011 15:13 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 7AAD13A6992 for <tls@core3.amsl.com>; Wed, 9 Mar 2011 07:13:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 lz56S60VLuMl for <tls@core3.amsl.com>; Wed, 9 Mar 2011 07:13:52 -0800 (PST)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 7F6963A683E for <tls@ietf.org>; Wed, 9 Mar 2011 07:13:52 -0800 (PST)
Received: by qyk7 with SMTP id 7so503974qyk.10 for <tls@ietf.org>; Wed, 09 Mar 2011 07:15:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hf9znjD+Y5OcWJafXeFcDOB/vEOf1QOjHu2KuVkXrNE=; b=s+DZkkQaI1jdXV8sRX2/cfSLwNy7bUz8mV3k5EhypYVx85WrJcrPchYhrbfEw7OJbz M627m2Hlcc4hxKkyDQomGdaZVReuUdwxNFtdQxbA/x6pTECy3V1sX3l5sT+LqDHJuErP xt9dAo312ea02Wm6VYu73Deiosdro6J9X/oY0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=LX3xISoL4BSUUtxJEHb3pkxyPrhXZQsSnXS6sZVZd0YbUj6i2LDt9yw134Q6vawhLG Stnnyx8J+lz3mJais1OOZYynMm2uZNZ/SvUSV9O2sPV2Lt2AwVodcbWhpsDNQN2rOSrx 3fLFQoNtRu+P0P8Qm73QoLqmqpjo7D/pof+pc=
MIME-Version: 1.0
Received: by 10.229.114.80 with SMTP id d16mr5312357qcq.18.1299683708594; Wed, 09 Mar 2011 07:15:08 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.229.20.71 with HTTP; Wed, 9 Mar 2011 07:15:08 -0800 (PST)
In-Reply-To: <AANLkTimYyAGikDpjQv7rFpAOtuxKJ-QMhcSVtm1o6Hi4@mail.gmail.com>
References: <4D5FF4CD.9070307@gnutls.org> <AANLkTik9o-D5oF0PqETtyAiQ8Z6NF98qsejgw861MRZ8@mail.gmail.com> <AANLkTikOY=329y-pP1XMs3SLF4uq9KaoS+EzCTh02R34@mail.gmail.com> <AANLkTi=J7V7A7voVghRk179mzfM1_-Mpd4=26PeMZ+Rd@mail.gmail.com> <AANLkTikKYBf7eAyN60K8GZnro3EE7RK3x1RaiN-0O2Zz@mail.gmail.com> <AANLkTi=1XBgriiV2o32MoDEA_UuU5_suvaWY2yzM5V+m@mail.gmail.com> <AANLkTimYyAGikDpjQv7rFpAOtuxKJ-QMhcSVtm1o6Hi4@mail.gmail.com>
Date: Wed, 09 Mar 2011 16:15:08 +0100
X-Google-Sender-Auth: I-OIQe9kNGMbG9Eqig-Q9rwcR6w
Message-ID: <AANLkTimtw2=FV=BdkUQurut_TyzsZFTpyenwXZ6Oj+xg@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Cc: "tls@ietf.org" <tls@ietf.org>, nagendra@cs.stanford.edu
Subject: Re: [TLS] DTLS 1.0 and DTLS 1.2 issues with retransmission
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: Wed, 09 Mar 2011 15:13:53 -0000

On Tue, Mar 8, 2011 at 3:00 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>> If there is no answer to that, then a DTLS handshake would always require
>> a fixed amount of time (additional to calculations), e.g. 60 seconds -
>> if we take
>> the maximum time allowed for retransmission - to complete. That is because
>> I see protocol transition from
>> "handshake" -> "application data exchange"
>> only after handshake has been fully completed. Or is it implicit that
>> "draft-bmoeller-tls-falsestart-00" applies to DTLS? (in that case it
>> should be explicit).
>
> I don't think I understand the question.
> As soon as either side has *received* the last message it expects to
> get from the
> other side, it can start sending data.

Ok I think I got the point, but I don't think this is obvious.
What you are suggesting here is that a handshake such as:

Client                                  Server

ClientHello                  -------->
                                        ServerHello
                                        Certificate*
                                        ServerKeyExchange*
	                                CertificateRequest*
                             <--------  ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished                     -------->
                                        [ChangeCipherSpec]
	                     <--------  Finished **lost**
                             <--------  Application Data
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished                     -------->
                                        [ChangeCipherSpec]
	                     <--------  Finished **lost**
                             <--------  Application Data
                             <--------  Application Data
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished                     -------->
                                        [ChangeCipherSpec]
	                     <--------  Finished
Application Data             <------->  Application Data

is valid for DTLS. My impression after reading draft-ietf-tls-rfc4347-bis-04
was that it is similar to TLS, in the sense that the handshake protocol
has to finish (for both parties) before application data are to be
exchanged (and
thus the above handshake would be invalid).



Something out of curiocity. Why was the handshake layer retransmission and
reassembly was preferred comparing to a retransmission and reassembly
layer at the
record protocol (for records exchanged during the handshake protocol)?

regards,
Nikos