On Tue, Jul 12, 2016 at 2:27 PM, Ilari Liusvaara <ilariliusva...@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.po...@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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
