Re: [TLS] Data volume limits

[Eric Rescorla <[e-mail]>]

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