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