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

From: RFC Errata System <[email-masked]>
Date: Sat, 14 May 2016 01:27:17 -0700 (PDT)

The following errata report has been submitted for RFC5288,
"AES Galois Counter Mode (GCM) Cipher Suites for TLS".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5288&eid=4694

--------------------------------------
Type: Technical
Reported by: Aaron Zauner <[email-masked]>

Section: 6.1

Original Text
-------------
   AES-GCM security requires that the counter is never reused.  The IV
   construction in Section 3 is designed to prevent counter reuse.

   Implementers should also understand the practical considerations of
   IV handling outlined in Section 9 of [GCM].

Corrected Text
--------------
   Security of AES-GCM requires that the "nonce" (number used once) is 
   never reused. The IV construction in Section 3 does not prevent 
   implementers from reusing the nonce by mistake. It is paramount that 
   the implementer be aware of the security implications when a nonce 
   is re-used even once. 

   Nonce re-use in AES-GCM results in catastrophic failure of it's
   authenticity. Hence, TLS sessions can be effectively attacked through
   forgery by an adversary. In the case of e.g. HTTPS sessions content
   injection is possible, XSS and other attack vectors.

Notes
-----
Obviously the original wording is so ambiguous that implementers got it wrong in the real world. Related to: https://www.blackhat.com/us-16/briefings.html#nonce-disrespecting-adversaries-practical-forgery-attacks-on-gcm-in-tls

It may be worth adding a reference to [JOUX] http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/...38.../GCM/Joux_comments.pdf and maybe the paper we're intending to release on the actual HTTPS forgery/injection attack.

I'd actually like to change the nonce construction to that of the ChaCha20/Poly1305 document, but I figure this will cause massive breakage for already deployed implementations. TLS 1.3 fixes this issue per design.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5288 (draft-ietf-tls-rsa-aes-gcm-03)
--------------------------------------
Title               : AES Galois Counter Mode (GCM) Cipher Suites for TLS
Publication Date    : August 2008
Author(s)           : J. Salowey, A. Choudhury, D. McGrew
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 15 May 2016 03:27:55 +0000

RFC Errata System <[email-masked]> writes:

>The following errata report has been submitted for RFC5288, "AES Galois
>Counter Mode (GCM) Cipher Suites for TLS".

I think the erratum needs an erratum.  Firstly, "nonce" doesn't mean "number
used once", and secondly nonce re-use in AES-GCM doesn't just result in
"catastrophic failure of it's authenticity", it results in catastrophic
failure of the entire mode, both confidentiality and integrity/authenticity.

Peter.

---

From: Rick van Rein <[email-masked]>
Date: Sun, 15 May 2016 20:43:39 +0200

Hi,

> failure of the entire mode, both confidentiality and integrity/authenticity.

I'd like to add that I don't see a difference between a "failure" and a
"catastrophic failure".  It's probably better to stay away from subjective
words like that.

-Rick

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 15 May 2016 08:52:56 +0000

Aaron Zauner <[email-masked]> 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.

>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.

Peter.

---

From: Aaron Zauner <[email-masked]>
Date: Sun, 15 May 2016 13:39:15 +0700

Hi,

On May 15, 2016 10:28, "Peter Gutmann" <[email-masked]> wrote:
> I think the erratum needs an erratum.

No problem, but:
>Firstly, "nonce" doesn't mean "number

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,
just authenticity (and thus integrity). For HTTPS this allows us to inject
content which then may lead to a compromise of the session confidentiality.

Maybe I misunderstood what you meant.

Aaron

> Peter.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Aaron Zauner <[email-masked]>
Date: Sun, 15 May 2016 20:50:20 +0700

> "nonce" is from medieval English, and predates modern cryptography and IVs

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?

> the

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

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 15 May 2016 17:49:37 -0700

On Sun, May 15, 2016 at 6:50 AM, Aaron Zauner <[email-masked]> wrote:

> 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?
>

I think "nonce" meaning number used once is fine for cryptographic
purposes.

I'd also note Adam Langley has taken to pronouncing the word nonce as
"n-once", at least at this year's RWC.

-- 
Tony Arcieri

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 15 May 2016 19:23:21 -0700

> "catastrophic failure".  It's probably better to stay away from subjective
[Joe] It would be better to state what actually fails:

"Nonce re-use in AES-GCM allows for the recovery of the authentication key
resulting in complete failure of the mode's authenticity.  Hence, TLS
sessions can be effectively attacked through forgery by an adversary.  This
enables an attacker to inject data into the TLS allowing for XSS and other
attack vectors. "

---

From: Judson Wilson <[email-masked]>
Date: Sun, 15 May 2016 20:24:12 -0700

The way I read the first draft, the wording made it sound like "nonce" was
a contraction of the words "(N)umber used (once)". I thought I learned
something. Then I looked it up, and unfortunately, that is not the case, as
cute as it would be.

That is the problem with the wording. Even if a nonce is number that is
only used once, the word is not derived from omitting letters from the
phrase, so we shouldn't mislead people into believing that. Removing the
scare quotes is sufficient to prevent this misunderstanding.

On Sun, May 15, 2016 at 7:23 PM, Joseph Salowey <[email-masked]> wrote:

> "Nonce re-use in AES-GCM allows for the recovery of the authentication
> key resulting in complete failure of the mode's authenticity.  Hence, TLS
> sessions can be effectively attacked through forgery by an adversary.
> This enables an attacker to inject data into the TLS allowing for XSS and
> other attack vectors. "
>
>
>
>> -Rick
>>
>
>

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 16 May 2016 03:32:45 +0000

Aaron Zauner <[email-masked]> writes:

>If so, could you suggest better wording for this specific paragraph?

I would just leave it as "nonce", with no attempt at a definition.  If there
are any cryptographers who don't know what a nonce is they can look it up.  If
they use an authoritative source they'll get the correct definition, and if
they use Wikipedia they'll get Wikipedia's definition.

>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 doesn't make it correct, it just makes it the most popular misconception.
For another crypto example, look up HDCP and Blom's Scheme on Wikipedia, and
see how much resemblance that bears to reality.

>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.

Since the paper for the Black Hat talk hasn't been published, I don't know
what the actual problem is (and by extension what the various reasons are),
but if you reuse a nonce I can't see how it would affect auth but not
confidentiality, since you'd be generating a repeated cipher stream.  If
confidentiality isn't affected then there should probably be a note explaining
why, since my immediate reaction to a comment about nonce reuse would be
"complete failure of the entire mode".

Peter.

---

From: Atul Luykx <[email-masked]>
Date: Mon, 16 May 2016 05:50:52 +0200

Here's a possible re-write of the second paragraph:

Nonce re-use in AES-GCM results in failure of both confidentiality and 
authenticity. Not only will confidentiality be breached by leaking the 
XOR of any two packets processed under the same nonce, but TLS sessions 
can also be attacked through forgery by an adversary. For example, in 
the case of HTTPS sessions content injection, XSS, and other attack 
vectors are possible.

Original text:

On 2016-05-16 05:32, Peter Gutmann wrote:
>> could

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 16 May 2016 04:02:52 +0000

>Here's a possible re-write of the second paragraph:

That looks good.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 May 2016 08:42:45 +0300

> On 16 May 2016, at 6:50 AM, Atul Luykx <[email-masked]> wrote:
> 
> Nonce re-use in AES-GCM results in failure of both confidentiality and authenticity. Not only will confidentiality be breached by leaking the XOR of any two packets processed under the same nonce, but TLS sessions can also be attacked through forgery by an adversary. For example, in the case of HTTPS sessions content injection, XSS, and other attack vectors are possible.

s/XOR of any two packets/XOR of any two records/

This is TLS, not IPsec. And yes, this looks fine.

Yoav

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 16 May 2016 16:04:57 +0700

Hi,

In the TLS case, RFC5288 defines the following IV construction (Section 3):

```
             struct {
                opaque salt[4];
                opaque nonce_explicit[8];
             } GCMNonce;

   The salt is the "implicit" part of the nonce and is not sent in the
   packet.  Instead, the salt is generated as part of the handshake
   process: it is either the client_write_IV (when the client is
   sending) or the server_write_IV (when the server is sending).  The
   salt length (SecurityParameters.fixed_iv_length) is 4 octets.
```

As you can see the salt is is implicitly derived from the *_write_IV. We have no influence on this part of the IV construction, whereas the `nonce_explicit` is generated by the implementer. I don't see a way how we could XOR some records and compromise confidentiality, we've checked, believe me. If somebody can come up with an attack though, that'd be nice.

On the catastrophic part: I'd like to keep it around. I don't think it deserves a name like a hurricane, but catastrophic is pretty spot on in this regard.

w.r.t. nonce/n-nonce: either we keep the parentheses with "number used once" around or we change it to n-once as suggested by Tony and beautifully pronounced by Adam Langley :)

Aaron

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 16 May 2016 09:18:02 +0000

Hi Aaron,

If AES-GCM ever generates two ciphertexts using the same key and the same
96-bit nonce, then the underlying CTR-mode keystreams will be the same.
XORing the ciphertexts together then produces the XOR of the plaintexts,
from which the two individual plaintexts can be recovered (usually) with
high probability using standard techniques (see the paper by Mason et al
at CCS 2006 for a full account of this step).

In the TLS context, this means using the same 64-bit nonce_explicit in a
given connection - because then opaque salt will be the same 32-bit value.

This condition is detectable by an adversary because the nonce_explicit
part is sent on the wire (the clue is in the name!).

You don't need to know the full 96-bit nonce to carry out the attack.

Once you've recovered a plaintext, you can also recover the corresponding
CTR-mode keystream. Together with the integrity key, this now enables
packet forgery attacks for arbitrary plaintexts (of length limited by that
of the known keystream).

IIRC, we discussed this by e-mail some months back...

Regards,

Kenny

On 16/05/2016 10:04, "TLS on behalf of Aaron Zauner" <[email-masked]
on behalf of [email-masked]> wrote:

>As you can see the salt is is implicitly derived from the *_write_IV. We
>have no influence on this part of the IV construction, whereas the
>`nonce_explicit` is generated by the implementer. I don't see a way how
>we could XOR some records and compromise confidentiality, we've checked,
>believe me. If somebody can come up with an attack though, that'd be nice.
>
>On the catastrophic part: I'd like to keep it around. I don't think it
>deserves a name like a hurricane, but catastrophic is pretty spot on in
>this regard.
>
>w.r.t. nonce/n-nonce: either we keep the parentheses with "number used
>once" around or we change it to n-once as suggested by Tony and
>beautifully pronounced by Adam Langley :)
>
>Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 16 May 2016 16:37:00 +0700

Hi Kenny,

> On 16 May 2016, at 16:18, Paterson, Kenny <[email-masked]> wrote:
> 
> Hi Aaron,
> 

