On Sun, Aug 28, 2016 at 11:41 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 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). > Yes, I agree separate ladders would fix this. I don't necessarily object to this change, but I'm not sure it's that big a deal either, because you really only get into this case when there's a big asymmetry in sending rate, so much that one side wants to send multiple updates before the other side has sent any data at all. Note: it's also possible to avoid the rollback problem with the existing single-ladder system: when you send a key update you compute: traffic_secret_N+1 read_key_N+1 write_key_N+1 You then discard traffic_secret N, write_key_N, but key read_key_N, so if you are M updates ahead of the other side, you have M read keys outstanding, but these cannot be used to produce the write keys. However, this probably isn't simpler than just running two ladders if we think this is important. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
