Re: [TLS] Two Decisions?

[Martin Thomson <[e-mail]>]

On 25 November 2014 at 15:25, Michael StJohns <[e-mail]> wrote:
> A/O TLS 1.2 the PRF function changed to be negotiable.   During discussions
> for things like session hash, the question was brought up (or at least I
> brought it up) as to whether or not the PRF function always needed to be a
> hash function (vs say a block cipher function) and I think the general
> consensus was that it was too difficult to remove due to its use in the
> finish message and session hash.   Would that be a fair assessment?  And if
> so, should text be added to make this clear?  (Specifically, the PRF
> negotiation specifies a hash, and the KDF and various other derived
> functions are based on the HMAC construct of that hash.)


One of the properties we are relying on here is preimage resistance.
I believe that to be a firm requirement for exporters, for instance.
That should certainly be documented as an assumption, because it does
remove a number of MAC constructions from consideration.

The 48-byte thing always bothered me a little.  If the PRF produces
any MS that is shorter, it's not like it contains any less entropy
when talking about traffic key derivation.  I'd be inclined to say
that a single crank of the PRF is all that is needed for any of the
long-term keys, which will mean more or less than 48 depending on the
negotiated PRF.

I don't think that this is significantly more complex.  And if we are
running more PRFs, it might save a few cycles at a critical moment
(i.e., the handshake).