> -----Original Message----- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Keith Winstein > Sent: Thursday, August 18, 2016 11:21 AM > To: David Benjamin <david...@chromium.org> > Cc: tls@ietf.org > Subject: Re: [TLS] KeyUpdate and unbounded write obligations > > It sounds like there are four properties in play here: > > P1: Either side can rekey its outgoing traffic whenever it wants. > > P2: Either side can "force an update to the entire connection," i.e. > can ask the other side to rekey *its* outgoing traffic. > > P3: A side can learn that P1 has been read by the other side.
If you are not getting any traffic back, it seems that this might a problem. P1 + P3 causing P4. Unless you are willing to not know the difference between traffic getting lost and traffic being processed. Jim > > P4: Neither side can cause the other to accrue an unbounded deferred write > obligation; in fact the maximum accruable deferred write obligation is one > KeyUpdate. > > The current draft has P1 and P2 only. > > My view: all four properties are important. > > I've previously argued for the benefit of P3. > > Re: P2, there seems to be some disagreement about the value. I think it is -- one > endpoint may well have knowledge (about the traffic or its future susceptibility > to compromise) that makes it want to ratchet the session. Forward secrecy is > not only valuable to the sender. I don't think it's enough to recommend that > each side rekey its own direction occasionally. > > I don't think it's a particularly hard design or implementation challenge to get all > four properties. > > Here a simple explicit and verbose design as a straw-man, that gets P1, P2, P3, > and P4: > > 1) As David proposes, separate the tracks and have two KeyUpdate ladders. > > 2) Define KeyUpdate like this: > > struct { > uint64 desired_minimum_receive_generation; > uint64 current_receive_generation; > } KeyUpdate; > > Language: "An implementation MAY update its send keys by sending a > KeyUpdate. An implementation MAY request that the other side update its send > keys by increasing the desired_minimum_receive_generation. An > implementation MUST NOT set desired_minimum_receive_generation to be > greater than its current_receive_generation plus one." > > "Upon receiving a KeyUpdate, the receiver MUST increment their receiving > generation by one. If the desired_minimum_receive_generation > is greater than its current send generation, the receiver MUST update its send > keys and send a KeyUpdate. If the desired_minimum_receive_generation is > greater than the current send generation plus one, the receiver SHOULD abort." > > -Keith > > On Thu, Aug 18, 2016 at 10:26 AM, David Benjamin <david...@chromium.org> > wrote: > > On Thu, Aug 18, 2016 at 1:08 PM Benjamin Kaduk <bka...@akamai.com> > wrote: > >> > >> On 08/17/2016 11:29 PM, David Benjamin wrote: > >> > >> However, we lose the "free" (really at the cost of this unboundedness > >> problem) generation-based bidirectional KeyUpdate sync. Depending on > >> what we want out of KeyUpdate, I can imagine a few options: > >> > >> > >> My recollection is that the only reason we have KeyUpdate is to avoid > >> going over the limit for amount of ciphertext encrypted in the same > >> key within our safety margin (recall the analyses debating whether > >> such limits would even be reachable for the ciphers currently in use, > >> as well as the disagreement as to what the safety margin should be). > >> > >> > >> - Don't. KeyUpdates are unilateral. Recommend in the spec to > >> KeyUpdate every N records or so and leave it at that. (I think this > >> is the best option on grounds of simplicity, assuming it meets the > >> primary needs of KeyUpdate.) > >> > >> > >> If we're in a world where implementations are considering leaving out > >> the required "catch up" KeyUpdate, we may want to consider > >> alternative options to put in the spec that are easier to implement. > >> That is, we can write the spec in various ways to get the > >> functionality that both write directions get the key updates needed > >> to avoid the ciphertext limit, and we are reliant on implementations to follow > the spec in order to get that safety property. > >> So, given that we can only get the safety property if all > >> implementations follow the spec, why not just ... require > >> implementations to track the amount sent and rekey if it's too close > >> to the limit? That is consistent with a unilateral/unidirectional > >> KeyUpdate, and having per-connection byte/record counters does not seem > to be a huge overhead. > >> > >> Keeping the two write directions' keys independent would also avoid > >> conflict when the two peers disagree on how often a rekey is > >> necessary (as might happen if a resource-constrained device decided > >> to not implement byte counters and just rekey after every N records, > >> which is "free" since you need to track serial numbers anyway). > > > > > > Yup. If we say implementations SHOULD/MUST/whatever send KeyUpdates > > frequently and we're fine with just saying we rely on each sender to > > honor that w.r.t. their own send keys with little other fanfare, I > > think this option is the clear winner. We're already relying on the > > sender to not, say, exfiltrate all data somewhere nasty. > > > > There seemed to be other motivations for KeyUpdate (Keith's passive > > observer use case, I've heard some theories around one side knowing > > more about the cipher than another, etc.), so I left that alone for > > now. I'm not currently convinced by those use cases, but perhaps the > > working group feels differently. I'm reasonably confident splitting > > the key tracks is correct regardless, but I wasn't sure which > > KeyUpdate motivations were considered important and which weren't. > > > >> > >> - If you receive a KeyUpdate and didn't send one in the last N > >> minutes (where N minutes >>> 1 RTT), (optionally?) flag your next > >> write to be preceded by KeyUpdate. This is simple but needs an ad-hoc > >> timeout to prevent ping-ponging. > >> > >> - Variations on sticking a please_echo boolean in the KeyUpdate > >> message, generation counts, etc., to get synchronization with > >> coalescing if we need it. I would much prefer the simpler options unless we > truly need this. > >> (KeyUpdate is right now a *required* feature, so simplicity should be > >> a priority. Rare use cases are what extensions are for.) > >> > >> Thoughts? > >> > >> David > >> > >> PS: We've seen this before with renego (I've seen many OpenSSL > >> consumers which lock up if the peer renegotiation), error alerts > >> triggered on reads (often they don't get sent), and close_notify > >> (also don't get sent in practice). Deviations from dumb filters are expensive. > >> > >> > >> Yes, simple is better. Well, here at least :) > >> > >> > >> PPS: I'm wary of over-extending post-handshake auth for the same > >> reason, though I haven't had time to look carefully at the latest proposal yet. > >> Still, having TLS specify and analyze the crypto while lifting the > >> actual messages into application-level framing would be preferable > >> for these sorts of side protocols. The application gets to make > >> assumptions about read/write flows and knows in which contexts what is and > isn't allowed. > >> > >> > >> Hmm, so [in the above proposal] that would involve the application > >> doing the byte/record counters and pushing a "give me a rekey packet > >> now" button when needed? I am not sure that I'm comfortable moving > "crypto sensitive" > >> code (well, sort-of) into the application, since many applications > >> won't do it. Also, not all applications will have access to the > >> record serial number, as I understand it, and the formulas I remember > >> for the ciphertext limits involved both records and bytes. > > > > > > Sorry, that was unclear. That was more of a side comment to help > > explain why I have such strong visceral reactions to any > > post-handshake auth mechanisms since part of it is the same issue. I > > am not proposing we lift KeyUpdate to the application layer. I'm > > proposing we split the KeyUpdate tracks in two and do [insert preferred option > here] w.r.t. the bidirectionality issue. > > Probably should not have mentioned it since it's mostly a distraction > > for this topic. I ramble a lot. :-) > > > > David > > > > _______________________________________________ > > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls