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

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 12 July 2016 21:28 UTC

Return-Path: <ilariliusvaara@welho.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 2E04E12D97C for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 14:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
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 nGnr-KOWBRKG for <tls@ietfa.amsl.com>; Tue, 12 Jul 2016 14:28:25 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3091712D9C5 for <tls@ietf.org>; Tue, 12 Jul 2016 14:27:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 13012650F; Wed, 13 Jul 2016 00:27:44 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id V2n2Wfqbvwtn; Wed, 13 Jul 2016 00:27:43 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id AD939289; Wed, 13 Jul 2016 00:27:43 +0300 (EEST)
Date: Wed, 13 Jul 2016 00:27:40 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Douglas Stebila <dstebila@gmail.com>
Message-ID: <20160712212740.GC32363@LK-Perkele-V2.elisa-laajakaista.fi>
References: <C6FAB38B-FF5A-43D3-A0DB-554FAF23ED92@gmail.com> <CY1PR03MB21554CF98C27A89230DDD5F18C3F0@CY1PR03MB2155.namprd03.prod.outlook.com> <3F568B47-BE31-4EBB-AA95-C3045911956B@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <3F568B47-BE31-4EBB-AA95-C3045911956B@gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PVsJrQQ9322UFSBoO1WwY89301s>
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 21:28:27 -0000

On Tue, Jul 12, 2016 at 10:00:35AM -0400, Douglas Stebila wrote:
> > On Jul 11, 2016, at 19:24, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> > 
> > Back to the question...
> > One challenge with this is that exporters are often used to compare
> > things.  For instance, one side signs an exported value, the other
> > validates the signature by independently exporting the same value.
> > Getting different values for a particular exporter will cause some
> > classes of things to fail in subtle ways.
> 
> Agreed, this does create the possibility that the endpoints will export
> different values at different times due to unsynchronized context
> switches.  

It gets worse: KeyUpdate is explicitly designed to work even when
arbitrarily unsynchronized and run behind app's back (the application
never having to care for it).

 
> However, we should compare this failure mode (which might cause two
> "partnered" parties to not get the same exporter key) with the failure
> mode if we use the same EKM for the whole session (which might cause
> more parties than we expect to get the same exporter key).  Fail-closed
> versus fail-open.

Also, I wouldn't expect rekeying occur very often at default. 24M
records in bulk transfer is quite a bit of data (would require quite
fast connection to do in a few hours even at full blast). And there
is no recommendation on time-based rekeying (and Chacha can run
as good as forever even on the fastest connections).

So, even if rekey changed EKM, it likely would not save you if
application misused exporters in way vulernable to this.


Worth security consideration? Certainly.



Also, why does post-handshake auth seemingly always use traffic_secret_0,
instead say whatever happens to be the newest in forward (C->S)
direction when the Finished is sent (that would be well-defined key)?


-Ilari