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

[Masanobu Katagi <[e-mail]>]

Hi Geoffrey and all,

Thank you for your comments on our draft.

1. ciphersuites with SHA-1

According to the following information,
http://www9.atwiki.jp/kurushima/pub/pkimisc/SSLTLS_CipherSuite_Support_Table_.html
the SHA-2 family has not been supported by major SSL Servers and Web Browsers.
Our concern is that if we define new ciphersuites without SHA-1,
these ciphersuites cannot be used now.

Does somebody know when the SHA-2 family will be supported by Apache, IE, and Firefox?

2. GCM

The efficiency of hardware implementation is one of the advantages of CLEFIA.
There is no security concern known in using CLEFIA in GCM.
We'd like to define the ciphersuites with GCM.

3. mac_length for SHA-384, choice of SHA-384/512

Are these new topics to be discussed in TLS ML?
Both suggestions seem to be applicable to other block ciphers:
AES(RFC 5288, 5289), Camellia(draft-kanno-tls-camellia-03), and ARIA(RFC 6209).
These ciphersuites also use SHA-384, not SHA-512.

Please let me know whether there have been similar discussions before.
We'd like to follow the TLS WG's consensus.

4. transmission of very large amounts of data

This issue belongs to a limitation of using a 128-bit block cipher under 
a single key. For n-bit block ciphers, encryption more than 2^(n/2) blocks 
by a single key should be banned in most modes of operations.

Regards,
Masanobu Katagi

On Wed, 6 Jul 2011 03:41:50 +0900
Geoffrey Keating <[e-mail]> wrote:
> 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.