|
On 8/8/2013 2:35 PM, Wan-Teh Chang
wrote:
Hi Mike,
Thank you for your suggested changes.
Thanks very much for reviewing them. I think you caught mostly the
same ones I caught, but the double check is very very helpful.
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.
Yup. I found this out as I was working through all of the
permutations. I'm adding a TLS PRF based mechanism that can only be
used for key derivation. The name is CMK_TLS12_KDF and accepts a
label, set of random values and an optional context per that RFC.
I figured out that you don't have to provide an output structure to
produce multiple keys - instead do a second (third, fourth etc)
derivation from the produced key stream using one of the trivial kdf
functions - CKM_EXTRACT_KEY_FROM_KEY to break up the key stream.
It's a few more steps, but is a general solution to the problem of
producing multiple keys from a single derivation result.
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.
Considered actually folding this into the generic mechanism and
using CKM_TLS_PRF as the KDF mechanism, but figured that since this
was replacing a previously existing mechanism I'd make it as easy as
possible and not require the provisioning of a params structure
(since the PRF and mac length are fixed and known).
Neither was more secure so I erred on the side of making it easier
for the programmer.
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.
I caught this one as well.
CK_TLS12_MAC_PARAMS
is a structure that provides the parameters to the CKM_TLS12_MAC
mechanism. It is
defined as follows:
typedef
struct CK_TLS12_MAC_PARAMS {
CK_MECHANISM_TYPE
prfHashFunction;
CK_ULONG ulMacLength;
CK_ULONG
ulServerOrClient;
}
CK_TLS12_MAC_PARAMS;
This is from a soon-to-be-published version. ulMacLength is >=
12 per the RFC. The appropriate table was updated as well .
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.
Yeah. I found this when doing my final pass for correctness. I
sent a note to the CCM and GCM authors about this. I also may submit
some text for TLS1.3 - it's *really* annoying me that I can't fix
this easily.
I may ask the CCM/GCM author to propose a new mechanism that gets
its IVs from somewhere else. For TLS1.3, I'm thinking that
inserting a key derivation step between the key generation and IV
generation step might work - e.g. derive 4 keys plus an IV subkey.
From the IV sub key derive the two IVs. The private data will never
be extractable as public data by doing it this way. Unfortunately,
both of these approaches require either a new TLS or a new set of
AEAD TLS mechanisms. *sigh*
I may end up providing two mechanisms - one that allows the IV to be
extracted and one that doesn't - still thinking about this. Then
CKA_ALLOWED_MECHANISMS can be used to prevent some leaks. Will have
something decided by tomorrow late.
I did ended up providing a black box notice:
Note
Well: This mechanism
produces both private (key) and public (IV) data. It is possible to "leak"
private
data by the simple expedient of decreasing the length of
private data
requested. E.g.
Setting ulMacSizeInBits
and ulKeySizeInBits to 0 (or other lengths less than the key
size) will result
in the private key data being placed in the destination
designated for the
IV's. Repeated calls
with the same master
key and same public data but with differing lengths for the
private key
material will result in different data being leaked.
I should have a merge between Robert's document and my edits done by
the end of this week.
Mike
Wan-Teh
|