IETF Logo Mail Archive

Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?

Andrei Popov <Andrei.Popov@microsoft.com> Tue, 12 July 2016 15:56 UTC

Return-Path: <Andrei.Popov@microsoft.com>
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 DDBDA12D181 for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 08:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 c7hcJa4IXZlF for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 08:56:45 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0121.outbound.protection.outlook.com [104.47.38.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B6B12D17B for <tls@ietf.org>; Tue, 12 Jul 2016 08:56:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=weXNCWpiqvykR7Mkg34lIj0HiElCSFsN3dizZSc0ZHQ=; b=jNJY/lMlv60IzPRZXLLB1XJ6kf7QQEfCz8Q94Ypxed+knIS3MSXjxzk++dvBSQNElUSmRk72YAcsscqlLhEmdxkKLY4y0ZLEbkXP0yhhulQNxGLiE2r47FSa8EJbOt8trYGO9K1vbUI5YvT39mXU0480Y265nmVy/gXYNkczKQQ=
Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.534.14; Tue, 12 Jul 2016 15:56:38 +0000
Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0534.023; Tue, 12 Jul 2016 15:56:38 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Bill Cox <waywardgeek@google.com>, Douglas Stebila <dstebila@gmail.com>
Thread-Topic: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?
Thread-Index: AQHR26wJxPHbdy3C0U+IgpZY4K5NtqAT3JCggAD3nYCAABpAAIAABckQ
Date: Tue, 12 Jul 2016 15:56:38 +0000
Message-ID: <CY1PR03MB21559FF8FA1DBF9128F7285D8C300@CY1PR03MB2155.namprd03.prod.outlook.com>
References: <C6FAB38B-FF5A-43D3-A0DB-554FAF23ED92@gmail.com> <CY1PR03MB21554CF98C27A89230DDD5F18C3F0@CY1PR03MB2155.namprd03.prod.outlook.com> <3F568B47-BE31-4EBB-AA95-C3045911956B@gmail.com> <CAH9QtQEZh-SXt1uUz6XU7QKD1AqNAaRqH0OYFivaCmcABBSeZg@mail.gmail.com>
In-Reply-To: <CAH9QtQEZh-SXt1uUz6XU7QKD1AqNAaRqH0OYFivaCmcABBSeZg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-originating-ip: [50.46.229.189]
x-ms-office365-filtering-correlation-id: fee531b5-f441-4805-eb16-08d3aa6d1c18
x-microsoft-exchange-diagnostics: 1; CY1PR03MB2155; 6:FOb6blwJYZCX5YSsunqyS6pl0/HsieM/WyavNQanOhuSCFo286V2ekAPwKQzxuAPZElrxxfMZTnswRyQVd16jfAT8H5sYO2A86sm30MUR64fTUrBzfFtQYBsFKGEsEN7EKUvrUB0eap8G1uLgnRCUOmqiHju05dqI1lxfRQ47fbA+Cgs9ntmyBYPVqM6kfbuMmpuopqic9RnjEeaV1t9IwRcCM9DAXg8j0MErf+DKkiDvkFTDd17CvzaRuGa83a9gZx3JJE7pHEPD/itwSquU5AEkumMfxiLaHB14knYnPgVUfJM4F99rGyBjCVY6H79VhH3fD4NEnSlAkl+mSJmaw==; 5:FjT+PeDoMtiw1ozHvo/X+lZpP66a271gECsVjwUZmRZ+0IaphHzP9YzXHgQs8oOInd04kR+SeFa6vRHfDAI5MZLZWpzh3sYdn0HFc5+VfNd2qK2BKKGcvnCxZDcugHDvfE7qLDz+LtHo9WJ6i0Ao2g==; 24:lbmlbDitzGkV5MdUPudz8mf5YXCX7Qe0msGkxFWffeQpUgkoki5u0XCt7chscZTpyskKjY1gLB3lObjX5aTWdao12PPsbgehi5gHU0O5t3w=; 7:aDMfqaL7SxUh/0Rt5PypvSOmguPQG3hlf39BleMDOKLIhbT5mP8bZzfGHAzWvjoqniisrZcz9+QCrR5WS5guJ0POxHXDpnRoG4Blp+ZfrQZmPafoY1imFPjVRQ6sfkL/P+orGp+6Hle7ORIQXuqvOpcMP9yGA6TZnCKSmRmFqy4T0SLv1RguNV2YqW91WiQOf5FfmN6QP4wGOXCmhA+Y/MJhmtE/yBoj8xNDTz+CspJyEWbOb84v5OkfBozldYSn
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2155;
x-microsoft-antispam-prvs: <CY1PR03MB2155DF7085421A2F5EFC2BEF8C300@CY1PR03MB2155.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(211936372134217)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2155; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2155;
x-forefront-prvs: 0001227049
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(377454003)(586003)(19625215002)(74316002)(15650500001)(19300405004)(15975445007)(66066001)(99286002)(5002640100001)(2950100001)(122556002)(106356001)(19580405001)(2900100001)(106116001)(19580395003)(92566002)(8936002)(9686002)(2420400007)(7736002)(105586002)(7846002)(77096005)(5003600100003)(7696003)(16236675004)(10090500001)(2906002)(97736004)(33656002)(10710500007)(102836003)(50986999)(3280700002)(790700001)(6116002)(4326007)(3660700001)(5001770100001)(10400500002)(5005710100001)(76576001)(68736007)(76176999)(54356999)(8676002)(10290500002)(101416001)(11100500001)(86612001)(189998001)(3846002)(87936001)(93886004)(86362001)(81156014)(81166006)(7110500001)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2155; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR03MB21559FF8FA1DBF9128F7285D8C300CY1PR03MB2155namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 15:56:38.7462 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2155
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VteQYS7Jt_W32ajgYHj69vKYbjY>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?
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: Tue, 12 Jul 2016 15:56:48 -0000

Ø  IIRC, in TLS 1.2 the same keys are used after resumption, and EKM values do not change.
Is this correct? EKM mixes in client and server randoms, which are hopefully different in each resumption.

Cheers,

Andrei

From: Bill Cox [mailto:waywardgeek@google.com]
Sent: Tuesday, July 12, 2016 8:35 AM
To: Douglas Stebila <dstebila@gmail.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Martin Thomson <martin.thomson@gmail.com>; tls@ietf.org
Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?

IIRC, in TLS 1.2 the same keys are used after resumption, and EKM values do not change.  I think most applications currently using EKM will break if the EKM values change after a PSK resume.

However, forcing TLS 1.3 to remember a 256-bit EKM seed will bloat tickets by 32 bytes, and complicate the state machine.  I think this could partially be addressed by enhancing the custom extension APIs found in popular TLS libraries to enable custom extensions to specify state that needs to be remembered on a resume.  That, in combination with requiring extensions to be sent and processed in order of extension number, could enable a lot of this complexity to be taken out of the main TLS code, and only connections that actually need such extensions would see the increase in ticket size.

Could something like this could work well for channel binding?

Bill

v2.23.0 | Report a Bug | By Email