Re: [TLS] [Technical Errata Reported] RFC5288 (4694)
"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Mon, 16 May 2016 09:18 UTC
Return-Path: <Kenny.Paterson@rhul.ac.uk>
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 8684812D0AD for <tls@ietfa.amsl.com>; Mon, 16 May 2016 02:18:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.onmicrosoft.com
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 oCpt5fJUIuOo for <tls@ietfa.amsl.com>; Mon, 16 May 2016 02:18:25 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0603.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::603]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4FF12D09A for <tls@ietf.org>; Mon, 16 May 2016 02:18:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pvUX4hNc0VyaMuKeS7OKnyAfCQFBAVEqAZkKaWN80fA=; b=Eipm9FH9iD0qqADpV3H9TrPEg9xhzPRPxEi6Ldvsj0xVAiOTgAhw7We/LU45aSl9mDSiyAxt/z+H0t5q0F75F0aOb/pzRX8EOJnTi+7r92cMdmL/FUnM9tt0/7N8mN7CsRAShwAmQR7R3zlpx4bjVuC+GuWUuAI27P3SQNDKL00=
Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1824.eurprd03.prod.outlook.com (10.166.42.150) with Microsoft SMTP Server (TLS) id 15.1.497.12; Mon, 16 May 2016 09:18:02 +0000
Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0497.017; Mon, 16 May 2016 09:18:02 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Aaron Zauner <azet@azet.org>, Yoav Nir <ynir.ietf@gmail.com>
Thread-Topic: [TLS] [Technical Errata Reported] RFC5288 (4694)
Thread-Index: AQHRri1W38UTfUlAuUKfMuT++e8QN5+5VwH6//9seYCAAO5MMoAAU08AgADlyICAAAUQAIAAH0OAgAA4foCAABTQAA==
Date: Mon, 16 May 2016 09:18:02 +0000
Message-ID: <D35F4D97.6C5B2%kenny.paterson@rhul.ac.uk>
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> <9A043F3CF02CD34C8E74AC1594475C73F4C817BE@uxcn10-5.UoA.auckland.ac.nz> <a05f1e9d02a96721479a0de75e335cc4@esat.kuleuven.be> <A1FEF4A5-AC64-4832-904A-47768E5D5AF9@gmail.com> <54302B87-4730-4B8E-9F55-B33B89425A51@azet.org>
In-Reply-To: <54302B87-4730-4B8E-9F55-B33B89425A51@azet.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.3.160329
authentication-results: azet.org; dkim=none (message not signed) header.d=none;azet.org; dmarc=none action=none header.from=rhul.ac.uk;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [134.219.227.30]
x-ms-office365-filtering-correlation-id: 6cf346d1-caaa-4e49-642f-08d37d6afb33
x-microsoft-exchange-diagnostics: 1; VI1PR03MB1824; 5:EmwFrBP0tKEOSJEBQfRmOdn1sjUEKGgx9oEdpbGjhsWpzf99GbPBqQ8o7Db3vCfJgRy7QXToUyqtMh9qsJtqDu5briXfp9O3Kc/gii7u66B7TTdh+lBEH8/hhlzJjPf6RE3MTJ+0uoHnZa9ycqoNfw==; 24:WghHyY1SfDNflUvVhE3awSn0JGL6N6EpWafXwKiJNa/CQdY6P1eCyGdbtFA7KSICT/YaQ4j26dfy3/N/PJwUndccUwYBvq/l8dtMiJLtiPs=; 7:X+XBZDMcVNo+dT9PxXAUtPKBPsRqWoWW7IUi8a0VKiFzf/S+Z9MQjwOOXSxkUT6ULfO49YXDYCNd/tDqyoS8UCE7VDgOF2o76Bm9tt2YFVtctY5CPXbwSZ7fpHo95cWaTokoocoeGYq5WJA+lzKDKfms6GTp+Hz/tquS+BKTR2Y=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1824;
x-microsoft-antispam-prvs: <VI1PR03MB182420B6E1523811349AD894BC770@VI1PR03MB1824.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR03MB1824; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1824;
x-forefront-prvs: 09443CAA7E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(81166006)(106116001)(76176999)(5001770100001)(8936002)(77096005)(2950100001)(122556002)(87936001)(8676002)(102836003)(6116002)(66066001)(19580395003)(19580405001)(74482002)(5002640100001)(3846002)(50986999)(2900100001)(1220700001)(54356999)(3660700001)(2906002)(189998001)(86362001)(36756003)(93886004)(5004730100002)(5008740100001)(11100500001)(586003)(4326007)(4001350100001)(10400500002)(3280700002)(92566002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1824; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-ID: <6635B809C9CEA14D93C7FE30EBB58C31@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2016 09:18:02.3357 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1824
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Ag3C_puLyHl1APyVX1JwIuN-K04>
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 09:18:27 -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" <tls-bounces@ietf.org
on behalf of azet@azet.org> wrote:
>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
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Aaron Zauner
- [TLS] [Technical Errata Reported] RFC5288 (4694) RFC Errata System
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Peter Gutmann
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Rick van Rein
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Peter Gutmann
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Aaron Zauner
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Aaron Zauner
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Tony Arcieri
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Joseph Salowey
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Judson Wilson
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Peter Gutmann
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Atul Luykx
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Peter Gutmann
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Yoav Nir
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Aaron Zauner
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Paterson, Kenny
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Aaron Zauner
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Paterson, Kenny
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Aaron Zauner
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Paterson, Kenny
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Aaron Zauner
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Aaron Zauner
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Aaron Zauner
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Joseph Lorenzo Hall
- Re: [TLS] [Technical Errata Reported] RFC5288 (46… Megan Ferguson
- [TLS] [Errata Verified] RFC5288 (4694) RFC Errata System
- Re: [TLS] [Errata Verified] RFC5288 (4694) Peter Gutmann