Re: [TLS] KeyUpdate and unbounded write obligations

[Ilari Liusvaara <[e-mail]>]

On Thu, Sep 01, 2016 at 02:11:13PM -0700, Keith Winstein wrote:
> I think we have to oppose a change to KeyUpdate that adds P4 (bounded
> write obligations) but not P3 (ability to learn that a KeyUpdate was
> read by other side). These are orthogonal and easily achievable with a
> pretty small tweak. Here are four options that would work for us:

Unfortunately, one can get into situations like this (saw this
in testing):

1) Client send KeyUpdate[req=true] (and continues blasting data)
2) Server receives the KeyUpdate[req=true]
3) Server queues a KeyUpdate[req=false], it gets stuck.
4) Client send KeyUpdate[req=true] (and continues blasting data)
5) Server receives the KeyUpdate[req=true]
6) Server quenches the KeyUpdate, since it has fresh keys.
7) Client send KeyUpdate[req=true] (and continues blasting data)
8) Server receives the KeyUpdate[req=true]
9) Server quenches the KeyUpdate, since it has fresh keys.
10) Server sends something, the KeyUpdate gets unstuck.
11) The client receives the KeyUpdate[req=false]


Considering those KeyUpdates are triggered every ~5min (by volume
trigger[1]), effective RTT was something like ~10-15min (despite sub-
millisecond transport latencies). And the 1 server-sent KeyUpdate
was in reaction to first client KeyUpdate, not the last...


[1] Set at 10,000,000 records (even for 0x1303, which can handle
far far more).


-Ilari