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

Achim Kraus <achimkraus@gmx.net> Mon, 12 October 2020 05: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 D455D3A0D94; Sun, 11 Oct 2020 22:41:39 -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 zqE3UPx9G0Ap; Sun, 11 Oct 2020 22:41:38 -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 75A623A0D92; Sun, 11 Oct 2020 22:41:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602481282; bh=LpP+MGURu2ChLJMhgbWmpPpJrNrWzPXD6UWnpcaJWdU=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=Pk98pSt03kYfYMIGMD7RQiMtxxQitDLVjrOpv9+MOVJR7Xk4h41lGoHvzS71PnRcf qxeYF8640y9UA2ph1jIkH8TjLDKyRK31jYmc6NBQyzmdVqT53fklYXR/x3w6n1anRW 2gWjY9qpWypcLin1LpPFLg0GN42dwp8fVN7tyZto=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.100] ([178.2.230.220]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N1wlv-1kKiyJ02en-012KpB; Mon, 12 Oct 2020 07:41:22 +0200
To: antoine@delignat-lavaud.fr, 'Watson Ladd' <watsonbladd@gmail.com>
Cc: draft-ietf-tls-dtls-connection-id@ietf.org, tls@ietf.org, 'Benjamin Kaduk' <kaduk@mit.edu>
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> <2ce401d6a010$a267c980$e7375c80$@delignat-lavaud.fr>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <a1e570fb-5880-7fc0-d9c8-8998969a6f3d@gmx.net>
Date: Mon, 12 Oct 2020 07:41:21 +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: <2ce401d6a010$a267c980$e7375c80$@delignat-lavaud.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:P4qxtRQEDiZWFKfxumROe4cyFME5VKQ04KXXP9ZVMVyZcbjQfpK lDRpn86tOocPd+aaGAlNrljQmJaOeGWzyll9MKw/tuZIAq1t8FJRQX27jzqRdnTJxkfAyBQ sGLIukrbevtj07i5Cg1JOdll+DjnrnW10D7rk7ToCJtGp8F57ucKwOn1c5eQiAPs+Jg77Q4 sRAMZhSrzK3CFgrA2zhpw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:asrCjXL4WRw=:55Kn+aGjfNcBu57Xo8m2wb iba/WPXBy7/xk1v5WI26a68Z5L1Y47DWy8qaGnvR6DmYTG0YCpTUTtOJm9QcRBDf2AVv54T5a OohV05MJ3ahtU3q1Sm0ZAa/NUUxsH1uPmk/u2f5I7CwUCvAwfuaF4HjBUneK8a6uimPSRWvfm SAXn0FBzJ2TKMPV/qcfLv0pW6WCvYLmWQVZgwt6muIgwIVsUELZA6j2LyUXcel9D5KlG8AxPr KxpfueqoFC2r8l4J7v59FIZJFPPBOHdkVGVyi//NXOqVrkqv6qWKjRLbogrEBHdcX9VhHV15C zMRpbgckCFFGcHkk+2bq133GlSwwbfWkZFxlRzEYJH/JpQnhPbbv0AB/zWISQlpoMZOfIkXz9 oQ7kCTL+tnQMJ57xDJxBNQDNWvJ73Ip11mhdAJ62r4zLkAo1rUS+wVTjjk2jOQCm/6pnY+Rgc 2ov9JhcDPNjTvrhUVgOLPP+UqiurgsAU8e93gQJ2gkd+1ZyUrrUgLHU33b969Rf1xWWBlsyFP PQHcFLsHwu/momxF9ILMavRiprq9eztSHTzCWTst6fgNUCFxXIZZwuSVFRLTlWUzBpTt0boL8 JJuMnd5RdyMSWotZoAn1aN8PLYT2nT8Ot390fY9Jb9ITZqgU8L2XNIwqISTgLOTQvswOYLFbn 3ebnpJ+NkYKumMTXw7uN107pKUYLjtl4m2REsfr4wcuE7yFMT7sYd5ylgsR+x8Z7afD0Y8N1V FX5/GC34CxUTcz5KZ64mA721sBBk/PgaINTlKtqVaQwkRmNgOQZcxuK/EcFf9qFEc2U4yvE99 Oh4yWB+NID9Jd3jqo56U9nca6miuRM9ozt16OT5sOfStf5qPt60t6NxHRsWnHTs+LyLogmKCl tKcjwu4pAy+pTnF8+iYLpOSj1wjyL4QWIw1gtC4zZxkxTdFQ1/tskQTD7Ye5Y+CVmO/Tkj7mT SwZmRZ2vPW/V1BJWzrAjQHcd0Ofjq99noLElug8TwUWiwg0I3LmACUBAcPyFFPpDalH54NoSo 0+/1TUZL2ShraHLEoBStdDBR6HdCItYn4TECx2cKaSbJCwDly6gWWqCbx/KpLsoGFcdAAL1yL gjdWoUxLNRo1d1ZkXdB16yuqfz1MKgFJPQB5NBps5nbwD0olZzu9Mll6AMRsRZepiPFfWJvXL rPK8ZMYsFBuV/TS3ii/KTB8H5LizhDLo3F2WU6jiuKq+38kWoB8Wznz0oj1eyDK6xXmZmA2GX 5y2l42OCltlBa2+jN8HhFHz7QkvpFD4mluG0+FA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WV1_qyZ4ZqqmgpZEBp_dmSLAbvM>
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: Mon, 12 Oct 2020 05:41:40 -0000

Dear Antoine,

thanks for adding the references.

I tried to understand https://eprint.iacr.org/2020/114.pdf (Section
III.D). But to be frank, as developer, it's extremley hard not to
misunderstand, what is documented there.

