ietf
[Top] [All Lists]

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

2011-03-08 13:24:23
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>