I think we have to oppose a change to KeyUpdate that adds P4 (bounded write obligations) but not P3 (ability to learn that a KeyUpdate was read by other side). These are orthogonal and easily achievable with a pretty small tweak. Here are four options that would work for us:
1. No change to message structures. Forbid implementations from sending an update_not_requested KeyUpdate unless it is triggered by an update_requested KeyUpdate. 2. Add a uint8 field to KeyUpdate representing the sender's current receive generation (lower 8 bits). 3. Keep request_update an 8-bit field (same width as it is in the PR), and define the high bit as representing the update_requested boolean, and the remaining bits represent the lower 7 bits of the sender's current receive generation 4. Keep request_update an 8-bit field (same width as it is in the PR), define the high bit as representing the update_requested boolean, and the remaining bits represent a 7-bit opaque value that must be echoed in the response. (If multiple update_requested KeyUpdates arrive, any of their values can be the one that gets echoed.) Approach 1 seems like it might be generally acceptable here, even understanding the concerns of the list. I am happy to draft sample text if helpful. -Keith On Thu, Sep 1, 2016 at 12:55 PM, Eric Rescorla <e...@rtfm.com> wrote: > 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 > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
