On Tue, Dec 29, 2015 at 5:08 PM, Dave Garrett <[email protected]> wrote:
> On Tuesday, December 29, 2015 02:10:25 pm Brian Smith wrote: > > 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 > > The current spec mostly uses the former, so yes, I guess we really should > stop saying "rekey" if this has been defined like this. The single use of > "rekey" in the doc should probably be changed to "key update" if we keep > things as-is, then. Maybe. I don't find this taxonomy particularly evocative. > On Tuesday, December 29, 2015 02:33:38 pm Eric Rescorla wrote: > > Note: the keys here are *not* derived from the old keys. Rather, they > are derived via > > a KDF from the same secret that was used to generate the old keys. > > Yes, but they are derived from the same entropy as the old keys. Yes. I didn't say otherwise. > Yes, that's not the same thing, but they're not totally independent new > keys either. If we're only doing this as a hack to fix ciphers that have > problems (that really should just be fixed instead), then this is fine. I > think it's just the fact that we _could_ add a full rekey mechanism without > a fantastic amount of additional effort is what's giving some people pause. > Well, i don't know what "fantastic" means here, but we did look at this prior to designing the present mechanism and it was a nontrivial amount of additional complexity. -Ekr
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
