On Sat, Mar 05, 2016 at 12:46:01AM -0800, Philip Levis wrote: > Something I think that might not have been clear is this proposal > doesn’t in any way change how KeyUpdates are generated or processed. > In that way, crossings do not matter for the protocol. However, from > an application standpoint, when a KeyUpdate is performed, there can > be ambiguities on which keys are in use. Ambiguities in secure > protocols can create problematic edge cases, like the one Judson > outlined. We’d like it to be possible to resolve those ambiguities > without changing TLS or adding any significant complexity.
There should be no ambiguities from application standpoint. The whole reason for fully asynchronous design is that the application does not have to care about rekeying (other than setting parameters if the defaults aren't suitable). And TLS stacks only need to know current valid receive keys (which is just one key for non-datagram TLS) and the newest send key. > Ilari, do you see a security flaw in having one side know which > keys the other side is using? Explicit information between the > two endpoints seems like a good idea to me. Or do you think this > change makes TLS more complex and harder to implement correctly? I don't think the application needs to know that. And TLS stacks know valid receive keys anyway. And thanks to fully asynchronous design, have fun if client requests 27GB Blu-Ray ISO over HTTP/1.1 and server decides to rekey... The security problems arise when one uses this as basis to reveal keys (which is not something TLS libraries should even support, just the existence of API breaks the security models in all sorts of nasty ways). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
