RE: [TLS] Suite B compliance of TLS 1.2

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
deployed.

-----Original Message-----
From: Martin Rex [mailto:martin.rex@sap.com] 
Sent: Wednesday, July 26, 2006 4:20 PM
To: Blumenthal, Uri
Cc: martin.rex@sap.com; tls@ietf.org
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
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.

-Martin

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls