Re: [TLS] Consensus call on Implicit IV for AEAD

[Brian Smith <[e-mail]>]

Joseph Salowey <[e-mail]> wrote:
> In the interim meeting we had consensus to use an implicit IV for AEAD.  The
> proposal was to use the record sequence number and pad with zeros as
> described in pull request 155
> (https://github.com/tlswg/tls13-spec/pull/155/files).  This was also
> discussed in the IETF-92 meeting in Dallas along with options to change the
> offset.  The consensus was to stay with the original proposal.  We are
> posting to the mailing list to confirm this consensus. If you have comments,
> please reply by April 17, 2015.

Right now, based on my reading of the draft minutes, it doesn't look
like there was a complete, reasoned discussion of the issue during
IETF 92, nor is it clear to what extent any kind of consensus or
agreement was expressed during the meeting. Perhaps the draft minutes
are incomplete, but the statement that there was a consensus to stay
with the original proposal doesn't seem consistent with draft minutes.

Conversely, there is a clear record of my objection to the
zero-padding mechanism on the mailing list, and there seems to be at
least some mild support for my suggested alternative of deriving the
initial nonce from the keyblock. I think I provided a good
justification for moving to the randomized initial nonce. I think that
the concerns about it being more work to support a randomized nonce in
crypto modules that attempt to enforce a cryptographic boundary are
valid,m but those concerns outweigh the security benefits of starting
with a randomized nonce. I would be happy to work with the people who
expressed that concern to show that a randomized initial nonce can
work well and isn't unreasonably burdensome even in such products.

I've also thought of another reason why it seems useful to start with
a randomized initial nonce: As mentioned previously on this list, in
reality many AES-GCM implementations are far from being constant-time.
As far as I can reason, AES-GCM with predictable nonces, combined with
predictable plaintext and/or chosen plaintext, seem more likely to
attack via side channel attacks than AES-GCM with randomized nonces.
This is another significant advantage of randomization.

Finally, Ilari Liusvaara noted in the previous thread on the topic
that SSH already does exactly what I'm proposing, or very similar.
And, he also noted that IPSEC partially randomizes the nonce, as does
TLS 1.2. It seems like zero padding would be a regression from what
TLS 1.2 does, in terms of security. I find that concerning.

Here's exactly what Ilari Liusvaara wrote in [1]:
> As to what other protocols do with GCM, both SSH and IPSec do derive
> initial nonce out of key block (like TLS 1.2 does).
[...]
> As to what other protocols do with GCM, SSH derives a full block and
> increments that. IPSec derives just a prefix (like TLS 1.2).

Cheers,
Brian

[1] https://www.ietf.org/mail-archive/web/tls/current/msg15578.html