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

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 <Kenny.Paterson@rhul.ac.uk> 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:
> 
> 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
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg