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)? -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
