Re: [Cfrg] Do we need a selection contest for AEAD?

Martin Thomson <mt@lowentropy.net> Thu, 02 July 2020 01:24 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4893A12D4 for <cfrg@ietfa.amsl.com>; Wed, 1 Jul 2020 18:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=Rg+AxUMg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IjlcHXZ+
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 u8a4rP0JgYfg for <cfrg@ietfa.amsl.com>; Wed, 1 Jul 2020 18:24:04 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E5753A12D0 for <cfrg@irtf.org>; Wed, 1 Jul 2020 18:24:04 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id CA99B313 for <cfrg@irtf.org>; Wed, 1 Jul 2020 21:24:02 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 01 Jul 2020 21:24:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=aggKV U5eppbT3INHjMF3InlrAU+O4vVblKVdiiJtWxo=; b=Rg+AxUMgtzs29efdk0Pat 2Y/G8G5nelDeis6nxxH3uPW3t7ifm2+xu0iR1pg2R7OFeSyvc8fUfmFPvoYKqcJn enULEWYoo6yeZpparIvzBv4Pc774JUlYfaqlNpDlFwyw9Xor6KTPAW3z9i5dk87D 25lzGosX9jpaT5t1EGVHRsPdiZ5RVo33N+SVrmJqWuAaKzagHLA0S6AH1/EYyz1U OiIL50lpKlZNEbXdzYk3Sl0oguu8epE65jbPn62tXdD72/PpjXI8Y+Z/zp+9pWrT 3eUGvVs2y9VirjoVjbvYwsKGjqUx/jmVmUk9adWioV5DYJHtD0g1MVDHvX2BI5PY g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=aggKVU5eppbT3INHjMF3InlrAU+O4vVblKVdiiJtW xo=; b=IjlcHXZ+EHnyaWJSJLplRwFHOQfR6aOwI6Z6t7iPramYXXygYdAgrDb3Y tmIr9TFVzi9UE8F7beBZGTqLEaXFAgzuXurMjfcuN26v7lkxmhojZ0aF989euWwT x7irXSH157GikVTv+HuPDMLuk9JnL/+1OVOvIwwlKe8BlJXN9pdEpofnX8/tREVQ 4XCAMd6KFJ7EAY48tE11wrOm1UfNAlGg0Ey89ZWYq6W795joJL3DjIne5zEqcVP4 wxVuTXTP5hPOZB3/jDo+jEMAicpPWalsEJ9Dwhm8ExDmBkiULKcmyL+7sDX1AdyI h/r1VQYeXgv3C5icbd9GgpyBO/GAg==
X-ME-Sender: <xms:Mjf9XrbMqtXsM0KE7pLLPP9yaDHjRQjo3enbJvx8lEjWprf3MDxIpw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtdefgdeghecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpedufedvkeehueeileeghe ffgeefkefhhedugfehleelueehueeufedtfeffudehvdenucffohhmrghinhepihhrthhf rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:Mjf9XqbJYkFuqb7ASBDyMEVHu_Y6gcp_L9AcHw5PB3MzKYmJKJgaWg> <xmx:Mjf9Xt9Xo2iTGOpUk2W_VWbtpI0d89sTAVtyMHDIx7WuI3dwXKyo3g> <xmx:Mjf9Xhow9vYTnf-gc9iMZzk15RRt6SQSPJMFwq5Meqoh7kuFDysR7g> <xmx:Mjf9Xn6C1yc-tQacroqrQaNSvBFtLZQygx3Z3YH1DvzkcFdxTaDyZQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 02B67E00ED; Wed, 1 Jul 2020 21:24:01 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668
Mime-Version: 1.0
Message-Id: <b0f00c68-ace9-49c2-8620-7632636217ab@www.fastmail.com>
In-Reply-To: <042e01d64fcd$9b248480$d16d8d80$@augustcellars.com>
References: <CAMr0u6=QJuG9mshppB6qeryk6qekVKgi9D=WqGoa_L4sNgtYLg@mail.gmail.com> <C55EF5A9-F283-4721-98B9-22CE168D4E08@cisco.com> <042e01d64fcd$9b248480$d16d8d80$@augustcellars.com>
Date: Thu, 02 Jul 2020 11:23:18 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: cfrg@irtf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/x7_2l5bo1eIKOpXAA-5fiUu4YPA>
Subject: Re: [Cfrg] Do we need a selection contest for AEAD?
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: Thu, 02 Jul 2020 01:24:07 -0000

