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). > - 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. -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
