> 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. > 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. It's always good to state what you don't know. Seriously. Thanks for doing this -- it doesn't happen often enough. > Bruce Schneier seems to confirm my suspicion: > 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: richs...@jabber.at Twitter: RichSalz _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
