On Tue, Dec 29, 2015 at 2:10 PM, Brian Smith <[email protected]> wrote: > Ilari Liusvaara <[email protected]> wrote: >> >> OTOH, you can't drop an attacker knowing older key without doing >> new key exchange. > > > I think it would be very unfortunate to have the complexity of key update > (the new keys are derived from the old keys) without having the benefits of > rekeying (the new keys are independent of the old keys).
What complexity? Sending a special packet with a different protocol that triggers a change in record layer state is not that tricky, and even DTLS is designed to handle this already. In fact one could even use the epoch number implicitly. What benefits? The concern isn't that an attacker obtains the key, but that confidentiality is lost. If we're worried about attackers who can read memory the answer is clear: write in a language that doesn't permit this. > > Note that NIST Special Publication 800-133 [1] defines these separate terms, > and I suggest we use them in this conversation to avoid confusion: > > Key update: A procedure in which a new cryptographic key is computed as a > function of the (old) cryptographic key that it will replace. > > Rekey: A procedure in which a new cryptographic key is generated in a manner > that is independent of the (old) cryptographic key that it will replace. > > [1] > http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133.pdf. > > Cheers, > Brian > -- > https://briansmith.org/ > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
