RE: [TLS] Truncated HMAC

["Blumenthal, Uri" <uri.blumenthal@xxxxxxxxx>]

Pasi,

I support your proposal. It is a good solution, as it puts a clean
separation between the entangled "mac", "hash" and "key".


-----Original Message-----
From: Pasi.Eronen@xxxxxxxxx [mailto:Pasi.Eronen@xxxxxxxxx] 
Sent: Monday, November 20, 2006 8:52 AM
To: mike-list@xxxxxxxxx; tls@xxxxxxxx
Subject: RE: [TLS] Truncated HMAC

Mike <mike-list@xxxxxxxxx> wrote:

> Then I would propose changing "CipherSpec.hash_size" to 
> CipherSpec.mac_length so that "hash_size" does not have
> 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

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls