Re: [pkcs11] Groups - TLS 1.2 mechanisms uploaded

[Wan-Teh Chang <wtc@google.com>]

Hi Mike,

Thank you for your suggested changes.

On Tue, Aug 6, 2013 at 10:53 AM, Michael StJohns <msj@nthpermutation.com> wrote:
> 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.

My NSS colleague Brian Smith pointed out that this proposed change
makes it impossible to implement the TLS keying material exporter
(RFC 5705). So we still need a mechanism that provides *secure* access
to the TLS 1.2 PRF. This mechanism needs to take a string as the 'label'
input to the TLS 1.2 PRF, with the strings "client finished", "server finished",
"master secret", etc. prohibited, and output a generic secret key object
of the specified length as output.

Comments on your TLS MAC mechanisms:

1. It seems that we can just use a single CKM_TLS10_MAC mechanism
that takes a parameter for specifying server or client.

2. The CK_TLS12_MAC_PARAMS structure needs to have a field for
specifying the output length. See this paragraph from section 7.4.9 of
RFC 5246:

      In previous versions of TLS, the verify_data was always 12 octets
      long.  In the current version of TLS, it depends on the cipher
      suite.  Any cipher suite which does not explicitly specify
      verify_data_length has a verify_data_length equal to 12.  This
      includes all existing cipher suites.  Note that this
      representation has the same encoding as with previous versions.
      Future cipher suites MAY specify other lengths but such length
      MUST be at least 12 bytes.

Your proposal says:

    CKM_TLS12_MAC  This length should be in the range 0-20 (the output
    size of SHA-1 is 20 bytes). Signatures (MACs) produced by this
    mechanism will be taken from the start of the full 20-byte HMAC output.

Those two sentences refer to SHA-1 (and its output size of 20 bytes), which
is wrong for TLS 1.2 because TLS 1.2 defaults to P_SHA256 for the PRF.

> 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.

Although pIVClient and pIVServer in the CK_SSL3_KEY_MAT_OUT
structure are not used by the CBC block ciphers in TLS 1.2, they are
used by the AES-GCM cipher suites specified in RFC 5288 and
RFC 5289. (Search for "client_write_IV" and "server_write_IV" in
RFC 5246 and RFC 5288.) So I'm afraid that we can't make the
change you suggested.

Wan-Teh