I don't understand this reasoning. Why does the output size of the pre-truncated PRF influence the desirable length of the verify_data (provided that the output size is > than the length of the verify_data of course). -Ekr On Tue, Mar 8, 2011 at 7:59 AM, Martin Rex <mrex@xxxxxxx> wrote: > Sean Turner wrote: >> > >> > Yours was the first document I noticed to use SHA384 as PRF. If there >> > are other documents that specify that, and don't set the verify_data_length >> > size then it applies to those as well. (just noticed that applies to RFC5288 >> > as well). >> >> If the verify_data_length default is 12 (from 5246) then saying nothing >> means that it's still 12 right? Or, do you think an explicit statement >> saying "the default value for verify_data_length of 12 is used" is needed? > > > Truncating the PRF output to 12 octets for TLSv1.2 seems like an error. > > If truncating a SHA-1 based PRF in TLSv1.0/TLSv1.1 to 12 Octets is > considered adequate (20/12), then truncation in TLSv1.2 with > a SHA-256 based PRF should have been (32/20) and truncation for > a SHA-384 based PRF should be more like (48/28) or (48/32). > > To me, Truncating the output of a SHA-384 PRF to 12 Octets looks like > unreasonable cutdown of the security margin for the Finished messages. > > -Martin > _______________________________________________ > TLS mailing list > TLS@xxxxxxxx > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf