Re: [TLS] KeyUpdate and unbounded write obligations

[Eric Rescorla <[e-mail]>]

I'd like to close this discussion if we can.

I'd prefer to keep things as simple as possible here and from that
perspective, I think any indicator from side A to side B that it wants a
key change over and above the KeyUpdate is extra complexity. I do, however,
want to retain the property that one side can ask the other one to rekey
[0]. I believe we can get this by modifying the rule in the spec by treating
a run of KeyUpdates as a single generation.

Specifically.
"Upon receiving a KeyUpdate, the receiver MUST update its receiving
keys. If the receiver has sent any data records since receiving the
last KeyUpdate it MUST also increment its min_send_generation counter
by 1. Otherwise, the min_send_generation MUST remain unchanged. Prior
to sending a record, if min_send_generation is greater than the
current sending generation, the sender MUST first send a KeyUpdate."

This still leaves open the question of whether we should advertise the
current
receiving generation or have two ladders, but I believe those are
orthogonal to
David's issue. Does anyone see a reason why this won't work?

-Ekr

[0] My reasoning here is that it allows implementations who learn about new
limits for a cipher or are otherwise more conservative than their peer to
get more aggressive updates even if it's the other side doing most of the
sending.



On Thu, Aug 25, 2016 at 12:31 PM, Keith Winstein <[e-mail]>
wrote:

> 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
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>