Subject: [Cfrg] Call for adoption for draft-wood-cfrg-aead-limits

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Wed, 22 Jul 2020 15:17:13 +0300

Dear CFRG participants,
This email commences a 3-week call for adoption for "Usage Limits on AEAD
Algorithms" draft (draft-wood-cfrg-aead-limits-00) that will end on August
11th 2020:

https://datatracker.ietf.org/doc/draft-wood-cfrg-aead-limits/

Please give your views on whether this document should be adopted as a CFRG
draft, and if so, whether you'd be willing to help work on it/review it.
Please reply to this email (or in exceptional circumstances you can email
CFRG chairs directly at [email-masked]).

Thank you,
Stanislav (for the chairs)

---

From: "Paterson Kenneth" <[email-masked]>
Date: Wed, 22 Jul 2020 12:47:02 +0000

I support adoption.

I will support the effort by working on/reviewing it as needed.

(Declaration of CoI: Felix Günther works with me at ETH Zurich).

Cheers

Kenny

--
Kenny Paterson
Applied Cryptography Group

ETH Zurich, Computer Science Dept.
Universitätstrasse 6, CNB E 104.2
CH-8092 Zurich

tel. +41 44 632 32 52
www.appliedcrypto.ethz.ch

From: Cfrg <[email-masked]> on behalf of "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Wednesday, 22 July 2020 at 14:18
To: CFRG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [Cfrg] Call for adoption for draft-wood-cfrg-aead-limits

Dear CFRG participants,
This email commences a 3-week call for adoption for "Usage Limits on AEAD Algorithms" draft (draft-wood-cfrg-aead-limits-00) that will end on August 11th 2020:

Please give your views on whether this document should be adopted as a CFRG draft, and if so, whether you'd be willing to help work on it/review it. Please reply to this email (or in exceptional circumstances you can email CFRG chairs directly at [email-masked]<mailto:[email-masked]>).

Thank you,

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Jul 2020 14:07:39 +0000

Strongly support adoption and will review.

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 22 Jul 2020 17:25:59 +0300

I strongly support adoption.

I'm also interested in adding the MGM mode (
https://tools.ietf.org/html/draft-smyshlyaev-mgm-17) to the comparison.

On Wed, Jul 22, 2020 at 3:17 PM Stanislav V. Smyshlyaev <[email-masked]>
wrote:

> Please give your views on whether this document should be adopted as a
> CFRG draft, and if so, whether you'd be willing to help work on it/review
> it. Please reply to this email (or in exceptional circumstances you can
> email CFRG chairs directly at [email-masked]).
>
> Thank you,
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

-- 
SY, Dmitry Belyavsky

---

From: Russ Housley <[email-masked]>
Date: Wed, 22 Jul 2020 10:36:37 -0400

I support adoption of this document.

Russ

> On Jul 22, 2020, at 8:17 AM, Stanislav V. Smyshlyaev <[email-masked]> wrote:
> 
> Dear CFRG participants,
> https://datatracker.ietf.org/doc/draft-wood-cfrg-aead-limits/ <https://datatracker.ietf.org/doc/draft-wood-cfrg-aead-limits/>   
> 
> Please give your views on whether this document should be adopted as a CFRG draft, and if so, whether you'd be willing to help work on it/review it. Please reply to this email (or in exceptional circumstances you can email CFRG chairs directly at [email-masked] <mailto:[email-masked]>).
> 
> Thank you,

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 22 Jul 2020 14:52:29 +0000

I support adoption. 

Regards,
Uri

> On Jul 22, 2020, at 10:37, Russ Housley <[email-masked]> wrote:
> 
>> Please give your views on whether this document should be adopted as a CFRG draft, and if so, whether you'd be willing to help work on it/review it. Please reply to this email (or in exceptional circumstances you can email CFRG chairs directly at [email-masked]).
>> 
>> Thank you,

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Wed, 22 Jul 2020 14:58:43 +0000

Hi Stanislav,

I support adoption.  The draft is well written and clear, but I have a few review comments below.

The confidentiality advantage definition measures the increase in probability that an attacker can "distinguish an AEAD ciphertext from the output of an ideal pseudorandom permutation (PRP).”   That should read “random function” instead of “ideal PRP”.  It would be good to add a reference that explains what the advantage means.

