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

On Tue, Jul 12, 2016 at 2:27 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> 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)?
>

Thinko.

Filed an issue for this.
https://github.com/tlswg/tls13-spec/issues/545

-Ekr

>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>