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

Achim Kraus <achimkraus@gmx.net> Thu, 15 October 2020 06:12 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 CB3373A12DC; Wed, 14 Oct 2020 23:12:24 -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 FC0tJluyosjF; Wed, 14 Oct 2020 23:12:23 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 1BAA53A12DB; Wed, 14 Oct 2020 23:12:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602742334; bh=C05xHxer4O7bLJg0aY52qypNxqLimntXvXycpkzSSC0=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=IibaAzqwirB/BuuChdoHuozHpGSxAbXq7It/cZllTJNHY/0q/Jjd+nGYNqDK/0D3l 6v+DK+t09wyeE6lWZzXsqweY/odsGzhigKtZBqH3oXCf4xHYSiabI7fHy1PGzWPrKL Ovv5BrFGTt9lVJZ+EO8eMxnt9054b2oW229zLz9A=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.100] ([178.2.230.220]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MXXuB-1kxvd32ivH-00YwbS; Thu, 15 Oct 2020 08:12:14 +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: <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> <bab402e6-3353-d750-a849-21c91081f94e@gmx.net> <20201014212428.GP50845@kduck.mit.edu>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <a7110178-6220-175e-869d-fcc44400f773@gmx.net>
Date: Thu, 15 Oct 2020 08:12: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: <20201014212428.GP50845@kduck.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:+lz3hN5AEHz8IG63L6RSkKlypcMqledb3OGvB7IBP/i42UIAFQE mSmgLIp3G6sFevu0b2W2xVl+6BDx0mGO+BkAcoUUG8qWRyJHwz8bq0XydPOR3Gm1g3DhTiw G6RtHUMDf7JDOz3dNrL7jPooPAXjtWgIvZp5F8g9/v7S6Lf5HyZq8KbSK+bjYxA/yNiXqkv NrBjYn5Yoc2I4lSuHTjyQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:sjLawVs2jKg=:Nw+H7/ojE9TIhZ4Weha5LW byNwPpfk4QYWvgalYbKcQQ4sgt1mED22oQwLxs/BYEsp8zoNIdPzq05hLO4aKQ1mdPQgiLAy8 X19oWnsRhabEBw0Xwqa9qNkUkwgi8uduvmrkzn3ZRiMMVJjje1PHw9sM+RVN+Rf4jZSSIHV/w cp8MsQc+ERq0DZTrbsMa851lQZlb6j8h9B7PRSRO5XO+92Wzo6+7XC29iZ3IXzmfuNzt5nygN sVq0TyTetv7dHJl0ZtpOmJHLNc9g4ZZmctEp0bt7vW4oJIHyns1zAeJanJ3pVWvL8hnFxlORD v4odkKHPSX0xED+bjxuQFDtl9YcW6jOTPrUKIDgbuEJnlkIlDPUllwBN3LGbSFNHjG0yV+AAG D4F+eBslZCwz+EbITET9lGmyIu66B+qJDCgvnqvbPrIgB59IuIVYWwjk1t/D0z0lARH1crv/h S97pNi5JcRhpurv0sC3HoaKwBhXv8LpE40AuQEk+ES14KeH+VvYOhXSwE5zl0lFK4XUa4Pzbt evUztgVPaRRH7iywi7AQsSCERqzign0X2z3VXVWixRJ7ThT74hsrSFRCujxGKQXxKjbteuqur bgSLiUOIZlb9tAxxI3N+1KONefkTZhBZ6AZmxG9oxIpot7xMDwNsutxKzjhaujG23VHDgB6sO FgLmeBLBRge3EbV+KGxFr3QUVShSY9KvpApIwiBPZGYjFI09J5o3+VqOytCFq5T5VcXYzFGqp MgdBhTCsUHHvZ1ETpVO0ag2DMMMX/NWZe6jCbPdqqiz27mgJHVfn/B7wTZj/Np8hJI+md0O0m zVhIA7JtCyKUYKDy1uUklfDz5iTlOvzT5ieXVzlfGTivph6Itl8iKUfJt2UR7+/M2kh78Urpu E1Ik9UWpDI3E8QuRgOqA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/M8TcpVUPKfyU4gQszsOoNVeSQiY>
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: Thu, 15 Oct 2020 06:12:25 -0000

Hi Ben,

> The attack does not require that both are valid for the same peer at the
> same time -- the attack can still occur when the party producing the MAC is
> induced to use the "wrong" (invalid CID) interpretation of the byte stream
> but then the version with valid CID is presented to the party verifying the
> MAC.

Though I consider the CID mainly as lookup-key for the security context,
including the MAC_write_key for Block Ciphers or the write_key /
write_IV for AEAD Ciphers provides in almost all casses the protection,
not the cid in the MAC. The only exclusion would be, if two different
cids point to the same security context. With a injective cid encoding,
that is mitigated.

As far as I understand your description:

1. The (server) peer 1 used cid "abcd" for it's encryption context.

2. An attacker modifies that cid "abcd" into a different cid (any
assumptions about that? Should it be "abcd12"? Or "ef3456"? Or no
special consideration?)

3. Then the other peer 2 uses the modified cid to place it into the
FINISH record and to calculate the MAC for that. The used security
context on peer 2 is NOT defined by that modified CID, it's defined by
peer 1's 5-tupel (according draft-ietf-tls-dtls-connection-id-07).

4. Now peer 1 will use the modified cid to
4.a. lookup the security context. What is assumed as result here?
4.b. calculated the MAC using the security context and modified cid

In my opinion, the MAC verfication generally fails, if at least one
input is different. So either a different security context or a
different cid will fail the MAC verification.

Though you say, that not both cids need to be valid for peer 1, the
consequence for me is, that peer 1 knows only the unmodified cid, but
not the modified cid. With that, peer 1 doesn't even have a security
context to calculate the MAC with.

It's totally mystic to me, what you assume as attack.

I guess, you adapt now your example. If so, would it be possible, that
you try to follow the above steps and show, where you deviate?

> If the internal structure (including length encoding) of the CID is
> opaque to the party producing the MAC, that party cannot validate the data
> used as input to the MAC.
>
> (Sorry for duplicating this previous paragraph here and on the github
> issue.)
>

 From the github issue:

 > In short, you asked me to show how having a cid-length (in a different
 > position than currently) will prevent an attack: the attack in
 > question occurs when the client is generating a (its first) MAC, not
 > at the time when the MAC is validated.

I still fail to follow your description, even with that amend.
Would it be possible, to get more information about an attack applied on
the generation of a MAC (above in step 3)? Or does the effect occur in
an other step (maybe 4)? Which effect should be considered?

Maybe, someone else has also an opinion about that attack or the
description.

best regards
Achim Kraus