Re: [TLS] Consensus call for keys used in handshake and data messages
"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Fri, 17 June 2016 16:46 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 15A7012D85F for <tls@ietfa.amsl.com>; Fri, 17 Jun 2016 09:46:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 zuuSXAji8_rk for <tls@ietfa.amsl.com>; Fri, 17 Jun 2016 09:46:03 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0077.outbound.protection.outlook.com [104.47.1.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86C9912D85E for <tls@ietf.org>; Fri, 17 Jun 2016 09:46:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=owmHEXrSwLDg78lkgy++t7kaalrAMfZkN64xHTvYjFg=; b=eW8Auxdcc2WEL+OCy1rpnCAJXR/37rJQ/8oadIW47H9j5BXmpwWqySHWMs9S4kwO5Y47mSvEjNES69mhIDsga2jsDf6MHNecZzXs+jj5Rm6HDuHT8jSh79w1Ma787ELAylbS9+XNqgddIjmitZSoLjVSiPW5PeyyaH8a2j2hgm4=
Received: from AM4PR03MB1811.eurprd03.prod.outlook.com (10.167.88.147) by AM4PR03MB1809.eurprd03.prod.outlook.com (10.167.88.145) with Microsoft SMTP Server (TLS) id 15.1.517.8; Fri, 17 Jun 2016 16:46:00 +0000
Received: from AM4PR03MB1811.eurprd03.prod.outlook.com ([10.167.88.147]) by AM4PR03MB1811.eurprd03.prod.outlook.com ([10.167.88.147]) with mapi id 15.01.0517.014; Fri, 17 Jun 2016 16:45:59 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Ilari Liusvaara <ilariliusvaara@welho.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Consensus call for keys used in handshake and data messages
Thread-Index: AQHRyLe6z4Pt+m6ycEKUe6eKsuHzbw==
Date: Fri, 17 Jun 2016 16:45:59 +0000
Message-ID: <D389E54F.6EA0D%kenny.paterson@rhul.ac.uk>
References: <CAOgPGoDRZdJN7DY10tDoEEidVkxeKabCcW_U3vQqaaH6x162gw@mail.gmail.com> <1465977655.20266.3.camel@redhat.com> <26741B4E-3C0F-4E0C-AB44-F7DFCCEFED53@gmail.com> <871t3y1s99.fsf@alice.fifthhorseman.net> <20160615162338.GA10695@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20160615162338.GA10695@LK-Perkele-V2.elisa-laajakaista.fi>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.4.160422
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kenny.Paterson@rhul.ac.uk;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [134.219.148.47]
x-ms-office365-filtering-correlation-id: 5c63ddeb-7249-4129-0966-08d396cedcb3
x-microsoft-exchange-diagnostics: 1; AM4PR03MB1809; 6:Xq3YUxQtM1Rw+k3QOTbvLbBAHc9nBx/Fp84vjCW2R9IL4iWbV+Wa8V3h1Fp8G+/lik6h27D0btb66SbKUWA5I/Tn5dxpMSzhA4xSR1AWf/E2amxz0Op4chnRo8P4o0EEbSTnAAAjveevUEsjx6IpbhOKQ20BAVqTFIBrygEBjxw4KGiMybK78qPgVR2O4TCQzJ3rCAHR/jgbIEkr4hMYd2VcX4uAv6/9M94WVzPjwEQfkL4O6fBiooCtRAMHJOf7inFXXuTERZx2o7l2D7gd4knDiy8t7NaVOPIKKQAaNdc=; 5:9cwiWG3a7fSofkR8S6K3AHakRYV6AufmdLTSk8CNDthiegr+tk1DF1vABGpRume8eJEMWf3Wsa7aTF677YoiXsOUCyR3XdnQa+KVka0gXTF2VVNlftYeCafRg4XrleZSN3alt/1qWXF9p4T+5oXSTA==; 24:zN3panra872i5Avja4b0N6TM+5W95McSKe63jFeidMtkaio6toNixzCWSaaaKBsiATv2QdmT8uvZRP7dh5MuHplrxI2HxncGvN/hMSDcSyE=; 7:vzLxdIFtQtrw/gATnC5tFeASp+GaRZzFNW+xzKTvtpBKf62LS8PLJa0juASbKvA/XML5txR/3fxWYYQGdWu04wyYgfONUtN1E44GBv5tIEquoA04bc09g8fB1f0nbjs1U2raMC1ONuRop+BdnlOQ4r+NGrzIUMxUjx9nkVeAhEILqGOMDXFnY6hntWegQAe7JVfCbFW+vNLP/YR9Ro0TCw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR03MB1809;
x-microsoft-antispam-prvs: <AM4PR03MB180957F8FFB34A9B29A77FDBBC570@AM4PR03MB1809.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AM4PR03MB1809; BCL:0; PCL:0; RULEID:; SRVR:AM4PR03MB1809;
x-forefront-prvs: 09760A0505
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(24454002)(377424004)(189002)(86362001)(5004730100002)(36756003)(66066001)(6116002)(102836003)(3846002)(3660700001)(3280700002)(586003)(93886004)(68736007)(83506001)(92566002)(2501003)(189998001)(5002640100001)(19580395003)(4001350100001)(19580405001)(122556002)(97736004)(107886002)(5001770100001)(105586002)(54356999)(76176999)(15650500001)(50986999)(10400500002)(74482002)(15975445007)(2900100001)(106356001)(106116001)(2950100001)(87936001)(2906002)(101416001)(8936002)(8676002)(77096005)(81156014)(81166006)(7846002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR03MB1809; H:AM4PR03MB1811.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE;
received-spf: None (protection.outlook.com: rhul.ac.uk does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <1F09C967808652428D9DE322D89AC861@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2016 16:45:59.8861 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1809
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8w5st3DL0Km5-hgCCX3F1TlUyhw>
Subject: Re: [TLS] Consensus call for keys used in handshake and data messages
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: Fri, 17 Jun 2016 16:46:05 -0000
Hi Ilari, On 15/06/2016 17:23, "TLS on behalf of Ilari Liusvaara" <tls-bounces@ietf.org on behalf of ilariliusvaara@welho.com> wrote: >On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote: >> On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: >> >> To be clear, we're being asked to trade these things off against each >> other here, but there are other options which were ruled out in the >> prior framing of the question which don't rule either of them out. >> >> In particular, if we're willing to pay the cost of a slightly more >> complex key schedule (and an increased TLS record size), we could have >> "packet header" keys which protect the content-type itself for all >> non-cleartext TLS records. If we do that, these keys might as well also >> be used to protect the TLS record size itself. This would result in an >> opaque data stream (though obviously record size would still leak in >> DTLS, and timing and framing is still likely to leak the record size in >> the lowest-latency TLS applications). > >Does this need to enlarge TLS record size? Why doesn't encrypting the >content-type/length and then authenticating those off main MAC work >(that's how SSH with CHACHA20-POLY1305 does things)? I presume >problems from header-flipping (tho in TLS that will kill the >connection if you try...) Yes, this can be made to work in the style adopted for ChaCha20-Poly1305 in SSH. However, because the record length is now determined by data that is encrypted, and you need to know its value in order to "receive" enough bytes to have obtained the record MAC which comes at the end of the record, and because the record MAC can't now be checked before you make use of the length field .... you need to be a bit careful. But it can be proved secure when using certain AEAD schemes as the basis, and in a suitable security model that allows for decryption in part depending on data that was acted on before it was unauthenticated and for delivery of records in a fragmented fashion. Just don't use CBC mode for the encryption :-) (A more serious point: this kind of thing would not be secure using a generic EtM-style AEAD scheme as the building block.) In fact, if you're careful enough with the analysis, you can improve a bit on the ChaCha20-Poly1305 construction in SSH: it currently uses a 64-byte key, with 32 bytes being used to create one ChaCha20 context for encrypting the length field and another 32 bytes being used to create a second ChaCha20 context for encrypting the rest. This is not necessary if you construct the ChaCha20 nonces/IVs in a slightly different way - a single ChaCha20 context suffices. The same ought to be true in the slightly different TLS setting, and also for an AES-GCM-based construction. Happy to follow-up with discussion of more details if people seriously want to consider this kind of construction for TLS 1.3. It's not what's currently on the table, but maybe it should be... Cheers Kenny > >Also, in DTLS, there could be issues switching the encryption on >(but then, looks like DTLS 1.3 has other unsolved problems >currently..) > > >-Ilari > > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls
- Re: [TLS] Consensus call for keys used in handsha… Eric Rescorla
- Re: [TLS] Consensus call for keys used in handsha… Will Serumgard
- Re: [TLS] Consensus call for keys used in handsha… Björn Tackmann
- Re: [TLS] Consensus call for keys used in handsha… Subodh Iyengar
- Re: [TLS] Consensus call for keys used in handsha… Ilari Liusvaara
- Re: [TLS] Consensus call for keys used in handsha… Dave Garrett
- Re: [TLS] Consensus call for keys used in handsha… Colm MacCárthaigh
- Re: [TLS] Consensus call for keys used in handsha… Eric Rescorla
- Re: [TLS] Consensus call for keys used in handsha… Daniel Kahn Gillmor
- Re: [TLS] Consensus call for keys used in handsha… Hugo Krawczyk
- Re: [TLS] Consensus call for keys used in handsha… Martin Rex
- Re: [TLS] Consensus call for keys used in handsha… Paterson, Kenny
- Re: [TLS] Consensus call for keys used in handsha… Paterson, Kenny
- Re: [TLS] Consensus call for keys used in handsha… Ilari Liusvaara
- Re: [TLS] Consensus call for keys used in handsha… Daniel Kahn Gillmor
- Re: [TLS] Consensus call for keys used in handsha… Hubert Kario
- Re: [TLS] Consensus call for keys used in handsha… Dave Garrett
- Re: [TLS] Consensus call for keys used in handsha… Daniel Kahn Gillmor
- Re: [TLS] Consensus call for keys used in handsha… Nick Sullivan
- Re: [TLS] Consensus call for keys used in handsha… Dan Harkins
- Re: [TLS] Consensus call for keys used in handsha… Ilari Liusvaara
- Re: [TLS] Consensus call for keys used in handsha… Daniel Kahn Gillmor
- Re: [TLS] Consensus call for keys used in handsha… Yoav Nir
- Re: [TLS] Consensus call for keys used in handsha… Nikos Mavrogiannopoulos
- Re: [TLS] Consensus call for keys used in handsha… Benjamin Dowling
- Re: [TLS] Consensus call for keys used in handsha… Ilari Liusvaara
- Re: [TLS] Consensus call for keys used in handsha… Felix Günther
- Re: [TLS] Consensus call for keys used in handsha… Björn Tackmann
- Re: [TLS] Consensus call for keys used in handsha… Martin Thomson
- Re: [TLS] Consensus call for keys used in handsha… Yoav Nir
- Re: [TLS] Consensus call for keys used in handsha… Watson Ladd
- Re: [TLS] Consensus call for keys used in handsha… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Consensus call for keys used in handsha… Henrik Grubbström
- Re: [TLS] Consensus call for keys used in handsha… Hannes Mehnert
- Re: [TLS] Consensus call for keys used in handsha… Cas Cremers
- Re: [TLS] Consensus call for keys used in handsha… Eric Rescorla
- [TLS] Consensus call for keys used in handshake a… Joseph Salowey
- Re: [TLS] Consensus call for keys used in handsha… Andrei Popov
- Re: [TLS] Consensus call for keys used in handsha… Karthikeyan Bhargavan