I have created a PR for this at: https://github.com/tlswg/tls13-spec/pull/611
As it seems there was rough consensus for this change, I will merge this weekend absent some violent objections or direction to the contrary from the chairs. -Ekr On Mon, Aug 29, 2016 at 3:06 PM, Russ Housley <hous...@vigilsec.com> wrote: > 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
