Re: [TLS] Suite B compliance of TLS 1.2

Martin Rex <> Wed, 26 July 2006 20:22 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1G5ptP-0003lQ-6U; Wed, 26 Jul 2006 16:22:07 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1G5ptN-0003k4-TZ for; Wed, 26 Jul 2006 16:22:05 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1G5ptM-0005ga-GJ for; Wed, 26 Jul 2006 16:22:05 -0400
Received: from (smtpde03) by (out) with ESMTP id WAA25080; Wed, 26 Jul 2006 22:20:05 +0200 (MESZ)
From: Martin Rex <>
Message-Id: <>
Subject: Re: [TLS] Suite B compliance of TLS 1.2
To: (Blumenthal Uri)
Date: Wed, 26 Jul 2006 22:20:05 +0200 (MET DST)
In-Reply-To: <> from "Blumenthal, Uri" at Jul 26, 6 01:08:14 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
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: <>, <>

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 in
> addressing the weaknesses, not improving what's already "strong"? Then I
> 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 communication
and therefore must provide integrity protection against real-time attacks.
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