Subject: [TLS] DTLS retransmission problem

From: Robin Seggelmann <[email-masked]>
Date: Wed, 25 Feb 2009 12:17:07 +0100

While testing the retransmission functionallity of my DTLS  
implementation, I have found a problem which is not covered by the  
specification. The scenario is that client and server are performing  
an initial handshake and the ChangeCipherSpec/Finished flight of the  
server gets lost. The handshake will look like this:

ClientHello
ServerHello, Certificate, Certificate Request, ServerHelloDone
Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec,  
Finished
ChangeCipherSpec (Epoch: 0, Seq: 4), Finished (Epoch: 1, Seq: 0) -->  
got lost

The client will discover a timeout because its last flight has not  
been acknowledged and starts to retransmit:

Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec,  
Finished

The server then also repeats its last flight:

ChangeCipherSpec (Epoch: 0, Seq: 1), Finished (Epoch: 1, Seq: 2)

The client discards the repeated ChangeCipherSpec because the replay  
check fails. There already was a message with sequence number 1 at  
epoch 0, the Certificate. The sequence number has been reset to 0  
after sending the ChangeCipherSpec and retransmissions have to get a  
new sequence number according to the specification. To solve this,  
there has to be an exception for retransmitted ChangeCipherSpecs.  
Either the rule to reset the sequence numbers or the rule to use a new  
sequence number for every retransmission has to be ignored. In the  
first case an increased number of the old epoch (5 in the example  
above) would be used. In the latter case the same sequence number (4  
here) would be used again. Just accepting ChangeCipherSpecs with  
already used sequence numbers would be a security risk.

In this case the client is still awaiting the ChangeCipherSpec and  
retransmits again. This results in an inifite loop until the maximum  
number of timeouts is reached and the connection is dropped.

Best regards,
Robin

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 25 Feb 2009 13:09:52 +0100

Hi Robin,

a comment in-line.

Best regards
Michael

> ChangeCipherSpec (Epoch: 0, Seq: 1), Finished (Epoch: 1, Seq: 2)
I would expect it to be
ChangeCipherSpec (Epoch: 0, Seq: 5), Finished (Epoch: 1, Seq: 1)

Can you provide a pointer to the text which is describing the  
behaviour you
saw in the OpenSLL implementation?
> Either the rule to reset the sequence numbers or the rule to use a  
> new sequence number for every retransmission has to be ignored. In  
> the first case an increased number of the old epoch (5 in the  
> example above) would be used. In the latter case the same sequence  
> number (4 here) would be used again. Just accepting  
> ChangeCipherSpecs with already used sequence numbers would be a  
> security risk.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 25 Feb 2009 16:25:38 +0100

Dear all,

I had a look at
http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4347-bis-01.txt
and think the text gives the impression that you have only one
sequence_number variable.

I think this is wrong, one should have (conceptually) one  
sequence_number
per epoch. When retransmitting records, one should use for the
retransmission a new sequence_number from the epoch of initial  
transmission.
Of course, one should also use the same set of algorithms for the
retransmission as was used for the initial transmission.

Do you agree? If yes, I think we need to add some text...

Best regards
Michael

On Feb 25, 2009, at 1:09 PM, Michael Tüxen wrote:

>> specification. The scenario is that client and server are  
>> performing an initial handshake and the ChangeCipherSpec/Finished  
>> flight of the server gets lost. The handshake will look like this:
>>
>> ClientHello
>> Certificate, ClientKeyExchange, CertificateVerify,  
>> ChangeCipherSpec, Finished
>> ChangeCipherSpec (Epoch: 0, Seq: 4), Finished (Epoch: 1, Seq: 0) -- 
>> > got lost
>>
>> Certificate, ClientKeyExchange, CertificateVerify,  
>> ChangeCipherSpec, Finished
>>
>> The client discards the repeated ChangeCipherSpec because the  
>> replay check fails. There already was a message with sequence  
>> number 1 at epoch 0, the Certificate. The sequence number has been  
>> reset to 0 after sending the ChangeCipherSpec and retransmissions  
>> have to get a new sequence number according to the specification.  
>> To solve this, there has to be an exception for retransmitted  
>> ChangeCipherSpecs. Either the rule to reset the sequence numbers or  
>> the rule to use a new sequence number for every retransmission has  
>> to be ignored. In the first case an increased number of the old  
>> epoch (5 in the example above) would be used. In the latter case  
>> the same sequence number (4 here) would be used again. Just  
>> accepting ChangeCipherSpecs with already used sequence numbers  
>> would be a security risk.
>>
>> retransmits again. This results in an inifite loop until the  
>> maximum number of timeouts is reached and the connection is dropped.
>>
>> Best regards,
>> Robin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Feb 2009 07:59:55 -0800

At Wed, 25 Feb 2009 16:25:38 +0100,
Michael Tüxen wrote:
> per epoch.

Agreed.

> When retransmitting records, one should use for the

Yep.

> Do you agree? If yes, I think we need to add some text...

OK. I can do that, but if you want to contribute some, I wouldn't
complain :)

-Ekr