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

Achim Kraus <achimkraus@gmx.net> Sun, 11 October 2020 06:26 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 1E8EA3A0F09; Sat, 10 Oct 2020 23:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level:
X-Spam-Status: No, score=-2.312 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, URIBL_BLOCKED=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 UEgXUzxykB6e; Sat, 10 Oct 2020 23:26:56 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 DBD243A0F08; Sat, 10 Oct 2020 23:26:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602397610; bh=oxb0NooCTcwKCSAHWQDzB4OlKgy88N4NifHwb40rT5Q=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=VzlTRyp7Q1+zNNb7RUoa3y0jxkTudeX2CSekNlGqJ9Eljl/lppPikBd1xPfMoIjg+ nrB9jU11nPcbYRX+KttV5soZZQOfUzRe8qHo4Id4VwB+182MtvEvlvbVFchF+39qV2 0UzpJEm6r34eIHK6fFa0tEptEXtQs3E6sbI8roP0=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.100] ([88.64.90.178]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MhU9Z-1jwIrx0te7-00eZJ7; Sun, 11 Oct 2020 08:26:50 +0200
To: Joseph Salowey <joe@salowey.net>
Cc: Benjamin Kaduk <kaduk@mit.edu>, 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> <fe7eab66-a14a-5f18-46be-7bae471c3b20@gmx.net> <CAOgPGoBWRyqQUNk3JQx2_Cna-7s-A7gENVwW-sh8+tRoJ_=V_Q@mail.gmail.com>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <13a821d3-30cc-94b8-842c-22a87d280f09@gmx.net>
Date: Sun, 11 Oct 2020 08:26:47 +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: <CAOgPGoBWRyqQUNk3JQx2_Cna-7s-A7gENVwW-sh8+tRoJ_=V_Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:ZGnGTxIiDmFEI3U111GNdrmvtOZsm5KiZW0Pr0JqCIUUTa8Cx5x Cdb1QgNWYre0jiF8oYjkSksMRyaIcaP4t0RdQ7+7akkA2TwtPbmFi/xjg85rgaOsQxHmz8g sIAv/hkzLQs8ANUymcZzRXdHeIrpw9+jQv0PC3K2ZVdfmGFlD1FMCpGss/yIyMk6T0/BAEK MCNWbSo/M0Q7QSIu/gkzw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:+9goszpCuIs=:nWcqAAPm2k30hY/vjC/nJD l4fzbkMA+oXFGAm821uVg0cIjthWQXq+vemX7IPrnqCvtHSA8DXRNWaCQU46dLGP1EcyyEEzC pZOnNr92w3vuFo1Ftgyil7MOPoNirqEVRA9c2XdgVUmKxyeW3PS9uWH84BUD2Q1SoCqsvLjNm HK71nXIPUOXWbHss/SQuXn0ayW4EINhv3d1RzAnWXXkmq+Cf5kF7EdkUeysdDWbpformDGibr wZby75T6SkGsZtukP9lEBHwnuqnU9bE3Coi1SkKJDPgnrkStby7+0cqFOhFsuXdMHPH27PZnv gw5UYASslZha2N78qpEZeGUn4vKt0x3Bve+CafcrJ5RhYY9Y1cO03QazieUWvb9BimQqIk0iL D+9iCLHLQ4/8clpygo5M/ot2crH4fPH8pXWDABmzJL55gSCwJDob1QuPgs/e/8BH5snsdaulg 8Sv2FBM1tQ9rsCErdjEy9iSCcylR1xhUBGwFWGvYFc5eA9qjIUXa2a8ewTdSGHIxu9rppocPZ otxfYvSc7ppteAXZOwPO0hb+rkbJ/Ng6TavAxGyUkGjuE39olVp1IXxwlg+0UjVg+l22cjARs dEC/wv30mb79kznctwG78dNAot44VVodcJVxvhxm4Q/o9T0BbyxCZNrdGDVjefEyIVy6FKeQa 6CUfGiAse2PWN/OBXdlsOc6aSKU0R/vjTrwQ3Bc+37k9MYlgZEgu0pdXfZgdvRXljWTkiZgnG hDX8Q4QFRXS+NcdrGD9W2WL6b1rtzeYnX2bWZe7jw3Dvp72M2dBfKeWs0GdEkmnGnRHppugS6 hgROFmUusKXSju0RPedUW7KSC9eTPTJk7nOKg5WfpVp8kczb7BTfXvBAVWimU/ETCBUCISsDy 8xZA2vF1DKj1Pzrx4k+LywnH9XRejXOMRp0PmA76tUAh1VOa6+oA8TV1a5sbouRD5x91UKwSj YcfJsL4KkLdl59pzzFAWc/v9K/ifdvmvvMvCbQIhGPz8Fm04dCqQqXFn6lXvVWLE9ZejT9Obq yivTvMYD+BXknaUPnPc0ibruqypq6JRz45Zd9n+2zVBPL+icNN9/JMU5nB1j2En+4TUHgvemg wBHJrYzNnY1KVOeHC03xGFS3fLywIwUUuDGmSIQ1oFkNLycnEsVz+nD/pCHp7HuXRTZ3J77Qi cmwREyJxijr3pjkXNcGYvmrJYlxzkBCGQAKi3CnHV9nn4xcSIhlNs/xdCe1wjAKpjOcSFRKr3 REERO4nAtFMxEI2gtXm3Bsx/EwPVoQLZaGA72Zg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_dJNlGb-p5sFYj_K67-OFp2lhco>
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: Sun, 11 Oct 2020 06:26:58 -0000

Hi Joe,

 > [Joe]  It's unfortunate to find issues that require breaking change at
 > the end of the review cycle, especially for a draft that has taken a
 > long path to get here.   If there is an issue that is exploitable, even
 > in a corner case, someone will develop an attack, clever name, logo and
 > website and we will all have to scramble to deploy a fix.   It's better
 > to fix now rather than later.

Agreed, therefore I wrote at the begin of the discussion with Ben:

 >> I would prefer, if this is not changed again without strong
 >> arguments!

 > In this case, I don't have a way to
 > exploit this issue, but unless someone has a way to demonstrate that
 > this is not going to be an issue then I believe it is prudent to fix it
 > now.
 >

In my opinion, ONE change may be possible. A server may be configured to
use only the old, only the new, or both by "try on the client's finish".
I'm not happy with such "dirty" work-around. I would prefer to do so for
something more the "cryptographic hygiene".

So, if the MAC is considered to be adpated again, should it not be
discussed, why at all the cid-length should be put in?
I asked this already in January 2019

https://github.com/tlswg/dtls-conn-id/pull/29#discussion_r246654915

The MAC contains already a overall length. Even in that discussion, no
one mentioned the reason for adding it. So if there a doubts about
injection, why not remove it at all?

 > Would this issue have been caught by formal verification?

That may also be something to help, not to change still again and again.

best regards
Achim Kraus

Am 11.10.20 um 00:26 schrieb Joseph Salowey:
>
>
> On Sat, Oct 10, 2020 at 12:14 AM Achim Kraus <achimkraus@gmx.net
> <mailto:achimkraus@gmx.net>> wrote:
>
>     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 :-).
>
>
> [Joe]  It's unfortunate to find issues that require breaking change at
> the end of the review cycle, especially for a draft that has taken a
> long path to get here.   If there is an issue that is exploitable, even
> in a corner case, someone will develop an attack, clever name, logo and
> website and we will all have to scramble to deploy a fix.   It's better
> to fix now rather than later.   In this case, I don't have a way to
> exploit this issue, but unless someone has a way to demonstrate that
> this is not going to be an issue then I believe it is prudent to fix it
> now.
>
> Would this issue have been caught by formal verification?
>
>     best regards
>     Achim Kraus
>
>     _______________________________________________
>     TLS mailing list
>     TLS@ietf.org <mailto:TLS@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tls
>