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

Geoffrey Keating <> Tue, 05 July 2011 18:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EC5E21F88F4 for <>; Tue, 5 Jul 2011 11:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gJ58z9t1giju for <>; Tue, 5 Jul 2011 11:42:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2498921F8832 for <>; Tue, 5 Jul 2011 11:41:58 -0700 (PDT)
Received: by (Postfix, from userid 501) id 9569633D17C; Tue, 5 Jul 2011 18:41:50 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Masanobu Katagi <>
References: <>
From: Geoffrey Keating <>
Date: 05 Jul 2011 11:41:50 -0700
In-Reply-To: <>
Message-ID: <m2wrfwefip.fsf@localhost.localdomain>
Lines: 36
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [TLS] Fw: 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: Tue, 05 Jul 2011 18:42:03 -0000

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

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.