In Table 1, I suggest rewording “Size of the AEAD block cipher (in bits)” to “Number of bits per block”

The number q is defined both as the "number of protected messages” and “encryption attempts”; I think the former will make more sense to the reader.   It might be helpful to define q and v in terms of the number of invocations of the Authenticated Encryption and Authenticated Decryption functions from RFC5116.

Thanks,

David

On Jul 22, 2020, at 8:17 AM, Stanislav V. Smyshlyaev <[email-masked]<mailto:[email-masked]>> wrote:

Dear CFRG participants,

Thank you,
Stanislav (for the chairs)
_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg

---

From: Loganaden Velvindron <[email-masked]>
Date: Wed, 22 Jul 2020 19:00:15 +0400

I support adoption.

---

From: Mihir Bellare <[email-masked]>
Date: Wed, 22 Jul 2020 12:32:35 -0700

A question about this. Shouldn't the integrity bound of 5.1.2 also depend
on the number q of encryption attempts? Comparing to Eq. (15) of reference
[GCMProofs], it seems the draft has set q=0. I was wondering what is the
reason for that choice.

Mihir

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Jul 2020 13:48:20 +1000

On Thu, Jul 23, 2020, at 05:32, Mihir Bellare wrote:
> A question about this. Shouldn't the integrity bound of 5.1.2 also 
> depend on the number q of encryption attempts? Comparing to Eq. (15) of 
> reference [GCMProofs], it seems the draft has set q=0. I was wondering 
> what is the reason for that choice.

q as defined in the draft is the number of encryption attempts, so yes, q is indeed relevant.  In the analysis we did for QUIC there were cases where this resulted in a limited that affected q as much as it did v (or q' as used in the paper).

The authors have been discussing moving to an analysis based on https://eprint.iacr.org/2018/993 instead.  Assuming that goes ahead, we'll have a different result to report there.

---

From: Dan Harkins <[email-masked]>
Date: Fri, 24 Jul 2020 19:46:54 -0700

Hello,

   I very much support adoption of this draft.

   But as I mentioned on the virtual meeting I'd like to see some 
analysis on
the impact that the amount of AAD has on the integrity (and if 
applicable, the
encryption) bound. I know this draft is motivated by the use of AEAD 
algorithms
with QUIC and TLS where the AAD will be a fraction of the ciphertext, but it
should address other uses of AEAD algorithms that may do things differently.

   regards,

   Dan

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 26 Jul 2020 10:58:54 -0700

I support adoption and am willing to help to work on it.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 27 Jul 2020 14:31:28 +1000

Hi Dan,

> should address other uses of AEAD algorithms that may do things differently.

This is good feedback.  Counting the AAD alongside the plaintext was a simplification that made sense, but I agree that it isn't always that way.  From memory, CCM was one that had clear separation, and that was a factor of 2 difference (because the limits count applications of the block cipher).  Generally, I would not concern myself with a mere factor of 2, but the margins on some CCM variants are pretty dismal, so could probably benefit from the extra margin.

Chris opened an issue so that we don't forget this feedback: https://github.com/chris-wood/draft-wood-cfrg-aead-limits/issues/16

---

From: Hal Murray <[email-masked]>
Date: Thu, 30 Jul 2020 03:32:34 -0700

[email-masked] said:
> I know this draft is motivated by the use of AEAD  algorithms with QUIC and
> TLS where the AAD will be a fraction of the ciphertext, but it should address
> other uses of AEAD algorithms that may do things differently.

Another use case...

NTP (Network Time Protocol) uses UDP which is easy to forge.  It's getting a 
layer of authentication which uses AEAD.

The basic NTP packet is 48 bytes.  NTS bumps that up to roughly 200.  The 
client-to-server has no encryption.  The server-to-client encrypts roughly 100 
bytes.

That 100 bytes is a cookie which also uses AEAD.  The cookie contains a 
client-to-server and a server-to-client key for the above AEAD so the server 
doesn't have to maintain any per-client state.  The cookie key is maintained 
by the server.

The RFC as been approved but is still in the editor's queue.  Last draft here:
  https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-28

-- 
These are my opinions.  I hate spam.