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

From: Masanobu Katagi <[email-masked]>
Date: Tue, 05 Jul 2011 09:33:42 +0900

Dear all,

We have submitted the Internet draft that defines cipher suites to support CLEFIA in TLS.
http://tools.ietf.org/id/draft-katagi-tls-clefia-00.txt

CLEFIA is a 128-bit block cipher presented at FSE2007 and it is now used in commercial products.
The algorithm of CLEFIA was published as RFC6114 in March 2011. 
CLEFIA is a lightweight block cipher compared with AES, Camellia, and SEED. 
We believe that CLEFIA will contribute to the Internet of Things as a lightweight cipher algorithm.

The security and performance of CLEFIA have been evaluated through the CRYPTREC project 
which evaluates and monitors the security of Japan e-Government recommended ciphers. 
It also has been submitted to the ISO/IEC standard (ISO/IEC 29192, Lightweight cryptography) and it's
in the Final Draft International Standard.

Any comments on this draft would be appreciated.

Best regards,
Masanobu Katagi
Sony Corporation

Forwarded by Masanobu Katagi <[email-masked]>
----------------------- Original Message -----------------------
 From:    "[email-masked]" <[email-masked]>
 To:      "Katagi, Masanobu" <[email-masked]>
 Cc:      "Katagi, Masanobu" <[email-masked]>,
          "Moriai, Shiho" <[email-masked]>
 Date:    Mon, 4 Jul 2011 17:51:44 +0900
 Subject: New Version Notification for draft-katagi-tls-clefia-00.txt
----

A new version of I-D, draft-katagi-tls-clefia-00.txt has been successfully submitted by Masanobu Katagi and posted to the IETF repository.

Filename:	 draft-katagi-tls-clefia
Revision:	 00
Title:		 CLEFIA Cipher Suites for Transport Layer Security (TLS)
Creation date:	 2011-07-04
WG ID:		 Individual Submission
Number of pages: 16

Abstract:
   This document specifies a set of cipher suites for the Transport
   Security Layer (TLS) protocol to support the CLEFIA encryption
   algorithm as a block cipher.  CLEFIA is a lightweight block cipher
   and suitable for constrained devices.

The IETF Secretariat

--------------------- Original Message Ends --------------------

---

From: Satoru Kanno <[email-masked]>
Date: Tue, 05 Jul 2011 12:00:46 +0900

Hi Masanobu,

I have two comments for your draft.

[For IPR statement]
I can't find an IPR statement on CLEFIA for TLS when searching for that 
draft on the IPR Disclosure search page:

https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-katagi-tls-clefia

In the case of Camellia, we submitted the IPR statement for TLS as a 
following:

https://datatracker.ietf.org/ipr/41/

Since CLEFIA is patented by SONY, I believe you need to submit an IPR　 
disclosure for this document.

[For ciphersuites with SHA-1]
Are you really suggesting that CLEFIA be used with SHA-1?
NIST is saying not to use SHA-1 very soon. I believe these suites should 
be removed because RFC 6209 and new I-D on Camellia are not defined on 
these suites recently.
Of course, I checked security considerations for ciphersuites with SHA-1 
in your draft.

What do you and TLS folks think of these ciphersuites?

Regards,
Satoru

(2011/07/05 9:33), Masanobu Katagi wrote:
> Forwarded by Masanobu Katagi<[email-masked]>
>   From:    "[email-masked]"<[email-masked]>
>   To:      "Katagi, Masanobu"<[email-masked]>
>   Cc:      "Katagi, Masanobu"<[email-masked]>,
>            "Moriai, Shiho"<[email-masked]>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Satoru Kanno

Security Business Unit
Mobile and Security Solution Business Group
NTT Software Corporation

e-mail: [email-masked]

---

From: Masanobu Katagi <[email-masked]>
Date: Tue, 05 Jul 2011 14:20:43 +0900

Hi Satoru,

Thank you for your comments on our draft!

We submitted our IPR disclosure related to the document,
but it seems to take some time before it becomes available 
on the web. 

As you mentioned, our considerations on SHA-1 are written 
in Section 4 (Security Considerations) in the document.
We are happy to hear comments from TLS WG experts.

Best regards,
Masanobu Katagi

On Tue, 5 Jul 2011 12:00:46 +0900

---

From: Andre Silaghi <[email-masked]>
Date: Tue, 05 Jul 2011 08:19:32 +0200

Hi there,

[For ciphersuites with SHA-1]
I also would suggest to think again about using SHA-1. There has been
one theoretical attack on it in 2008:

http://eprint.iacr.org/2008/469.pdf

What about SHA-2 (256/512)?

Regards,
Andre

Am 05.07.2011 05:00, schrieb Satoru Kanno:
> I can't find an IPR statement on CLEFIA for TLS when searching for
> that draft on the IPR Disclosure search page:
>
> NIST is saying not to use SHA-1 very soon. I believe these suites
> should be removed because RFC 6209 and new I-D on Camellia are not
> defined on these suites recently.
> Of course, I checked security considerations for ciphersuites with
> SHA-1 in your draft.
>
>> A new version of I-D, draft-katagi-tls-clefia-00.txt has been
>> successfully submitted by Masanobu Katagi and posted to the IETF
>> repository.
>>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 5 Jul 2011 10:46:23 +0300

> We believe that CLEFIA will contribute to the Internet of Things as a lightweight cipher algorithm.

Hello,
 What is the use-case of this cipher in TLS? In particular what is the
point of having a lightweight
cipher combined with non-lightweight primitives such as RSA and Diffie
Hellman key exchange,
and SHA MACs?

regards,
Nikos

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 06 Jul 2011 00:25:50 +1200

Nikos Mavrogiannopoulos <[email-masked]> writes:

>What is the use-case of this cipher in TLS? In particular what is the point
>of having a lightweight cipher combined with non-lightweight primitives such
>as RSA and Diffie Hellman key exchange, and SHA MACs?

The use case is "It's a Sony!".

Peter.

---

From: Andre Silaghi <[email-masked]>
Date: Tue, 05 Jul 2011 16:20:43 +0200

Hi there,

I would suggest to think about another hashing algorithm because there
is at least one theoretical attack on SHA-1.

What about SHA-2 (256 or eve 512)?

Regards,
Andre

---

From: Geoffrey Keating <[email-masked]>
Date: 05 Jul 2011 11:41:50 -0700

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.

---

From: Masanobu Katagi <[email-masked]>
Date: Wed, 06 Jul 2011 18:48:01 +0900

Hi Nikos,

Our point is that lightweight ciphers contribute to efficient implementations 
and lower energy consumption in total
because, even if combined with non-lightweight primitives such as RSA and DH,
they are effective for encryption and MAC in TLS communication.

Best regards,
Masanobu Katagi

On Tue, 5 Jul 2011 16:46:23 +0900

---

From: Masanobu Katagi <[email-masked]>
Date: Thu, 07 Jul 2011 19:32:28 +0900

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

---

From: Masanobu Katagi <[email-masked]>
Date: Wed, 20 Jul 2011 19:38:45 +0900

Hi all,

Thank you for valuable comments on our proposal of CLEFIA ciphersuites:
http://tools.ietf.org/id/draft-katagi-tls-clefia-00.txt.

In our draft above, we proposed a lot of combinations with SHA-1.
In response to the comments from the TLS working group, 
we would like to remove the following sets of SHA-1 based ciphersuites:
- All combinations involving CLEFIA_256 (from viewpoint of equivalent security to SHA-1)
- Combinations involving not commonly used public key primitives

Our updated proposal of SHA-1 based ciphersuites is as follows.

     CipherSuite TLS_RSA_WITH_CLEFIA_128_CBC_SHA            = {TBD,TBD};
     CipherSuite TLS_DHE_DSS_WITH_CLEFIA_128_CBC_SHA        = {TBD,TBD};
     CipherSuite TLS_DHE_RSA_WITH_CLEFIA_128_CBC_SHA        = {TBD,TBD};
     CipherSuite TLS_DH_anon_WITH_CLEFIA_128_CBC_SHA        = {TBD,TBD};
     CipherSuite TLS_ECDHE_ECDSA_WITH_CLEFIA_128_CBC_SHA    = {TBD,TBD};
     CipherSuite TLS_ECDHE_RSA_WITH_CLEFIA_128_CBC_SHA      = {TBD,TBD};
     CipherSuite TLS_PSK_WITH_CLEFIA_128_CBC_SHA            = {TBD,TBD};
     CipherSuite TLS_DHE_PSK_WITH_CLEFIA_128_CBC_SHA        = {TBD,TBD};

We are going to update this change in the next version of our draft.

Best regards,
Masanobu Katagi
Sony Corporation

On Tue, 5 Jul 2011 09:33:42 +0900