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

From: Jim Schaad <[email-masked]>
Date: Wed, 1 Jul 2020 10:32:31 -0700

+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 <[email-masked]> On Behalf Of David McGrew (mcgrew)
> Sent: Tuesday, June 30, 2020 4:33 PM
> To: Stanislav V. Smyshlyaev <[email-masked]>
> Cc: CFRG <[email-masked]>
> 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 <[email-masked]>
> 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
> > [email-masked]
> > https://www.irtf.org/mailman/listinfo/cfrg
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 02 Jul 2020 11:23:18 +1000

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.
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Jul 2020 02:35:57 +0100

On 02/07/2020 02:23, Martin Thomson wrote:
> I don't want this to lead to a multitude of options. 

+ a multitude

Cryptographers seem to inevitably offer more options
than are useful... just in case.

One imperfect-but-ok option is far better than a pile,
each of which is perfect in some scenario.

Cheers,
S.

---

From: Jim Schaad <[email-masked]>
Date: Wed, 1 Jul 2020 19:17:49 -0700

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

> From: Cfrg <[email-masked]> On Behalf Of Martin Thomson
> Sent: Wednesday, July 1, 2020 6:23 PM
> To: [email-masked]
> 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.
> 
> > > 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
> > >
> > > initiate an AEAD mode selection contest in CFRG, to review modern
> > > AEAD modes and recommend a mode (or several modes) for the IETF.
> > > >
> > > 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.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 1 Jul 2020 22:22:30 -0400

Martin -

One of the things I kept running up against in building a FIPS certified 
hardware module with AEAD algorithms was the FIPS requirement that the 
plain text not be released prior to the authentication being 
validated.   That turned out to have a very interesting side effect in 
that it required either a two pass run against the data, or it required 
sufficient buffering space within the hardware security boundary to 
decrypt/verify in one pass.

This was for both of the CTR based CCM and GCM AEAD modes.   It turned 
out that neither of the specifications gave guidance on  the maximum 
required message size.  Fortunately, most of the protocols we use tend 
to use fairly small message sizes and we picked something around 2K as 
the buffer size.  That turned out to increase the cost of the chip a bit 
(more RAM == more wafer space == higher cost) and there was some 
screaming.  This in turn led us to delete the modes from the FIPS list 
(and instead implement them as firmware wrap-arounds of the ECB hardware 
support ).

This is just a long winded way of saying that I agree with Jim that we 
need a set of properties, and that I hope that whatever modes are 
created won't constrain us based on how they need to be implemented in 
hardware.  (e.g. it would be problematic if the mode picked 2K for a max 
message size and that's what gets implemented in hardware, while we in a 
year or so start looking at protocols for high-speed transmission that 
are using 64K messages).

Later, Mike