Subject: [TLS] Key derivation processes

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jul 2014 13:58:19 -0700

We've had a bit of discussion thus far about the role of the PRF and
its form.  I think that having a map that describes what material goes
where might help understanding the process.

Here's how I think we should try to structure the flow of keying material:

The handshake determines the PMS.  That's not any different from TLS 1.2.

>From the PMS, we derive a set of other keys and material derived from
those keys.  How that material is subsequently protected can vary
depending on the requirements around its usage.

   - A client read/server write encryption key

   - A client read/server write IV

   - A client write/server read encryption key

   - A client write/server read IV

   - Input for calculating the Finished message

   - A TLS extractor [RFC5705] primitive to be used in place of the MS

   - A TLS unique [RFC5929] value

   - A resumption key that is used as input to the PMS of a resumed connection

Then the PMS is discarded.

This design is basically TLS extractor, which is no coincidence.

The function that is used to derive each of these doesn't matter at
this level of the description. The constraints here are well-known
(triple handshake, etc...). That means that inputs probably include
PMS (which is the resumption key if that's what is going on), plus
everything that appears in the handshake prior to the start of
encryption: version, client random, server random, cipher suite offer
and selection (including group), and DH shares.

I think that this addresses the concerns Mike StJohns has raised with
the current read/write/IV generation function by having independent
streams for keying material and IVs.

I'll note that from the TLS extractor primitive you could derive
several of these items rather than rely on the PMS.  That would allow
their creation to be deferred.  The input to Finished is one
possibility.  TLS unique is another good candidate for this since it
isn't intrinsic to the protocol; though we may want to wait until
after we decide the fate of Finished before we determine the fate of
TLS unique.  That said, you really don't want to derive anything
secret from the TLS extractor key, like the encryption keys, since
that creates a nasty validation problem for extractor.

Rekeying of the form that I proposed simply requires the application
of a one-way function - which might be the same function as above - to
the encryption keys (and IVs) in the affected direction.