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

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Mon, 16 May 2016 09:48 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 7258412D0BC for <tls@ietfa.amsl.com>; Mon, 16 May 2016 02:48:54 -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 MYdaKqDdPDGE for <tls@ietfa.amsl.com>; Mon, 16 May 2016 02:48:52 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0695.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::695]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE61D12D0B0 for <tls@ietf.org>; Mon, 16 May 2016 02:48:51 -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=p8rVZG+xelvJdB4wIzEhMu2WKCuO3dJREYjbxO2Ipos=; b=NanvI7wifpTbjoYyG5IDCWHKhU0dakcASgkAKk9uLGljN/1w3YCS+LULOfQyHQ0BEQaQ05paxuYnSblADCS9JZr488zrh+MtjNlS7dIj27/x7fL+BCY4o8xOu+i+yQhFk8UtA5nUJV2neZ/w6MoOGJ6x/8O9h1Frjct46KIgTTA=
Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1823.eurprd03.prod.outlook.com (10.166.42.149) with Microsoft SMTP Server (TLS) id 15.1.497.12; Mon, 16 May 2016 09:48:32 +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:48:31 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Aaron Zauner <azet@azet.org>
Thread-Topic: [TLS] [Technical Errata Reported] RFC5288 (4694)
Thread-Index: AQHRri1W38UTfUlAuUKfMuT++e8QN5+5VwH6//9seYCAAO5MMoAAU08AgADlyICAAAUQAIAAH0OAgAA4foCAABTQAP//9CQAgAAUZ4A=
Date: Mon, 16 May 2016 09:48:31 +0000
Message-ID: <D35F5460.6C5D0%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> <D35F4D97.6C5B2%kenny.paterson@rhul.ac.uk> <53384A13-5F80-4CF0-BD8F-F68E304ADF15@azet.org>
In-Reply-To: <53384A13-5F80-4CF0-BD8F-F68E304ADF15@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: 72c94029-f399-4b90-9ab7-08d37d6f3da8
x-microsoft-exchange-diagnostics: 1; VI1PR03MB1823; 5:sXe8wHH/RUGroM+95FtqkBotRpLGI6eT0ErQGVuTpyaQM1CmR6CqLz3l2Hs3MMoqfs5VGu28FaW5uNjQxaORJ/XvLLol0dP/uICQGxcrkqpUCk+i8qtOBGBfowYaj+C/JFp9ArRGdjx21+ZhjwAdNg==; 24:dEabUD1/wcQxgBEStynL6dMVEA7hQeWeWnKkUKe6RN3KU3DB5Q8DjOSCUrN1OeOWdf/9K3Z0mgKOZejVpwN1zu/hlNWRSZafeg3eQ92QJrs=; 7:xxzRWlZNLc2UJQx56xN4sOxH8chqss8MYcHsT2hE2EZXZE2glRQllo8mCfvjbtPR9AZjxHeFFz5z/FO8Ncu1Is8WT5dyV378olllxmFfIQ/8Aia58PW7i/eFKuEz9GDrgh3aF3LVWziIybVWXp7icKiOqGskUktJyBW77+v6M04=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1823;
x-microsoft-antispam-prvs: <VI1PR03MB1823A202BA82FD47ACB8F695BC770@VI1PR03MB1823.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)(3002001)(10201501046); SRVR:VI1PR03MB1823; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1823;
x-forefront-prvs: 09443CAA7E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(24454002)(87936001)(586003)(83506001)(122556002)(3280700002)(86362001)(5008740100001)(4326007)(3660700001)(8936002)(3846002)(102836003)(1220700001)(77096005)(54356999)(76176999)(36756003)(81166006)(2906002)(8676002)(5004730100002)(101416001)(189998001)(110136002)(4001350100001)(50986999)(6116002)(106116001)(5002640100001)(66066001)(93886004)(2950100001)(92566002)(10400500002)(19580395003)(74482002)(2900100001)(19580405001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1823; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-ID: <DA736D4F77236D4DA53A87866A8A97EE@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:48:31.7423 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1823
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/lNWVzehdLgXYNyKY3-vRbXEOpME>
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:48:54 -0000

Hi

On 16/05/2016 10:37, "Aaron Zauner" <azet@azet.org> wrote:

>Hi Kenny,
>
>> On 16 May 2016, at 16:18, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk>
>>wrote:
>> 
>> 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.
>
>Yes, I understood that, of course. But:
>
>> 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).
>
>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  


>
>Thank you,
>Aaron