Subject: [ietf-tls] Re: Other AES key lengths

From: Pete Chown <[email-masked]>
Date: Wed, 6 Dec 2000 12:04:10 +0000

Hironobu SUZUKI wrote:

> I don't familiar with this TLS ML discussion. Anyway, I'd like to make
> a list of ciphersuites for AES 128/192/256 as below.
> 
> TLS_RSA_WITH_AES_128_CBC_SHA          = { 0x00,0x2F }
> TLS_DH_DSS_WITH_AES_128_CBC_SHA       = { 0x00,0x30 }
> TLS_DH_RSA_WITH_AES_128_CBC_SHA       = { 0x00,0x31 }
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA      = { 0x00,0x32 }
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA      = { 0x00,0x33 }
> TLS_DH_anon_WITH_AES_128_CBC_SHA      = { 0x00,0x34 }
> 
> TLS_RSA_WITH_AES_192_CBC_SHA          = { 0x00,0x35 }
> TLS_DH_DSS_WITH_AES_192_CBC_SHA       = { 0x00,0x36 }
> TLS_DH_RSA_WITH_AES_192_CBC_SHA       = { 0x00,0x37 }
> TLS_DHE_DSS_WITH_AES_192_CBC_SHA      = { 0x00,0x38 }
> TLS_DHE_RSA_WITH_AES_192_CBC_SHA      = { 0x00,0x39 }
> TLS_DH_anon_WITH_AES_192_CBC_SHA      = { 0x00,0x3A }
> 
> TLS_RSA_WITH_AES_256_CBC_SHA          = { 0x00,0x3B }
> TLS_DH_DSS_WITH_AES_256_CBC_SHA       = { 0x00,0x3C }
> TLS_DH_RSA_WITH_AES_256_CBC_SHA       = { 0x00,0x3D }
> TLS_DHE_DSS_WITH_AES_256_CBC_SHA      = { 0x00,0x3E }
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA      = { 0x00,0x3F }
> TLS_DH_anon_WITH_AES_256_CBC_SHA      = { 0x00,0x40 }

Thanks; I will probably do exactly this if the consensus is to add 192
and 256 bit ciphersuites.

Eric Rescorla wrote:

> I really don't think [192 bit] is necessary. Let's for the moment
> say that the arguments for why we need 256 are convincing. (I don't
> think so, but never mind that). I don't see why this means we need
> all three lengths.

I see what you are saying.  The only advantage of 192 bit is better
performance than 256 bit while better security than 128 bit.  Also I
suppose it would be cleaner to support 192 bit because then it would
support all the AES options (as opposed to all the Rijndael options,
of which there are many more).

Also as Nelson Bolyard pointed out, it is important that we can
support all the requirements of the AES FIPS.

I'd be happy with either solution on this one (I'm just worried that
it will become a bone of contention which wastes a lot of time).

> Sure, it's possible that 192 is more secure than 128 or 256, but
> if we believe that it suggests that AES is seriously broken and 
> we need a different backup entirely.

Quite so.

Ben Laurie wrote:

> Its been raised already, but I don't remember seeing a resolution ...
> what about block length?

This will be fixed in the next draft.

Andreas Sterbenz wrote:

> Regarding block sizes, NIST has not asked and nobody ever really looked at
> block sizes other than 128 bit.

Yes, I don't think we should be supporting *block sizes* other than
128 bit.  There are arguments for supporting longer keys though, even
if I think that on balance it is a bad idea.  I think we should stick
to supporting AES features rather than the extra "bonus" Rijndael
features that NIST didn't ask for.

There are actually (minor) advantages to supporting different modes of
operation as well, but we will never agree on anything if we go down
that road!

-- 
Pete

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]