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

Xuan k <kxuanobj@gmail.com> Thu, 28 November 2019 07:16 UTC

Return-Path: <kxuanobj@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997D9120C61 for <tls@ietfa.amsl.com>; Wed, 27 Nov 2019 23:16:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paWetKAVLYzJ for <tls@ietfa.amsl.com>; Wed, 27 Nov 2019 23:16:16 -0800 (PST)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E5F120C62 for <tls@ietf.org>; Wed, 27 Nov 2019 23:16:16 -0800 (PST)
Received: by mail-vs1-xe2c.google.com with SMTP id y195so3106645vsy.5 for <tls@ietf.org>; Wed, 27 Nov 2019 23:16:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GhLWwDx1su25KMizyw4oLWcEgBw99S3k5NCNxrih3IA=; b=DicQvLklEEvl/9e5ia1OUbAj0SoXSGDnShE4jliFC0CzTg/k8X9CDF3SHoqH/Y98hi XgWg2ebgu7LzzsS9hqpQsLaO9PsY5zSHtx1TErSJ5tr/htwTVD5lrPTAOYL12xMTaHf3 qTtB94I/MovMsW1WID1jroDR1Rbrz6Tt1NYiJn8vtIKWdqF9S1QkcwrCVOs88yNIRS7V 4TjxrEcVl4BMrn6Oc8rMZL1/FVR95y9O8fll/Jz4byASxhngK46N5A3ix3hqWzZYgFQl Mvi3KAVSq6zTHu3O0d3NlHFb3r8nRtJvr1g0FqWKLP4EgpaWDE7sf04piXbFxyGkgtOl 5SGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GhLWwDx1su25KMizyw4oLWcEgBw99S3k5NCNxrih3IA=; b=Il68LV+xSE0m9/kjXzNxk2tfbRcHmgnGJdt55pHNLnaOalvZTalt9X4kE+wyzzZXH5 30sQ7UeerwMcI7vueWYkY++VCeKsEAnGtnMX/qsi/1J10mzkCnn8JIROjlDy7WcbJZxk TM9VegrR2rJNvhKwb1rO3rmpdT3NkmDJtL/SaR5TM8ti2BjUedszky67tm7vezjT+Jj0 iNpp52zjCahCxeuE4EXLnROG270bN2nVzfxJ/dii8UmiJgjytK4MTVewcqjq/mf4QNyL PUkeeOcvOuDykFPI6L3tDKklV+rYH/pP9WrrKcqMhaWyZJGy1JlHyGuCJuO3QWoNNht7 G4FQ==
X-Gm-Message-State: APjAAAUQtmecBmr+GLIzoM4mbCQZj8pW8eR5Ge3QJyZYmglUTOi9H5ZZ LyqHg2+cAyat5j3knR2t9MIPanZvy8AgNx1LNk/iMRuS8TQ=
X-Google-Smtp-Source: APXvYqyfftMxbLmWq788YI9Ir7gFxi55mQJdbxVHpkTtf0KgtFCVUIm5ML98vDo3EXgiqaItQEdfbsdIaBR4VXV9GPk=
X-Received: by 2002:a67:d396:: with SMTP id b22mr7240917vsj.195.1574925374829; Wed, 27 Nov 2019 23:16:14 -0800 (PST)
MIME-Version: 1.0
References: <CAAnY7J27g1Df0XBe1U66z98ThQgRaom1YBF9k2UGTi4YL9i+Ng@mail.gmail.com> <CABcZeBOuJ3bOKOt6vFRJzOZbwkXzZK0jUJNyAxeAmkpxQJCzzA@mail.gmail.com>
In-Reply-To: <CABcZeBOuJ3bOKOt6vFRJzOZbwkXzZK0jUJNyAxeAmkpxQJCzzA@mail.gmail.com>
From: Xuan k <kxuanobj@gmail.com>
Date: Thu, 28 Nov 2019 15:15:38 +0800
Message-ID: <CAAnY7J0z_btrQYzGtZavQqJwrEJ6H-+tho7xqhy9Y6RM6atv+Q@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000083c58b059862e3f9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/U0hBBYKAK8MstH-9qtWBNYTnRvY>
Subject: Re: [TLS] [DTLS1.3]About the retransmission of Handshake records
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Nov 2019 07:16:18 -0000

 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:



On Tue, Nov 26, 2019 at 10:05 PM Xuan k <kxuanobj@gmail.com>; 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.
>

Yes.

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

-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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>