[TLS] IV Generation was: Clarifications and questions: TLS1.3 - Static RSA and AEAD

[Michael StJohns <[e-mail]>]

On 5/26/2014 11:25 PM, Eric Rescorla wrote:
> On Mon, May 26, 2014 at 8:14 PM, Michael StJohns 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     On 5/26/2014 10:32 PM, Eric Rescorla wrote:
>>
>>         Does it also result in changing the output of the "key
>>         expansion" phase as only "client_write_key" and
>>         "server_write_key"s will be needed for AEAD?
>>
>>
>>     I don't believe so, since AEAD still at least potentially
>>     requires an IV.
>
>     Right - but we really need to get IV material in a way where it
>     isn't derived from the master secret.
>
>
> I don't agree with this claim. As I understand the constraints, they 
> merely
> need to be derived in a way that is isolated from the keying material.
> Is there a reason that it's unsafe to generate the IVs from the MS 
> provided
> that this condition is met?


I'm going to answer this twice because EKR's comment appears to include 
an slight internal inconsistency or I'm mis-understanding what he meant:

1) ----------------------------------

"isolated from the keying material" can be accomplished one of two ways 
- by deriving a sub-secret from the master secret and then using that 
for generating the IV in a keyed PRNG, or by deriving a second secret 
from the pre-master secret at the same time you generate the master 
secret and generating the IV from that second secret.  I would claim 
that neither of those is equivalent to "generate the IV's from the MS...."

There's a third way that basically injects per-key and iv length 
information into the KDF expansion - I looked at this and rejected it as 
it made the KDF security analysis complex and it violated the general 
principle that cryptographic functions output either public (cipher 
text, signatures) or private data (key material) and not both.

Is there a fourth way you were thinking of? and "isolated" needs to mean 
"cryptographically isolated".


2) ----------------------------------

As a specific comment on how the master secret is used:

The general rule is that the same key shouldn't be used for multiple 
things.  In this case the master secret is used (ignoring for a moment 
that the functions are all iterations of the PRF):

  * with a Key Derivation Function to derive key material
  * with a MAC function to sign the finished messages
  * with a keyed pseudo random number generator to derive the IV's.

By my count that's two too many.  The fact that the KDF and PRNG steps 
are part of the same process is even more problematic.

There's literature on this - but an easy reference is section 5.2 of 
NIST's SP800-57 part 1 rev 3 - 
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-57-Part%203-Rev.1:

> 5.2 Key Usage
> In general, a single key should be used for only one purpose (e.g., 
> encryption, authentication,
> key wrapping, random number generation, or digital signatures). There 
> are several reasons for
> this:

> 1. The use of the same key for two different cryptographic processes 
> may weaken the
> security provided by one or both of the processes.

> 2. Limiting the use of a key limits the damage that could be done if 
> the key is compromised.

> 3. Some uses of keys interfere with each other. For example, consider 
> a key pair used for
> both key transport and digital signatures. In this case, the private 
> key is used as both a
> private key-transport key to decrypt data-encryption keys and a 
> private signature key to
> apply digital signatures. It may be necessary to retain the private 
> key-transport key
> beyond the cryptoperiod of the corresponding public key-transport key 
> in order to decrypt
> the data-encryption keys needed to access encrypted data. On the other 
> hand, the private
> signature key shall be destroyed at the expiration of its cryptoperiod 
> to prevent its
> compromise (see Section 5.3.6). In this example, the longevity 
> requirements for the
> private key-transport key and the private digital-signature key 
> contradict each other.

> This principle does not preclude using a single key in cases where the 
> same process can provide
> multiple services. This is the case, for example, when a digital 
> signature provides assurance of
> the identity of the originating entity, non-repudiation, source 
> authentication and integrity
> protection using a single digital signature, or when a single 
> symmetric data-encryption key can
> be used to encrypt and authenticate data in a single cryptographic 
> operation (e.g., using an
> authenticated-encryption operation, as opposed to separate encryption 
> and authentication
> operations). Also refer to Section 3.7.

> This Recommendation also permits the use of a private key-transport or 
> key-agreement key to
> generate a digital signature for the following special case:
> When requesting the (initial) certificate for a static 
> key-establishment key, the associated
> private key may be used to sign the certificate request. Also refer to 
> Section 8.1.5.1.1.2.

Because the IV may be used for things like nonces, the IV generator 
needs to be unpredictable, but able to be generated synchronously from 
data available to the sender and receiver.  It's unclear that it needs 
any more entropy (e.g. a key)  than that available in the client_random 
and server_random.  If the per-message IV is carried in its entirety in 
the message, then the IV generator need not be coordinated between 
sender and receiver.

 From a general cryptographic point of view, an IV is NOT a confidential 
data element.  A cipher mode is required to be secure even if the IV is 
available to an attacker, so again, it's unclear the IV generator needs 
to be a keyed PRNG.

Mike