I understand the appeal of tuning algorithms to particular purposes, and the possibility that there are applications with constraints that dictate the use of an common primitive.

The effort of identifying these important characteristics and classifying functions using those characteristics is good.  But I don't want this to lead to a multitude of options.  Though it may be inevitable, anything more than one option is not good.  Keep in mind that we already have a number of AEADs we have to carry.  There are likely good reasons to add more, any addition comes with significant costs.  We've come a long way to making this stuff cheap and available, and especially when it comes to availability of crypto in hardware, I don't want to see that progress broken down.

On Thu, Jul 2, 2020, at 03:32, Jim Schaad wrote:
> +1 
> 
> Having a document that I can point to that gives what the properties 
> are and do I care about them when deciding on an algorithm would be 
> very useful.  In the past I have completely ignored this and made 
> assumptions about what it means.
> 
> > -----Original Message-----
> > From: Cfrg <cfrg-bounces@irtf.org> On Behalf Of David McGrew (mcgrew)
> > Sent: Tuesday, June 30, 2020 4:33 PM
> > To: Stanislav V. Smyshlyaev <smyshsv@gmail.com>
> > Cc: CFRG <cfrg@irtf.org>
> > Subject: Re: [Cfrg] Do we need a selection contest for AEAD?
> > 
> > Hi Stanislav, Alexey, and Nick,
> > 
> > It would be great for CFRG to review modern AEAD modes and their properties,
> > but instead of holding a contest at this time, I suggest focusing on the
> > applicability of these properties to IETF protocols.  It would be valuable for the
> > community to get to a better understanding of which properties have the most
> > applications, and which are niceties and which are nececessities. In the same
> > vein, having a deeper understanding about the scenarios that have led to
> > security failures in the field would help to motivate properties like robustness
> > and leakage resilience.  So I suggest having a call for presentations and
> > documents that includes these broader topics around AEAD.  If nothing else, it
> > could be a prelude to a contest.
> > 
> > The list of properties below is a great start; nonce hiding and resistance to
> > multiple forgery attacks are also worth considering (and have been raised by
> > others I believe).
> > 
> > Regards,
> > 
> > David
> > 
> > > On Jun 19, 2020, at 1:32 PM, Stanislav V. Smyshlyaev <smyshsv@gmail.com>
> > wrote:
> > >
> > > Dear CFRG,
> > >
> > > The chairs would like to ask for opinions whether it seems reasonable to
> > initiate an AEAD mode selection contest in CFRG, to review modern AEAD
> > modes and recommend a mode (or several modes) for the IETF.
> > >
> > > We’ve recently had a CAESAR contest, and, of course, its results have to be
> > taken into account very seriously. In addition to the properties that were
> > primarily addressed during the CAESAR contest (like protection against side-
> > channel attacks, authenticity/limited privacy damage in case of nonce misuse
> > or release of unverified plaintexts, robustness in such scenarios as huge
> > amounts of data), the following properties may be especially important for the
> > usage of AEAD mechanisms in IETF protocols:
> > > 1) Leakage resistance.
> > > 2) Incremental AEAD.
> > > 3) Commitment AEAD (we've had a discussion in the list a while ago).
> > > 4) RUP-security (it was discussed in the CAESAR contest, but the finalists may
> > have some issues with it, as far as I understand).
> > > 5) Ability to safely encrypt a larger maximum number of bytes per key
> > (discussed in QUIC WG)..
> > >
> > > Does this look reasonable?
> > > Any thoughts about the possible aims of the contest?
> > > Any other requirements for the mode?
> > >
> > > Regards,
> > > Stanislav, Alexey, Nick
> > > _______________________________________________
> > > Cfrg mailing list
> > > Cfrg@irtf.org
> > > https://www.irtf.org/mailman/listinfo/cfrg
> > 
> > _______________________________________________
> > Cfrg mailing list
> > Cfrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/cfrg
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>