Subject: [TLS] draft-rescorla-dtls-05.txt

From: Rob Dugal <[email-masked]>
Date: Thu, 10 Nov 2005 08:51:37 -0500

How does DTLS handle datagrams containing application data that are lost 
or delivered out of order? 
The draft seems to indicate that only handshake messages are subject to 
re-transmission, timeouts, and re-ordering. 

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: [email-masked]
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 10 Nov 2005 07:17:13 -0800

> re-transmission, timeouts, and re-ordering. 

That's correct. The philosophy here is to provide an interface that's
as much like that provided by normal datagram transport protocols as
possible. Those protocols don't take care of this stuff for application
data, so neither does DTLS.

-Ekr

---

From: Rob Dugal <[email-masked]>
Date: Mon, 14 Nov 2005 07:14:13 -0500

Another question:

If only handshake messages have a message sequence number, how can the 
record layer determine the correct order of a ChangeCipherSpec or Alert
when some records are lost?  Why not add an MSN to these too, making it 
clear what the order of the CCS/Alert is in relation to the handshake 
messages?

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Nov 2005 07:57:27 -0800

Rob Dugal <[email-masked]> writes:
> when some records are lost?
> Why not add an MSN to these too, making it 

All messages have a sequence number. The handshake messages have
a second sequence number to assist in reassembly.

-Ekr

---

From: Rob Dugal <[email-masked]>
Date: Mon, 14 Nov 2005 11:33:42 -0500

> a second sequence number to assist in reassembly.

Ok I understand that all records have a record sequence number and 
handshake messages have a message sequence number. But suppose the peer 
sends a number of handshake messages plus the ChangeCipherSpec, and 
suppose everything is lost except the ChangeCipherSpec. I know there are 
some lost records based on the RSNs
but I don't know how many handshake messages are lost. There could be 
multiple messages in each record or the messages could be fragmented 
across multiple records so the number of lost records doesn't tell me 
much.

It seems to me that if you included an MSN in the ChangeCipherSpec & 
Alerts I could tell exactly how many handshake messages are lost. This 
would make it easier for me to sort through the re-transmitted messages 
and determine exactly when I am back in sync.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Nov 2005 09:14:06 -0800

> across multiple records so the number of lost records doesn't tell me 

Well, sort of. In general, it's unambiguous about what messages should
be sent in the State Machine. However, recall that the Finished
message contains the HSN as well, so you can count backwards to see if
any messages were lost.  And if you don't have enough information to
process the CCS/Finished, then you absolutely know messages were lost.

> and determine exactly when I am back in sync.

Yes, this would make things a bit easier, but at the cost of substantial
additional complexity, IMO. 

-Ekr

---

From: Rob Dugal <[email-masked]>
Date: Mon, 14 Nov 2005 13:34:20 -0500

Eric Rescorla <[email-masked]> wrote on 11/14/2005 12:14:06 PM:

> be sent in the State Machine. 

That's not always true. I recently looked at the salowey extension for 
resuming with a session ticket. It is impossible to know if the server is 
resuming until you receive the ChangeCipherSpec message. And the server 
could decide to resume but issue a new session ticket which you won't know 
until you receive the ticket.
I don't know if anyone will wish to use this extension with DTLS but the 
way you wrote the draft implies (to me) that DTLS should support any of 
the extensions supported by TLS.

> However, recall that the Finished

> additional complexity, IMO. 

Why would you say this would add substantial complexity?
You already have to handle the MSN with handshake messages so adding it to 
CCS/Alert shouldn't add much.
And it will substantially simplify the task of determining when messages 
are lost and how to figure out the order of a CCS/Alert when you receive 
re-transmitted messages.

---

From: nagendra modadugu <[email-masked]>
Date: Mon, 14 Nov 2005 11:20:38 -0800

> across multiple records so the number of lost records doesn't tell me 

Actually you can tell -- there are only two possible scenarios for the 
situation you describe:

(1) Client receives ChangeCipherSpec.  This implies that there were no
    missing handshake messages:  ChangeCipherSpec is the first message from
    Flight 6 (page 16 of the draft.)
(2) Server receives ChangeCipherSpec.  No more than three handshake messages
    could be missing: Certificate, ClientKeyExchange, and CertificateVerify.
    The server cannot proceed if necessary messages are missing, and the usual
    retransmission strategy is employed.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Nov 2005 17:44:05 -0800

> the extensions supported by TLS.

I agree that this is a valuable goal, but I don't agree with your
interpretation of the ticket spec. You absolutely know that you need
to receive *some* message after the ServerHello, so until you get that
the CSS is of no value to you. And once you get that message, it's either
a Certificate, SKE, or a SessionTicket, and you know how many messages
you need to receive--or rather what the last message of the flight will 
be. Why is this problematic? 

And as noted previously, you can always tell what's up when you
see the Finished message, since you need to see all the messages
in order to compute the Finished.verify.

