Re: [pkcs11] Groups - TLS 1.2 mechanisms uploaded

[Michael StJohns <msj@nthpermutation.com>]

On 8/29/2013 4:14 PM, Wan-Teh Chang wrote:
> Hi Bob and Mike,
>
> I have started to implement your proposal in NSS. Note that NSS
> already supports vendor-defined TLS 1.2 mechanisms that are hardcoded
> to use P_SHA256 as the TLS PRF. So I did not start from scratch.
>
> I have implemented the three easy mechanisms:
> * CKM_TLS12_MASTER_KEY_DERIVE
> * CKM_TLS12_MASTER_KEY_DERIVE_DH
> * CKM_TLS12_KEY_AND_MAC_DERIVE
>
> Note: as I noted in private email, I am not planning to implement
> CKM_TLS12_KEY_SAVE_DERIVE in NSS because it can't be used with the
> AES-GCM cipher suites.
>
> My code consists of two changelists.
> 1. Changelist for the NSS softoken: https://codereview.chromium.org/23510003
> 2. Changelist for the NSS SSL library: https://codereview.chromium.org/23713003
>
> While implementing these three mechanisms, I found that it is
> advantageous to add the new 'prfHashMechanism' field to the end of the
> CK_TLS12_MASTER_KEY_DERIVE_PARAMS and the CK_TLS12_KEY_MAT_PARAMS
> structs. This allows the same structures to be used as the old
> CK_SSL3_xxx structs for the corresponding mechanisms for SSL3 and TLS
> 1.0-1.1. I remember Mike pointed out this advantage but I didn't fully
> appreciate it at that time. This also requires resurrecting the
> bIsExport field in CK_TLS12_KEY_MAT_PARAMS.
>
> Here is the changeI made to the params structs:
>
> https://codereview.chromium.org/23510003/diff2/1:4001/nss/lib/util/pkcs11t.h

Unfortunately, that isn't what's being balloted.   Perhaps I shouldn't 
have given in so easily with respect to the "struct" definitions, but I did.

I'd recommend at this point sticking with what's in the document rather 
than the changes you made.  There isn't any real issue as the old 
definitions have different names than the new definitions just for this 
purpose.   This is sort of false economy in any event as all you're 
doing is saving a few lines in the .h file.

Mike



> I am, however, not sure if this violates the "anti-aliasing" rules of
> the C language, but it is quite common to do it this way in low-level
> C code.
>
> Wan-Teh Chang