Re: [TLS] Issue 56: AES as MTI

Nelson B Bolyard <nelson@bolyard.com> Fri, 14 September 2007 21:11 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWIRM-0001ny-Sy; Fri, 14 Sep 2007 17:11:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWIRL-0001nj-RU for tls@ietf.org; Fri, 14 Sep 2007 17:11:03 -0400
Received: from smtpout1430.sc1.he.tucows.com ([64.97.157.130] helo=n007.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWIRK-0002g1-I2 for tls@ietf.org; Fri, 14 Sep 2007 17:11:03 -0400
Received: from [192.168.0.5] (24.6.51.98) by n007.sc1.he.tucows.com (7.2.069.1) (authenticated as nelson@bolyard.com) id 465670BB0145F92F; Fri, 14 Sep 2007 21:11:01 +0000
Message-ID: <46EAF8E2.8090202@bolyard.com>
Date: Fri, 14 Sep 2007 14:10:58 -0700
From: Nelson B Bolyard <nelson@bolyard.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070527 SeaMonkey/1.5a
MIME-Version: 1.0
To: tls@ietf.org
Subject: Re: [TLS] Issue 56: AES as MTI
References: <20070912231150.ED1D533C21@delta.rtfm.com> <65C7072814858342AD0524674BCA2CDB0D2E6E3E@rsana-ex-hq2.NA.RSA.NET> <20070912232636.2B5FE33C21@delta.rtfm.com> <5E75C29FF611C298B79DC0E1@[10.1.110.5]>
In-Reply-To: <5E75C29FF611C298B79DC0E1@[10.1.110.5]>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.0 (-)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: Chris Newman <Chris.Newman@Sun.COM>, "Yee, Peter" <pyee@rsasecurity.com>
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

Chris Newman wrote:
> As far as I can tell, the real-world MTI for SSL/TLS as deployed is
> RC4.  I dislike it when the real world MTI and the specified MTI differ
> and the specification fails to explain the difference.

I think the RFC does not need a Mandatory Cipher Suite.  There are
different marketplaces for TLS, and each one will define its own mandatory
cipher suite.  I see no need to say that all implementations must do one.
Each implementation is intended to operate in one or more marketplaces,
and market forces will ensure that all implementations in each market will
implement the cipher suite that is the de facto standard mandatory one.

TLS 1.0 defined TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and the eCommerce
marketplace utterly ignored that.  Several implementations STILL do not
implement that cipher suite to this day, yet that has not resulted in a
lack of interoperability.  Interoperability for eCommerce has employed
the RSA+RC4 cipher suites, as Chris noted.

> It's my belief that AES-CBC is more likely to result in future alignment
> of the real-world MTI and the specified MTI than 3DES and thus I support
> a change from 3DES to AES as MTI.   I would also support a change from
> 3DES to RC4 as MTI despite some concerns about the cryptographic
> longevity of that cipher.

Going forward, it's clear that in some markets, AES will be mandated to
the exclusion of all else, but in others RC4 will still dominate.

I suggest that the RFC should call for the development of profiles of TLS,
selected subsets of cipher suites, hello extensions, and perhaps EC curves
that will form the basis for interoperability for implementations within
the marketplace of each profile.

/Nelson

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