Re: [TLS] KeyUpdate and unbounded write obligations

[Eric Rescorla <[e-mail]>]

On Mon, Aug 29, 2016 at 10:30 AM, Ilari Liusvaara <[e-mail]>
wrote:

> On Sun, Aug 28, 2016 at 11:50:27AM -0700, Eric Rescorla wrote:
> > On Sun, Aug 28, 2016 at 11:41 AM, Ilari Liusvaara <
> [e-mail]>
> > wrote:
> >
> > > On Sun, Aug 28, 2016 at 10:53:14AM -0700, Eric Rescorla wrote:
> > > >
> > > > 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."
> > >
> > > Timing- and propagation-wise, it looks workable (also, could be done
> > > with two flags[1], no need for counter).
>
> I tried to implement this, and probably got it wrong somehow:
>
> Test setup consisists of multi-Gbps stream in one direction and fairly
> slow one in another. Very low latencies. Also, TLS stack can't do new
> flights.
>
> 1) The fast stream eventually (~5min) reaches the rekey threshold,
>    triggering a KeyUpdate.
> 2) The other side receives the KeyUpdate. Since last record it sent
>    was not KeyUpdate, it marks KeyUpdate to be sent.
> 3) The slow stream transmits something. Since KeyUpdate is pending,
>    it is sent, along with something else (so last record is not a
>    KeyUpdate.
> 4) The fast sender receives the KeyUpdate. Since last record it
>    sent was not a KeyUpdate (it has sent more data since) it
>    schedules a KeyUpdate to be sent.
> 5) Almost immediately new data arrives, and since KeyUpdate is pending,
>    it is sent, along with something else (so last record is not a
>    KeyUpdate).
> 6) Goto 2.
>
> The result is ping-pong of KeyUpdate's that starts as soon as one side
> sends one (at rate determined by the send rate of the slower peer,
> which still can be pretty high).
>

Did you use the "flags" approach or the generation approach, since it seems
like in the latter approach, at that point it would be in send=2, recv=1 and
it wouldn't update.

-Ekr


>
> -Ilari
>