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

[Jim Schaad <[e-mail]>]

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 <[e-mail]> On Behalf Of Martin Thomson
> Sent: Wednesday, July 1, 2020 6:23 PM
> To: [e-mail]
> 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 <[e-mail]> On Behalf Of David McGrew
> > > (mcgrew)
> > > Sent: Tuesday, June 30, 2020 4:33 PM
> > > To: Stanislav V. Smyshlyaev <[e-mail]>
> > > Cc: CFRG <[e-mail]>
> > > 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
> > > > <[e-mail]>
> > > 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
> > > > [e-mail]
> > > > https://www.irtf.org/mailman/listinfo/cfrg
> > >
> > > _______________________________________________
> > > Cfrg mailing list
> > > [e-mail]
> > > https://www.irtf.org/mailman/listinfo/cfrg
> >
> > _______________________________________________
> > Cfrg mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/cfrg
> >
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg