Re: Additional suggested cleanups for TLS

> From: Dan Simon <dansimon@microsoft.com>
>
> Standardized key generation using PRFs
> 
> Hugo Krawczyk recently suggested to the WG on this list that an explicit
> PRF primitive be introduced into the spec, so that the protocol could be
> based on an easily replaceable function whose assumed properties would
> be clearly defined and well understood.  Currently, there's an
> implicitly defined PRF in the spec, used for master secret and key block
> generation.  It has the following structure:
> 
> f(k,x) =
> 	MD5(k + SHA('A' + k + x)) + 
> 	MD5(k + SHA('BB' + k + x)) +
> 	MD5(k + SHA('CCC' + k + x)) + [...];
> 
>            [...]
> 
> As well as standardizing the key derivation process, this change to a
> uniform PRF-based method would encourage implementers to make the PRF
> pluggable, allowing more secure or more efficient functions to replace
> the current one in the future as needed.  (In fact, we might consider
> switching to a better PRF immediately, if we are already breaking
> backward compatibility by changing HMAC.)  Ideally the current cipher
> suites would either implicitly or explicitly specify the current default
> PRF, so that additional PRF options could be added, if necessary, simply
> by adding new cipher suites.
> 
> Comments on these proposals (especially from Hugo!) are welcomed.



I agree completely, and support the PRF proposals from Dan and Hugo.

Hugo also mentioned some other topics:

 1) The form of the PRF used by IPSEC, which uses an appended one-up
    counter to generate successive key blocks, is not optimal.

The SSL form, using prepended 'A', 'BB', 'CCC', [...] seems much better
in that it varies a) the value of the unique data, b) the length of the
unique data, and c) the position of k and x.  But I'd like to hear
Hugo's confirmation that the SSL form looks like a good key block
generation method.  Although it's unlikely that anyone would ever
try to make more than 26 blocks, there should probably be an
explicit statement that it is forbidden to go past 'ZZZZ...Z', and
that if more bits are needed it's time go get some more entropy.

 2) Mixing MD5 and SHA in a single ad-hoc function probably doesn't
    buy anything because it is difficult to imagine a situation in
    which SHA is broken but MD5 remains sound.

This sounds reasonable, and I'd support using a "better PRF" based
on non-mixed HMAC-SHA.

 3) For integrity purposes (not for signatures!) it may be more secure
    to truncate the SHA output to 128 bits.

Although the suggestion originally had nothing to do with security (it
was motivated by the desire to have the same size output for MD5 and
SHA), the idea that truncating keyed hash functions may improve their
robustness by hiding some state is intuitively appealing.  But I don't
know if there is enough of a theoretical basis yet to suggest using
HMAC-SHA-128.

Received on Tuesday, 17 December 1996 12:53:52 UTC