On Wed, Aug 24, 2016 at 9:23 PM, Ilari Liusvaara <[email protected]> wrote: > The generations are not specified as integers. It is just some abstract > sequence (nowhere in protocol is that generations are integers used).
The current draft requires that upon receipt of a KeyUpdate, "the receiver MUST update their receiving keys and if they have not already updated their sending state up to or past the then current receiving generation MUST send their own KeyUpdate prior to sending any other messages." This requires the generation counts to be comparable for inequality. Implementations will have to keep track of the generations, or the difference between them, in an integer counter. (How else would you do it?) > Due to design, one can't do a reciproal rekey. Hmm, there must be some misunderstanding. In the current draft, *every* time a node receives KeyUpdate #N (rekeying the incoming direction), it MUST reciprocate by rekeying its outgoing direction unless it has already sent at least N KeyUpdates. Current text: "This mechanism allows either side to force an update to the entire connection." >> (3) Fire-and-later-check. The TLS implementation exposes #2 above, but >> also `tls_session_generations()`, which returns a pair of integers >> giving the current sending and receiving generations. >> >> Any application we might want to build can be built on top of #3. > > Nope, the KeyUpdate is designed to deal with arbitrary latency in > order to fully decouple the direction (any coupling there would lead > to API problems, which apparently are more major than I initially > thought). Not quite sure what you're disagreeing with. Our proposal is also designed to deal with arbitrary latency. It's a field piggybacking on the otherwise-unmodified KeyUpdate messages. -Keith _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
