Subject: [Cfrg] Second RGLC on "AES-GCM-SIV"

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 16 Jan 2018 16:32:35 +0000

Dear CFRG participants,

This message starts a second 2-week RGLC on "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" (draft-irtf-cfrg-gcmsiv-07), that will end on January 30th. See https://datatracker.ietf.org/doc/draft-irtf-cfrg-gcmsiv for the latest version of the draft.

We are having a second last call because, although there only were small changes to the draft in going from 06 to 07, we also had the benefit of new security analysis on the draft:

http://www.cs.ucsb.edu/~tessaro/papers/BHT17.pdf

We also had some productive discussion on the benefits of using POLYVAL versus GHASH during the previous last call period, with the thread beginning at:

https://www.ietf.org/mail-archive/web/cfrg/current/msg09333.html

Please send your comments, as well as expression of support to publish as an RFC (or possible reasons for not doing so) in reply to this message or directly to CFRG chairs. Your feedback will help chairs to decide whether the document is ready for review by IRSG and subsequent publication as an RFC.

Thank you,

Alexey and Kenny

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 16 Jan 2018 09:17:17 -0800

Looks good to me

On Tue, Jan 16, 2018 at 8:32 AM, Paterson, Kenny <[email-masked]>
wrote:

> Dear CFRG participants,
>
> This message starts a second 2-week RGLC on "AES-GCM-SIV: Nonce
> Misuse-Resistant Authenticated Encryption" (draft-irtf-cfrg-gcmsiv-07),
> that will end on January 30th. See https://datatracker.ietf.org/
> doc/draft-irtf-cfrg-gcmsiv for the latest version of the draft.
>
> We are having a second last call because, although there only were small
> changes to the draft in going from 06 to 07, we also had the benefit of new
> security analysis on the draft:
>
> We also had some productive discussion on the benefits of using POLYVAL
> versus GHASH during the previous last call period, with the thread
> beginning at:
>
> Please send your comments, as well as expression of support to publish as
> an RFC (or possible reasons for not doing so) in reply to this message or
> directly to CFRG chairs. Your feedback will help chairs to decide whether
> the document is ready for review by IRSG and subsequent publication as an
> RFC.
>
> Thank you,
>
> Alexey and Kenny
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

-- 
Tony Arcieri

---

From: Russ Housley <[email-masked]>
Date: Tue, 16 Jan 2018 15:13:34 -0500

I think that the IRTF should publish this document as an RFC.

Russ

On Tue, Jan 16, 2018 at 8:32 AM, Paterson, Kenny <[email-masked] <mailto:[email-masked]>> wrote:
Dear CFRG participants,

This message starts a second 2-week RGLC on "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" (draft-irtf-cfrg-gcmsiv-07), that will end on January 30th. See https://datatracker.ietf.org/doc/draft-irtf-cfrg-gcmsiv <https://datatracker.ietf.org/doc/draft-irtf-cfrg-gcmsiv> for the latest version of the draft.

http://www.cs.ucsb.edu/~tessaro/papers/BHT17.pdf <http://www.cs.ucsb.edu/~tessaro/papers/BHT17.pdf>

https://www.ietf.org/mail-archive/web/cfrg/current/msg09333.html <https://www.ietf.org/mail-archive/web/cfrg/current/msg09333.html>

Thank you,

Alexey and Kenny

---

From: Ronald Tse <[email-masked]>
Date: Thu, 18 Jan 2018 19:27:57 +0000

Dear Chairs,

I fully support the publication of this document as an RFC.

Kind regards,
Ron

_____________________________________

Ronald Tse
Ribose Inc.

On Jan 17, 2018, at 12:32 AM, Paterson, Kenny <[email-masked]<mailto:[email-masked]>> wrote:

Dear CFRG participants,

Thank you,

Alexey and Kenny

---

From: "Paterson, Kenny" <[email-masked]>
Date: Fri, 19 Jan 2018 16:00:35 +0000

Hi,

One comment from me on the AES-GCM-SIV draft, with my co-chair hat on:

