Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx

[Martin Rex <[e-mail]>]

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