[TLS] Two Decisions?

[Michael StJohns <[e-mail]>]

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.