> packet forgery attacks for arbitrary plaintexts (of length limited by that

Right. Joux's attack doesn't recover a plaintext of the actual TLS session, we attack GHASH in this case and factor possible candidate polynomials of the /authentication key/. In this context I assume 'confidentiality compromise' with: somebody can recover plaintext from captured TLS records. At least in our attack this isn't the case. We're merely able to inject malicious content. Am I amiss? Or am I just confused about nomenclature?

Thank you,
Aaron

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 16 May 2016 09:48:31 +0000

Hi

On 16/05/2016 10:37, "Aaron Zauner" <[email-masked]> wrote:

>Right. Joux's attack doesn't recover a plaintext of the actual TLS
>session, we attack GHASH in this case and factor possible candidate
>polynomials of the /authentication key/. In this context I assume
>'confidentiality compromise' with: somebody can recover plaintext from
>captured TLS records. At least in our attack this isn't the case. We're
>merely able to inject malicious content. Am I amiss? Or am I just
>confused about nomenclature?

I think you are amiss.

Maybe the confusion is this: in your authenticity attack, you do recover
the GHASH key, and the effect is catastrophic. In the confidentiality
attack, one can recover plaintexts for the records with repeated nonces,
but not the encryption key. The effect may be bad - but it's perhaps not
as catastrophic in practice as the authenticity attack.

Think about it this way: for your injection attack, you need to recover
the CTR keystream - otherwise you couldn't properly AES-GCM-encrypt your
chosen plaintext record for the injection. But if you recovered the
keystream as part of your attack, then you've also recovered the plaintext
for the original record.

Or maybe in your injection attack you were assuming you already *knew* the
plaintext? That would make sense, I guess - a lot easier then to recover
the keystream than doing the "undoing the XOR" attack needed to recover
P_1 and P_2 from P_1 XOR P_2.

Cheers

Kenny

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 16 May 2016 17:15:05 +0700

Hi Kenny,

> On 16 May 2016, at 16:48, Paterson, Kenny <[email-masked]> wrote:
> 

Ah, I see. Yes and we do not consider this in our paper at all. Maybe we should? Not sure how practical this is.

> P_1 and P_2 from P_1 XOR P_2.

The first step of our attack involves attacker controlled content. So yes (phishing, unauthenticated HTTP, selective company DPI etc.). In our example we use a local proxy to carry out the attack. I hope I can post a full version of the actual paper and PoC to this thread soon.

Aaron

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 16 May 2016 10:24:35 +0000

Hi

>should? Not sure how practical this is.

Good to get this cleared up. Yes, it's eminently practical to recover the
two plaintexts from their XOR assuming you have a good language model
(e.g. one can use a Markov model with a suitable memory length; this would
work for HTTP records, natural language, etc). To code it all up is not
trivial - I currently set it as a final year project for our undergrad
students, for example. The paper by Mason et al from CCS 2006 gives a nice
account of the whole business.

>The first step of our attack involves attacker controlled content. So yes
>(phishing, unauthenticated HTTP, selective company DPI etc.). In our
>example we use a local proxy to carry out the attack. I hope I can post a
>full version of the actual paper and PoC to this thread soon.

OK, makes sense now.

Cheers

Kenny

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 17 May 2016 01:41:39 +0700

Hi Kenny,

> On 16 May 2016, at 17:24, Paterson, Kenny <[email-masked]> wrote:
> 

Yes, we (I?) mixed up two different attack vectors.

I wasn't aware of the CCS 2006 paper, that was long before I got into TLS, to be honest. I'll certainly read up on it. It's a really nice undergrad project, I'm always happy to hear that universities do teach practical attacks, let their students write PoC for them etc., unfortunately I've seen quite the opposite on a lot of occasions and lecturers teaching on out-dated crypto protocols and primitives or trying to explain simple designs with very "esoteric" slide-decks.

Anyhow: what has been said in the thread already on the attack does of course make sense to me, but it isn't what I was referring to w.r.t. our attack contribution. So I think I'm to blame for the confusion here. I think both attacks are worth noting in the Errata as some implicitly already mentioned before. Does anyone disagree on that?

> OK, makes sense now.

Perfect :)

Thank you for the feedback,
Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 20 May 2016 00:11:12 +0700

Hi,

> The first step of our attack involves attacker controlled content. So yes (phishing, unauthenticated HTTP, selective company DPI etc.). In our example we use a local proxy to carry out the attack.…

https://eprint.iacr.org/2016/475
https://github.com/nonce-disrespect/nonce-disrespect

(data-sets should be indexed by scans.io in a bit)

Aaron