Subject: RE: [TLS] Suite B compliance of TLS 1.2

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 26 Jul 2006 16:36:37 -0400

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:[email-masked]] 
Sent: Wednesday, July 26, 2006 4:20 PM
To: Blumenthal, Uri
Cc: [email-masked]; [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 26 Jul 2006 19:43:02 -0400

Both from my personal opinion as a cryptographer and from a political
point of view - one may argue about whether all the OTHER ciphersuites
are worth the effort that you so succintly described. Suite B is beyond
contest. Protocols WILL migrate to it, like it or not.

One might add that Suite B beats other defined ciphersuites and is
comparable in strength to the current Russian crypto standard - and I
have deep respect for the later.

I think enough has been said on this subject. Except that yes there are
real benefits - but you need to look deeply at the algorithms to
understand it.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Wednesday, July 26, 2006 6:38 PM
To: Blumenthal, Uri
Subject: Re: [TLS] Suite B compliance of TLS 1.2

Blumenthal, Uri wrote:
> 
> >To me "Suite B compliance of TLS 1.2" sounds like adding several new
> >algorithms to the base spec with at least "RECOMMENDED" status,
> >and not like "we already have all hooks for proprietary extensions,
> >go and write an informational draft if you care".
> 
> In the future it may well be that Suite B ends up being the only
> mandatory-to-implement ciphersuite.
> 
> Regardless, I don't understand your comment.

New crypto algorithms cause a lot of resources to be burnt,
so one should not do it just for the fun of it.

Things that come to mind:
  - export approvals that some governments require
  - import approvals that some governments require
  - usage approvals that customers in some countries require
  - module re-evaluation/re-certification in some cases
  - implementation&test, interoperability tests
  - legal dep. will require another risk assessment because of IP issues
  etc.

So if there is no real benefit we should be wary to put it into
the base standard because of all the resources that implementors
and vendors (incl. OEM vendors) will have to spend on it.
The resources that gets spent here will be missing in other
areas, where improving the security might be magnitudes more
important -- or it will not be adopted by a significant number
of installations.

As a standars body, all IETF working groups should have an interest
in broad adoption of their standards and smooth interoperability.
Complexity and feature-creep (to cater niches) are part of the
problem trying to reach that goal, not part of the solution.

Regards,
-Martin