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). > 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. I.e., K_send_0 = KDF(MK_0, <label1>) K_recv_0 = KDF(MK_0, <label2>) MK_1 = KDF(MK_0, <label3>) K_send_1 = KDF(MK_1, <label1>) K_recv_1 = KDF(MK_1, <label2>) 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. > Hmm... It seems to me that there are three (at least) three separate possible designs: 1. Generate the new keys by a new application of the KDF with no additional inputs. 2. Generate the new keys by a new application of the KDF with additional random inputs. 3. Generate the new keys by a new PK key exchange (potentially also using the old keys and new random inputs). These all have different security properties and it's not clear to me which buckets these fall into. As far as complexity goes, 3 is more complicated than 2 which is more complicated than 1. -Ekr
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