I believe it would be preferable if the final version of this draft were to also refer to the analysis of Bose-Hoang-Tessaro. It looks like the paper is now accepted to Eurocrypt 2018 (see https://eurocrypt.iacr.org/2018/acceptedpapers.html) so there should be a stable reference pretty soon. Perhaps in the "Security Considerations" section?

Thanks,

Kenny 

-----Original Message-----
From: "Paterson, Kenny" <[email-masked]>
Date: Tuesday, 16 January 2018 at 16:32
To: "[email-masked]" <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>, Yehuda Lindell <[email-masked]>, Adam Langley <[email-masked]>, Shay Gueron <[email-masked]>
Subject: Second RGLC on "AES-GCM-SIV"

    Dear CFRG participants,

    

    
    Thank you,
    
    Alexey and Kenny

---

From: Yoav Nir <[email-masked]>
Date: Sat, 20 Jan 2018 21:10:20 +0200

Hi

The document looks good to me and I support publication.

CFRG documents are often used as input and reference to IETF document that will have names like “AES-GCM-SIV and its use in [protocol X]”.  For this reason they need to have some text explaining applicability. 

This document has one sentence at the end of section 1:

   We suggest that these AEADs be considered in any situation where
   there is the slightest doubt about nonce uniqueness.

I don’t believe that this is enough. IMO two things are missing:

The text should list some cases where there is such slight doubt. When there is a single encryptor for network traffic such as in TLS, IPsec and SSH, it’s easy for the encryptor to keep a counter and then there is no doubt that nonces are not repeated. So what are the scenarios where there may be such doubt?  I can think of two: multi-encryptor such as in multicast IPsec (RFC 6407), and cases where one or more encryptors encrypt and decrypt data across reboots such as for encrypting files or storage.

The other missing piece is what to do when nonce uniqueness cannot be guaranteed. The document has two things to say about this:
"we do not recommend using a fixed nonce as a policy”
"This also means that selecting nonces at random is a safe practice with AES-GCM-SIV”

I’d prefer a stronger statement:
“We suggest that these AEADs be considered in any situation where nonce uniqueness cannot be guaranteed” in the introduction, and
“Nonce uniqueness cannot be guaranteed but we would like to minimise collisions. To achieve this it is RECOMMENDED that nonces are randomly generated” - not sure where this goes.  Maybe in section 9 or maybe in the introduction.

The reason for this recommendation is that using a fixed nonce is bad, but using counters may lead to pairwise collisions between two encryptors, and that’s not ideal either. If we can’t do any better than recommending randomness is the best.  There is still the issue of encryptors having too little randomness. One approach can be to use counters with a random starting point if we can assume that the encryptors have 96 bits of randomness but not more, but I don’t think there’s a better general solution to poor randomness than the discussion at the top of page 12. I guess it will have to do.

Yoav

> On 16 Jan 2018, at 18:32, Paterson, Kenny <[email-masked]> wrote:
> 
> Dear CFRG participants,
>

---

From: Stefano Tessaro <[email-masked]>
Date: Sat, 20 Jan 2018 11:26:08 -0800

> The reason for this recommendation is that using a fixed nonce is bad, but
> using counters may lead to pairwise collisions between two encryptors, and
> that’s not ideal either.

In addition to this, one of the points highlighted by our multi-user
analysis (linked above) is that there is a great security benefit in
the multi-user/multi-key setting if we can ensure that each particular
nonce value is re-used by a small number of users only. This is of
course true if nonces are chosen with sufficient randomness. (Our
security bounds show how security degrades as nonces are re-used by
more users.) This is particularly important when using 128-bit keys,
less relevant with longer (256 bits) keys.

Best,
Stefano

-- 
Stefano Tessaro
Assistant Professor of Computer Science
University of California, Santa Barbara
http://cs.ucsb.edu/~tessaro/

---

From: Tony Arcieri <[email-masked]>
Date: Sat, 20 Jan 2018 12:01:24 -0800

> less relevant with longer (256 bits) keys.

Would it be useful to include some text similar to the beginning of the
"Shifting Language" section from https://eprint.iacr.org/2015/189.pdf ?

The paper defining MRAE [54] never suggested that nonce-reuse was OK; it
> said that an MRAE scheme must do “as well as possible with whatever IV is
> provided”

-- 
Tony Arcieri