RE: [TLS] Suite B compliance of TLS 1.2

"Blumenthal, Uri" <uri.blumenthal@intel.com> Wed, 26 July 2006 17:09 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5msa-0002UA-JW; Wed, 26 Jul 2006 13:09:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5msZ-0002Ts-Ja for tls@ietf.org; Wed, 26 Jul 2006 13:09:03 -0400
Received: from mga02.intel.com ([134.134.136.20] helo=orsmga101-1.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5msW-0003D8-Qi for tls@ietf.org; Wed, 26 Jul 2006 13:09:03 -0400
Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101-1.jf.intel.com with ESMTP; 26 Jul 2006 10:08:35 -0700
Received: from fmsmsx332.fm.intel.com (HELO fmsmsx332.amr.corp.intel.com) ([132.233.42.148]) by fmsmga001.fm.intel.com with ESMTP; 26 Jul 2006 10:08:19 -0700
X-IronPort-AV: i="4.07,185,1151910000"; d="scan'208"; a="105048941:sNHT2503702866"
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 10:08:18 -0700
Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 10:08:18 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Suite B compliance of TLS 1.2
Date: Wed, 26 Jul 2006 13:08:14 -0400
Message-ID: <279DDDAFA85EC74C9300A0598E7040565DC103@hdsmsx412.amr.corp.intel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Suite B compliance of TLS 1.2
Thread-Index: Acaw0cKLGih/+QRlQ/K95A/txnyXTwAAyiCQ
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: <martin.rex@sap.com>
X-OriginalArrivalTime: 26 Jul 2006 17:08:18.0451 (UTC) FILETIME=[17263E30:01C6B0D6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

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