Subject: [TLS] A little room for AES-192 in TLS?

From: Leonard den Ottolander <[email-masked]>
Date: Mon, 16 Jan 2017 16:23:10 +0100

L.S.,

Seeing how AES-192 seems to hold up well against related key attacks (at
least the (theoretical) one described in
http://eprint.iacr.org/2009/317) I am rather surprised no AES-192
ciphers have been defined for TLS
(http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4). I feel the cipher is being treated rather stepmotherly.

I do understand that the number of slots for ciphers in the above list
is somewhat limited and additions should be considered carefully.

However, seeing that there are over 60 TLS_DH_* ciphers in that list and
well over 60 CAMMELIAs - to be clear, I am not arguing against the
latter algorithm - the argument not to include AES-192 ciphers in that
list seems somewhat arbitrary.

Also there still seems to be plenty of space available (slots 0x01-55,*
and 0x56,0x01-0xC0,0x00) until this "definition by permutation" approach
can be replaced by a cheaper "definition by slot" where the slots are
chained, i.e. using identifiers for key exchanges, asymmetrical ciphers,
symmetrical ciphers and block modes separately.

Even though I have an interest in mathematics and number theory I do not
claim to have anything more than a rudimentary understanding of the
mathematics involved so please correct me where my insights are wrong.

On superficial reading of http://eprint.iacr.org/2009/317 I grasp that
the higher resistance of AES-192 vs. AES-256 is caused by the fact that
"the key schedule of AES-192 has better diffusion".

Bruce Schneier seems to confirm my suspicion:
https://www.schneier.com/blog/archives/2009/07/another_new_aes.html &
https://www.schneier.com/academic/paperfiles/paper-rijndael.pdf

In the blog he states "The attack exploits the fact that the key
schedule for 256-bit version is pretty lousy -- something we pointed out
in our 2000 paper -- but doesn't extend to AES with a 128-bit key."

He even goes so far as to state "And for new applications I suggest that
people don't use AES-256."

What is causing this better diffusion? Is it the fact that the key size
of AES-192 is not, and the block size is a power of 2? I seem to
remember reading somewhere about DES that the odd key size vs the block
size was considered a strength.

Have the same analyses been done for AES-128? How is AES-128 holding up
against these attacks? (Partially answered by Bruce Schneier's remark above.)

Seeing that we live in "a world of 2^50 keys" and the fact that AES-192
seems to be more robust against related key attacks than AES-256 is I
would like to suggest the inclusion of a few AES-192 ciphers in TLS,
lets say all equivalents of AES-256, possibly reduced by the ciphers
that use hashes weaker than SHA256. Not sure if "DH" and "DH_anon" are
different approaches, but those could be excluded as well, resulting in
something like this list:

TLS_RSA_WITH_AES_192_CBC_SHA256
TLS_DHE_DSS_WITH_AES_192_CBC_SHA256
TLS_DHE_RSA_WITH_AES_192_CBC_SHA256
TLS_RSA_WITH_AES_192_GCM_SHA384
TLS_DHE_RSA_WITH_AES_192_GCM_SHA384
TLS_DHE_DSS_WITH_AES_192_GCM_SHA384
TLS_PSK_WITH_AES_192_GCM_SHA384
TLS_DHE_PSK_WITH_AES_192_GCM_SHA384
TLS_RSA_PSK_WITH_AES_192_GCM_SHA384
TLS_PSK_WITH_AES_192_CBC_SHA384
TLS_DHE_PSK_WITH_AES_192_CBC_SHA384
TLS_RSA_PSK_WITH_AES_192_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_192_CBC_SHA384
TLS_ECDH_ECDSA_WITH_AES_192_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_192_CBC_SHA384
TLS_ECDH_RSA_WITH_AES_192_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_192_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_192_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_192_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_192_GCM_SHA384
TLS_ECDHE_PSK_WITH_AES_192_CBC_SHA384
TLS_RSA_WITH_AES_192_CCM
TLS_DHE_RSA_WITH_AES_192_CCM
TLS_RSA_WITH_AES_192_CCM_8
TLS_DHE_RSA_WITH_AES_192_CCM_8
TLS_PSK_WITH_AES_192_CCM
TLS_DHE_PSK_WITH_AES_192_CCM
TLS_PSK_WITH_AES_192_CCM_8
TLS_PSK_DHE_WITH_AES_192_CCM_8
TLS_ECDHE_ECDSA_WITH_AES_192_CCM
TLS_ECDHE_ECDSA_WITH_AES_192_CCM_8

Thank you for considering this request.

Regards,
Leonard den Ottolander.

-- 
mount -t life -o ro /dev/dna /genetic/research

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 16 Jan 2017 15:52:58 +0000

> I do understand that the number of slots for ciphers in the above list is
> somewhat limited and additions should be considered carefully.
> 
> However, seeing that there are over 60 TLS_DH_* ciphers in that list and well
> over 60 CAMMELIAs - to be clear, I am not arguing against the latter algorithm
> - the argument not to include AES-192 ciphers in that list seems somewhat
> arbitrary.

Think of it in the context of history.  RFC 4132 (Camellia) was in 2005 and DH was part of RFC 2246 in 1999.  Some things have evolved since then. For example, we're moving away from DH (both static and ephemeral) in favor of ECDH. And overall, we are moving away from adding ciphers "just because."  The IANA registry is about to change so that each cipher says "required by RFC nnnn" or "no comment" (summarizing).  That is a subtle and important difference. 
 
> Also there still seems to be plenty of space available 

There are other issue to consider.  For example, some popular software stacks and middleboxes have (had?) trouble with larger clientHello messages, which are exacerbated by more ciphers.  And some toolkits, such as OpenSSL my default to offering/accepting "all" ciphers because it is just too hard for the world to make informed decisions about what is both needed and secure.

> mathematics involved so please correct me where my insights are wrong.

It's always good to state what you don't know.  Seriously.  Thanks for doing this -- it doesn't happen often enough.
 
> https://www.schneier.com/blog/archives/2009/07/another_new_aes.html

This paper is eight years old, and focuses on the number of rounds.  Nobody changes the number of rounds of AES; it just doesn't happen.  If you can find followup research that shows the attacks have gotten better, and that AES 192 is not susceptible to those attack, then I think you might see more interest in your proposal.

> to be more robust against related key attacks than AES-256 is I would like to
> suggest the inclusion of a few AES-192 ciphers in TLS, lets say all equivalents
> of AES-256, possibly reduced by the ciphers that use hashes weaker than
> SHA256. Not sure if "DH" and "DH_anon" are different approaches, but those
> could be excluded as well, resulting in something like this list:

Proposing more than two dozen new ciphers is not going to get past the WG.  I'm only an individual, but I've been around here for some time and think that's an accurate view of the likely consensus.  Note that TLS 1.3 defines only three ciphers.

The pendulum is swinging back. We used to define everything in case something broke, but now we try to define as few as possible because of the deployment issues and, well, we ain't gonna need it.

Hope this helps.
--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz