Re: [TLS] KeyUpdate and unbounded write obligations

[David Benjamin <[e-mail]>]

On Thu, Aug 18, 2016 at 1:08 PM Benjamin Kaduk <[e-mail]> 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