Deprecate the CKM_TLS_* and CKM_SSL_* mechanisms.

[Michael StJohns <msj@nthpermutation.com>]

Hi -

This is a follow up to my previous message which mentioned the topic in 
passing.

While looking at various things for a FIPS140-2 evaluation, I realized 
that the TLS key derivation functions were flawed in one really bad way.

Consider the TLS pre-master key.  To get to the TLS master key, you 
apply the TLS PRF to the pre-master key, with a specific label and 
seed.  If you use the CKM_MASTER_KEY_DERIVE mechanism with C_DeriveKey 
you get a TLS master key that has specific CKA_SENSITIVE etc values.

If you use the CKM_TLS_PRF with the same seed and label that 
CKM_MASTER_KEY_DERIVE uses, and the same pre-master key, you end up with 
a public array of bytes that is the private data for the master key.

Moving on to CKM_TLS_KEY_AND_MAC_DERIVE.  This TLS1.0 function allows 
the derivation of 4 keys and 2 IVs.  Unfortunately, it does this by 
chopping up a stream of bytes generated by the TLS_PRF in the order 
above - 4 chunks of private data and two chunks of public data.     So 
the way you can get private data out is by shrinking the data that gets 
assigned to the private keys (e.g. if the actual keys are AES256, change 
the template so you're getting AES128 keys, same thing with the MACs).  
The private data now leaks into the IVs which are public.  Or you could 
just use the TLS_PRF mechanism and generate the data directly.

Basically, if all of these mechanisms are present, there is no way to 
prevent the exposure of the TLS session keys outside of an HSM.

Unfortunately, to fix this requires a complete re-work rather than just 
elimnating the CKM_TLS_PRF mechanism and prohibiting the output of the 
IV data.

I think this is a lost cause for TLS1.0 and before.

I think a small fix can be done for TLS1.1 (remove the TLS_PRF, limit 
the output for CKM_TLS_KEY_AND_MAC_DERIVE to only key material, add a 
CKM_ mac mechanism to deal with the TLS final messages).

I think the TLS1.2 function becomes a single TLS derive function (pass 
in the label and seed and key, get out as many keys as you want), and a 
MAC function to deal with the TLS final message (same as the TLS1.1 
function, except uses the TLS1.2 PRF).

The general rule here - don't let your KDFs generate public data.

Mike