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

Masanobu Katagi <> Thu, 07 July 2011 10:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01CE121F868D for <>; Thu, 7 Jul 2011 03:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.173
X-Spam-Status: No, score=0.173 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W0eb9saTBGnF for <>; Thu, 7 Jul 2011 03:31:06 -0700 (PDT)
Received: from ( [IPv6:2001:cf8:0:56::198]) by (Postfix) with ESMTP id EF50C21F867C for <>; Thu, 7 Jul 2011 03:31:04 -0700 (PDT)
Received: from ( [IPv6:2001:cf8:0:191::12]) by (R8/Sony) with ESMTP id p67AV1XL013461 for <>; Thu, 7 Jul 2011 19:31:01 +0900 (JST)
Received: from (localhost []) by (R8/Sony) with ESMTP id p67AV1qp019357 for <>; Thu, 7 Jul 2011 19:31:01 +0900 (JST)
Received: from ([]) by (R8/Sony) with ESMTP id p67AV1UI019332 for <>; Thu, 7 Jul 2011 19:31:01 +0900 (JST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 19:30:59 +0900
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 19:30:59 +0900
Date: Thu, 07 Jul 2011 19:32:28 +0900
From: Masanobu Katagi <>
To: Geoffrey Keating <>, "" <>
In-Reply-To: <m2wrfwefip.fsf@localhost.localdomain>
References: <> <m2wrfwefip.fsf@localhost.localdomain>
Message-Id: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.51.07 [ja] (Unregistered)
X-OriginalArrivalTime: 07 Jul 2011 10:30:59.0197 (UTC) FILETIME=[F64B02D0:01CC3C90]
Cc: "Moriai, Shiho" <>
Subject: Re: [TLS] New Version Notification for draft-katagi-tls-clefia-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jul 2011 10:31:07 -0000

Hi Geoffrey and all,

Thank you for your comments on our draft.

1. ciphersuites with SHA-1

According to the following information,
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.

Masanobu Katagi

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