RE: [TLS] Suite B compliance of TLS 1.2

"Blumenthal, Uri" <> Wed, 26 July 2006 20:44 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1G5qF5-00038r-Pd; Wed, 26 Jul 2006 16:44:31 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1G5qF4-00038G-IA for; Wed, 26 Jul 2006 16:44:30 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1G5qF3-00022C-3C for; Wed, 26 Jul 2006 16:44:30 -0400
Received: from ([]) by with ESMTP; 26 Jul 2006 13:37:13 -0700
Received: from (HELO ([]) by with ESMTP; 26 Jul 2006 13:37:00 -0700
X-IronPort-AV: i="4.07,185,1151910000"; d="scan'208"; a="105235211:sNHT4764088042"
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 13:36:59 -0700
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 13:36:41 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Suite B compliance of TLS 1.2
Date: Wed, 26 Jul 2006 16:36:37 -0400
Message-ID: <>
Thread-Topic: [TLS] Suite B compliance of TLS 1.2
Thread-Index: Acaw8XnYJ30mjGzfR36ySRk6fBtNdwAAQ9+g
From: "Blumenthal, Uri" <>
To: <>
X-OriginalArrivalTime: 26 Jul 2006 20:36:41.0164 (UTC) FILETIME=[3358D8C0:01C6B0F3]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
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: <>, <>

I think that (a) specifying a reliable hash-function, and (b) defining
self-consistent ciphersuites is a requirement that we must satisfy - and
NOT a "feature-creep".

The smallest iteration on base spec is to keep SSLv3. And it is already

-----Original Message-----
From: Martin Rex [] 
Sent: Wednesday, July 26, 2006 4:20 PM
To: Blumenthal, Uri
Subject: Re: [TLS] Suite B compliance of TLS 1.2

Blumenthal, Uri wrote:
> I.e. you're arguing that cryptography is the strongest link in the
> Navigator and similar products, and therefore efforts should be made
> addressing the weaknesses, not improving what's already "strong"? Then
> sympathize, but...
> To this my answer would be: we as TLS WG have no power over
> implementation bugs. However we have the power to make sure that the
> specified cryptography is not only "Navigator's strongest link" but is
> strong according to the today's cryptologic science and technology.

I was thinking in a more general fashion, and I'm getting off-topic.

This is more geared towards "where do we as the IETF" should we put
our efforts.

Within the IETF we have been having a problem of insufficient
"cross-pollination" between the security area and the other areas,
because we security geeks are constantly busy improving our own
stuff and making it ever more complex.  We do not spent sufficient
time to help the non-security guys to use the existing standards
and protocols, even those that are already pretty good.

Within Software development (in particular when one is not a
niche-only provider of just a particular middleware component),
there are limits to the available resources, what one can buy
(if it is OEM) or what one can do (if you're implementing it yourself).

I want to slightly caution about feature creep.  There was a discussion
at the IETF plenary about why so few documents/protocol advance on the
standards track, and feature creep is the predominant reason.

For the integrity protection, TLS is about protecting online
and therefore must provide integrity protection against real-time
The encryption algorithms, on the other hand, should be strong enough
to provide confidentiality for many years.  Digital signatures on
archived documents is the area that has to focus on updating their
hash algorithms.

The "smaller" an iteration of the base spec is, the more likely
it will be implemented/adopted widely, and the more likely there
will be interoperability on newer features, because of the
lower cost to implement/adopt it.


TLS mailing list