To be clear, the concern that we are trying to alleviate is encrypting too much plaintext with the same key (see the discussion by Watson at the beginning of this thread). For that purpose, I'm not following why we need to introduce new randomness (draft-11 doesn't do so, but just cranks the KDF forward).
It's possible I've misunderstood something, though, so happy to be corrected. -Ekr On Mon, Dec 28, 2015 at 3:40 PM, Blumenthal, Uri - 0553 - MITLL < [email protected]> wrote: > Off-hand, key update or re-key without new/fresh‎ randomness sounds weird. > > > Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. > *From: *Eric Rescorla > *Sent: *Monday, December 28, 2015 15:37 > *To: *Florian Weimer > *Cc: *[email protected] > *Subject: *Re: [TLS] Data volume limits > > > > On Mon, Dec 28, 2015 at 3:33 PM, Florian Weimer <[email protected]> > wrote: > >> On 12/28/2015 09:11 PM, Eric Rescorla wrote: >> >> >> You still have the added complexity that during rekey, you need to >> >> temporarily switch from mere sending or receiving to at least >> >> half-duplex interaction. >> >> >> > >> > That's not intended. Indeed, you need to be able to handle the old key >> > in order to send/receive the KeyUpdate. Can you elaborate on your >> concern? >> >> Ah, so you want to keep the current mechanism and not inject fresh >> randomness? Isn't this fairly risky? > > > Can you explain the risk you are concerned about in more detail? > > -Ekr > > > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
