Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

[Aaron Zauner <[e-mail]>]

On Sun, May 15, 2016 at 3:52 PM, Peter Gutmann <[e-mail]>
wrote:

> Aaron Zauner <[e-mail]> writes:
>
> >What do you think nonce stands for?
> >https://en.wikipedia.org/wiki/Cryptographic_nonce
>
> Well there's your first mistake, you're using Wikipedia as a reference.
> "nonce" is from medieval English, and predates modern cryptography and IVs
> by
> about 800 years.
>

Sure, I wouldn't cite Wikipedia in an academic publication, but it's what
pops up first if someone looks for "nonce" via a Google search. That was my
point. In general I think the wording should be more clear and a little
less of crypto-only nomenclature, thus -- maybe -- more convenient for
engineers. I suspect this was one of the issues with the document and why
we found vulnerable implementations in the first place. If you read
carefully and do your home-work the RFC in current form pretty much tells
you that you shouldn't re-use the nonce. Compared to TLS 1.3 and the
ChaCha20/Poly1305 document (and my OCB draft): the construction does not
prevent implementers from re-using the same nonce by mistake. Ideally it
would be handled in such a way that human error results in
non-interoperable implementations, like with said drafts and 1.3. But as
noted: it'll probably cause massive breakage among deployed implementations
and may even be the cause for more security issues with implementations to
pop up.

I know that the word "nonce" does have another meaning as well (BTW I'm not
a native english speaker, as you may have guessed). But do you think that
is really relevant in this case? If so, could you suggest better wording
for this specific paragraph?


>
> >In TLS nonce reuse allows us to attack the authentication key of GCM. Not
> the
> >actual master secret. There's no direct break of the confidentiality,
>
> If you reuse the IV/nonce in GCM (or more specifically CTR mode), you
> repeat
> the cipher stream.  An XOR makes it go away, so you lose any
> confidentiality.
>

This document is on TLS cipher-suites, not AES-GCM in general. This attack
isn't applicable here for various reasons. But I agree that the errata
could be clearer here. What'd be your suggestion as an addition or change?
I'm sure the relevant editors will be willing to amend/change my wording in
this errata.

More feedback is always appreciated. I suggest people on this list comment
as much as they think is relevant to this errata, we should get it perfect
this time around. It should be as clear as possible and be understood by
everyone - otherwise the errata doesn't make any sense.

Thanks,
Aaron