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

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 26 Jul 2006 13:08:14 -0400

>> I think the preferred direction is to hash with the new negotiated
hash.
>> What would be the purpose of hashing with the old one?
>
>Aren't the client hello and server hello included in the hash?
>So the client doesn't know which one has been negotiated until
>after interpreting the ServerHello message (unless the client
>is determined from the beginning to not interoperate with older
servers).

So? The authentication decision (with all the computations) is made in
the end of the exchange anyway. It might be more convenient to be able
to hash messages as they come and forget them - but it may have to wait
until it is clear what hash to use. Isn't security worth a bit of
inconvenience? :-)

>> But I'm confused wrt. what Martin calls "strongest link". Clearly
it's
>> not RSA or SHA-1 (and hopefully not MD5 :-)?
>
>Except for the weakness in the random number generator of the
>Netscape Navigator browser over 10 years back I haven't heard about
>attacks against SSL sessions (ignoring the export ciphersuites here).
>Most weaknesses were implementation flaws (XSS, use of frames
>giving false impressions, incorrect certificate path validation),
>but there were also design issues involved (the magic how an
>awfully large number of questionable trust anchors are
>created/initialized, CAs inappropriately issuing certificates,
>IDNs and how they interact with HTTPS endpoint identification) 

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 do agree that MD5 should no longer be used for integrity
>protection because of the known weaknesses.  But when used
>together with SHA-1 in the SSL/TLS handshake fashion, it is
>NOT utterly useless.

It is useless enough to be done with it and not spend any more cycles of
the participants on discussing it. 

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Wed, 26 Jul 2006 22:20:05 +0200 (MET DST)

> 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