[TLS] [Errata Verified] RFC5288 (4694)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 24 November 2016 13:03 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299371298D3; Thu, 24 Nov 2016 05:03:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.699
X-Spam-Level:
X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUHEIwEjlLhd; Thu, 24 Nov 2016 05:03:09 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC38129953; Thu, 24 Nov 2016 05:03:09 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id AF3D3B8132E; Thu, 24 Nov 2016 05:03:08 -0800 (PST)
To: azet@azet.org, jsalowey@cisco.com, abhijitc@cisco.com, mcgrew@cisco.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20161124130308.AF3D3B8132E@rfc-editor.org>
Date: Thu, 24 Nov 2016 05:03:08 -0800 (PST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sfIzypxiy3pkPJOcWgWVaPjRXf8>
Cc: tls@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org
Subject: [TLS] [Errata Verified] RFC5288 (4694)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Nov 2016 13:03:11 -0000

The following errata report has been verified 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

--------------------------------------
Status: Verified
Type: Technical

Reported by: Aaron Zauner <azet@azet.org>;
Date Reported: 2016-05-14
Verified by: Stephen Farrell (IESG)

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

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.

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