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

+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