Current Mechanisms, Section 2.29, TLS 1.2 Mechanisms

[Dina Kurktchi <dina.kurktchi@oracle.com>]

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.