Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

Achim Kraus <achimkraus@gmx.net> Sat, 24 October 2020 06:56 UTC

Return-Path: <achimkraus@gmx.net>
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 F1EFC3A09D7; Fri, 23 Oct 2020 23:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.347
X-Spam-Level:
X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 DZBbACPMGBUl; Fri, 23 Oct 2020 23:56:17 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8EE3A09C3; Fri, 23 Oct 2020 23:56:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1603522570; bh=bsmpd3tYwSkvK6rR231ydd9cddOxe84x7Wg6YDEM5mk=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Raiu/XUpCetHfyyK5TN1L+klAvhB83KXWWzSjvb0TbBMmY4OzRr1NJ1fzn4kFNyOL uS5N/1nA9pNlRhEozpf9d525zr/U6iOxjD5wl8VrdmXPUwhgnTkmSLAz+WG3mBlrtF 1AqwJCY9hDCHApTkboqDXs7ilbSpuZkoz6s4uMZk=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.100] ([94.216.242.80]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M1poA-1kYQOQ0sTg-002GsB; Sat, 24 Oct 2020 08:56:10 +0200
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: "tls@ietf.org" <tls@ietf.org>, draft-ietf-tls-dtls-connection-id@ietf.org
References: <fe7eab66-a14a-5f18-46be-7bae471c3b20@gmx.net> <CAOgPGoBWRyqQUNk3JQx2_Cna-7s-A7gENVwW-sh8+tRoJ_=V_Q@mail.gmail.com> <13a821d3-30cc-94b8-842c-22a87d280f09@gmx.net> <CACsn0cn4QcnaoocQeoiUXgGoAvfOs+1+Ei76z1Kuq8MMqNEh3Q@mail.gmail.com> <0327abb0-6317-b848-28d0-1fc50f4bf50e@gmx.net> <20201012200548.GD1212@kduck.mit.edu> <bab402e6-3353-d750-a849-21c91081f94e@gmx.net> <20201014212428.GP50845@kduck.mit.edu> <a7110178-6220-175e-869d-fcc44400f773@gmx.net> <CABcZeBNocUYZO9yxuG-DYh33ss+Dum1EOxHYEdww5OCR=rKFXw@mail.gmail.com> <20201024021316.GN39170@kduck.mit.edu>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <082806e2-5ff2-61d3-e181-31e50daef7f2@gmx.net>
Date: Sat, 24 Oct 2020 08:56:08 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20201024021316.GN39170@kduck.mit.edu>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:M9ON6EtpbXunGNEn0b9fbEGyLugKu4pZCZ38h305xMILkxMfKzM ZLJLJXrpL39QPgiIkubd429WRnDeyJH4JB2C2jTTEl8x8DH20qgAFeoB01mT+pmkcUoPsqD MaDm1YodFKAiWMmn6WwQiRFQj5lmZHfHRsqAPc8Q5wq/7jigyDESLyFGV8FG50lT+BqTpwt ucOChctAzVXPUlPlQnAGQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:n2lQYAknCAA=:b407EmFIK2pbCeQjUraY5q MTpGzjedsRoGGXoOny6u0UwtQ4C4WnnUAJXAOMeHrFDY7FJf7PfkVxtVGHaLRXhPT9BvsgzI0 GqHNrQthIoPrTgX9iKuMsFhMfPmdzXc10ZTqr2NDeXjq0cWbxCHAlAvBSW2Ost0IFmucd4r8z i1VsjsI8lqDYwOzXkLQUW2xWWAVKlFvh+QOYlJ4jz17G6eDRLSGqN5ueTwBlP9+21vl611Yl3 nSydBtbdFRWhvw+cCyy/o5B1//q11UGFi1meyjRMY9ODglGZzvdO8/+AiHRHq1rSPmrRcbMOS YTTSNigza7XqwPZKcrtac8sYqG4mt5Ra07niQJ40iJ+3QS4QZSDB0vK0p8n3lK3sjb700apmR ebCjFffCEqx9sxKpSelgF/2bg+4he/NBlcxhXDvMCZSkngofFooFRFLuuV60VA951osYUcpvX Lu860EK3PHubljRy7GpjBXFaFPdSdztMVP19OQoWjT0bQDZpRi74H1vSdg/hkDT0SLth5LkGj RHIxw2EQgwqrgDTlk9zWr6RGmsx3b8/qEWym4jfNG8fPgA9mp5yvGkFc4+UQnrJI7LYizxa6J HCbObQZqknHudY5FmoXiRF+RSWlbGCpXKtCLwKYtO/dmuAbC8lTRibeuE5Lhi97qcy/LAUvwu 9nmqKriuk+aRE8PhKHsS/b1ZQv8DwJpW7I3DPyRVVgkNhf2H8OfCB7yY1IleOOAkCz9cVH24Q IowTJVJOMGBDWo7sVL+Lfhppuc5nN0HJ1EePWot4wmEfvO8dV2YuU0S3vGonr09EMCg7iWDgz jGzae+K3ncGAliAFUJbVFYoTqmKKENsWgtxkIfX5vt5+teIbf+sLSlBd8EvKAvOQJU8XG15Tr a33QPENtqvcObFLo8jWg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/t-qjvXP_FwfON2zwKr8g6igN4As>
Subject: Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07
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: Sat, 24 Oct 2020 06:56:19 -0000

Hi Ben,

>>     Because each party sends the value in the "connection_id" extension
>>     it wants to receive as a CID in encrypted records, it is possible for
>>     an endpoint to use a globally constant length for such connection
>>     identifiers.  This can in turn ease parsing and connection lookup,
>>     for example by having the length in question be a compile-time
>>     constant.  Implementations, which want to use variable-length CIDs,
>>     are responsible for constructing the CID in such a way that its
>>     length can be determined on reception.  Such implementations must
>>     still be able to send CIDs of different length to other parties.
>>     Note that there is no CID length information included in the record
>>     itself.
>
> ...and thanks for the reminder about how we say so in the text already.

(your example from a previous e-mail)

 > Attempting to construct a trivial example on the fly, (hex)

 > 01 01 02 02 01 <513 bytes of plaintext content>

 > could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202,
 > DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be
 > cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201,
 > DTLSInnerPlaintext.content = <513 bytes>.

I would feel much more comfortable, if you state,
that you consider now either

1. that example was not compliant to the draft,

or

2. the draft is not clear enough about that.

If 1. is true, https://github.com/tlswg/dtls-conn-id/issues/76 could be
closed.

best regards
Achim Kraus