Re: [TLS] KeyUpdate and unbounded write obligations

[Keith Winstein <[e-mail]>]

On Wed, Aug 24, 2016 at 9:23 PM, Ilari Liusvaara
<[e-mail]> wrote:
> The generations are not specified as integers. It is just some abstract
> sequence (nowhere in protocol is that generations are integers used).

The current draft requires that upon receipt of a KeyUpdate, "the
receiver MUST update their receiving keys and if they have not already
updated their sending state up to or past the then current receiving
generation MUST send their own KeyUpdate prior to sending any other
messages."

This requires the generation counts to be comparable for inequality.
Implementations will have to keep track of the generations, or the
difference between them, in an integer counter. (How else would you do
it?)

> Due to design, one can't do a reciproal rekey.

Hmm, there must be some misunderstanding. In the current draft,
*every* time a node receives KeyUpdate #N (rekeying the incoming
direction), it MUST reciprocate by rekeying its outgoing direction
unless it has already sent at least N KeyUpdates. Current text: "This
mechanism allows either side to force an update to the entire
connection."

>> (3) Fire-and-later-check. The TLS implementation exposes #2 above, but
>> also `tls_session_generations()`, which returns a pair of integers
>> giving the current sending and receiving generations.
>>
>> Any application we might want to build can be built on top of #3.
>
> Nope, the KeyUpdate is designed to deal with arbitrary latency in
> order to fully decouple the direction (any coupling there would lead
> to API problems, which apparently are more major than I initially
> thought).

Not quite sure what you're disagreeing with. Our proposal is also
designed to deal with arbitrary latency. It's a field piggybacking on
the otherwise-unmodified KeyUpdate messages.

-Keith