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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Mon, 16 May 2016 03:32 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 60CAB12D0FF for <tls@ietfa.amsl.com>; Sun, 15 May 2016 20:32:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level:
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 bkLmr26fy1Gp for <tls@ietfa.amsl.com>; Sun, 15 May 2016 20:32:49 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89C3E12B01E for <tls@ietf.org>; Sun, 15 May 2016 20:32:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1463369568; x=1494905568; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PiI7LRmAleWNhLS/f0JN8DP+l1Q83irf0VaWKcqWyAY=; b=VH/PmPSolznUNB+oxHAJ5640iIq04ZcDkqSwramhP7DgHU4MjeLDpQmB n005VhrphH3sArvDW4ewlkVRlO8E6T5f3xAqwS8JpRrkNw67eHsDRKhDm HUI/eT3J3SZr+2qf/hFm2GAzi8iueAA+wFsg1T9LiYOLaNMaZ6pVrOBG7 CITSXXOhmN+HdxpN4Fs4sKwNiGV8+d8rtfnn1MhrZ3s5bUo/prVjNzFk4 7mHPcgDu3TU8BngurOZnspXa6zPDXDE2js1HSZZB8CE5vYupZrXohHjzP j4j/TQqEfgnmqz0GVMW35sMx+Upc79ucrrAhfizkdiJYZMeKm6ezmfyAS g==;
X-IronPort-AV: E=Sophos;i="5.24,625,1454929200"; d="scan'208";a="86098912"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 16 May 2016 15:32:46 +1200
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Mon, 16 May 2016 15:32:46 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Aaron Zauner <azet@azet.org>
Thread-Topic: [TLS] [Technical Errata Reported] RFC5288 (4694)
Thread-Index: AQHRri1VhVjCQK4OfkSA69GbEmT/Zp+5VwH6//9seYCAAO5MMv//iiUAgAGuf0g=
Date: Mon, 16 May 2016 03:32:45 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz>
References: <20160514082717.7997D180004@rfc-editor.org> <9A043F3CF02CD34C8E74AC1594475C73F4C80CD0@uxcn10-5.UoA.auckland.ac.nz> <CAN8NK9EaDQ-Pugi2j=3KcXrn5G-8mcXVs4O2HGCkH7h7GSKbbA@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C80F76@uxcn10-5.UoA.auckland.ac.nz>, <CAN8NK9Gn9iK72dBq3opQ2E_HEZyVB+ysCqo5JxMH8vHhy4gEEg@mail.gmail.com>
In-Reply-To: <CAN8NK9Gn9iK72dBq3opQ2E_HEZyVB+ysCqo5JxMH8vHhy4gEEg@mail.gmail.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.6.3.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/z0Ljuwiu776EpziN8J8Jw4S75n0>
Cc: "mcgrew@cisco.com" <mcgrew@cisco.com>, "tls@ietf.org" <tls@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [TLS] [Technical Errata Reported] 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: Mon, 16 May 2016 03:32:52 -0000

Aaron Zauner <azet@azet.org> 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.

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

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.