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

Eric Rescorla <ekr@rtfm.com> Wed, 09 March 2011 15:39 UTC

Return-Path: <ekr@rtfm.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 3FB753A68D1 for <tls@core3.amsl.com>; Wed, 9 Mar 2011 07:39:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.923
X-Spam-Level:
X-Spam-Status: No, score=-102.923 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 XqYDV1bzG+pB for <tls@core3.amsl.com>; Wed, 9 Mar 2011 07:39:12 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 5F8423A67C1 for <tls@ietf.org>; Wed, 9 Mar 2011 07:39:12 -0800 (PST)
Received: by iwl42 with SMTP id 42so797207iwl.31 for <tls@ietf.org>; Wed, 09 Mar 2011 07:40:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.43.58.135 with SMTP id wk7mr149036icb.433.1299685228486; Wed, 09 Mar 2011 07:40:28 -0800 (PST)
Received: by 10.42.234.9 with HTTP; Wed, 9 Mar 2011 07:40:28 -0800 (PST)
In-Reply-To: <AANLkTimtw2=FV=BdkUQurut_TyzsZFTpyenwXZ6Oj+xg@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> <AANLkTimtw2=FV=BdkUQurut_TyzsZFTpyenwXZ6Oj+xg@mail.gmail.com>
Date: Wed, 09 Mar 2011 07:40:28 -0800
Message-ID: <AANLkTin4xqxfE4P+zvK5Tqe3OH4LmA_0K86=M_xtzeNC@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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:39:13 -0000

On Wed, Mar 9, 2011 at 7:15 AM, Nikos Mavrogiannopoulos <nmav@gnutls.org> wrote:
> 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.

I'm not sure what you mean by "valid". The client can't process the server's
application data until it receives the finished, but the server can
certainly send
the finished even if the application data is lost. This happens in TLS too,
it's just that TCP hides it from the TLS stack.



> 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)?

Because then we would have had to add a whole reliability protocol for
the records
even though many of the use cases we were concerned with didn't want to have
reliable data. This seemed better. It could be that we were wrong of course.

-Ekr