Re: [TLS] Fw: New Version Notification for draft-katagi-tls-clefia-00.txt

[Geoffrey Keating <[e-mail]>]

The draft seems to be heavily based off existing ciphersuite
definitions for other ciphers.  This is good, but it means that it
also propagates many of the deficencies in those RFCs.  Here are the
ones I noticed:

1. It appears a cipher suite is defined for every combination of CLEFIA
with a hash algorithm and key exchange algorithm.  I suggest that many
of these combinations will never be used.

As this is a new cipher, I don't see any reason to define ciphersuites
for backwards compatibility with old versions of TLS or old
implementations.

2. I would suggest removing at least:
- All combinations involving SHA-1
- All combinations involving DSS
- All combinations involving DH keys or ECDH keys
as these are obsolete, are not commonly used even with AES, or both.

3. If TLS is faster with this cipher in GCM, and this cipher is
considered to be secure in GCM, I would suggest only defining GCM
ciphersuites; otherwise, I would suggest not defining any GCM
ciphersuites.  Given that this cipher is targeted at hardware
implementations where the gate count of AES is a limiting factor on
performance, it seems like GCM should be strongly recommended, to
avoid needing to implement SHA256 in fast hardware.

4. I don't see anywhere in the draft where the mac_length and
mac_key_length is defined for these ciphersuites.  This is especially
important for SHA-384 since RFC 5246 does not mention it.

5. Why SHA-384 and not SHA-512, especially when using GCM?

6. The security considerations section should point out that CLEFIA is a
128-bit block cipher and so unsuitable for transmission of very large
amounts of data (on the order of 2^64 bytes), the same as AES.