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

Martin Rex <> Fri, 11 March 2011 16:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 962BF3A68D1; Fri, 11 Mar 2011 08:08:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.224
X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MtT9vfOJyM0Z; Fri, 11 Mar 2011 08:08:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 284B63A69CC; Fri, 11 Mar 2011 08:08:51 -0800 (PST)
Received: from by (26) with ESMTP id p2BG7YKW019159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Mar 2011 17:07:34 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
To: (Eric Rescorla)
Date: Fri, 11 Mar 2011 17:07:34 +0100 (MET)
In-Reply-To: <> from "Eric Rescorla" at Mar 11, 11 06:49:53 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Subject: Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Mar 2011 16:08:53 -0000

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:

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.  Jan-1998  HMAC-SHA-1-96 (for IPSEC)  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.