Re: [Lake] Ways forward on MTI cipher suite text

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 26 January 2022 15:35 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: lake@ietfa.amsl.com
Delivered-To: lake@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241313A14B4 for <lake@ietfa.amsl.com>; Wed, 26 Jan 2022 07:35:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 (2048-bit key) header.d=sandelman.ca
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 flDzgaPA-6Fu for <lake@ietfa.amsl.com>; Wed, 26 Jan 2022 07:35:16 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C9BD3A14B9 for <lake@ietf.org>; Wed, 26 Jan 2022 07:35:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BBFF038AFF; Wed, 26 Jan 2022 10:42:01 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sX00j5VuOtjR; Wed, 26 Jan 2022 10:41:59 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 986BD389F0; Wed, 26 Jan 2022 10:41:59 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1643211719; bh=Gg21OKewIUKaQ0JFqjV0Y4tkhuYw75oVttA/e3HOVYc=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=CnaQjpcIu3xXu8h4jJKg+7La+RjPjIASo1KdQQQ9l5+r5FDwRK1aVtLSdgiwemDIs 4iVa9+ZMGwGt47nIrb1/JvOeTBuvrTjfoObjxk7FEkaxGGIpvhgbnAGe+ultqS8F14 aG3RttJc2CPF9fI+LtxfDe7cKcQpSiXcoZfcwfq5tDeic5lGm1OiWcLFXNBeZuk8jM ByaXDE1fNNram/ERWw3IVvU7ZPi+7s04n4RmqM9S2C2J2mAMlFvGHMNBwvGUKax6zk Zq4gvODmqK8uFehQZMT7V5JXmjEiN3bu2rQvFTsDltIATtLr6aOhWFfxtjrrkxQVRZ wu7gO9cfwJJEw==
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CC9F83FB; Wed, 26 Jan 2022 10:35:10 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: John Mattsson <john.mattsson@ericsson.com>
cc: "lake@ietf.org" <lake@ietf.org>
In-Reply-To: <HE1PR0701MB3050626ED7924371EC03DADF89209@HE1PR0701MB3050.eurprd07.prod.outlook.com>
References: <2A2081E4-BAAF-4292-925E-0B683AA6CD23@inria.fr> <24192.1643036826@localhost> <AM4PR0701MB2195208CA41C14108E5CD85AF45E9@AM4PR0701MB2195.eurprd07.prod.outlook.com> <14667.1643068411@localhost> <24988.1643129342@localhost> <HE1PR0701MB3050626ED7924371EC03DADF89209@HE1PR0701MB3050.eurprd07.prod.outlook.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 26 Jan 2022 10:35:10 -0500
Message-ID: <27615.1643211310@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lake/0lP25nddHmPOSofBE3ZUyaHa7lc>
Subject: Re: [Lake] Ways forward on MTI cipher suite text
X-BeenThere: lake@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Lightweight Authenticated Key Exchange <lake.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lake>, <mailto:lake-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lake/>
List-Post: <mailto:lake@ietf.org>
List-Help: <mailto:lake-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lake>, <mailto:lake-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2022 15:35:21 -0000

John Mattsson <john.mattsson@ericsson.com> wrote:
    >> So what do these extra 8 bytes actually do?

    > 8 byte tags provide 64-bit security against online brute force
    > attacks. 16 byte tags provides 128-bit security against offline brute
    > force attacks.

Brute force attacks against the integrity key, or brute force attacks to
change that specific packet?

    > To break 64-bit security against online brute force an
    > attacker would on average have to send 4.3 billion messages per second
    > for 68 years, which is infeasible in constrained IoT radio
    > technologies.

Agreed, if you are doing an online attack with the responder being your
oracle.   I don't know how to do this in an offline mode because of way that
we use the integrity key.

    > A forgery against a 64-bit MAC in EDHOC breaks the
    > security of all future application data, while a forgery against a
    > 64-bit MAC in the subsequent application protocol (e.g., OSCORE
    > typically only breaks the security of the data in the forged packet.

Agreed.  I'm trying to understand what the extra 8 bytes gives anyone.
I'm just not convinced that it is ever worth it, and that the people who
think that it gives more "security" are not actually thinking things through.

    > - For most MAC algorithms, a forgery only breaks the security of that
    > single packet and the complexity of key recovery is equal to the key
    > length. For GCM, the complexity of authentication key recovery is equal
    > to the tag length. But the complexities of multi-forgeries for most
    > other MAC algorithms are not well understood.

This is the attack I'm talking about.

    > - If the MAC length is not integrity protected and the receiver accepts
    > different length, an attacker can perform forgeries on 32 bit MAC even
    > if the sender only uses 128 bit MACs.

That's silly, that means that the algorithm selection was ignored by the receiver.
Yes, there are people out there who think that receivers will process any
algorithm in the IANA registry.  Really.  I've met them.  It makes a slight
bit of sense when processing *certificates*, but no sense when we have an
AKE.




--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide