RE: [TLS] Suite B compliance of TLS 1.2

>> 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
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls