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

Jim Schaad <ietf@augustcellars.com> Thu, 02 July 2020 02:17 UTC

Return-Path: <ietf@augustcellars.com>
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 3F3F53A0811 for <cfrg@ietfa.amsl.com>; Wed, 1 Jul 2020 19:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 d16Lp1CdjCB5 for <cfrg@ietfa.amsl.com>; Wed, 1 Jul 2020 19:17:57 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CD73A0810 for <cfrg@irtf.org>; Wed, 1 Jul 2020 19:17:57 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 1 Jul 2020 19:17:51 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Martin Thomson' <mt@lowentropy.net>, <cfrg@irtf.org>
References: <CAMr0u6=QJuG9mshppB6qeryk6qekVKgi9D=WqGoa_L4sNgtYLg@mail.gmail.com> <C55EF5A9-F283-4721-98B9-22CE168D4E08@cisco.com> <042e01d64fcd$9b248480$d16d8d80$@augustcellars.com> <b0f00c68-ace9-49c2-8620-7632636217ab@www.fastmail.com>
In-Reply-To: <b0f00c68-ace9-49c2-8620-7632636217ab@www.fastmail.com>
Date: Wed, 1 Jul 2020 19:17:49 -0700
Message-ID: <047801d65016$fd566ad0$f8034070$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
thread-index: AQJV9zpKieO8w4OilKrmZ7VY/5Gz3gJfpmRNAUcUbnQDOinc8Ke9N5jw
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/hlbi1zngrFPB6b-76JNeMpzCNcw>
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 02:17:59 -0000

I completely and totally agree that I do not want to see lots and lots of AEAD algorithms defined so that I get lost in the choices.  However, there is already some places that seem to be calling for an AEAD algorithm that "commits?" and not only do I not really have a solid idea of what this means I do not have any idea of why it is desired.  And somebody has already talked about needing this property for some JOSE based protocol.  As a DE it would be nice if I could see what the properties are when having to look at registration.

Jim


> -----Original Message-----
> From: Cfrg <cfrg-bounces@irtf.org> On Behalf Of Martin Thomson
> Sent: Wednesday, July 1, 2020 6:23 PM
> To: cfrg@irtf.org
> Subject: Re: [Cfrg] Do we need a selection contest for AEAD?
> 
> 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
> >
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg