Subject: RE: [TLS] Truncated HMAC

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 16 Nov 2006 16:26:11 -0500

It simply means that the *final output* of HMAC would be truncated to 10
bytes - but *not* that its input or key would be truncated in any way.

-----Original Message-----
From: Mike [mailto:[email-masked]] 
Sent: Thursday, November 16, 2006 3:32 PM
To: [email-masked]
Subject: Re: [TLS] Truncated HMAC

Casey Marshall wrote:
> On Nov 15, 2006, at 5:02 PM, Mike wrote:
> 
>> I have a question regarding the truncated HMAC extension.
>> When this extension is negotiated, the spec says that
>> CipherSpec.hash_size is 10 bytes.  So does that mean I
>> should only generate 10 bytes for each MAC secret?
> 
>  From RFC 4366, section 3.5:
> 
> "Note that this extension does not affect the calculation of the 
> pseudo-random function (PRF) as part of handshaking or key
derivation."

I saw that, but interpreted it to mean that the HMAC used in the
PRF itself is not truncated.  It is still unclear to me whether
saying "CipherSpec.hash_size = 10" means that the MAC secrets
should be 10 bytes.  My implementation currently computes the
MAC secrets the same whether HMAC truncation is specified or not.
However, I think the spec. could be clarified to say that the
secrets are not reduced to 10 bytes (if that's the intention).
I suggest getting rid of the statement that CipherSpec.hash_size
changes when the extension is used.

Mike

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Mike <[email-masked]>
Date: Thu, 16 Nov 2006 16:03:34 -0800

> bytes - but *not* that its input or key would be truncated in any way.

Then I would propose changing "CipherSpec.hash_size" to 
CipherSpec.mac_length so that "hash_size" does not have
two related but different meanings.

Mike

---

From: <[email-masked]>
Date: Mon, 20 Nov 2006 15:52:02 +0200

> two related but different meanings.

The spec actually never defines a structure named "CipherSpec",
so we need some more changes to make this consistent (and yes,
this was inconsistent already in RFC2246...). Here's my 
proposal:

- Rename "CipherSpec.hash_size" with "SecurityParameters.mac_length"
- Add field called "mac_key_length" to SecurityParameters structure,
  and use this when defining client/server_write_MAC_secret
- Rename field "key_material_length" (in SecurityParameters) to
  "enc_key_length"

And other consistency corrections:

- Remove field "key_size" from SecurityParameters structure 
  (it's not used or mentioned anywhere in the document!)
- Replace "CipherSpec.cipher_type" with "SecurityParameters.
  cipher_type" (the field is already there)
- Replace "CipherSpec.block_length" with "SecurityParameters.
  block_length", and add field called "block_length" to 
  SecurityParameters.
- Replace "CipherSpec.iv_length" with "SecurityParameters.
  iv_length", and add field called "iv_length" to  
  SecurityParameters.

Best regards,
Pasi