On 8/6/2013 2:43 PM, Robert Relyea
wrote:
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?
Did you look at what I attached?
Delete the PRF section you provided, add the TLS MAC section I
provided. Make the edit to section 1.1.6.
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.
I understand.
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
|