Re: [TLS] KeyUpdate and unbounded write obligations

[Eric Rescorla <[e-mail]>]

I have created a PR for this at:
https://github.com/tlswg/tls13-spec/pull/611

As it seems there was rough consensus for this change, I will merge this
weekend
absent some violent objections or direction to the contrary from the chairs.

-Ekr


On Mon, Aug 29, 2016 at 3:06 PM, Russ Housley <[e-mail]> wrote:

> Eric:
>
> > Yes, I agree separate ladders would fix this. I don't necessarily object
> to this
> > change, but I'm not sure it's that big a deal either, because you really
> only get
> > into this case when there's a big asymmetry in sending rate, so much that
> > one side wants to send multiple updates before the other side has sent
> > any data at all.
>
> I can think of many situations where one side sends a lot more data than
> the other.
>
> > Note: it's also possible to avoid the rollback problem with the existing
> > single-ladder system: when you send a key update you compute:
> >
> > traffic_secret_N+1
> > read_key_N+1
> > write_key_N+1
> >
> > You then discard traffic_secret N, write_key_N, but key read_key_N, so
> if you
> > are M updates ahead of the other side, you have M read keys outstanding,
> > but these cannot be used to produce the write keys. However, this
> probably
> > isn't simpler than just running two ladders if we think this is
> important.
>
> That seems to work.  However, I think that splitting the ladders seems to
> marry well with the many situations where one side sends a lot more than
> the other.  So, I suggest that we split the ladders.
>
> Russ
>
>