Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications

[Taylor R Campbell <[e-mail]>]

   Date: Fri, 15 Apr 2016 13:46:19 -0700 (PDT)
   From: "Dan Harkins" <[e-mail]>

     Way back at IETF70 I proposed some ciphersuites for TLS using
   AES-SIV (RFC 5297). AES-SIV has the same nonce-misuse properties
   as AES-GCM-SIV but it's a 2-pass cipher mode. The general response
   I received can be summarized as "we don't need nonce misuse because
   the nonce is not part of the API that Joe User, who may be ignorant
   of nonce usage issues, calls and everyone writing a TLS implementation
   knows what he or she is doing so it's not a problem."

I drafted the following message in reply:

`For TLS, it is not a matter of ``all the implementors know what
 they're doing''.  Rather, if you reuse a nonce, your implementation
 is simply broken and will immediately, noisily fail to interoperate.

`For that case, AES-GCM-SIV is strictly less secure than AES-GCM
 because AES-GCM-SIV effectively uses randomly chosen 96-bit nonces
 and hence has a small birthday bound before an accidental internal
 nonce reuse (which is catastrophic).  AES-GCM nonces, in contrast,
 are guaranteed never to repeat in a TLS conversation.'

But then, on fact-checking myself, I discovered that the AES-GCM
cipher suites in TLS (RFC 5288) do not actually mandate the use of the
message sequence number as the nonce, which would have the fail-early
fail-closed effect I described -- instead the senders pick nonces on
their own arbitrarily and transmit them alongside the message, and the
receivers accept any nonces they receive.