On 08/06/2013 10:53 AM, Michael StJohns
wrote:
Hi Robert -
I don't have any big problems with the TLS derive mechanisms,
but I do have a problem exposing the TLS1.2 PRF as a directly
callable mechanism.
In the the protocol, the PRF is used to both derive keys and to
perform a MAC over the final data. The problem is that the PRF
produces public data by default, which means that you can use
the PRF to derive the key data - since both the keys and the MAC
are derived from the TLS master key.
I'd provided the fixes for this in conjunction with my
C_DeriveKeys proposal. I've attached only the relevant section
above. Basically, the TLS12MAC mechanism uses the TLS PRF as an
internal function and doesn't allow you to specify arbitrary
labels. By preventing the specification of arbitrary labels, you
can prevent the release of the key material since that key
material uses different labels to generate it.
Lastly, I would prohibit the release of IV material to the
CK_SSL_KEY_MAT_OUT structure (para 6 of 1.1.6) as you can cause
the release of key material by simply shrinking the lengths of
the keys requested for the first four slots - that causes the
key material to leak into the IV space.
Mike
Mike,
Do you have an actual counter proposal that can be used to implement
TLS? I would be OK with taking that instead if it's fully formed,
otherwise this is a tweak on what we already have defined for TLS
1.1. I am very much against holding up peoples ability to implement
TLS 1.2 for a second rev of the spec.
bob
On 7/31/2013 8:41 PM, Robert Relyea wrote:
Submitter's message
Please comment on the following areas specifically before we
propose this for a ballot:
Mechanism and PARAM names: I changed TLS-> TLS12, but that
may not be the best as the mechanism are likely to apply to
future versions of TLS as well. Names with _WITH_HASH seemed a
little unwieldy, but I wouldn't object to them.
Whether or not I should add the hash text to each mechanism
description instead if just in the beginning, PRF and in the
PARAM description.
The hash parameter is a CKM_MECHANISM_TYPE hash; with no
descriptive prefix (a la ulHash for instance). I did this
because I could not find any other examples of a
CKM_MECHANISM_TYPE parameter other then in the CKM_MECHANISM
structure (where it is devoid of a descriptive prefix as well).
I'm will to add one if everyone is agreed. mHash or ulHash may
be better.
bob
-- Mr. Robert Relyea
Document Name:
TLS
1.2 mechanisms
Description
This adds the new mechanism needed to support TLS 1.2.
TLS 1.2 is basically the same as TLS 1.0 and TLS 1.1
except that in TLS 1.2
the underlying hash used for the PRF can be negotiated
as part of the
protocol. This proposal adds a mechanism the parameters
for the TLS
mechanism to select the desired hash. A hash of CKM_SHA1
would produce the
same results as the existing TLS mechanism.
Download
Latest Revision
Public
Download Link
Submitter:
Mr. Robert Relyea
Group: OASIS PKCS 11 TC
Folder: Documents
Date submitted: 2013-07-31 17:41:06
|
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|