OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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:
> 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

> 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)? 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC