Eric: > 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.
I can think of many situations where one side sends a lot more data than the other. > 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. That seems to work. However, I think that splitting the ladders seems to marry well with the many situations where one side sends a lot more than the other. So, I suggest that we split the ladders. Russ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
