[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [security-services] TLS & SSL ciphersuite language
Hal Lockhart wrote: > > I think we should look to the future instead of the past. I suggest AES as > the mandatory to implement symmetric algorithm. Specifically: > > TLS_RSA_WITH_AES_128_CBC_SHA > > This is described here: > > http://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-05.txt Thanks, this is a very good point. In fact this I-D entered IETF-wide Last Call Thu, 11 Oct 2001. This is good, becase hopefully the I-D will become a standards-track RFC before we need to finalize our docs -- and we can reference it. > I believe that the IETF Security Working Group has stated the intent to move > to AES as quickly as possible. > > Considering that performance is the most commonly cited reason for NOT USING > ENCRYPTION AT ALL, why not move to an algorithm that is six times as fast as > 3DES? However, there's a non-trivial installed-base issue. The way I suggest handling it is to specify.. TLS_RSA_WITH_3DES_EDE_CBC_SHA (when using TLS) SSL_RSA_WITH_3DES_EDE_CBC_SHA (when using SSL) ..as MUSTs (and therefore mandatory-to-implement) with the present installed base in mind. And then explicitly call out TLS_RSA_WITH_AES_128_CBC_SHA as a SHOULD, with the rationale somehow folded in. Are you suggesting we specify AES_128_CBC rather than AES_256_CBC based on performance or other considerations (e.g. generating longer keys is sometimes problematic randomness-wise)? thanks, JeffH
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC