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

Achim Kraus <achimkraus@gmx.net> Sat, 10 October 2020 07:14 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 41EA43A0D38; Sat, 10 Oct 2020 00:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.313
X-Spam-Level:
X-Spam-Status: No, score=-2.313 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.213, 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 Gv0-P_BtHSXD; Sat, 10 Oct 2020 00:14:01 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 A4E533A0D37; Sat, 10 Oct 2020 00:14:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602314033; bh=3m6amE+Krs5T4b49jXJA8a6sQ9NBZ7AOPYDHlFZAeuA=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=jlp9Hp+b4gBMNH+Mbr+9ubJxWa9jbcYPqvsmhPUAbNNgZF8mhJPsCYN16jGmI+anC NMO2SEES5NhXarjLRWvFrukmjey7j9d77tY6wXtoCqEdyG3cpklD0/0cuEDvff9eM0 RuJH7r5AhcWxLika9tND4+C5nDET9q7OGPL+C8m8=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.100] ([88.65.148.189]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MpDJX-1k8rPj3L27-00qiij; Sat, 10 Oct 2020 09:13:52 +0200
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: draft-ietf-tls-dtls-connection-id@ietf.org, "tls@ietf.org" <tls@ietf.org>
References: <0da9b525-ec78-bef5-6ceb-5f377019ade4@gmx.net> <4ca7c2f9-1e9d-0d16-0089-649f013b4565@gmx.net> <20201008233454.GF89563@kduck.mit.edu> <6185242d-8ba8-2d2f-5938-afad46c2e854@gmx.net> <20201009212240.GK89563@kduck.mit.edu>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <fe7eab66-a14a-5f18-46be-7bae471c3b20@gmx.net>
Date: Sat, 10 Oct 2020 09:13:51 +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: <20201009212240.GK89563@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:Q2VuK7N0galQ+FJrZwssPF2/WuMld3NXOLPK1ZGq/Lp6geYU3MP gFeb07ekZgSfY+of4unYpIfh+v7KDrp42bJCommBOI+HbwU37SlygOdg9sg3GOTYP+xFKl7 05bFeJVpA+8blfuZVlE6BxVo4TZSGL6iLqsEklmcq7EQ/pEWED6tu/5WDNI2dvGZf+TmN7R +OHB+A9IR3ViN6n4P8HIQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:PIoAXZ5grEQ=:kj+8ZXD+LFmOmoOFnsScAS pOgjdMYZ90sUQnyqSITlyfhhmBimsGeZe8HNaBTBwicPpwojy4oGlBgoRmTXhXTfHqpYltxD5 BYGsfbjb702QS3gXvS0K89+cs9PU2gPkjYlXYAlaEYctM1wXQuxlXgoOqgVT8qopz98lvEplT sWkj6oAScjVmPxb6UVmtvtGptO1sP6DjLiL+qSWr9bGvJnzCnH543S/Hv/6o75AhCgYRo0xAz blTJiNk+EpuGboE/GN3woW7QqtdP3jx8OYHr0GuMwuJOmu5pxibmzYL3gPI2cBmET2cZfvu0M XREp/+WPRKbwlT7izCn6R/NnQIyk3bE4a4Cfv7fCPBjkBqztbaM+1lrPR2cSpySfiWWn5xHxH hDa6DC61GLdDVXakE46uCR7d/Vsl20hQ7/CoVvgQmmuw14QL6anVa+krbjv9ndOscwEEqYPdq y9fUgvfs70Dwmzq/zyxww72OBLEeGUiTTL007RFIKE9RtJUjyAQ9Rc4C8014rErps96wZ6XgA ruxc1Zo1Mnd5ozrdRgGm0gxW+5gZbPnEYgRalmVO/LX/IA4+k5t46VtM3Vz1HHiP1jtVPw6Gw zAPv8NrdohaVM5gsfOw1cN9IjX4rHxu3aENEfAiHsPVqGk/pgq3AroPr+HPtZK1DRkMKVr9Om grmZU6ZSOkQTfr9fdi3CgF3yRjGbHkzyZi6UFUebRakCUXjbAwyoKK/ML42mnrP1UQ6TYfho2 VzdKo8bfVnayQ+SIIzRBuJCHBRneAt/kC5c0oOT65QB5ehD2PiP6Qms2AapdoBkZOwdtaWzxg IgSwz4aehB7shVWowyTBMn013cv4GjCHnQZCrEoMlZm4Pq88U/NiWdgmD8IxVS64LuFQ6GcCN 5vJI28CGlDGjz/q56HQg5pLg7+iRjr9rmArjT7twazee7lKxgJATPBe5CnqptKsqITC9pTm70 vBzrDGj22ahrqbNu5P8PEbspj77dJLpV+NQEuT8g++WE8Jo/WVttcRUWS1B7J1QpItFNvbJaz VvsSMWnXwF+myPTpHM7u0prW6fUnq8J276cCqvZpcQ4fsLwbtJheo5Hz4v4j9EuIu26WpxSxZ teiNjb5cLPrymNfXw69S8Hz9uO9FQ03r9na3rC1P0tS1Ua1CX5HEZ/MAe1a4at7bWzYV28lfz PeoGY5MUMRENvcQIjFk9lU9qBS9lf8F/X/fyJRChaTLTOxs19dHNpVEdPUC7hATdeD2tS5LIV Ty4OdJUnKDsvny5EVxGm5DcT537LlRZlNou6vWA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/d-jO6eO7mk8_mOPGqlBo3nnkYis>
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, 10 Oct 2020 07:14:02 -0000

Hi Ben,

>
> To be frank, I'm actually surprised that this is even seen as a matter for
> discussion.

As developer, I'm surprised, that this discussion now spans a couple of
years, starting on summer 2018 with:

https://github.com/tlswg/dtls-conn-id/issues/8

There are many (proposed) changes since then. I already tried to point
to that with my e-mail answer from 4. September

 >> That order was also discussed a lot.
 >> https://github.com/tlswg/dtls-conn-id/pull/29
 >> I would prefer, if this is not changed again without strong arguments!

For me, "cryptographic hygiene", which breaks the API, are not strong
arguments. Sure, that's only my personal opinion. I'm not sure, if a new
code-point helps, nor that a new one is emitted for changing a draft (I
would not recommend to do so, draft is a draft).

So let me try to find a end:
As developer, I see it's very important to come to a stable definition
of the MAC. If now the order of the cid/cid-length is changing the MAC
(again), and in half a year the next "cryptographic hygiene" campaign
removes the cid-length (because it's not on the header and some
(including me) don't see the benefit), then FMPOV this "process" just
demonstrates more weakness, than I appreciate.

So:
If there is a guideline for constructing MACs, is that guideline
documented somewhere?
If the guideline is changing over the time, are these changes documented?

And I would really welcome, also based on the experience with the long
history of this discussion, if more can give their feedback about
changing the MAC again. Please, this year, not next :-).

best regards
Achim Kraus