For me, this seems like in QUIC, the length of the CID is encoded in the
sent message (so it's on the wire).

For draft-ietf-tls-dtls-connection-id-07, at least as far as I
understood it, there are two general possiblities:

- a peer chose to emit only CID with the same static length. In that
case, the cid-length will always be the same (cid-length is not on the
wire). It can't be injected, except someone injects the execute programm
code itself.

- a peer chose to emit CIDs with variable length. In the case the other
peer is intended just to add that received CID in the hello extension to
the dtls-records. The emitting peer has to chose a encoding for such CID
with variable length, that the emitting peer is able to decode it. In
this case the cid-length is on the wire, but the encoding is not
specified in draft-ietf-tls-dtls-connection-id-07. In my opinion it's
extremely important, to chose a encoding, which could not be interpreted
in different ways (I guess, that's what Watson ment by "injective").

With these both options, FMPOV, to add explicit someting as the
cid-length to the MAC is not required. It's either the same static
value, or must be already encoded in the CID itself, which is already in
the MAC. But it may be required, to add constraints about such a
encoding for variable length CIDs to the draft.

The confusion may be mainly caused by the idea, to support both, static
length CID and variable length CIDs. That misleads to build examples,
assming that two CID may be used, where one CID is the start of the
other. In my opinion, that's a problem of the encoding of the variable
length CID, but not the MAC.

best regards
Achim Kraus


Am 11.10.20 um 22:53 schrieb antoine@delignat-lavaud.fr:
> Dear Watson,
>
> I object to your comment about formal models of TLS not capturing wire encoding issues. miTLS does in fact formally specify the format of all messages on the wire to the bit.
> In fact this is complex enough that we have a full paper just about the subject that will tell you more or less everything that was said in this thread
> http://antoine.delignat-lavaud.fr/doc/usenix19.pdf - https://github.com/project-everest/mitls-fstar/blob/dev/src/parsers/Parsers.rfc is the formal TLS message format specification including the demonstrably unsafe constructions (implicit tags on server key exchange in 1.2 and CertificateEntry in TLS 1.3).
>
> In the specific context of connection ID, QUIC up to draft 16 did suffer from an attack caused by the lack of encoding of the CID length. The attack is caused by the concatenation of two variable length fields in the network format (the CID and the packet number) that can both be tampered by an active attacker. The boundary of the concatenation is made ambiguous to the crypto authentication (AAD of packet content encryption) by QUIC header protection, which is applied before decryption. See https://eprint.iacr.org/2020/114.pdf (Section III.D) for a description of the attack. See https://github.com/project-everest/everquic-crypto/blob/master/src/QUIC.Spec.VarInt.fsti and https://github.com/project-everest/everquic-crypto/blob/master/src/QUIC.Spec.VarInt.fst  for the formal proof that the QUIC varint encoding with minimal length representation satisfies the strong prefix property.
>
> Antoine
>
> -----Original Message-----
> From: TLS <tls-bounces@ietf.org> On Behalf Of Watson Ladd
> Sent: dimanche 11 octobre 2020 08:50
> To: Achim Kraus <achimkraus@gmx.net>
> Cc: draft-ietf-tls-dtls-connection-id@ietf.org; tls@ietf.org; Benjamin Kaduk <kaduk@mit.edu>
> Subject: Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07
>
> On Sat, Oct 10, 2020 at 11:27 PM Achim Kraus <achimkraus@gmx.net> wrote:
>>
>> 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?
>
> 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. Here though it isn't clear if two different inputs to the encoding could end up the same. 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.
>
>>
>>   > Would this issue have been caught by formal verification?
>>
>> That may also be something to help, not to change still again and again.
>
> I don't think the formal models of TLS reach the wire encoding.
>
>
> --
> Astra mortemque praestare gradatim
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>