Subject: [TLS] [DTLS1.3]About the retransmission of Handshake records

From: Xuan k <[email-masked]>
Date: Wed, 27 Nov 2019 13:06:42 +0800

Hi all,

I'm trying to implement a DTLS1.3 library for embedded devices. But It
seems something weird about retransmissions and ACKs.

In the section "5.2. DTLS Handshake Message Format":

   The first message each side transmits in each association always has
   message_seq = 0.  Whenever a new message is generated, the
   message_seq value is incremented by one.  When a message is
   retransmitted, the old *message_seq value is re-used*, i.e., not
   incremented.  From the perspective of the DTLS record layer, the
   retransmission is a new record.  This record will have a *new*
*   DTLSPlaintext.sequence_number* value.

In the section "7. ACK Message", the ACK message use the record_numbers
(corresponds to *DTLSPlaintext.sequence_number*).

For my understanding, the "message_seq" belongs to "Handshake" and the
"sequence_number" or "record_numbers" belongs to
record layer.

The retransmission detection is done by "Handshake" using "message_seq",
but the "acknowledge" is done by "record layer" using "record_numbers".
It is so weird.

The retransmission, retransmission detection and acknowledge should be done
in handshake process, but we need the record layer passing the
record_numebrs to the handshake process.

Since a new "sequence_number" is used for retransmission, we have to
maintain a "record_numbers" to "message_seq" map with dynamic size.
Each retransmission attempt creates a new relationship between a new
"record_numbers" to an old "message_seq".

Since ACK is only used with Handshake messages, is it possible that we use
"message_seq" in ACK messages?
Or we use *old* "sequence_number" for retransmission, so we do not need
maintain the dynamic map. And if replay detection is implemented, the
retransmitted
record can be dropped by record layer (by replay detection), the "Handshake
Protocol" do not need to do retransmission detection.

Thanks
Zhai Zhaoxuan

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Nov 2019 13:37:12 -0800

> "sequence_number" or "record_numbers" belongs to

Yes.

> but the "acknowledge" is done by "record layer" using "record_numbers".

Hmm... I don't think that this is particularly weird. This is, for
instance, how QUIC stream acknowledgement and retransmission works.

> "record_numbers" to an old "message_seq".

Yes, that's how it works in NSS.

> "message_seq" in ACK messages?
Or we use *old* "sequence_number" for retransmission,

Both of these give you strictly less information about the network. One of
the cool innovations in QUIC is to label each packet separately so you can
determine whether an ACK is an ACK of the original packet or a retransmit.
We are trying to inherit tha there

-Ekr

so we do not need maintain the dynamic map. And if replay detection is
> implemented, the retransmitted
> record can be dropped by record layer (by replay detection), the
> "Handshake Protocol" do not need to do retransmission detection.
>
> Thanks
> Zhai Zhaoxuan
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Xuan k <[email-masked]>
Date: Thu, 28 Nov 2019 15:15:38 +0800

Hi Ekr,

Thanks for your help.

I have another question about the "message_seq" in section "6. Example of
Handshake with Timeout and Retransmission".
Could you please explain it?

In the secion 6, the Client send message_seq = 0 in Record 0 and
message_seq = 2,3,4 in Record 2.

Why message_seq = 1 is skipped by Client?
I think the ClientHello in the figure should begin with message_seq=1. The
message_seq = 0 is used by the first ClientHello which is the one without
cookies.

Thanks,
Zhai Zhaoxuan

On 11/28/19 5:37 AM, Eric Rescorla wrote:

Yes.

-Ekr