RFC 5288, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", August 2008
Note: This RFC has been updated by RFC 9325Source of RFC: tls (sec)
See Also: RFC 5288 w/ inline errata
Errata ID: 4694
Publication Format(s) : TEXT
Reported By: Aaron Zauner
Date Reported: 2016-05-14
Verifier Name: Stephen Farrell
Date Verified: 2016-11-24
Section 6.1 says:
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].
It should say:
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 reused even once. Nonce reuse 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.
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.