Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-camellia-00.txt

From: [email-masked]
Date: Wed, 04 Oct 2000 06:55:53 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the IETF.

	Title		: Addition of the Camellia Encryption Algorithm to TLS
	Author(s)	: S. Moriai
	Filename	: draft-ietf-tls-camellia-00.txt
	Pages		: 4
	Date		: 03-Oct-00
	
This document proposes the addition of new cipher suites to the TLS
protocol 1.0 to support the Camellia encryption algorithm as a bulk
cipher algorithm.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-camellia-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-tls-camellia-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-tls-camellia-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: David Hopwood <[email-masked]>
Date: Wed, 04 Oct 2000 19:27:04 +0100

-----BEGIN PGP SIGNED MESSAGE-----

> http://www.ietf.org/internet-drafts/draft-ietf-tls-camellia-00.txt

Camellia is patented; from draft-nakajima-camellia-00.txt:

  Mitsubishi Electric Corporation (Mitsubishi Electric) and Nippon
  Telegraph and Telephone Corporation (NTT) have filed patent
  applications on the techniques used in Camellia. For more
  information, please contact at [email-masked] and/or
  [email-masked].

Similar arguments against adding it apply as for MISTY1.

Also,

    This document is an Internet-Draft and is NOT offered in accordance
    with Section 10 of RFC2026, and the author does not provide the IETF
    with any rights other than to publish as an Internet-Draft.

I don't know why the draft was even allowed to be published with this
condition. It's completely unacceptable.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

---

From: Eric Rescorla <[email-masked]>
Date: 04 Oct 2000 14:09:16 -0700

> condition. It's completely unacceptable.
Actually, it's not. It's quite legal. In fact this text comes right 
out of http://www.ietf.org/ietf/1id-guidelines.txt
That doesn't mean it's not objectionable, of course.

-Ekr

---

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 4 Oct 2000 14:08:00 -0700

>condition. It's completely unacceptable.

I fully agree. Drafts like this should not be a WG product.

--Paul Hoffman, Director
--Internet Mail Consortium

---

---

From: Eric Rescorla <[email-masked]>
Date: 04 Oct 2000 14:18:58 -0700

> I fully agree. Drafts like this should not be a WG product.
oops. I hadn't noticed that it was draft-ietf-tls. I retract
my previous disagreement and agree with Paul and David.

-Ekr

---

---

From: Pete Chown <[email-masked]>
Date: Thu, 5 Oct 2000 11:29:08 +0100

> http://www.ietf.org/internet-drafts/draft-ietf-tls-camellia-00.txt

I've just noticed that this draft uses the same ciphersuite numbers as
the AES draft.  I don't mind changing the numbers I am using, but
whatever happens we mustn't forget!

Personally I wonder whether Camellia is of wide enough interest to
merit an RFC.  I think parts of the introduction could do with changes
as well:

> However, the TLS Protocol Version 1.0 [4] currently does not support
> cipher suites including 128-bit block ciphers that offer a high
> level of security and performance.

I hope people don't mind me "selling" my own draft here!  IMHO while
this is true, it is better addressed by adding AES ciphersuites.
Camellia is patented and hasn't had anything like the same amount of
cryptanalytic effort.

> An optimized implementation of Camellia in assembly language can
> encrypt on a Pentium III (800MHz) at the rate of more than 276 Mbits
> per second, which is much faster than the speed of an optimized DES
> implementation.

Certainly -- any modern cipher ought to be faster than DES.  How does
it compare with AES or RC4?

-- 
Pete

---

---

From: Peter W <[email-masked]>
Date: Thu, 5 Oct 2000 07:59:07 -0400

On Thu, Oct 05, 2000 at 11:29:08AM +0100, Pete Chown wrote:
> merit an RFC.

> Camellia is patented and hasn't had anything like the same amount of

We don't need it, we're not sure we can trust it, and we can't freely implement it.

