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
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:
and the whole thread is a very interesting read.
e.g. excerpt from Dan Simon's message
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,
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:
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.
Ietf mailing list