RE: [TLS] Suite B compliance of TLS 1.2

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

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5t4Q-00069G-4a; Wed, 26 Jul 2006 19:45:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5t4O-00069B-Ki for tls@ietf.org; Wed, 26 Jul 2006 19:45:40 -0400
Received: from mga01.intel.com ([192.55.52.88] helo=fmsmga101-1.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5t4N-00073O-4f for tls@ietf.org; Wed, 26 Jul 2006 19:45:40 -0400
Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 26 Jul 2006 16:43:27 -0700
Received: from fmsmsx333.fm.intel.com (HELO fmsmsx333.amr.corp.intel.com) ([132.233.42.2]) by fmsmga001.fm.intel.com with ESMTP; 26 Jul 2006 16:43:26 -0700
X-IronPort-AV: i="4.07,185,1151910000"; d="scan'208"; a="105398125:sNHT20020042"
Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 16:43:26 -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 16:43:05 -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 19:43:02 -0400
Message-ID: <279DDDAFA85EC74C9300A0598E7040565DC3F6@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: AcaxBlaseKnswC6JTpWmPh5Zh0bTZgAAE0dg
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: tls@ietf.org
X-OriginalArrivalTime: 26 Jul 2006 23:43:05.0432 (UTC) FILETIME=[3DB0B580:01C6B10D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc:
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

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:martin.rex@sap.com] 
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

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