I'd like to close this discussion if we can. I'd prefer to keep things as simple as possible here and from that perspective, I think any indicator from side A to side B that it wants a key change over and above the KeyUpdate is extra complexity. I do, however, want to retain the property that one side can ask the other one to rekey [0]. I believe we can get this by modifying the rule in the spec by treating a run of KeyUpdates as a single generation.
Specifically. "Upon receiving a KeyUpdate, the receiver MUST update its receiving keys. If the receiver has sent any data records since receiving the last KeyUpdate it MUST also increment its min_send_generation counter by 1. Otherwise, the min_send_generation MUST remain unchanged. Prior to sending a record, if min_send_generation is greater than the current sending generation, the sender MUST first send a KeyUpdate." This still leaves open the question of whether we should advertise the current receiving generation or have two ladders, but I believe those are orthogonal to David's issue. Does anyone see a reason why this won't work? -Ekr [0] My reasoning here is that it allows implementations who learn about new limits for a cipher or are otherwise more conservative than their peer to get more aggressive updates even if it's the other side doing most of the sending. On Thu, Aug 25, 2016 at 12:31 PM, Keith Winstein <kei...@cs.stanford.edu> wrote: > On Wed, Aug 24, 2016 at 9:23 PM, Ilari Liusvaara > <ilariliusva...@welho.com> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
