Subject: Re: [TLS] Data volume limits

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 28 Dec 2015 21:17:04 +0000

"Cranking the KDF" suffices for providing "subkeys" that are cryptographically intractable, which should address the concern of "too much plaintext under the same key". That's less than what I'd consider a "full re-key". ‎And even then "cranking the KDF" with something newly-random isn't a bad idea at all.

I don't think common crypto expertise would disagree.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Salz, Rich
Sent: Monday, December 28, 2015 16:09
To: Blumenthal, Uri - 0553 - MITLL; Eric Rescorla
Cc: Florian Weimer; [email-masked]
Subject: RE: [TLS] Data volume limits

> When the key is changed, the change procedure should involve new randomness. 
‎
I don't think this is necessary, and I don't think the common crypto expertise agrees with you, either. But I am not a cryptographer, maybe one of the ones on this list can chime in.

"Crank the KDF" suffices.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 30 Dec 2015 00:20:28 +0000

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-masked]
Subject: Re: [TLS] Data volume limits

On Tue, Dec 29, 2015 at 5:08 PM, Dave Garrett <[email-masked]> 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

‎