On Mon, Aug 29, 2016 at 10:30 AM, Ilari Liusvaara <ilariliusva...@welho.com> 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 < > 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). > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
