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, since it is clearly against the rationale 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 of 96 for a PRF-386 based hash, which is extremely far off the recommended minimum length of 192 bits. 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf