Re: [TLS] KeyUpdate and unbounded write obligations

[Ilari Liusvaara <[e-mail]>]

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).

Yes, this causes lots more desync between sides, but existing
mechanism needed to cope with that already.


However, one problem: Because both sides take their keys from one
ladder, if one side is behind the other, one can extract past keys
of other side from the one that is behind (running separate ladders
in both directions[2][3] would fix this).


[1] Specifically:
- last_tx_key_update: Was the last record I sent a KeyUpdate?
- next_tx_key_update: Will the next record I send be a KeyUpdate?

[2] Any current implementation likely already has per-direction
traffic secrets (at least mine certainly does). 

[3] Allowing multiple steps at once would open things up for DoS
attacks.



-Ilari