On Mon, Aug 29, 2016 at 11:11 AM, Adam Langley <[email protected]> wrote:
> On Sun, Aug 28, 2016 at 11:50 AM, Eric Rescorla <[email protected]> wrote: > > 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 think that cases where there's a big asymmetry in sending rates are > in the majority. > Well, it has to be more than just asymmetric in terms of traffic volume, but I take your point. > 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 works but I agree that splitting the ladders is nicer and I think > that we should do that. > I'm fine with that. Unless someone objects soon I'm going to prepare a PR to do this along with the rule above (both changes are required). -Ekr > > > Cheers > > AGL > > -- > Adam Langley [email protected] https://www.imperialviolet.org >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
