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

Achim Kraus <achimkraus@gmx.net> Sun, 11 October 2020 17:43 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 041723A0EFA; Sun, 11 Oct 2020 10:43:26 -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 GCReb40tCI-c; Sun, 11 Oct 2020 10:43:24 -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 252DB3A0EF9; Sun, 11 Oct 2020 10:43:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602438195; bh=HSpVoZi2tDyc1ysWQq7Yp3wftcYYG3AwtVimiyfsQ0o=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=FayMnnt8Dx9QlzJ3uoZzs2M8NJruPrYcUO1wTVRQZAWadF7FdczCwPJ3F0yO1hxRw W+wnYpI18IR5jSqhrxpnbrayS4d5VqTbYVmSayqgeVPIDT54y25bhHhHouhu5YDm98 IudQrK8RwPAWaNfmbK6wpF51aAlX/yWGWISxzw+c=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.100] ([88.64.90.178]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MpDJX-1k8L761kT9-00qiaJ; Sun, 11 Oct 2020 19:43:15 +0200
To: Watson Ladd <watsonbladd@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>
Cc: 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>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <0327abb0-6317-b848-28d0-1fc50f4bf50e@gmx.net>
Date: Sun, 11 Oct 2020 19:43:14 +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: <CACsn0cn4QcnaoocQeoiUXgGoAvfOs+1+Ei76z1Kuq8MMqNEh3Q@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:qLllTIEW+zqFeZCoQlvP8CbQlOzJTOzhKKFsJLoWLtJHRPDdlAQ yTEXCBfV+V/ByXnImTbKpUHeubWHUgE7Ho7gCxner2F0Th464K/YxIFhPHYTMBzeOaR5XIZ 5yJ6at4NXhLx6u1GkHVVIlUk3B0YagppI3r2HjQRGR7OTJe+19/BXYiepoIiqdq85/z41F6 9Y3+4rXc+zeIBednEODVQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:BQZ5OoT4G3k=:4w51zQoEpueEw3Yr6nQML/ 0XSYVoHLwS1aWxne6LQiLujs6GfV8Y0zRwpMAfqfqZIA58JcHmgkRGI+RH6AkIozA5JYIjTkq J1pNgFiLqv1GJwUSEFO2vas4NeipEX8xdmIP+BEiez4mciYaSlqKGbFxjyhMGGOLNxrVsG7yQ 6cT/E71Ijhy6o+NycMMOqQsjubfj5+xE+Iz3L/GlJmsMdnW9adrWUYVQ/CwmxpslhUwkStQxC LFmVRqG1SF8MER8X9snLdlWC3Oyx7EkZiJWtcFKF6AOI0yWCGDa18DiXKG/97gVwpeCWHjIOo KZvryXPPa8oZzzfm7xW087a+GBIwEBy3U8gcVOfZ52N2GRHxli0zQyNmhd9aVZA5zu7bfzfab biJ02NdKUbS5//u5NazanO0WxnROnzu7eVAfT8DsvdAIqLEKP3Zc4c5cVx5+/y1/DNq5JaVQs IWzrA40Nn7Jc/JBlxJAUwsFpJuCq/2FNDztQZ0Rqer82xfO5OS4hCUtBOpv1A1TQ4rVctazcF lZRS/Osq+C+4l6IJEzYLY4m8G56O3FSSeUnwkrpq6nLRoXvT78dfrGQteoY7Gs6DAcT8WEgRl pWDUfhtN3Myc3h4GImoXJgsy8RtVFg6uBV6PqaO0GAlk/PaSAuB/6FLpf7LOhittzd2QOS8h4 0g0FmjslD/FMfA8lxGTHQPogEktyxSZwGIdxL/Vn4Ms8JVOBM95MHvS8D6s2Iy0kezLDCM2il z+tai81ahIqUJU+4bjkvTE2D0Dr0PrWukaWM9P2J7zK0d5iFBxxdemx3ckWooG0tCgfn/KwGU /FDFOwrky03sEuBmlNxgV8+/Zt3lvOgXoB6Ei1FCoPMadbmW8Ass0dBZ1708TwFP90FJTSUXc Kiap1tNIFspW/94KSaxcaalNBBZQMOEZzVlXLnG8uSLzKUxb83oCxHCETsT4SJGdyD3Zl2KeL gA6uGIrPNMuajbvnMoRcFWFH1XPUIiwxu+Y7pOLrkiz6N9BXesPAjLGC2f+hXMYaVqjU6GZYX OTbq9TPm5SQXHGBmZ9pkckVgWQsXG0oe7Nm5I8WDQ/co7X0qz/3hx3dVmW+WPOiIUCuinPHDG cODClxeXp2HmXD37i3Qd7MiJNToQqOfkyLvYbp73m3jLfolql0z/PKdNgTXqnLIatubDzVd9Q YfndCP3pVCxu7Pr3YmLrqBvyweih6DUvatZrzCZ8sovqKAbdejdbyuTqHPOA+UuWemlkcmBo2 XzYX8S0A9V4pNoGh8CPliXvpkKlPDCTPmVUNAbg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/QCjCExuSki870pz3grPHG1QtspQ>
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 17:43:26 -0000

Hi Wadson,

> The doubt is because of where it appears not that it appears. If every
> value was preceded by its length the encoding would obviously be
> injective.

I hope, this is just a "typo" or "mistake".

Prepending the length is the change, Ben want to use to protect against
injection. You now say, this will be "obviously injective".

> Here though it isn't clear if two different inputs to the
> encoding could end up the same.

Though the MAC definition starts with "MAC_write_key", I'm pretty sure,
all examples so far are just incomplete. They must declare, if the
"different/ambiguous" CIDs are refer to the same "MAC_write_key" or not.

"different MAC_write_key" => obviously "end up" different.
"same MAC_write_key" => the decoding of the records gets ambiguous

> In fact I think in the MAC setting
> there almost certainly is a problem as the length of the ciphertext is
> right after the cid length, and with some cleverness you can come up
> with a cid and ciphertext that could be interpreted multiple ways.
> Unfortunately I haven't followed the draft's discussions that closely.
>
> I do not understand how a CID is supposed to be parsed by a recipient
> when the length can change and the length field is not encoded, but
> perhaps I'm misreading the intent of the [] notation in the record
> layer of the draft.

That's just a theroretical numbers game. No one os far made any really
useful example from start to end. FMPOV, "CID with dynamic length" MUST
use a unique/deterministic encoding. If that encoding ambiguous, as
others imply/assume in their "numbers game", the whole record gets
ambiguous.

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

best regards
Achim Kraus