<Pasi.Eronen@xxxxxxxxx> writes:
Simon Josefsson wrote:
Generally speaking, I believe the crypto community will produce
several AEAD cipher modes with rather different properties (speed,
IV-use, provable security, patent status, and so on).
Having all those ciphers defined for TLS is an advantage, to allow
interoperable testing. What is less clear at this point is which of
the alternatives to prefer.
Many of the arguments made in the recent discussion about IDEA
(e.g., more code means more complexity and less security in
practise, especially if some of that code is rarely used and thus
largely untested; and having too many "vanity" options just causes
problems) would suggest that having *all* those ciphers defined in
TLS would not be a such good idea.
I think there is a significant difference between the IDEA situation
and
the AEAD situation: the IDEA ciphersuites are mentioned in the core
TLS
specification. We should (rightly) be more conservative about any
complexity complications in the core document.
As far as I have understood, no single AEAD ciphersuite will be
recommended or specified in the TLS 1.2 specification.
If so, having multiple informational documents on different AEAD
ciphersuites leads to simpler real-world-like comparisons between
them.
When we have had some time to evaluate these, and have let the crypto
community scrutinize the various different AEAD modes for some time,
we
can chose a small set of them (possibly a single one) to promote to
standards track status.
However, I don't feel strongly about this, and this is just my gut
reaction on how I would prefer to do it. There may be some compelling
arguments for doing it in some other way that I haven't considered.