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

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 8 Mar 2011 14:36:49 +0100

On Mon, Feb 21, 2011 at 3:26 PM, Nikos Mavrogiannopoulos
<[email-masked]> wrote:

>> There is some guidance in 4.2.4.1 (1 second doubling up to 60 seconds.).
>> Can you give me an idea of what sort of more detailed guidance you woud
>> like?
> How long would the client need to wait for the last flight retransmit (in order
> to retransmit his finished)? If the application protocol requires the client
> to start sending application data this is an issue.

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

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Mar 2011 06:00:03 -0800

> "draft-bmoeller-tls-falsestart-00" applies to DTLS? (in that case it

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. However, it needs to buffer the
last message
that it sent in order to do a retransmit in case said message was
lost. That retransmit
is triggered by the other side retransmitting their last message
(which has already
been received and processed by the first side). So, to abstract away from DTLS,
say that the last two messages of the handshake are;

Alice -> Bob:  Foo
Bob -> Alice: Bar

Alice sends "Foo" and waits for Bob to send "Bar". As soon as Bob has sent "Bar"
he considers the handshake over and can start sending data. Alice
needs to wait to
receive "Bar". If she doesn't, then she times out and sends "Foo" which triggers
Bob to retransmit "Bar".

Note that this is actually partly true of TLS as well. Consider that
in the normal
handshake, the server receives the client's Finished and then sends
his own Finished
and then can start sending data. He has no way of knowing that the
client actually
received the server Finished (though TCP guarantees that the messages will
be processed in order on the client.) We're just enforcing a looser
version of the
same property here.

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 9 Mar 2011 16:15:08 +0100

On Tue, Mar 8, 2011 at 3:00 PM, Eric Rescorla <[email-masked]> wrote:

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Mar 2011 07:40:28 -0800

On Wed, Mar 9, 2011 at 7:15 AM, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> 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.

> 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