On Sun, Aug 28, 2016 at 10:53:14AM -0700, Eric Rescorla wrote: > > 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."
Timing- and propagation-wise, it looks workable (also, could be done with two flags[1], no need for counter). Yes, this causes lots more desync between sides, but existing mechanism needed to cope with that already. However, one problem: Because both sides take their keys from one ladder, if one side is behind the other, one can extract past keys of other side from the one that is behind (running separate ladders in both directions[2][3] would fix this). [1] Specifically: - last_tx_key_update: Was the last record I sent a KeyUpdate? - next_tx_key_update: Will the next record I send be a KeyUpdate? [2] Any current implementation likely already has per-direction traffic secrets (at least mine certainly does). [3] Allowing multiple steps at once would open things up for DoS attacks. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
