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

[Taylor R Campbell <[e-mail]>]

   Date: Sat, 14 Jan 2017 20:08:01 +0100
   From: Leonard den Ottolander <[e-mail]>

   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 would be surprised if TLS relied in any way on resistance to
related-key attacks.  The only advantage for TLS's sake would be in
situations requiring greater performance than AES-256 can attain,
where a security level below 2^96 against future quantum cryptanalysis
or multi-target attacks are acceptable.

That said, proposals for TLS are probably better heard at the IETF
working group for TLS.

   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.

It turns out that handing inexpert users a dizzying array of
cryptographic acronym soups and seasonings to combine securely does
not tend to yield very good results.  The enormous enumeration of
precombined cipher suites is bad enough; asking users to make sensible
choices to combine their parts is worse.