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

Achim Kraus <achimkraus@gmx.net> Tue, 13 October 2020 04:41 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 9A6D43A09F7; Mon, 12 Oct 2020 21:41:59 -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 HAKUJYAEMCmH; Mon, 12 Oct 2020 21:41:58 -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 A3FF03A0DFE; Mon, 12 Oct 2020 21:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602564112; bh=nqeO1TdU2B24GP0RivXKniMxouH5et7naGBQexXzueU=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Ae1eJ/l+b5XtmhVhEF+Qhu33S9ZQRe88W+iliydSRppohV42ooOXESfUS+FvmozFD YnJfay475+G8YPolDHIf0btwuji56RTzVqLraScqBOKV1Sn8g47ReevSGX6oA34mxT 5L+4iO0BoxELXSjQQcY0c0KkPKe0uKljO83yGROM=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.100] ([178.2.230.220]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MHoN2-1kenag1mMg-00EtKc; Tue, 13 Oct 2020 06:41:52 +0200
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Watson Ladd <watsonbladd@gmail.com>, Joseph Salowey <joe@salowey.net>, "tls@ietf.org" <tls@ietf.org>, draft-ietf-tls-dtls-connection-id@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> <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>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <bab402e6-3353-d750-a849-21c91081f94e@gmx.net>
Date: Tue, 13 Oct 2020 06:41:50 +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: <20201012200548.GD1212@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:lj6JxVfdQzEAhUyk3N3FdS00OhZKMnkOluzobUE33GOJ4/HZmPT +F4SQkTKflN4fRXKXoaplh5CESqQkLRDOeNRdm7Fbnv4gFAe0hp5nj01f6Lqs2QUf195tu6 lR3yUaDudEKd9gprgtfGcbLyIZavCYrNDsqRIMS7HmFkRpsG+mBfjMIFHsJUZJfoz79vgjp vfK3bBKeSYWAYVobOtBsA==
X-UI-Out-Filterresults: notjunk:1;V03:K0:7RmvnOPCGeY=:UknsYKbqmBtTTEzXsMWdga oFG18qJ7a1XRJVfjRbuWeb1VXd88zM55F6YH6hVf5IlFGR+/orfhmxw93mwW1oAW4PtcFlZ5N jmAfVMsMeIPqZI7JvmaHzk5TMwdg6t/USFLL2/Kef+kZh/w5H/LRmGHVkgNP400tkPZEGL6Gb qSiLxjm/BiXGF3ayIVb3W5u4uHiV1eFSCc8x0HKT7jJoUmJsW2ZD8EUTvPt1A+PZJKt+u4u96 jBe3/E2JVcxvzyjh3BmGFIPCBlFZZm7rxOUDe1BP4/AzizigRCF0ttT8iyeARi+NgbjVVM+nh hg1bBH9E/lHZsUG3n2K9J8wMr9v4WrIsoe68ibBQPtThtkn7n4dzLfvNaUxgYy5W7hQtEqmao HCT6mPlvO1YToG9FNDMc70qg9t30+ktP3Gm++xG2mNR4TkxV/TOVz3oJkD2XMZErN5yw1kn3K OTW8BDF8OWkJqLJ8F9qHg3KaQzIBbhuwXSQE9b2X9ZTbf4tO6hyaOsBQDB+AeS0Sc0jVQ94nB 1/Zfsx/Szyrlw0ZGyFGrkeJUrhI6Wg1Mwi5GbwHjw+BugBDRw94vpglsA/MwcVTzvF/VjOsro JVK3Mn89lT+4JDsS3i4SytA3QYHcU8JVZHXhI+xjWO2ZZvVvObHZWAcDffSyYD6EOxXxD1Yuv m+uAMiFtVehJEURNm/fKiygCLbwcWESAANAdpq2DMMbDmJY7H78zU+08GhxGfTYIgSPMOUJwy qf/Vextx5k5gb4Zvxlbqrh5GsX3Hy5gr20KhD4xMupPIc21JVu8G8M2NsgNAtnTx6aqiRO1bP MvmB7UrbNQWs4YkZ33GZOIBcWTtC5xWuObHjrpYqvF+kdtwkWJ9EyfF6VApOIKJbQ7y2zMCKZ T4xgiOmGBTyMwWFk605oFHD46NEx/Hx0wqWQ0oNjYUTTNh8xEYowyVNzF2v45tXR/stqXNnF2 79fURNl7q5OGGptY1KTqtrDZsTGG5k5UHMcz7H19GlMIuRfc7MefP1Rg9vKf/IY9VKlMVSj7f Zdoxr2rUsjinLqaHKAuzzwBj08V44INKH1jl+la6++JA+voLeAL07bjTvXVYOtPwSHjvi6XEz qOyRxXwARmY5YmQ2pfEDPcEEAbRe5OdDUQ1PYsKNNrvscmv+yfAXLTWI1wq+pvD1hkTPfPFxR YMeJUvCH8dZ1W/hlvd9yIDSBs1LR+ortc8dsR88hD03ENPLzd+4AcAPf1FdYrzB2vjDQrNUos Uryh9VPsVUxxE6R38zrECW2M2k1kBTgm484/sCA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/wDr0o_fpLPibhv1aRA935ygLzzM>
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: Tue, 13 Oct 2020 04:42:00 -0000

Hi Ben,

>
>> Just as forecast:
>> Without agreement, that the CIDs must be encoded using deterministic
>> interpretation, which in my opinion obsoletes these "number games",
>> next Summer either Raccoon or Kenny will write up their next
>> "time side channel attack" on this.
>> (The ambiguity will end up in try out the MAC for both "different
>> MAC_write_key" and so create a time signal. Or with "same MAC_write_key"
>> the receiver will not know by the failing MAC, which interpretation is
>> the right. I guess, this will end up in decrypt twice, also obvious time
>> signal.)
>
> Just to check my understanding: your forecast of an attack is predicated on
> implementations that accept both potential MAC calculations proposed (CID
> length before CID and CID length after CID)?  I do not think we should
> allow things to progress to a state where accepting both forms is
> encouraged, precisely because it leads to this sort of difficulty.   Hence,
> my suggestion to assign a different extension codepoint, so an
> implementation knows exactly which procedure to use.
>

My concerns are based on permit ambiguous CIDs.

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

That results in my opinion in cid 01 and cid 01 01 being valid for the
same peer and same time.

or

 > - Application record on CID 63 containing 04 00 02 FF, or
 > - Application record on CID 63 01 00 05 containing FF.

being valid for the same peer and same time.

That seems to be the precondition for the threats. Permitting such
ambiguous CIDs may be then the root cause for such a "time side channel".

With the reference from Antoine (https://eprint.iacr.org/2020/114.pdf,
Section III.D), I started to consider the encoding of a "variable length
CID" to be the real spot. That points for me to the same direction, it's
that encoding not the position of the cid-lenght.

best regards
Achim Kraus