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

Eric Rescorla <> Wed, 27 November 2019 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A98D6120AC1 for <>; Wed, 27 Nov 2019 13:37:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MZKjse8QtZ0N for <>; Wed, 27 Nov 2019 13:37:50 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31DA51209E3 for <>; Wed, 27 Nov 2019 13:37:50 -0800 (PST)
Received: by with SMTP id d5so26105735ljl.4 for <>; Wed, 27 Nov 2019 13:37:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hQOGlchDPccE9g9J3xWgfxZzttllpUu0S70IYu6g3qY=; b=QTiuZ0TLiRpjymUkLJu2eywUf8wQdKFRRI9bgmNJnr8Bxf23V/qtfL8VWOuJlxTtQ7 O/3xDnYXkIGu/zICYPnW1ZJWyuT9cxysNg8Dq4HmbJoJiolyqg8G/pTgXO8Nckz0GHdh SEMvLysm5vuEK+Zh86cdVRL3ZZYqcfQEDl9oTrm6s+f5eE0A3yoLK/gTqtHkU4IlnSl7 hSnj0ohRbCLl4vxN7ssJBom56u18XI5qNU6vpOwlG6t9RsjQcZ3mGqlXll9FK98e3k3q JKG0Ek+griozWKbhIlu25/UN0iWDpA5XyL7+6mzFDhso58r5QurEWNnnsJ95qVX2TOnV Z+aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hQOGlchDPccE9g9J3xWgfxZzttllpUu0S70IYu6g3qY=; b=oCihXCqHNajtQC9zPdQ/bAm2NFK2sbO2sexODHO+xJFGKiW4Zb+mjdmhia1pCCK/rY 3675hZCxumo1HG2Zd30o1lu2fNdDdSDrd/x626k1wmVvxxJIYgZpsqRWJ/lNjbMF4Hi+ +bRl6v6gx+FmzljIsHU9tMcVQutKhEpad3CQxIKxNJvwx6XEEmOjK/X6/3DUPlZyBG9X uXaNs1RykIhoqIZvqqURKQtUNdkvo0QS9xIaxywcQabrDFIE7vkjkQ/4911MPF9j+PIK bdO1s3UDvCV01cC60O3vJW45/atBJBwKwgY00jXnlpTq3lEIp8dX58sDcFvkA2+Vufah NFZw==
X-Gm-Message-State: APjAAAUOJvZte6+pNtqRjwWzeCRJqelE+B+q0E6ms+0OM5Q3ooN1vpxB U0pj8I/T+17WsifK3tonYUahtswG0NqLyZ/ZwsA0gQ==
X-Google-Smtp-Source: APXvYqzReae0e+BmA5S59DnJ01yJ7r9lUHganWghu3Aw8TgIBimNIj18LRLFBy80CyeVaTx58gRTeD/rs1/Fxv4SYn0=
X-Received: by 2002:a2e:9842:: with SMTP id e2mr31939623ljj.93.1574890668453; Wed, 27 Nov 2019 13:37:48 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Wed, 27 Nov 2019 13:37:12 -0800
Message-ID: <>
To: Xuan k <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="000000000000da89c205985ace63"
Archived-At: <>
Subject: Re: [TLS] [DTLS1.3]About the retransmission of Handshake records
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Nov 2019 21:37:53 -0000

On Tue, Nov 26, 2019 at 10:05 PM Xuan k <> wrote:

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

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

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

Yes, that's how it works in NSS.

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,

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


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