Re: [TLS] Suite B compliance of TLS 1.2

Martin Rex <> Wed, 26 July 2006 13:37 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1G5jaI-0002CA-As; Wed, 26 Jul 2006 09:37:58 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1G5jaG-0002C1-V9 for; Wed, 26 Jul 2006 09:37:56 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1G5jaF-0004kd-I9 for; Wed, 26 Jul 2006 09:37:56 -0400
Received: from (smtpde03) by (out) with ESMTP id PAA26759; Wed, 26 Jul 2006 15:37:34 +0200 (MESZ)
From: Martin Rex <>
Message-Id: <>
Subject: Re: [TLS] Suite B compliance of TLS 1.2
Date: Wed, 26 Jul 2006 15:37:28 +0200 (MET DST)
In-Reply-To: <> from "Eric Rescorla" at Jul 25, 6 09:32:28 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
X-Mailman-Version: 2.1.5
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: <>, <>

Eric Rescorla wrote:
> Wan-Teh Chang <> writes:
> > At the 2005 RSA Conference, the US National
> > Security Agency (NSA) announced Suite B Crytography
> > (
> > This suite of cryptographic algorithms includes AES,
> > ECDSA, ECDH, ECMQV, and SHA-256/SHA-384.
> >
> > I'm interested in the Suite B compliance of TLS 1.2.
> > Simply put, it means the ability to do TLS 1.2 using
> > only Suite B algorithms.
> >
> > The primary goal of TLS 1.2, to remove the protocol's
> > dependency on the MD5 and SHA-1 digest algorithms, is
> > in line with Suite B compliance.  I'd like to start
> > the discussion by proposing additional goals:
> > - merge in or reference RFC 4492

AFAIK, the dependency on the combination of SHA-1 and MD5 is
hardwired into the protection of the SSL handshake,
and independent of the ciphersuite that is negotiated.

So in order to remove the dependency, one does not only need
new TLS ciphersuite, but also a significant change in the
handshake protocol (hashing of the handshake messages
and the creation/verification of the finished message).

Hashing the handshakes messages with both, old and new hash
algorithms and deciding later in the handshake which results
go into creation/verification of the finished message when
it has been determined/negotiated which algorithms to use
should be doable, and just moderately more expensive.

I'm slightly worried about the potential "market pressure"
which this might cause.  I certainly don't mind adoption/offering
of strong cryptographic protocols/technologies, but right
now I do NOT consider TLS fundamentally broken or weak,
and I would prefer if people focus on the acutal weaknesses
within the technology, rather than replacing the
(currently) strongest link in a weak chain with a much
stronger one.


TLS mailing list