Re: [TLS] Issue 56: AES as MTI
Chris Newman <Chris.Newman@Sun.COM> Sat, 15 September 2007 00:31 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 1IWLZF-00040C-G8; Fri, 14 Sep 2007 20:31:25 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWLZE-0003we-7b for tls@ietf.org; Fri, 14 Sep 2007 20:31:24 -0400
Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWLZD-0004Kf-5i for tls@ietf.org; Fri, 14 Sep 2007 20:31:24 -0400
Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8F0VMbw009872 for <tls@ietf.org>; Sat, 15 Sep 2007 00:31:22 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JOD00201W335U00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for tls@ietf.org; Fri, 14 Sep 2007 18:31:22 -0600 (MDT)
Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JOD00BDXW455BD0@mail-amer.sun.com>; Fri, 14 Sep 2007 18:31:20 -0600 (MDT)
Date: Fri, 14 Sep 2007 17:32:26 -0700
From: Chris Newman <Chris.Newman@Sun.COM>
Subject: Re: [TLS] Issue 56: AES as MTI
In-reply-to: <46EAF8E2.8090202@bolyard.com>
To: Nelson B Bolyard <nelson@bolyard.com>, tls@ietf.org
Message-id: <BD3C2076F4105E05B728EA42@[10.1.110.5]>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.6 (Mac OS X)
Content-type: text/plain; format="flowed"; charset="us-ascii"
Content-transfer-encoding: 7bit
Content-disposition: inline
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: "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
Nelson B Bolyard wrote on 9/14/07 14:10 -0700: > 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. This was a mistake the IETF made in TLS 1.0 due to patent issues. The RSA patent had not expired when TLS 1.0 was published so there was a desire for an interoperable patent-free mechanism. The fact the marketplace cared a lot more about performance than patents/licensing is telling and should inform future IETF behavior when such situations arise. Regardless I would like to see that mistake corrected honestly in the specification. >> 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. If that's the case, I would like the document to say something to that effect. Being silent about the dominance of RC4 makes the specification negligent about real world interoperability. > 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. I think the base TLS spec needs one or more mandatory to implement cipher suites that will be present in generic TLS stacks and will interoperate in emerging/experimental marketplaces that don't have a specific profile. Frankly, I don't trust spec writers to remember to always set a MITM appropriate for the protocol that uses TLS so I want to see an interoperable fallback in the base specifications. However, I have no problem with marketplace-specific profiles replacing the mandatory-to-implement requirements with different ones and to the extent this better reflects reality, I'd like to see more of it in the IETF. For example, RFC 3501 section 11.1 adjusts the MITM requirements for TLS when used with IMAP. Our rules would seem to permit that. - Chris _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] Issue 56: AES as MTI Eric Rescorla
- Re: [TLS] Issue 56: AES as MTI Eric Rescorla
- RE: [TLS] Issue 56: AES as MTI Joseph Salowey (jsalowey)
- Re: [TLS] Issue 56: AES as MTI Mike
- [TLS] Re: Issue 56: AES as MTI Simon Josefsson
- Re: [TLS] Issue 56: AES as MTI Russ Housley
- Re: [TLS] Issue 56: AES as MTI Chris Newman
- Re: [TLS] Issue 56: AES as MTI Nelson B Bolyard
- Re: [TLS] Issue 56: AES as MTI Mike
- Re: [TLS] Issue 56: AES as MTI Eric Rescorla
- Re: [TLS] Issue 56: AES as MTI Russ Housley
- Re: [TLS] Issue 56: AES as MTI Chris Newman
- Re: [TLS] Issue 56: AES as MTI Nelson B Bolyard
- Re: [TLS] Issue 56: AES as MTI Nicolas Williams