[CFRG] Utility of nonce misuse resistance [was: Questions for the group from the HPKE presentation]

Loup Vaillant-David <loup@loup-vaillant.fr> Tue, 10 August 2021 12:42 UTC

Return-Path: <loup@loup-vaillant.fr>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 481F53A0802 for <cfrg@ietfa.amsl.com>; Tue, 10 Aug 2021 05:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id MNB6lODQVmni for <cfrg@ietfa.amsl.com>; Tue, 10 Aug 2021 05:42:22 -0700 (PDT)
Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F9D3A0803 for <cfrg@irtf.org>; Tue, 10 Aug 2021 05:42:21 -0700 (PDT)
Received: (Authenticated sender: loup@loup-vaillant.fr) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id EA9971BF209; Tue, 10 Aug 2021 12:42:17 +0000 (UTC)
Message-ID: <ed1374b74a504f1e9c9a813506d5ddd1b5836f0a.camel@loup-vaillant.fr>
From: Loup Vaillant-David <loup@loup-vaillant.fr>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>, "cfrg@irtf.org" <cfrg@irtf.org>
Date: Tue, 10 Aug 2021 14:42:17 +0200
In-Reply-To: <747276B5-678B-4983-82FB-B36BF9B5C7CB@ll.mit.edu>
References: <a582bedb-35ce-41ba-ba9b-2dd1c074b248@www.fastmail.com> <747276B5-678B-4983-82FB-B36BF9B5C7CB@ll.mit.edu>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/ZLVIfbEzYMZo6cqTpneFIwaTNLs>
Subject: [CFRG] Utility of nonce misuse resistance [was: Questions for the group from the HPKE presentation]
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Aug 2021 12:42:26 -0000

Blumenthal, Uri wrote:
> Semi-related. Am I the only one who became rather antagonistic to
> AEAD modes that can't survive nonce reuse/misuse?
> I'd like to see only nonce misuse-resistant AEAD as we move forward.

Designing actual protocols convinced me that AEAD is not enough. We
need to go all the way to actual wire protocols, or file formats.

First, we need to establish a session key. It's pretty easy in some
cases (password based key derivation, and done), but key exchange is
generally more problematic (just look at Noise to get an idea of what
it takes to actually exchange keys).

In some cases (such as file encryption), it may be more practical to
have a random (and therefore unique) key for each instance. In this
case, we don't even need a nonce, and we could fix it at zero. (Let's
ignore the likes of AES-CBC).

Finally, we have other considerations, such as key rotation (ratchet)
for forward secrecy, various limits such as chunk length, number of
message per session, replay attack resistance, DoS resistance…


Simply put, AEAD, even with nonce-misuse resistance, is not enough.
Application writers need full blown protocols, ideally with some
reference implementation, and a test suite that tests various attacks
that might occur from specific implementation errors… such as nonce

At that point, AEAD is just a (crucial) building block for protocol
designers. I believe it is reasonable to assume that protocol designers
(as opposed to application developers), will not design protocols that
reuse nonces. Just like it's reasonable to assume that AEAD designers
aren't going to misuse Poly1305.

So, just like we've been telling application developers to use
authenticated encryption instead of combining AES/GHASH (or
Chacha20/Poly1305) manually, we probably want to give them the
protocols they need, and tell them to use those.

If we do this, nonce-misuse sensitive AEAD such as RFC 8439 should be
much less of a problem. In this context, I believe the security
increase provided by a nonce-misuse resistance is minimal. Possibly not
enough to justify any perceivable decrease in performance.

For me, if we can get application writers to use high-level protocol
implementations, nonce-misuse resistance is just a nice to have.