I like option (2) from Eric's taxonomy. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. From: Eric Rescorla Sent: Tuesday, December 29, 2015 18:12 To: Dave Garrett Cc: Florian Weimer; [email protected] Subject: Re: [TLS] Data volume limits
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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
