[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Current Mechanisms, Section 2.29, TLS 1.2 Mechanisms
See below. On 11/05/15 01:22, Dina Kurktchi wrote:
Hi, I have some questions about Section 2.29. I'm looking at http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/os/pkcs11-curr-v2.40-os.html which I hope is the right one. The section that once contained TLS definitions is missing. I must not have been paying attention when that happened, but it does impact the statement about being "backward compatible with v2.20". Things like CKM_TLS_PRE_MASTER_KEY_GEN are missing, and CK_TLS_PRF_PARAMS. I do see CK_TLS_PRF_PARAMS is mentioned on the Oops Page, but not pre-master key gen: https://wiki.oasis-open.org/pkcs11/Definitions My colleagues and I reviewed this section closer, now that we're stuck having to implement it, and found some other items that don't make sense to us. a. CKM_TLS10_MAC_SERVER and CKM_TLS10_MAC_CLIENT are still there. Weren't they removed by a subsequently approved proposal? b. Tell us again why we need CKM_TLS12_KEY_SAFE_DERIVE? We're not really buying the reason stated in the spec. If one wanted to state that it's advisable in some cases to set .ulIVSizeInBits to 0 in CK_TLS12_KEY_MAT_PARAMS, to prevent data leakage, then so state and rename 2.29.7 to "Safely deriving keys with CKM_TLS12_KEY_AND_MAC_DERIVE" Creating a new mechanism for this seems unnecessary, now that we've sat down to implement it! c. CKM_TLS12_MAC should be CKM_TLS_MAC? Section 2.29.3 describes TLS MAC, not TLS12 MAC. d. Seeing that .prfMechanism is listed last in the param structures that are have parallels for TLS and TLS12, CK_TLS_MAC_PARAMS should do the same and list it last. d. While we're at it, the TLS MAC 2.29.3 Section should instead move between 2.29.7 and .8. Seems to flow better that way. e. As mentioned earlier, we need the old 2.29.3 and 2.29.4 back that describe "2.29.3 TLS PRF (pseudorandom function)" and "2.29.4 Pre_master key generation" f. This is nit-picky, but .prfHashMechanism in CK_TLS12_MASTER_KEY_DERIVE_PARAMS is not really a hash mechanism if you allow CKM_TLS_PRF for TLS 1.0/1.1. It seems better to call it simply .prfMechanism. g. Move CK_TLS_KDF_PARAMS structure out of 2.29.2, which is "TLS 1.2 mechanism parameters", down 2.29.8 where it belongs with "Generic Key Derivation using the TLS PRF". h. 2.29.3 TLS MAC, why is it a C_Sign/C_Verify mechanism? I suppose this is something we don't understand, and if someone can shed some light we'd appreciate it. The only time it seems that one can do CKM_TLS_MAC is at the end of the TLS handshake. After the entire hash of all the messages (minus the last ones) has been finalized. We can't justify an Init/Update/Final for CKM_TLS_MAC. It seems to fit much better with C_DeriveKey -- the MAC is derived from hash-of-all-messages. It also seems that C_Sign/C_Verify can't be involved in keeping the running hash-of-all-messages. A number of handshake message precede the master key derivation which is the required key object input to C_SignInit/C_VerifyInit. Would someone please clarify for us if they see it differently? Thank you very much! D.
More questions: i. #define CKM_TLS12_PRF is what ??? We're currently using 0x80000AAA because I couldn't find it anywhere. Did I miss it? j. CKM_TLS_KDF and CK_TLS_KDF_PARAMS Where should the output go? Thanks again! D.