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

Andrei Popov <> Mon, 11 July 2016 23:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA9B412D66B for <>; Mon, 11 Jul 2016 16:24:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7UZvw_x-n5ol for <>; Mon, 11 Jul 2016 16:24:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2C0212D1D3 for <>; Mon, 11 Jul 2016 16:24:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4B2O4ztNfI7TRGD7GsiOP0EaSv+r2nBnGHblS75xMbo=; b=S+Xeq4AidkeFFtZRwDzyl12Q0Xl80ynFL2j4L/2zdwaaLXT/yWtvhO2ULajhSLYzHp/XF9FjS4B/TK7XWKnChkGFDIMQH4gYWpsgCTgef6+QhZBjli/vZyxqauVLyL5PjgY3YGwoJC0UF9epZNXTFkMw8TmMmn85il7oyDHP3vA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.534.14; Mon, 11 Jul 2016 23:24:30 +0000
Received: from ([]) by ([]) with mapi id 15.01.0534.022; Mon, 11 Jul 2016 23:24:30 +0000
From: Andrei Popov <>
To: Douglas Stebila <>, "" <>
Thread-Topic: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?
Thread-Index: AQHR26wJxPHbdy3C0U+IgpZY4K5NtqAT3JCg
Date: Mon, 11 Jul 2016 23:24:30 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:7::1d2]
x-ms-office365-filtering-correlation-id: 87f7089e-76bd-4c9d-f9a2-08d3a9e28245
x-microsoft-exchange-diagnostics: 1; CY1PR03MB2155; 6:tvhvHxaZVUBYSU24lxcMgr7PgVy1UN20ywUJyev/oFO6a/c75t0ngK6dKbIHXPEA7Wibfm8JZbAgX3Mfc3L0mVCLB2q+8TbbJpiCliHT9179gHKYkeyj7F2qQbzG4lLvH/1fwdGEsqI7hv2V0Y0O3KqKxakgcmQxBPn04ldpGGR76inOlVuyzIvPc/HOhUN7kYBTyXQ9rlax0It1fR1canVqJ7Nec3cDOY/hq3SD9kmi7X6k17TQV6M17kb4m8xygcmIaSXrWIzQjpErANH4K6UvALytuX6YknGOi0/CdHvJ7iwg1267fD7mTshg9V4NfzsPFfb+4cAG7nDaai3PuA==; 5:C4TMDFKqD7RzDPs3aLSVQ5hHn0Mhg2fAIG6fyPK2cP9UlB/v0eKW+DP6PryKj+h9gdLvU98pqHEC1yfy2yhha2U1p6raBqj39pYdgFVCGA4k8vL5XCWx7rI0ocTQKiNBJigUCNohoTPK6AQaHN1pRg==; 24:Rd6mjonny/BNxIADthfSETEyHN1HpfgxbRFOhUeZo8lEdW08n2aNdbYGX9qmsNf6c8sVyaQfRdhCn/xsW2U37dIwx6AIaIp1E8Hto6GRhTU=; 7:7k67t+/2+bt2JKgzeIALQMn4ZI0xuYVs7bRzWrPdLMWWjdVp4qgRmT80iB7LkvFMWz1uNDOSETY7Akvjkxhtplpqm+5CUeyxYPmvq71VMWKQfA23K0z3LmLqNiQ0guKjTYTiBm/e/6ougC7OhNWQs0DGe3VXjBWAPhPj42WGMx1CzGE+5h8qpJOADGz29G+TIKLkQ52EB1m5x7grkX0t5l6kuI6Y2hGt0hZ7AD0NCK6dHKaX8Re+xQCTDxVQVfwc
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2155;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
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: 00003DBFE7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(13464003)(189002)(5005710100001)(87936001)(5002640100001)(10400500002)(77096005)(33656002)(10290500002)(86612001)(3660700001)(101416001)(97736004)(106116001)(11100500001)(105586002)(10090500001)(9686002)(189998001)(76176999)(5001770100001)(54356999)(68736007)(2906002)(86362001)(76576001)(2900100001)(106356001)(8990500004)(7736002)(81156014)(81166006)(7846002)(5003600100003)(8676002)(102836003)(6116002)(15650500001)(305945005)(8936002)(74316002)(7696003)(92566002)(50986999)(107886002)(19580405001)(19580395003)(99286002)(122556002)(3280700002)(2950100001)(586003)(2501003)(15975445007)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2155;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2016 23:24:30.1117 (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: <>
Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Jul 2016 23:24:34 -0000

Hi Douglas,

As currently defined, post-handshake client auth allows the same client to present different identities, but not to repudiate a previously presented identity. So in your example, from the TLS perspective, the client is both Alice and Bob, and therefore I think the same EKM value makes sense.



-----Original Message-----
From: TLS [] On Behalf Of Douglas Stebila
Sent: Monday, July 11, 2016 12:40 PM
Subject: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?

Some of the discussions I've had with people about post-handshake client authentication have raised the question of whether application traffic secrets should be updated automatically upon post-handshake client authentication: the thinking being that every change in context should be accompanied by a change in keying material.  I used to think that was a good idea for TLS 1.3, although it was recently argued to me that if we view the application traffic secrets as being "internal" to the TLS protocol, then the change in client authentication status doesn't change the confidential or integrity properties of the record layer, it just serves as a "marker" to the application that certain portions of the application data were associated with certain authentication contexts.  I was convinced that this can be safely accomplished without a change in application traffic secret key material.

But I'm not sure that the same applies to *exporter* keys.  Should exported keying material change as the authentication context changes?

Consider a long-lived TLS connection, where different users come and go.  For example, a web browser on a public terminal may have established a long-lived TLS connection to a particular website, and send subsequent requests to the same website over the same TLS connection.  Now imagine two users use the terminal one after another:

1: initial handshake on a public terminal
2: [time passes]
3: Alice starts browsing
4: Alice does post-handshake client authentication
5: Alice purchases something
6: Alice hits "logout" at the application layer
7: [time passes]
8: Bob starts using the terminal
9: Bob does post-handshake client authentication
10: Bob purchases something
11: Bob hits "logout" at the application layer

TLS 1.3 will tell the application about events 4 and 9.  Events 6 and 11 happen at the application layer rather than the TLS layer (since I don't think TLS 1.3 has a client-de-authentication option).  But putting this all together, the application will learn all the correct authentication contexts: 1-3 is anonymous, 4-5 is Alice, 6-8 is anonymous, 9-10 is Bob, 11-onwards is anonymous.

Now imagine that we use keying material exporters in on lines 5 and 10:

1: initial handshake on a public terminal
2: [time passes]
3: Alice starts browsing
4: Alice does post-handshake client authentication
*5: Alice presses the "export keying material" button
6: Alice hits "logout" at the application layer
7: [time passes]
8: Bob starts using the terminal
9: Bob does post-handshake client authentication
*10: Bob presses the "export keying material" button
11: Bob hits "logout" at the application layer

Since the exporter master secret is not updated when client authentication changes, Alice and Bob will export the same keying material at steps 5 and 10.  If the intended goal of this exported key is for Alice to obtain confidentiality in some other use, this will not be achieved, since Bob will obtain the same exported key.

Now, a proviso is that RFC 5705 allows for the application to mix a "context value" into the export, which could mitigate this, but that is optional.

So it seems to me like in at least some scenarios, exported keying material should be associated with authentication context.  It is less clear to me if the same holds true for KeyUpdates.

TLS mailing list