Eric Rescorla wrote: > > If your question is why did the TLS WG decide to do this back in like > 1996 or so? > > If so, it would require a real archive search to get a definitive > answer A very superficial scan of the first ietf-tls 1996 archive I came across turned out an an interesting thread "Additional suggested cleanups for TLS" Index page: http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/ started on 16-Dec-1996 by Dan Simon with this message: http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0218.html and the whole thread is a very interesting read. e.g. excerpt from Dan Simon's message http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0224.html [...] On the other hand, there's simply no justification for using a weaker construction in the (more crucial) finished message than in the standard data MAC. Since you vehemently opposed anything weaker than HMAC for data MACing, even for the sake of efficiency (right here on this mailing list, in fact, when we were discussing pre-MAC'd data), I assume you'd never support using a weaker function in the finished message--right, Phil? In any event, the function used in SSL 3.0's finished message is flawed, [...] In case that Dan Simon stands to his message from 1996, it seems unlikely to me that he would consider a TLS cipher suite design reasonably balanced that uses HMAC-SHA-384 for data MACs, but keeps truncating "the (more crucial) finished message" to 12 octets. Another interesting excerpt from the first message of Dan Simon which started this discussion thread: http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0218.html [...] Standardized key generation using PRFs Hugo Krawczyk recently suggested to the WG on this list that an explicit PRF primitive be introduced into the spec, so that the protocol could be based on an easily replaceable function whose assumed properties would be clearly defined and well understood. [...] As well as standardizing the key derivation process, this change to a uniform PRF-based method would encourage implementers to make the PRF pluggable, allowing more secure or more efficient functions to replace the current one in the future as needed. (In fact, we might consider switching to a better PRF immediately, if we are already breaking backward compatibility by changing HMAC.) Ideally the current cipher suites would either implicitly or explicitly specify the current default PRF, so that additional PRF options could be added, if necessary, simply by adding new cipher suites. So the design of the PRF plugabbility was actually invented 1996, and an integral design element of TLSv1.0 (rfc2246 published in Jan-1999). It was never conceived to be limited to only TLSv1.2, and might explain why it is actually pluggable for third parties in Windows XP schannel (which is TLSv1.0) -- Dan Simons signature on these messages reads "Cryptographer, Microsoft Corp.". > > I don't recall why 12 bytes rather than 16 bytes or 20 was chosen. It is not unusual when a two group of folks (IPSEC and TLS) sourcing from the same pool of engineers and experts (IETF) have to do two very similar decisions (truncating HMAC-SHA-1) within a fairly short time, end up with the same conclusion. http://www.ietf.org/html/rfc2404 Jan-1998 HMAC-SHA-1-96 (for IPSEC) http://www.ietf.org/html/rfc2246 Jan-1999 TLSv1.0 The dates vs. rfc-numbers of these two documents look strange: The dates indicate they were published one year apart, but given their rfc-numbers, one would intuitively expect their dates to be just the other way round. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf