Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx

[Martin Rex <[e-mail]>]

Eric Rescorla wrote:
> 
> >
> > I'm sorry, but I think it is a bad idea to use a flawed design for
> > the TLS finished message by subverting the collision resistence
> > of stronger secure hash functions that are used for the PRF.
> 
> Yes, I realize you think that, but until you offer a cryptographic
> argument for that opinion I guess we're just going to have to disagree.


You got it backwards.  I say that it is a bad idea to truncate
a PRF based on SHA-256 to 96, and even worse idea to truncate a
PRF based on SHA-384  -- and anyone who wants to do that should
better provide a good cryptograhic argument.


Truncating HMACs and PRFs may have become first popular in
the IETF within IPSEC.

Looking at this table:

     http://tools.ietf.org/html/rfc4868#section-2.6


   +------------------+--------+--------+--------+--------+------------+
   |    Algorithm     | Block  | Output | Trunc. |  Key   | Algorithm  |
   |       ID         |  Size  | Length | Length | Length |   Type     |
   +==================+========+========+========+========+============+
   | HMAC-SHA-256-128 |   512  |   256  |  128   |  256   | auth/integ |
   +------------------+--------+--------+--------+--------+------------+
   | HMAC-SHA-384-192 |  1024  |   384  |  192   |  384   | auth/integ |
   +------------------+--------+--------+--------+--------+------------+
   | HMAC-SHA-512-256 |  1024  |   512  |  256   |  512   | auth/integ |
   +------------------+--------+--------+--------+--------+------------+
   | PRF-HMAC-SHA-256 |   512  |   256  | (none) |  var   |     PRF    |
   +------------------+--------+--------+--------+--------+------------+
   | PRF-HMAC-SHA-384 |  1024  |   384  | (none) |  var   |     PRF    |
   +------------------+--------+--------+--------+--------+------------+
   | PRF-HMAC-SHA-512 |  1024  |   512  | (none) |  var   |     PRF    |
   +------------------+--------+--------+--------+--------+------------+


If there existed a cryptographic argument (which you insist on) then
I'm sure there would be an HMAC-SHA-394-96 in the above list.

What is your argument why there should be a HMAC-SHA-384-96 in that list?
(which would apply to a ciphersuite with a SHA-384 based PRF and
finished messages truncated to 12 octets).

-Martin