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

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Mon, 16 May 2016 10:24 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 206F412D0EF for <tls@ietfa.amsl.com>; Mon, 16 May 2016 03:24:56 -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 NngERpktNAcl for <tls@ietfa.amsl.com>; Mon, 16 May 2016 03:24:54 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0677.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::677]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C7F12D0CE for <tls@ietf.org>; Mon, 16 May 2016 03:24:53 -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=FMCZApLSmxk8NwqDOS3a5TyKvBkT8tI7OS9WuidCHsU=; b=nmG3uAyV3wyGUrTF0UxydT8beFJBajhnp6uEEXLCoM10j5QWN4pAlY06swB5OTz4PQm+BUF3sky9RhUis9LTNVJFYTJkZT++kLH3c5Jc13nyieyNs6Jc1c0l1g6Jsheo6a8z+Qa+5WjlnnVJ9Twk4LkJ5fMkioxl1wpP9JoxsTU=
Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) with Microsoft SMTP Server (TLS) id 15.1.497.12; Mon, 16 May 2016 10:24:35 +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 10:24:35 +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//9CQAgAAUZ4D///Y9gAACesAA
Date: Mon, 16 May 2016 10:24:35 +0000
Message-ID: <D35F5D59.6C5EE%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> <D35F5460.6C5D0%kenny.paterson@rhul.ac.uk> <3B2C6D5A-939E-4539-B902-D4502EB9739C@azet.org>
In-Reply-To: <3B2C6D5A-939E-4539-B902-D4502EB9739C@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: 7ce96d9a-d281-4b95-1128-08d37d744779
x-microsoft-exchange-diagnostics: 1; VI1PR03MB1822; 5:N7twpS4YTokT3AZKzLvKrbHzKgS2eQ7of+AlKyHrq3euesF318XuPnimDUvDmzz1XlUVCxI0/EkmeSuG7mjepdWXwQEHiC77Lc89GoWodY6peZr5XGni6U53Q0gRfE00sjP3EptPS7z581TAEglrnQ==; 24:7FO/ydNGBCnmjrkKpo6hgB1VfS8Cu7AV7zLFWKB58gFeOSNIm5aqBZlcGR2qyVVTylFUpWA9BGRPNLtoLsnvnmm+wFAs2N5BNgaP4bM8qqw=; 7:G6VYl40rrHyNUSoX6Q8aZn0hOQaArD/kS53dwag1t6SKV3XXEvejA1E+aSUdVU3YSmx2kh1hIu6y46LbgzoMwOYlKhRXd3O+1ukglJ78z5zkUvDKtli0gt6Yht/U+rHRSgYei+gB/NYuDZZNL4Xa19gD23vHHLwC+jwadm3rUp0=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1822;
x-microsoft-antispam-prvs: <VI1PR03MB18224019F4449DACD860E071BC770@VI1PR03MB1822.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:VI1PR03MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1822;
x-forefront-prvs: 09443CAA7E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(54356999)(2900100001)(2950100001)(5004730100002)(11100500001)(8936002)(87936001)(5002640100001)(10400500002)(93886004)(586003)(76176999)(19580405001)(19580395003)(5008740100001)(189998001)(122556002)(77096005)(110136002)(3846002)(92566002)(50986999)(3280700002)(3660700001)(4001350100001)(106116001)(74482002)(36756003)(102836003)(6116002)(86362001)(2906002)(4326007)(81166006)(8676002)(66066001)(1220700001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1822; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-ID: <5950725919BA644392D4FB636B211649@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 10:24:35.6760 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1822
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/07_H09X01eok1b10d1laCxgJjO4>
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 10:24:56 -0000

Hi

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

>Hi Kenny,
>
>> On 16 May 2016, at 16:48, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk>
>>wrote:
>> 
>> 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.
>
>Ah, I see. Yes and we do not consider this in our paper at all. Maybe we
>should? Not sure how practical this is.

Good to get this cleared up. Yes, it's eminently practical to recover the
two plaintexts from their XOR assuming you have a good language model
(e.g. one can use a Markov model with a suitable memory length; this would
work for HTTP records, natural language, etc). To code it all up is not
trivial - I currently set it as a final year project for our undergrad
students, for example. The paper by Mason et al from CCS 2006 gives a nice
account of the whole business.

>
>> 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.
>
>The first step of our attack involves attacker controlled content. So yes
>(phishing, unauthenticated HTTP, selective company DPI etc.). In our
>example we use a local proxy to carry out the attack. I hope I can post a
>full version of the actual paper and PoC to this thread soon.

OK, makes sense now.

Cheers

Kenny 

>
>Aaron