On Sun, Aug 28, 2016 at 11:50:27AM -0700, Eric Rescorla wrote: > On Sun, Aug 28, 2016 at 11:41 AM, Ilari Liusvaara <ilariliusva...@welho.com> > 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). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
