Re: [TLS] Issue 56: AES as MTI

Nelson B Bolyard <nelson@bolyard.com> Sat, 15 September 2007 01:33 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 1IWMX4-0007Kc-Ci; Fri, 14 Sep 2007 21:33:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWMX3-0007Fz-0n for tls@ietf.org; Fri, 14 Sep 2007 21:33:13 -0400
Received: from smtpout1471.sc1.he.tucows.com ([64.97.157.171] helo=n007.sc1.he.tucows.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWMX1-0003EI-NN for tls@ietf.org; Fri, 14 Sep 2007 21:33:13 -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 465670BB01468F2C; Sat, 15 Sep 2007 01:33:09 +0000
Message-ID: <46EB364D.70306@bolyard.com>
Date: Fri, 14 Sep 2007 18:33:01 -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: Russ Housley <housley@vigilsec.com>
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]> <46EAF8E2.8090202@bolyard.com> <20070914214358.27C8633C21@delta.rtfm.com> <46EAB54E00062316@n024.sc1.he.tucows.com> (added by postmaster@bouncemessage.net)
In-Reply-To: <46EAB54E00062316@n024.sc1.he.tucows.com> (added by postmaster@bouncemessage.net)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
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

Russ Housley wrote:
> This has always been the case.  It ensures that there is a ciphersuite
> that can be negotiated between all implementations (unless it is
> explicitly turned off by policy controls).

And this is important why?

It is important that all implementations that must work in (say) US DOD
government installations (where AES is mandated exclusively) must all
use AES so that they can interoperate.  That market requires that they
interoperate.

It is important that in the field of eCommerce, where everyone uses RC4,
that implementations use RC4 so that they can interoperate for eCommerce.

An implementation that does RC4 and not AES will work fine in eCommerce
and not in the DOD.  An implementation that does AES only and not RC4
will not work with quite a few eCommerce servers out there.  So what?

Why do we need to impose interoperability requirements that the markets
themselves do not demand?

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