> CCS/Alert shouldn't add much.

It's a matter of layer clarity. CCS isn't part of the handshake layer
(IMO a bad design choice, but it's the one we have) and neither is the
Alert protocol. I don't want to mix the layers.

-Ekr

---

From: Rob Dugal <[email-masked]>
Date: Wed, 16 Nov 2005 09:23:39 -0500

[email-masked] wrote on 11/14/2005 08:44:05 PM:

> >> >> > If only handshake messages have a message sequence number, how 
can 
> > the 
> >> >
> >> >> > record layer determine the correct order of a ChangeCipherSpec 
or 
> >> > Alert

> >> > suppose everything is lost except the ChangeCipherSpec. I know 
there 
> > are 

> be. Why is this problematic? 

When resuming, draft-salowey-tls-ticket-05.txt says that the server may 
issue an optional 
SessionTicket after the ServerHello. So there are 2 possabilities:

(A)
         ClientHello
         (SessionTicket extension)      -------->
                                                          ServerHello
                                                   [ChangeCipherSpec]
                                       <--------             Finished
         [ChangeCipherSpec]
         Finished                      -------->
         Application Data              <------->     Application Data

(B)
         ClientHello
         (SessionTicket extension)      -------->
                                                          ServerHello
                                                        SessionTicket
                                                   [ChangeCipherSpec]
                                       <--------             Finished
         [ChangeCipherSpec]
         Finished                      -------->
         Application Data              <------->     Application Data

Suppose the server does case (B). Assume the MTU is large enough that the 
ServerHello and SessionTicket fit into a single record. So the Server 
transmits 3 records: ServerHello+SessionTicket, CCS, Finished.
Suppose the client only receives CCS and Finished records. It will know 
there is a lost record by the RSN but it doesn't know that record has 2 
handshake messages. Now suppose the server retransmits the ServerHello, 
CCS, and Finished messages. Just to make things a little complex suppose 
the server uses a much smaller MTU estimate, fragmenting the ServerHello 
into 2 records and fragmenting the SessionTicket into 2 records. Now 
suppose the client receives only the 2 records containing the ServerHello. 
The RSNs indicate to the client that records were lost but tells nothing 
about how many messages.
How does the client know that there is still a missing SessionTicket 
message? 
It cannot look at the MSN in the Finished message because the message is 
encrypted.
It cannot rely on the RSNs to tell how many messages should have been 
received.
It has received a ServerHello, CCS, and Finished message which looks like 
it could be the message flights from case (A). If the record layer were to 
pass only these 3 messages to the handshake layer the handshake will fail 
because the message hashes won't be correct.

Am I missing something?
On the other hand if the CCS had an MSN I would immediately know exactly 1 
handshake message is missing.

> in order to compute the Finished.verify.

The Finished message is encrypted so I cannot look at the MSN until the 
handshake layer has received the ChangeCipherSpec. The record layer will 
not deliver the CCS to the handshake layer until it has determined that it 
has received the entire flight of messages. So I don't see how the 
Finished message can tell me if I have received the entire flight of 
messages.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Nov 2005 07:55:58 -0800

>          Application Data              <------->     Application Data

I don't read this the same way as you do. The way I read it is that the 
SessionTicket is the signal that the server wishes to resume. If it's
not sent, the server does a full handshake.
> Finished message can tell me if I have received the entire flight of 

I think you're thinking at the wrong layer here. The handshake layer
is responsible for reliability here. And it *does* get the CCS and
the Finished and (even in your interpretation of -ticket) is able
to decrypt them and can then determine whether things were in order.

-Ekr

---

From: Rob Dugal <[email-masked]>
Date: Wed, 16 Nov 2005 15:11:23 -0500

Eric Rescorla <[email-masked]> wrote on 11/16/2005 10:55:58 AM:

> >> >> > handshake messages have a message sequence number. But suppose 
the 
> >> > peer 
> >> >> > but I don't know how many handshake messages are lost. There 
could 
> > be 
> >> >> > across multiple records so the number of lost records doesn't 
tell 
> > me 
> >> > resuming with a session ticket. It is impossible to know if the 
server 
> > is 
> >> > could decide to resume but issue a new session ticket which you 
won't 
> > know 
> >> > I don't know if anyone will wish to use this extension with DTLS 
but 
> > the 
> >> > way you wrote the draft implies (to me) that DTLS should support 
any 
> > of 

We will have to get Joe Salowey to clarify this because he also states: 
        "If the server successfully verifies the client's ticket then it 
may renew the
        ticket by including a SessionTicket handshake message after the 
ServerHello."

To me "may renew the ticket" implies that the SessionTicket is optional 
but that resumption can still take place.

> to decrypt them and can then determine whether things were in order.

Did you mean to say the record layer is responsible for reliability?
I think the record layer is responsible for ensuring that messages are 
transmitted and received reliably. Reliably means messages should be 
received by the handshake layer in the order of the original flight of 
messages sent by the peer.

My problem with the DTLS design deals with determining how to exit a 
waiting 
state as defined in point #3 of section 4.2.4

        3. The implementation receives the next flight of messages:
      if this is the final flight of messages the implementation
      transitions to FINISHED. If the implementation needs to
      send a new flight, it transitions to the PREPARING state.
      Partial reads (whether partial messages or only some of the
      messages in the flight) do not cause state transitions or
      timer resets.

Determing when you have received the complete next flight of messages is 
not trivial unless there were no loss of records. If some records were 
lost then the record layer must determine when it has the complete 
flight of messages through examining the contents of the messages 
themselves and by having some understanding of what messages are expected. 
 If I examine the ServerHello for a session id I will know whether the 
server is resuming and exactly how many messages to receive. If I look at 
the ciphersuite in the ServerHello I can tell if there will be a server 
key exchange message. If the client sent a certificate I can determine if 
a CertificateVerify message is expected. etc. I think SessionTicket is 
still a problem but let's wait for Joe Salowey to clear up the ambiguity 
in his draft.

To me this does not seem to be an ideal design for the record layer. I 
suggested adding an MSN to the ChangeCipherSpec message because I think it 
would make it clear how many handshake messages appear before 
the ChangeCipherSpec and would make it simpler for the record layer to 
determine when it has received the complete set of messages belonging to 
the next flight.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Nov 2005 13:31:16 -0800

> but that resumption can still take place.
But then how would you know resumption was taking place?

> messages sent by the peer.

No, absolutely not. The record layer just hands over the packets in whatever
order it gets them. The only layer that knows about reliability is
the handshake layer.

> determine when it has received the complete set of messages belonging to 

Again, I don't see the problem here. TLS (and DTLS) are lock-step
protocols. In order to know when you're done you *always* need
to know what messages to expect in a flight, whether it's TCP or
UDP. If Salowey's design doesn't include that, then there's
a problem because you need to feed messages into the Finished
hash in order and so they can't cross in flight.

-Ekr

---

From: Rob Dugal <[email-masked]>
Date: Thu, 17 Nov 2005 07:16:59 -0500

> But then how would you know resumption was taking place?

You tell if the server is resuming by receiving either 
ServerHello+SessionTicket+ChangeCipherSpec or
ServerHello+ChangeCipherSpec. 

> order it gets them. The only layer that knows about reliability is

Ok, I see where our difference in understanding is then. 
In your draft this statement from 3.2 had me believing that the record 
layer will be responsible
for ensuring that the messages are delivered to the handshake layer in the 
correct order.

3.2. Providing Reliability for Handshake

   The TLS handshake is a lockstep cryptographic handshake.
   Messages must be transmitted and received in a defined order
   and any other order is an error. Clearly, this is incompatible
   with reordering and message loss. In addition, TLS handshake
   messages are potentially larger than any given datagram, thus
   creating the problem of fragmentation. DTLS must provide fixes
   for both these problems.

In TLS, TCP ensures that the record layer delivers all the messages, 
including ChangeCipherSpec, in order to the handshake layer. I thought 
that the DTLS record layer would then also ensure that it delivers all the 
messages in order to the handshake layer. By adding an MSN to the 
ChangeCipherSpec the record layer would be able to do this easily. When 
the record layer reads a record it can buffer the record until it gets the 
next expected MSN and until it gets all the fragments for that message. 
The ChangeCipherSpec would then look pretty much like just another 
handshake record, except that it has no message data. I think this would 
also mean fewer changes in the handshake layer because now it receives 
messages in the same order as it would for TLS and all it has to do is 
handle differences in the message header.

> hash in order and so they can't cross in flight.

I don't think there is any major problem with the salowey design as far as 
using it in TLS, I have implemented it.  I don't believe I can implement 
it in DTLS though because of the lack of an MSN in the ChangeCipherSpec.
After a ServerHelloDone I don't know if I will get 
SessionTicket+ChangeCipherSpec or just ChangeCipherSpec so
I don't know how to determine if I lost the SessionTicket until I actually 
process the Finished message, and at that point it will be too late and 
the handshake will fail.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Nov 2005 07:39:47 -0800

> ServerHello+ChangeCipherSpec. 

I see your point, but arguably the CSS isn't part of the Handshake
state machine so I'd prefer to see cipher suites had explicit
messaging of this kind of state.

> handle differences in the message header.

Well, this is certainly one potential design, but it's not the one
that DTLS uses. The rationale for this is cleaner architectural
separation between the protocol layers.

> process the Finished message, and at that point it will be too late and 

Why would it fail? You compute the new cipher state, decrypt the
Finished message, look at the MSN, and then when it's not ready
yet, shove it into a buffer and wait for the next record.

One concern here might be that you've lost the old cipher
state but because of reordering you needed to keep it around for
a while anyway. That's what the "epoch" is for...

-Ekr