Somewhere in there is a sufficient reason to abandon Camellia. ;-)

-Peter

-- 
This fall, taxpaying American citizens will elect voting representatives to
the US Congress. Except for those in Washington, DC. http://www.dcvote.org/

---

---

From: David Hopwood <[email-masked]>
Date: Fri, 06 Oct 2000 01:13:20 +0100

-----BEGIN PGP SIGNED MESSAGE-----

> > http://www.ietf.org/internet-drafts/draft-ietf-tls-camellia-00.txt
[...]
> it compare with AES or RC4?

http://www.tml.hut.fi/~helger/aes/table.html

  10-round Rijndael is 441.4 Mbps on an 800 MHz PIII.
  14-round Rijndael is about 315 Mbps.

RC4 is much faster still.

- -- 

---

---

From: Shiho MORIAI <[email-masked]>
Date: Fri, 06 Oct 2000 15:31:15 JST

Thank you very much for many comments about the Internet-Draft
http://www.ietf.org/internet-drafts/draft-ietf-tls-camellia-00.txt.

I will update the Internet-Draft as follows soon.

* Status of this Memo

> with Section 10 of RFC2026, and the author does not provide the
> IETF with any rights other than to publish as an Internet-Draft.

The statement above was inadequate for a WG Internet-Draft.  This is
my mistake.  Sorry.

* Intellectual Property Statement

The intellectual property statement regarding royalty-free license is
now under review.  The current intellectual property statement will be
updated before the draft is expired.

* The number of ciphersuites

Since Camellia supports three key sizes, 128, 192, and 256 bits,
similarly to the AES, I simply defined ciphersuites for Camellia with
each key size.  So there are 18 ciphersuites in total.  However, I
will define only necessary ciphersuites following the AES
ciphersuites.  I also remove a DH-anon ciphersuite, since I just
followed the 3DES ciphersuites in RFC2246.

I don't mind changing the numbers I am using.  > Pete Chown
The collision of the ciphersuite numbers just happened accidentally.
Both of the internet-drafts were submitted almost at the same time.

* Advantage of Camellia

As is written in the Internet-Draft and I told at the last IETF
meeting, Camellia is suitable for both software and hardware
implementations.  The TLS protocol will be implemented on a wide range
of platforms including restricted-space environments.  DES and Triple
DES have very small hardware (within 10Kgates), which perfectly meet
the current market requirements in wireless cards, for instance, where
low power consumption is a mandatory condition.

As far as the designers know, Camellia is a 128-bit block cipher that
can be an alternative for Triple DES from hardware viewpoint: a small
number of gate counts and low power consumption.  The encryption and
decryption procedures of Camellia are symmetric, that is, they are the
same without the order of subkeys, while for Rijndael implementing
both encryption and decryption requires roughly double the area needed
for encryption alone.

Also Camellia establishes high software performance in modern PC
processors in the same level as that of AES finalists.  We hence
believe that Camellia is worthy of being included in ciphersuites for
the TLS protocol.

The performance shown in the Internet-Draft leaves room for further
optimizations; we expect it will achieve around 300 cycles/block
(about 341.3 Mbps on an 800 MHz PIII), although it will not be
superior to Rijndael on this platform. > David Hopwood

As Pete Chown said, certainly, Camellia hasn't had the same amount of
cryptanalytic effort as AES, but Camellia was designed by experts of
cryptanalysis and evaluated by some external experts, too.  Camellia
is designed based on the techniques used in E2 and MISTY.  E2 was
evaluated during the Round 1 public evaluation period of the AES
development effort, and there were no major attacks found.  Camellia
was presented at SAC and CRYPTO this summer and was also submitted to
NESSIE project.  Its high level of security will be recognized soon.

Anyway, we need alternative algorithms for TLS in terms of resiliency,
as is discussed in the NIST's report on the development of the AES.  I
hope Camellia will be a good choice.

Best regards,
Shiho Moriai <[email-masked]>

---