Re: [security-services] TLS & SSL ciphersuite language

[Jeff Hodges <jhodges@oblix.com>]

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