Re: [TLS] Suite B compliance of TLS 1.2

Blumenthal, Uri wrote:
> 
> >> Hashing the handshakes messages with both, old and new hash
> >> algorithms and deciding later in the handshake which results
> >> go into creation/verification of the finished message when
> >> it has been determined/negotiated which algorithms to use
> >> should be doable, and just moderately more expensive.
> 
> 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).

> 
> >> I'm slightly worried about the potential "market pressure"
> >> which this might cause.  I certainly don't mind adoption/offering
> >> of strong cryptographic protocols/technologies, but right
> >> now I do NOT consider TLS fundamentally broken or weak,
> >> and I would prefer if people focus on the acutal weaknesses
> >> within the technology, rather than replacing the
> >> (currently) strongest link in a weak chain with a much
> >> stronger one.
> >
> >I'm sensitive to what you're saying and I have the same doubts.
> >On the other hand, I also worry about the attacks on MD5 and SHA-1
> >getting much worse and then having to explain why we didn't
> >do anything about it
> 
> Exactly. 
> 
> 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).

However there have been and still are attacks against users that
were under the impression that their browser would protect them
through the use of SSL.

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

-Martin

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