resend (Sorry, for the typos.)
Martin Rex wrote:
The truncation of hashes/PRFs/HMACs is a trade-off.
A trade-off between collision-resistance and how much clue
is provided about the input.
TLSv1.0 (rfc2246) references RFC-2104 (HMAC)
TLSv1.1 (rfc4346) contains a normative reference to RFC-2104 (HMAC)
TLSv1.2 (rfc5246) contains a normative reference to RFC-2104 (HMAC)
http://tools.ietf.org/html/rfc2104#section-5
5. Truncated output
Applications
of HMAC can choose to truncate the output of HMAC by outputting the t
leftmost bits of the HMAC computation for some parameter t (namely,
the computation is carried in the normal way as defined in section 2
! above but the end result is truncated to t bits). We recommend that
! the output length t be not less than half the length of the hash
! output (to match the birthday attack bound) and not less than 80 bits
(a suitable lower bound on the number of bits that need to be
predicted by an attacker).
That rfc-5246 did not increase the finished messages to at least
16 octets (128) when using a SHA-256 based PRF, without providing
any rationale, seems like a defect to me. It is clearly against the
recommendation in the normative reference. The difference is not so
much about TLSv1.2 itself, where truncation to 96 bits is used
with SHA-256 instead of the recommended minimum length of 128,
but the bad precedent for successor specs using longer hashes,
suggesting a truncation to 96 bits for a SHA-384 based PRF, which
is extremely far off the recommended minimum HMAC truncation
length of 192 bits for SHA-384.
I think that a TLS cipher suite definition that uses a PRF based
on SHA-384 ought to be required to provide a rationale when
truncating the finished messages to 96 bits, instead of the
minimum "half the length of the hash" recommended by rfc-2104.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf