Subject: [TLS] Two Decisions?

From: Michael StJohns <[email-masked]>
Date: Tue, 25 Nov 2014 18:25:16 -0500

First item:

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.)

[Side comment - as I've stated before, I really would have liked to have 
the possibility of having a block cipher only PSK TLS implementation, 
but I think that given the general trend toward PFS suites which have 
public key type requirements, I would guess that that ship has sailed, 
even in the constrained device space.]

Second item:

The Master Secret has always been 48 bytes long.  A/O TLS1.2 wouldn't it 
make more sense to have the output of the Pre-Master Secret to MS key 
derivation be a key of the native length for the KDF function?  E.g. 64 
bytes for HMAC SHA256?

Right now, each round of the PRF function produces 32 octets (assuming 
HMAC-SHA256) each round so the function is run twice to get 64 octets, 
then left truncated to get 48 octets of the Pre Master Secret.  When you 
get to the MS to session key negotiation, the 48 octets is right zero 
padded back to 64 octets in the first step of the HMAC setup.

Of course for other SHA functions, the block size is larger - 128 octets 
for SHA384, etc requiring additional rounds in PMS to MS vs just padding.

This approach is slightly more complex, but does scale automatically 
with choice of cipher suite.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Nov 2014 16:10:30 -0800

On 25 November 2014 at 15:25, Michael StJohns <[email-masked]> 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).